From pkyzivat@cisco.com Mon Feb 1 09:29: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 D6A1328C17C for ; Mon, 1 Feb 2010 09:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 sqoaXB0BkE3C for ; Mon, 1 Feb 2010 09:29:08 -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 E44C728C165 for ; Mon, 1 Feb 2010 09:29:08 -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: ApoEAN6eZkutJV2d/2dsb2JhbADEDZcFhEUE X-IronPort-AV: E=Sophos;i="4.49,384,1262563200"; d="scan'208";a="294615605" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-1.cisco.com with ESMTP; 01 Feb 2010 17:29:43 +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 o11HThXw001542; Mon, 1 Feb 2010 17:29:43 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); Mon, 1 Feb 2010 11:29:43 -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, 1 Feb 2010 11:29:42 -0600 Message-ID: <4B670F85.4030808@cisco.com> Date: Mon, 01 Feb 2010 12:29:41 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2010 17:29:42.0813 (UTC) FILETIME=[23EAD4D0:01CAA364] Cc: "martini@ietf.org" , Hadriel Kaplan 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 17:29:10 -0000 Christer Holmberg wrote: > Hi, > >> 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". > > 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 beg to differ. The contact address is the ultimate target. There have been many documents pointing that out. And as long as you register each AOR independently it can be handled very cleanly. > I also think it is a very "clumsy" solution, when you mandate a 1-to-1 mapping of the R-URI/Contact userpart values (maybe it could also have security impacts). Its clumsy precisely because of implicit registration. Adam's proposal provided a way to do that mapping under the control of the recipient so that only expected contact addresses are used. > 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 explicitly (eventhough a wildcard mechanism is used) registers with the SIP network. The only clean way to treat the pbx as a single address is via loose routing. But there are issues with establishing loose routing tables via REGISTER. Thanks, Paul > Regards, > > Christer > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From bernard_aboba@hotmail.com Mon Feb 1 13:07: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 2893328C1CF for ; Mon, 1 Feb 2010 13:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 0O2i5pqWfEjo for ; Mon, 1 Feb 2010 13:07:23 -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 E3FCD3A6874 for ; Mon, 1 Feb 2010 13:07:22 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.73]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 13:07:58 -0800 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Dean Willis'" Date: Mon, 1 Feb 2010 13:07:57 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAA33F.93314FB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acqjgj4dWzkjAi2xSJW4yW6GRGwFYw== Content-Language: en-us X-OriginalArrivalTime: 01 Feb 2010 21:07:58.0273 (UTC) FILETIME=[A16B7310:01CAA382] Cc: martini@ietf.org Subject: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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 21:07:28 -0000 ------=_NextPart_000_0007_01CAA33F.93314FB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Why couldn't this approach also be used to register sip:+1972519XXX@sp.com and map it to sip:192519XXX@pbx.org or sip:192519XXX@10.1.2.3 ? Is it just the issue of the PBX proving that it actually owns pbx.org? Dean Willis said: " 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 at 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 at pbx.org ". If a call arrives at SSP for "tel:+19725199190" or "sip:+19725199190 at ssp.com;user=phone ", the SSP can contact-route the request to "sip:19725199190 at 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 at 10.1.2.3"." ------=_NextPart_000_0007_01CAA33F.93314FB0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Why = couldn’t this approach also be used to register sip:+1972519XXX@sp.com and map it to = sip:192519XXX@pbx.org or sip:192519XXX@10.1.2.3 = ?

 

Is it just the issue of the PBX proving that it = actually owns pbx.org? 

 

Dean Willis = said:

 

“

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 at 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 at pbx.org ".

 

If a call arrives = at SSP for "tel:+19725199190" or "sip:+19725199190 at = ssp.com;user=3Dphone ", the SSP can contact-route the request to = "sip:19725199190 at 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 at = 10.1.2.3".”

------=_NextPart_000_0007_01CAA33F.93314FB0-- From HKaplan@acmepacket.com Mon Feb 1 13: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 CA4993A69B3 for ; Mon, 1 Feb 2010 13:23:43 -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 FCPoddaVIMGW for ; Mon, 1 Feb 2010 13:23:42 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B62983A68B8 for ; Mon, 1 Feb 2010 13:23: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; Mon, 1 Feb 2010 16:24:15 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 1 Feb 2010 16:24:15 -0500 From: Hadriel Kaplan To: Paul Kyzivat , Christer Holmberg Date: Mon, 1 Feb 2010 16:23:52 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjZDaFr3agJBtQR+2L9xkUwA9uZQAHug5Q Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <4B670F85.4030808@cisco.com> In-Reply-To: <4B670F85.4030808@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-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 21:23:44 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, February 01, 2010 12:30 PM > To: Christer Holmberg >=20 > The only clean way to treat the pbx as a single address is via loose > routing. But there are issues with establishing loose routing tables via > REGISTER. Why does the method name impact the ability to establish a loose routing ta= ble? If the method was FOOBAR, would it suddenly be ok to route to AoR's using p= ath info learned from FOOBAR as a loose-route set? ISTM there is a distinction between the REGISTER method transaction updatin= g a database, and the request routing mechanism based on the info in that d= atabase. =20 -hadriel From pkyzivat@cisco.com Mon Feb 1 13:51: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 D2C403A68B8 for ; Mon, 1 Feb 2010 13:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 GecomEq8RrB7 for ; Mon, 1 Feb 2010 13:51:35 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 284593A6824 for ; Mon, 1 Feb 2010 13:51:35 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFbbZkurRN+K/2dsb2JhbADCc5c4hEUE X-IronPort-AV: E=Sophos;i="4.49,385,1262563200"; d="scan'208";a="143892301" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2010 21:52:10 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o11LqA3k001362; Mon, 1 Feb 2010 21:52:10 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, 1 Feb 2010 15:52:10 -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, 1 Feb 2010 15:52:09 -0600 Message-ID: <4B674D0A.3030104@cisco.com> Date: Mon, 01 Feb 2010 16:52:10 -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> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <4B670F85.4030808@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2010 21:52:09.0958 (UTC) FILETIME=[CDF27860:01CAA388] 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 21:51:35 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, February 01, 2010 12:30 PM >> To: Christer Holmberg >> >> The only clean way to treat the pbx as a single address is via loose >> routing. But there are issues with establishing loose routing tables via >> REGISTER. > > Why does the method name impact the ability to establish a loose routing table? > > If the method was FOOBAR, would it suddenly be ok to route to AoR's using path info learned from FOOBAR as a loose-route set? > > ISTM there is a distinction between the REGISTER method transaction updating a database, and the request routing mechanism based on the info in that database. I am not fundamentally opposed to this approach. But the same thing that makes REGISTER attractive (e.g. Path and Service-Route) raises questions of how those will work with loose routing. It can probably be made to work, but has it been fully understood? Thanks, Paul From adam@nostrum.com Mon Feb 1 15:45: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 59BAB28C0E4 for ; Mon, 1 Feb 2010 15:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 JhKMOAvtTA6G for ; Mon, 1 Feb 2010 15:45:10 -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 A457928C1D8 for ; Mon, 1 Feb 2010 15:45:09 -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 o11Njf61052318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Feb 2010 17:45:41 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6767A4.8000008@nostrum.com> Date: Mon, 01 Feb 2010 17:45: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: "martini@ietf.org" Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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 23:45:12 -0000 The more we talk about this, the further apart opinions seem to get. There appears to be a lot of ocean boiling going on right now, such that even when we can decide on a fairly narrow scope ("phone numbers only"), the system behavior that people expect appears to vary literally from person to person.

I'm going to try to do something like I did before with the diagrams, this time focusing on just what happens for E.164 numbers. I'll continue with using the same dead companies as before (CentricVoice as the SSP, and Pan-Am as the PBX).

In particular, I'm assuming that the tentative (albeit far from unanimous) agreement to do an initial batch of work towards E.164 numbers means that these kinds of use cases are not under discussion at the moment:
<Out Of Scope>

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:not-a-number@centricvoice.com |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:some-other-string@pan-am.com  |
    |                                  |--------------------------------->|


Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:not-a-number@pan-am.com       |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:some-other-string@pan-am.com  |
    |                                  |--------------------------------->|
</Out Of Scope>

So, ignoring those, we seem to still have a huge disconnect on what the SSP needs to be able to do as a result of the MARTINI operations. Now, one of the nice things we get from E.164 numbers is that usernames now become unique. We can specify transformations such that the username that arrives at the SSP stays the same as it passes through the SSP. Unlike my earlier examples, I'm going to assume that limiting to E.164 enables this kind of trivial transformation. Not in the *general* case, of course -- only for MARTINI-routed E.164 numbers.

As you read through these, try to place each use case in one of the following categories:
  1. This use case by itself is sufficient for the architecture {I am/my customers are} trying to deploy

  2. This use case is necessary for the architecture {I am/my customers are} trying to deploy, but requires other use cases also.

  3. This use case is neither necessary nor sufficient for the architecture {I am/my customers are} trying to deploy.

Frankly, I would expect almost everyone will be able to place each use case in category #1. All of these solutions certainly allow the PBX to figure out who the call is supposed to be sent to, and that appears to be the key criteria for the inbound messages.


================
Use Case 1
================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.
RFC3263 for "pan-am.com" is not relevant.

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:+12145550105@centricvoice.com |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:+12145550105@pan-am.com       |
    |                                  |--------------------------------->|


In this use case, the SSP receives a URI indicating its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having received information from Pan-Am about its PBX's IP address, it changes the domain to "pan-am.com," keeps the user ID, ignores RFC 3263 procedures, and sends the request to the MARTINI-registered IP address it has for Pan-Am.

The key drawback for this use case is the disregard for RFC3263 procedures.


================
Use Case 2
================

RFC3263 for "pan-am.com" resolves to the CentricVoice servers.


Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:+12145550105@pan-am.com       |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:+12145550105@pan-am.com       |
    |                                  |--------------------------------->|


In this use case, the SSP receives a URI indicating the domain for pan-am.com. Having received information from Pan-Am about its PBX's IP address, it leaves the Request-URI alone, ignores RFC 3263 procedures, and sends the request to the MARTINI-registered IP address it has for Pan-Am.

Note that this use case is predicated on an external entity -- something on the other side of the "Internet" cloud -- being able to take the E.164 number "+12145550105" and figure out that it needs to go to the domain "pan-am.com". I emphasize this because I know some people are interested in models in which is tenable to track "phone number to SSP" mapping, while the relatively larger number of "phone number to end customer" mappings might be unpalatable.

The key drawbacks for this use case are:
  1. The disregard for RFC3263 procedures
  2. Ambiguity around which SIP nodes are "responsible for" pan-am.com (in the RFC 3261 sense of that word). Cullen had a litmus test for this: is CentricVoice allowed to redirect calls for pan-am.com to a voicemail server or answering service?

Given that 3261 lacks a formal description of "responsible for," we can potentially define the problem of "responsible for" away (as Keith has proposed) -- but I'm pretty certain it's not within MARTINI's scope to clarify the terms appearing in RFC 3261. I think that would need to go back to DISPATCH, and I doubt we want to wait for such an effort to complete.


================
Use Case 3
================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:+12145550105@centricvoice.com |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:+12145550105@192.168.17.25    |
    |                                  |--------------------------------->|


In this use case, the SSP receives a request for its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having received information from Pan-Am about its PBX's IP address, it changes the domain to that registered IP address (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 procedures, and sends the request to the resulting host (192.168.17.25).

This use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrations (even though it is functionally identical to the model deployed for single registrations).


================
Use Case 4
================

RFC3263 for "pan-am.com" resolves to the CentricVoice servers.

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:+12145550105@pan-am.com       |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:+12145550105@192.168.17.25    |
    |                                  |--------------------------------->|

In this use case, the SSP receives a URI indicating the domain for pan-am.com. Having received information from Pan-Am about its PBX's IP address, it changes the domain to that registered IP address (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 procedures, and sends the request to the resulting host (192.168.17.25).

Like use case 3, this use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrations (even though it is functionally identical to the model deployed for single registrations). However, it is predicated on an external entity -- something on the other side of the "Internet" cloud -- being able to take the E.164 number "+12145550105" and figure out that it needs to go to the domain "pan-am.com".


================
Use Case 5
================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:+12145550105@centricvoice.com |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |tel:+12145550105                  |
    |                                  |--------------------------------->|


In this use case, the SSP receives a URI indicating its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. It changes the R-URI to a tel: URI containing only the E.164 number in question. Having received information from Pan-Am about its PBX's IP address, it sends the request to the resulting host (192.168.17.25). Since the URI in question is a TEL URI, RFC3263 issues are avoided altogether, eliminating any alt-root considerations.

The major drawback to this use case is that it (likely) requires the ability to register TEL URIs, which is currently normatively forbidden by RFC 3261. While this is tractable, it would require companion work in SIPCORE to relax this normative requirement. It also would likely require more mechanism than other approaches, since we're effectively adding on a new URI-to-host address resolution procedure.

================
Use Case 5a
================

A variation on Use Case 5, this use case ends up with a R-URI of the PBX's lead number, with an extension parameter that indicates the desired extension on the PBX:

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:+12145550105@centricvoice.com |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |tel:+12145550100;extension=1214555|
    |                                  |                              0105|
    |                                  |--------------------------------->|


This is effectively the exact same procedure as Use Case 5; however, it may make contact registration somewhat easier (depending on the exact mechanism used to communicate domain IP addresses).


================
Use Case 6
================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:+12145550105@centricvoice.com |                                  |
    |--------------------------------->|INVITE                            |
    |                                  |sip:+12145550105@centricvoice.com |
    |                                  |Route: <sip:pbx@192.168.17.25>    |
    |                                  |--------------------------------->|

In this example, In this use case, the SSP receives a URI indicating its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. It pushes the MARTINI-registered contact into the route set, leaves the Request-URI unmodified, invokes RFC 3263 procedures (on the Route) and sends the request to the resulting host.

A key drawback to this use case is that it cannot be effected using REGISTER without radically changing the semantics of REGISTER (i.e., registering a path towards an AOR instead of a contact for an AOR). These changes necessarily require intermediaries who are a party to the REGISTER transaction (e.g., using Path and/or Service-Route) to understand these changed semantics, and would require the use of a Proxy-Require to avoid the ensuing problems. Using a method other than REGISTER eliminates this class of problems.

A second major drawback to this approach pertains to domain responsibility: unless the Pan-Am PBX is "responsible for" centricvoice.com, it is in violation of SIP routing procedures if it fails to route it back to CentricVoice: "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."  In practice, I imagine it wants to route it to one of its internal extensions.


================
Use Case 7
================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:+12145550105@centricvoice.com |                                  |
    |--------------------------------->|INVITE sip:pbx@192.168.17.25      |
    |                                  |History-Info: sip:+12145550105@cen|
    |                                  |                     tricvoice.com|  
    |                                  |--------------------------------->|


Similar to use case 6, except the SSP swaps out the registered Contact URI for the Request-URI, and squirrels the incoming R-URI (containing the phone number) away in a History-Info header field.

On the plus side, this looks a lot like normal proxy/registrar behavior. Drawbacks include defining concrete procedures around which History-Info entry to use (which is a problem the 4244bis draft is currently struggling with), especially in the case that there are intermediaries between the SSP and the PBX. We would also be creating a normative dependency on the 4244bis document, which may delay a final delivery of MARTINI work substantially.


======================================================================

Now, I've heard and read things that imply that each these use cases are under consideration by at least one person. I think we need to focus. Clearly just saying "phone numbers" is not sufficient. Look back over how you rated each of the use cases relative to the "sufficient," "necessary but not sufficient," and "neither necessary nor sufficient" criteria. I think you'll find that, if you were honest with yourself, all or most of these use cases fall into the first category. I'm not saying you *like* them all -- merely that they will get the job done, if push were to come to shove.

So, I think we need to pick one and work on the mechanism required to enable it. And I think we need to be vigilant against scope creep. As we get into mechanism, it will be overwhelmingly tempting to say, "oh, but we can add on Use Case X if we just do *this* small thing!" But those small things can spiral out of control.

All other things being equal, I have a strong preference for Use Case 3, as its only real drawback is that it varies from the demonstrably flawed [1] mechanism that showed up on the IETF's doorstep. Any other approach is going to require interested parties coming to consensus on the issues associated with the other use cases, and I think we've seen that won't be a very fast process.

/a

[1] Lest this offend anyone as being too general a criticism, I refer to the set of shortcomings enumerated here: http://www.ietf.org/mail-archive/web/martini/current/msg00412.html

From dean.willis@softarmor.com Mon Feb 1 17:23: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 617C43A693E for ; Mon, 1 Feb 2010 17:23:40 -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 SLCblBo4kl+c for ; Mon, 1 Feb 2010 17:23:39 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8B4223A6767 for ; Mon, 1 Feb 2010 17:23: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 o121OBRa023378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2010 19:24:13 -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: Mon, 1 Feb 2010 19:24:05 -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: Tue, 02 Feb 2010 01:23:40 -0000 On Jan 31, 2010, at 7:29 PM, Hadriel Kaplan wrote: > > So if I understand what you're proposing, on the wire the routed > request would look like draft-shaken or whatever except the real > registered Contact-URI is not inserted as a Route header. And the > description of the process taking place in the RP is that it is > doing rfc3261-style AoR->Contact resolution, instead of > "retargeting" to the domain/ip of the PBX. Right? > I believe that's correct. > 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. The problem with SIP URIs is: what domain would go in the To:? Clearly it has to be the domain of the SSP, for all of our domain- authority work to do what it is supposed to do. There are still some questions about the security implications of multiple registrations over one Outbound connection, but I'm thinking (hoping?) those could be resolved by a carefully worded applicability statement. -- Dean From dean.willis@softarmor.com Mon Feb 1 17: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 4E2AB3A69F8 for ; Mon, 1 Feb 2010 17:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-HP4ADlP3hn for ; Mon, 1 Feb 2010 17:27:43 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8785F3A69CA for ; Mon, 1 Feb 2010 17:27:43 -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 o121SDFg023444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2010 19:28:15 -0600 Message-Id: <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> From: Dean Willis To: Christer Holmberg 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: Mon, 1 Feb 2010 19:28:08 -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" , Hadriel Kaplan 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: Tue, 02 Feb 2010 01:27:44 -0000 On Feb 1, 2010, at 1:30 AM, Christer Holmberg wrote: >> > > 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'm using it for carrying the contact URI that I expect the proxy- registrar t retarget to. That's what REGISTER is SUPPOSED to do, > I also think it is a very "clumsy" solution, when you mandate a 1- > to-1 mapping of the R-URI/Contact userpart values (maybe it could > also have security impacts). Actually, I think it;s the only way to NOT have the security implications. We have here a single REGISTER that results in exactly the same set of AOR-Contact mappings that would result from a multiplicity of requests using REGISTER as speced in RFC 261. > > 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 explicitly (eventhough a wildcard mechanism is used) > registers with the SIP network. > Exactly. That's why this approach works. Absolutely nothing is "implicit", everything is explicit. But it has very little more overhead than the hackneyed implicit registrations, and entirely solves the "how does the PBX figure out which user" mess that happens if there is only one Contact for many different AORs. -- Dean From dean.willis@softarmor.com Mon Feb 1 17:42: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 51B293A687C for ; Mon, 1 Feb 2010 17:42:35 -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 0Ieq+Rbi1+gf for ; Mon, 1 Feb 2010 17:42:34 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7DDA13A6767 for ; Mon, 1 Feb 2010 17:42:34 -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 o121h7wF023599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2010 19:43:09 -0600 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <4B6767A4.8000008@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, 1 Feb 2010 19:43:02 -0600 References: <4B6767A4.8000008@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 01:42:35 -0000 On Feb 1, 2010, at 5:45 PM, Adam Roach wrote: I don't understand the difference between Cases 1 and 3. case 1 is a result of a registration using a contact with a domain name (which MUST resolve using RFC 3263 procedures) and case 3 is a result of registration of a contact with an IP address. "Having received information from Pan Am about its PBX's IP address" implies to me "registering with a To: @pan-am.com and a Contact: @ip- address". This implies that the DNS SIP SRV record for "@pan-am.com" points to CentricVoice's servers. The only thing that is "provisioned" is a translation mapping from "sip:number@CentricVoice.com " to "@sip:number@pan-am.com", followed by a contact-routing operation from "number@pan-am" to "number@contact-ip-address". So where is RFC 3263 being disregarded? -- Dean From dean.willis@softarmor.com Mon Feb 1 17:44: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 722DC3A687C for ; Mon, 1 Feb 2010 17:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 UVPDkYpsPR0e for ; Mon, 1 Feb 2010 17:44:36 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 798663A6767 for ; Mon, 1 Feb 2010 17:44:36 -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 o121jAGi023619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2010 19:45:11 -0600 Message-Id: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> From: Dean Willis To: Bernard Aboba In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Feb 2010 19:45:04 -0600 References: X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 01:44:37 -0000 On Feb 1, 2010, at 3:07 PM, Bernard Aboba wrote: > Why couldn=92t this approach also be used to register = sip:+1972519XXX@sp.com=20 > and map it tosip:192519XXX@pbx.org or sip:192519XXX@10.1.2.3 ? > > Is it just the issue of the PBX proving that it actually owns pbx.org? > Yes, I think this could work: You would have a To: of = "sip:1972519XXXX@ssp.com=20 " and a Contact of "sip:1972519XXX@10.1.2.3". It requires that PBX know how to remap its own users to @ssp.com =20 domain users. -- Dean From md3135@att.com Mon Feb 1 17:49: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 173CD3A68CE for ; Mon, 1 Feb 2010 17:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC4t6uDu4wOu for ; Mon, 1 Feb 2010 17:49:43 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 372CC3A6767 for ; Mon, 1 Feb 2010 17:49:42 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1265075417!27022237!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 12052 invoked from network); 2 Feb 2010 01:50:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Feb 2010 01:50:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o121oBJt028804 for ; Mon, 1 Feb 2010 20:50:11 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o121o2Gh028747 for ; Mon, 1 Feb 2010 20:50:03 -0500 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, 1 Feb 2010 20:50:05 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0582965C@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed work split: tackletelephone-numberregistration first Thread-Index: AcqjpwYRGITiEhjHSEu0BvtvaH6LAwAAvPZA References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> From: "DOLLY, MARTIN C (ATTLABS)" To: "Dean Willis" , "Christer Holmberg" Cc: Hadriel Kaplan , 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: Tue, 02 Feb 2010 01:49:44 -0000 Every user registering is not implementable. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, February 01, 2010 8:28 PM To: Christer Holmberg Cc: martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] Proposed work split: tackletelephone-numberregistration first On Feb 1, 2010, at 1:30 AM, Christer Holmberg wrote: >> > > I think that is wrong usage of the Contact header. You more or less =20 > use it for carrying target information. We have other mechanisms for =20 > that. > I'm using it for carrying the contact URI that I expect the proxy-=20 registrar t retarget to. That's what REGISTER is SUPPOSED to do, > I also think it is a very "clumsy" solution, when you mandate a 1-=20 > to-1 mapping of the R-URI/Contact userpart values (maybe it could =20 > also have security impacts). Actually, I think it;s the only way to NOT have the security =20 implications. We have here a single REGISTER that results in exactly =20 the same set of AOR-Contact mappings that would result from a =20 multiplicity of requests using REGISTER as speced in RFC 261. > > Last, my understanding is still that, from a SIP network point of =20 > view, the PBX is seen as a single Contact, but in your solution =20 > every PBX user explicitly (eventhough a wildcard mechanism is used) =20 > registers with the SIP network. > Exactly. That's why this approach works. Absolutely nothing is =20 "implicit", everything is explicit. But it has very little more =20 overhead than the hackneyed implicit registrations, and entirely =20 solves the "how does the PBX figure out which user" mess that happens =20 if there is only one Contact for many different AORs. -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Mon Feb 1 18:29: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 AEEA33A6870 for ; Mon, 1 Feb 2010 18:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 h3YX6oCEW8Nu for ; Mon, 1 Feb 2010 18:29:01 -0800 (PST) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id 22F663A6851 for ; Mon, 1 Feb 2010 18:29:01 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 18:29:37 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 1 Feb 2010 18:29:38 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01CAA36C.835AEC90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqjr5FBfrykiyquTJCG1eQWFQxA3w== Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 02:29:37.0406 (UTC) FILETIME=[909971E0:01CAA3AF] 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: Tue, 02 Feb 2010 02:29:05 -0000 ------=_NextPart_000_0037_01CAA36C.835AEC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dean said: "The problem with SIP URIs is: what domain would go in the To:? Clearly it has to be the domain of the SSP, for all of our domain- authority work to do what it is supposed to do. There are still some questions about the security implications of multiple registrations over one Outbound connection, but I'm thinking (hoping?) those could be resolved by a carefully worded applicability statement." [BA] Yes, in the case you mentioned the domain in the To: would be the domain of the SSP, since only the Request-URI is remapped. As far as I can tell though, this doesn't lead to any of the problems referred to in the Problem Statement document. Are there other issues we should be thinking about? In terms of the security issues, I can understand the potential need to validate the remapping (e.g. you don't want to allow anyone to use "pbx.com" as a contact domain). But that concern exists for single-AOR registration as well as multiple. Is the concern that different AORs could be mapped to different contact domains and that this could intermingle requests among different "virtual PBXes"? If so, then each "virtual PBX" can just use its own separate connection, no? ------=_NextPart_000_0037_01CAA36C.835AEC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dean said:

 

“The problem with SIP URIs is: what domain would go in the To:? Clearly it = has to be the domain of the SSP, for all of our domain- authority work to do what = it is supposed to do.

 

There are still some questions about the security implications of multiple = registrations over one Outbound connection, but I'm thinking (hoping?) those could be resolved by a carefully worded applicability = statement.”

 

[BA]  Yes, in the case you mentioned the = domain in the To: would be the domain of the SSP, since only the Request-URI is remapped.   As far as I can tell though, this doesn’t = lead to any of the problems referred to in the Problem Statement document.  = Are there other issues we should be thinking about?

 

In terms of the security issues, I can understand = the potential need to validate the remapping (e.g. you don’t want to = allow anyone to use “pbx.com” as a contact domain).  But that concern exists for single-AOR registration as well as multiple.  =  Is the concern that different AORs could be mapped to different contact = domains and that this could intermingle requests among different “virtual = PBXes”?   If so, then each “virtual PBX” can just use its own separate = connection, no?

------=_NextPart_000_0037_01CAA36C.835AEC90-- From dean.willis@softarmor.com Mon Feb 1 18:35: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 27FF83A687A for ; Mon, 1 Feb 2010 18:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 yHn-vpSXGYXO for ; Mon, 1 Feb 2010 18:35:05 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 621B63A69F6 for ; Mon, 1 Feb 2010 18:35:05 -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 o122ZYRC024006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2010 20:35:36 -0600 Message-Id: <7EF5AC71-4E62-4731-B2F9-C7CDDBCEE98E@softarmor.com> From: Dean Willis To: "DOLLY, MARTIN C (ATTLABS)" In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0582965C@gaalpa1msgusr7e.ugd.att.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, 1 Feb 2010 20:35:28 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> <14C85D6CCBE92743AF33663BF5D24EBA0582965C@gaalpa1msgusr7e.ugd.att.com> X-Mailer: Apple Mail (2.936) Cc: Hadriel Kaplan , 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: Tue, 02 Feb 2010 02:35:06 -0000 On Feb 1, 2010, at 7:50 PM, DOLLY, MARTIN C (ATTLABS) wrote: > Every user registering is not implementable. > I didn't suggest they would. I suggested PBX would use one wild-card registration which would have the effect of registering a whole bunch of users with a single request. But the effect on the registration database is the same as it would be if every user registered separately: we get one (or more) Contact for each AOR, and one AOR for each phone number. There are many different possible syntaxes for the "wild-card" effect. My usage of X as a numeric-placeholder is just an example. The syntax from Adam's draft is probably better, just slightly harder to explain in a singe email. -- Dean From md3135@att.com Mon Feb 1 19:04: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 DE4813A6842 for ; Mon, 1 Feb 2010 19:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zytdYK4gaJNQ for ; Mon, 1 Feb 2010 19:04:40 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id ED7093A67D9 for ; Mon, 1 Feb 2010 19:04:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-4.tower-161.messagelabs.com!1265079914!21279242!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28477 invoked from network); 2 Feb 2010 03:05:15 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Feb 2010 03:05:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o12358uj023452 for ; Mon, 1 Feb 2010 22:05:08 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o12352J9023409 for ; Mon, 1 Feb 2010 22:05:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 1 Feb 2010 22:05:08 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D14@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed work split:tackletelephone-numberregistration first Thread-Index: AcqjsHBvUsDt7D+tSE2VOI9DwcQPoAABBbQT From: "DOLLY, MARTIN C (ATTLABS)" To: Cc: martini@ietf.org, HKaplan@acmepacket.com 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: Tue, 02 Feb 2010 03:04:41 -0000 T2ssIEkgdGhvdWdodCB5b3Ugc3RhdGVkIGV2ZXJ5b25lIHJlZ2lzdGVycw0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcgPG1hcnRp bmktYm91bmNlc0BpZXRmLm9yZz4NClRvOiBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpDQpDYzog SGFkcmllbCBLYXBsYW4gPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+OyBtYXJ0aW5pQGlldGYub3Jn IDxtYXJ0aW5pQGlldGYub3JnPg0KU2VudDogTW9uIEZlYiAwMSAyMTozNToyOCAyMDEwDQpTdWJq ZWN0OiBSZTogW21hcnRpbmldIFByb3Bvc2VkIHdvcmsgc3BsaXQ6dGFja2xldGVsZXBob25lLW51 bWJlcnJlZ2lzdHJhdGlvbiBmaXJzdA0KDQoNCk9uIEZlYiAxLCAyMDEwLCBhdCA3OjUwIFBNLCBE T0xMWSwgTUFSVElOIEMgKEFUVExBQlMpIHdyb3RlOg0KDQo+IEV2ZXJ5IHVzZXIgcmVnaXN0ZXJp bmcgaXMgbm90IGltcGxlbWVudGFibGUuDQo+DQoNCkkgZGlkbid0IHN1Z2dlc3QgdGhleSB3b3Vs ZC4gSSBzdWdnZXN0ZWQgUEJYIHdvdWxkIHVzZSBvbmUgd2lsZC1jYXJkICANCnJlZ2lzdHJhdGlv biB3aGljaCB3b3VsZCBoYXZlIHRoZSBlZmZlY3Qgb2YgcmVnaXN0ZXJpbmcgYSB3aG9sZSBidW5j aCAgDQpvZiB1c2VycyB3aXRoIGEgc2luZ2xlIHJlcXVlc3QuDQoNCkJ1dCB0aGUgZWZmZWN0IG9u IHRoZSByZWdpc3RyYXRpb24gZGF0YWJhc2UgaXMgdGhlIHNhbWUgYXMgaXQgd291bGQgYmUgIA0K aWYgZXZlcnkgdXNlciByZWdpc3RlcmVkIHNlcGFyYXRlbHk6IHdlIGdldCBvbmUgKG9yIG1vcmUp IENvbnRhY3QgZm9yICANCmVhY2ggQU9SLCBhbmQgb25lIEFPUiBmb3IgZWFjaCBwaG9uZSBudW1i ZXIuDQoNClRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCBwb3NzaWJsZSBzeW50YXhlcyBmb3IgdGhl ICJ3aWxkLWNhcmQiIGVmZmVjdC4gIA0KTXkgdXNhZ2Ugb2YgWCBhcyBhIG51bWVyaWMtcGxhY2Vo b2xkZXIgaXMganVzdCBhbiBleGFtcGxlLiBUaGUgc3ludGF4ICANCmZyb20gQWRhbSdzIGRyYWZ0 IGlzIHByb2JhYmx5IGJldHRlciwganVzdCBzbGlnaHRseSBoYXJkZXIgdG8gZXhwbGFpbiAgDQpp biBhIHNpbmdlIGVtYWlsLg0KDQotLQ0KRGVhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbWFydGluaSBtYWlsaW5nIGxpc3QNCm1hcnRpbmlAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFydGluaQ0K From bernard_aboba@hotmail.com Mon Feb 1 19:38: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 9246C28C173 for ; Mon, 1 Feb 2010 19:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=-1.232, 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 xeEXpv26He5j for ; Mon, 1 Feb 2010 19:38:07 -0800 (PST) Received: from blu0-omc2-s8.blu0.hotmail.com (blu0-omc2-s8.blu0.hotmail.com [65.55.111.83]) by core3.amsl.com (Postfix) with ESMTP id DF00F28C138 for ; Mon, 1 Feb 2010 19:38:06 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.72]) by blu0-omc2-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 19:38:43 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 1 Feb 2010 19:38:42 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01CAA376.2955D5C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqjuTdAU2MMyefxSfiAu0vbANdqJA== Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 03:38:43.0391 (UTC) FILETIME=[37CC8CF0:01CAA3B9] 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: Tue, 02 Feb 2010 03:38:10 -0000 ------=_NextPart_000_0065_01CAA376.2955D5C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just a reminder that MARTINI Virtual Interim III is scheduled for 8 AM to 10 AM Pacific Time on February 9, 2010. This will be the final virtual Interim prior to IETF 77 in Anaheim. So that we have the best shot at having a productive meeting, we are asking that solution authors update their drafts. If you have comments/improvements/edits to the solution documents, please post them to the list with a Subject: line corresponding to the document in question. Also, if you'd like Agenda time at MARTINI Virtual Interim III, please send mail to Spencer or myself. If you are an SSP, or if you know an SSP, or even if you aren't one and don't know one but are willing to kidnap one and force them to attend Virtual Interim III, let us know. We anticipate discussion of some of the following topics: . Use cases. . SSP perspectives. . Solution updates. See you there! ------=_NextPart_000_0065_01CAA376.2955D5C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that MARTINI Virtual Interim III is scheduled for 8 AM to 10 AM Pacific Time on February 9, 2010.  =  This will be the final virtual Interim prior to IETF 77 in Anaheim. =

 

So that we have the best shot at having a = productive meeting, we are asking that solution authors update their = drafts.   If you have comments/improvements/edits to the solution documents, = please post them to the list with a Subject: line corresponding to the document in question. 

 

Also, if you’d like Agenda time at MARTINI = Virtual Interim III, please send mail to Spencer or myself.

 

If you are an SSP, or if you know an SSP, or even = if you aren’t one and don’t know one but are willing to kidnap one = and force them to attend Virtual Interim III, let us know.

 

We anticipate discussion of some of the following = topics:

 

·         Use cases.

·         SSP perspectives.

·         Solution updates.

 

See you there!

------=_NextPart_000_0065_01CAA376.2955D5C0-- From bernard_aboba@hotmail.com Mon Feb 1 20:04: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 1B9943A699A for ; Mon, 1 Feb 2010 20:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-1.672, BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619, 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 0z-KR31LJmBH for ; Mon, 1 Feb 2010 20:04:06 -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 4C8133A67A8 for ; Mon, 1 Feb 2010 20:04:06 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.73]) by blu0-omc2-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 20:04:42 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 1 Feb 2010 20:04:41 -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: AcqTtgDNJhhnr6gOQwy26APUGVMGAgQBtdcQ Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 04:04:42.0094 (UTC) FILETIME=[D8DBC0E0:01CAA3BC] 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: Tue, 02 Feb 2010 04:04: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:20100202T040440Z DESCRIPTION:When: Tuesday\, February 09\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: Cyberspace\n\nNote: The GMT offset ab ove does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~ *~*\n\nTopic: MARTINI WG Virtual Meeting \nDate: Tuesday\, February 9\, 20 10 \nTime: 8:00 am\, Pacific Standard Time (San Francisco\, GMT-08:00) \nM eeting Number: 969 465 025 \nMeeting Password: martini \n\n\n------------- ------------------------------------------ \nTo join the online meeting (N ow from iPhones too!) \n-------------------------------------------------- ----- \n1. Go to https://workgreen.webex.com/workgreen/j.php?ED=131322887& UID=1112097932&PW=NZjNiMTY2ODYx&RT=MiM0 \n2. Enter your name and email add ress. \n3. Enter the meeting password: martini \n4. Click "Join Now". \n\n To view in other time zones or languages\, please click the link: \nhttps: //workgreen.webex.com/workgreen/j.php?ED=131322887&UID=1112097932&PW=NZjNi MTY2ODYx&ORT=MiM0 \n\n---------------------------------------------------- --- \nTo join the audio conference only \n-------------------------------- ----------------------- \nTo receive a call back\, provide your phone numb er when you join the meeting\, or call the number below and enter the acce ss code. \nCall-in toll number (US/Canada): 1-408-792-6300 1-408-792-630 0 \nGlobal call-in numbers: https://workgreen.webex.com/workgreen/globalca llin.php?serviceType=MC&ED=131322887&tollFree=0 \n\nAccess code:969 465 02 5 \n\n------------------------------------------------------- \nFor assist ance \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 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)\, c lick this link: \nhttps://workgreen.webex.com/workgreen/j.php?ED=131322887 &UID=1112097932&ICS=MRS3&LD=1&RD=2&ST=1&SHA2=FKFrM/VXl6V1pDv1V4vEfINO/rCHP TwZP3yrb0IWfUc=&RT=MiM0 \n\n\nWebEx will automatically setup Meeting Manag er for Windows the first time you join a meeting. To save time\, you can s etup prior to the meeting by clicking this link: \nhttps://workgreen.webex .com/workgreen/meetingcenter/mcsetup.php \n\n\nThe playback of UCF (Univer sal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting\, please check whethe r you have the players installed on your computer by going to https://work green.webex.com/workgreen/systemdiagnosis.php \n\nSign up for a free trial of WebEx \nhttp://www.webex.com/go/mcemfreetrial \n\nhttp://www.webex.com \n DTEND:20100209T180000Z DTSTAMP:20100202T040440Z DTSTART:20100209T160000Z LAST-MODIFIED:20100202T040440Z LOCATION:Cyberspace ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:1 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: Cyberspace

\n\n

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

\n\n

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

\n\n

< SPAN LANG="en-us">Topic: MARTINI WG Virtual Mee ting
\nDate: Tuesday\, February 9\, 2010
\nTime: 8:00 am\, Pacific S tandard Time (San Francisco\, GMT-08:00)
\nMeeting Number: 969 465 025< BR>\nMeeting Password: martini
\n
\n
\n-------------------------- -----------------------------
\nTo join the online meeting (Now from iP hones too!)
\n-------------------------------------------------------\n1. Go to http s://workgreen.webex.com/workgreen/j.php?ED=131322887&\;UID=1112097932&a mp\;PW=NZjNiMTY2ODYx&\;RT=MiM0
\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 clic k the link:
\nhttps://workgreen.webex.com/workgreen/j.php?ED=131322887&\;UID=1112097 932&\;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/ Canada):  1-408-792-6300  1-408-792-6300
\nGlobal 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\, click "\;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 O utlook)\, 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/rCHPTwZP3yrb0IWfUc=&\;RT=MiM0
\n
\n
\n 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 c licking this link:
\nhttps://workgreen.webex.com/workgreen/mee tingcenter/mcsetup.php
\n
\n
\nThe playback of UCF (Universal Commu nications Format) rich media files requires appropriate players. To view t his type of rich media files in the meeting\, please check whether you hav e the players installed on your computer by going to https://workgreen. webex.com/workgreen/systemdiagnosis.php
\n
\nSign up for a free trial of WebEx
\n< /SPAN>htt p://www.webex.com/go/mcemfreetrial
\n
\nhttp://www.webex.com

\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-APPTSEQTIME:20100123T214031Z 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 Mon Feb 1 20:07: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 9DB743A69F1 for ; Mon, 1 Feb 2010 20:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-1.108, 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 OkCndslPl3sJ for ; Mon, 1 Feb 2010 20:07:00 -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 DBBC43A6A00 for ; Mon, 1 Feb 2010 20:06:59 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.72]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 20:07:36 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 1 Feb 2010 20:07:35 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01CAA37A.323DA9C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqjvUAoC6p4XycLR8a0U0hCDCdWkQ== Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 04:07:36.0304 (UTC) FILETIME=[40B21700:01CAA3BD] Subject: [martini] Conference parameters for 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: Tue, 02 Feb 2010 04:07:00 -0000 ------=_NextPart_000_0011_01CAA37A.323DA9C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Are available here: http://www.ietf.org/mail-archive/web/martini/current/msg00238.html ------=_NextPart_000_0011_01CAA37A.323DA9C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are available here:

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

 

 

------=_NextPart_000_0011_01CAA37A.323DA9C0-- From bernard_aboba@hotmail.com Mon Feb 1 20:20: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 612BF3A693E for ; Mon, 1 Feb 2010 20:20:03 -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, 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 61oGPtE8knms for ; Mon, 1 Feb 2010 20:19:58 -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 EE16C3A6A35 for ; Mon, 1 Feb 2010 20:19:57 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.72]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 20:20:34 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 1 Feb 2010 20:20:33 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CAA37C.02160470" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqjvw/+ZDz6rln0Rfe4Pk9on1so4Q== Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 04:20:34.0255 (UTC) FILETIME=[1063FDF0:01CAA3BF] Subject: [martini] MARTINI Virtual Interim III 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: Tue, 02 Feb 2010 04:20:03 -0000 ------=_NextPart_000_0016_01CAA37C.02160470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim III February 9, 2010 8 AM - 10 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00238.html Agenda 8 AM - 8:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Usage Scenarios (30 minutes) 8:10 AM - 8:40 AM PT MARTINI Usage Scenarios, TBD (30 minutes) Solution Updates (30 minutes) 8:40 AM - 8:55 AM PT, Revised MARTINI Up, Adam Roach (15 minutes) http://tools.ietf.org/html/draft-roach-martini-up 8:55 AM - 9:10 AM PT, MARTINI Shaken & Stirred Update, Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-stirred-domain-registration http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s Perspectives & Discussion (30 minutes) 9:10 AM - 9:20 AM PT Service Provider Perspective, TBD (10 minutes) 9:20 AM - 9:40 AM PT Discussion: Participants (20 minutes) Wrap-up (20 minutes) 9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes) 9:55 AM - 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_0016_01CAA37C.02160470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim III

February 9, 2010

8 AM – 10 AM Pacific Time

 

Conferencing Details:

 

Slide Presentations:  http://ww= w.drizzle.com/~aboba/MARTINI/Jan-Interim-III/

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

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

 

Agenda

 

8 AM - 8:10 AM PT:  = Preliminaries

     Conference = issues/debugging

     Agenda bash

 

Usage Scenarios (30 minutes)

 

8:10 AM – 8:40 AM  PT MARTINI Usage = Scenarios, TBD (30 minutes)

 

Solution Updates (30 minutes)

 

8:40 AM – 8:55 AM PT, Revised MARTINI Up, = Adam Roach (15 minutes)

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

 

8:55 AM – 9:10 AM PT, MARTINI Shaken & = Stirred Update, Hadriel Kaplan (15 minutes)

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

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

 

Perspectives & Discussion (30 = minutes)

 

9:10 AM – 9:20 AM  PT Service Provider Perspective, TBD (10 minutes)

9:20 AM – 9:40 AM PT Discussion:  = Participants (20 minutes)

 

Wrap-up (20 minutes)

 

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

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

 

------=_NextPart_000_0016_01CAA37C.02160470-- From bernard_aboba@hotmail.com Mon Feb 1 20:21: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 E344E3A6A5B for ; Mon, 1 Feb 2010 20:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-1.161, 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 Il3ItoIR5UPK for ; Mon, 1 Feb 2010 20:21:42 -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 1594F3A6A5C for ; Mon, 1 Feb 2010 20:21:42 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.73]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 20:22:18 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 1 Feb 2010 20:22: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: AcqTtgDNJhhnr6gOQwy26APUGVMGAgQCU0tQ Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 04:22:18.0507 (UTC) FILETIME=[4E8795B0:01CAA3BF] 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: Tue, 02 Feb 2010 04:21:43 -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:20100202T042217Z DESCRIPTION:When: Tuesday\, February 09\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: Cyberspace\n\nNote: The GMT offset ab ove does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~ *~*\n\nMARTINI Virtual Interim III\nFebruary 9\, 2010\n8 AM – 10 AM Paci fic Time\n\nConferencing Details: \n\nSlide Presentations: http://www.dri zzle.com/~aboba/MARTINI/Jan-Interim-III/\nJabber room: martini at jabber. ietf.org (Please join)\nDial in Audioconference and WebEx details: http: //www.ietf.org/mail-archive/web/martini/current/msg00238.html\n\nAgenda\n\ n8 AM - 8:10 AM PT: Preliminaries\n Conference issues/debugging\n Agenda bash\n\nUsage Scenarios (30 minutes)\n\n8:10 AM – 8:40 AM PT MA RTINI Usage Scenarios\, TBD (30 minutes)\n\nSolution Updates (30 minutes)\ n\n8:40 AM – 8:55 AM PT\, Revised MARTINI Up\, Adam Roach (15 minutes)\n http://tools.ietf.org/html/draft-roach-martini-up\n\n8:55 AM – 9:10 AM P T\, MARTINI Shaken & Stirred Update\, Hadriel Kaplan (15 minutes)\nhttp:// tools.ietf.org/html/draft-kaplan-martini-stirred-domain-registration\nhttp ://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registrations\ n\nPerspectives & Discussion (30 minutes)\n\n9:10 AM – 9:20 AM PT Servi ce Provider Perspective\, TBD (10 minutes)\n9:20 AM – 9:40 AM PT Discuss ion: Participants (20 minutes)\n\nWrap-up (20 minutes)\n\n9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes)\n9:55 AM – 10:00 AM PT Next Steps : WG Chairs & ADs (5 minutes)\n\n\n\nTopic: MARTINI WG Virtual Meeting \n Date: Tuesday\, February 9\, 2010 \nTime: 8:00 am\, Pacific Standard Time (San Francisco\, GMT-08:00) \nMeeting Number: 969 465 025 \nMeeting Passwo rd: martini \n\n\n------------------------------------------------------- \nTo join the online meeting (Now from iPhones too!) \n------------------- ------------------------------------ \n1. Go to https://workgreen.webex.co m/workgreen/j.php?ED=131322887&UID=1112097932&PW=NZjNiMTY2ODYx&RT=MiM0 \n2 . Enter your name and email address. \n3. Enter the meeting password: mart ini \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=13 1322887&UID=1112097932&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/Canada): 1-408-792-6300 1-408-792-6300 \nGlobal call-in numbers: https://workgre en.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=131322887&tollFr ee=0 \n\nAccess code:969 465 025 \n\n------------------------------------- ------------------ \nFor assistance \n------------------------------------ ------------------- \n1. Go to https://workgreen.webex.com/workgreen/mc \n 2. On the left navigation bar\, click "Support". \n\nYou can contact me at : \namorris at amsl.com \n 1-510-492-408 1 1-510-492-4081 \n\nTo update this meeting to your calendar program (for example Microsoft Outlook)\, click this link: \nhttps://workgreen.webex.c om/workgreen/j.php?ED=131322887&UID=1112097932&ICS=MRS3&LD=1&RD=2&ST=1&SHA 2=FKFrM/VXl6V1pDv1V4vEfINO/rCHPTwZP3yrb0IWfUc=&RT=MiM0 \n\n\nWebEx will au tomatically setup Meeting Manager for Windows the first time you join a me eting. 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 Communications Format) rich media files requires appropriate players. To view this type of rich media files in th e meeting\, please check whether you have the players installed on your co mputer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.p hp \n\nSign up for a free trial of WebEx \nhttp://www.webex.com/go/mcemfre etrial \n\nhttp://www.webex.com\n\n DTEND:20100209T180000Z DTSTAMP:20100202T042217Z DTSTART:20100209T160000Z LAST-MODIFIED:20100202T042217Z LOCATION:Cyberspace ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:2 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: Cyberspace

\n\n

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

\n\n

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

\n\n

MARTINI Virtu al Interim III

\n\n

February 9\, 2010

\n\n

8 AM – 10 AM Pacific Time

\n\n

Conferencing Detail s:

\n\n

Slide Presentations:  http://www.drizzle.com/~aboba/MAR TINI/Jan-Interim-III/

\n\n

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

\n\n

Dial in Audioc onference and WebEx details:   < A HREF="http://www.ietf.org/mail-archive/web/martini/current/msg00238.html ">http://www.ie tf.org/mail-archive/web/martini/current/msg00238.html

\n\n

Agenda

\n\n

8 AM - 8:10 AM PT:  Preliminar ies

\n\n

     Conference issues/debugging

\n\n

     Agenda bash

\n\n

Usage Scenarios (3 0 minutes)

\n\n

8:10 AM – 8:40 AM  PT MARTINI Usage Scenarios\, TBD (30 minute s)

\n\n

Solution Updates (30 minutes)

\n\n

8:40 AM – 8:55 AM PT\, Revised MARTINI Up\, Adam Roach (15 minutes)

\n\n

http://tools.ietf.or g/html/draft-roach-martini-up< /A>

\n\n

8:55 AM – 9:10 AM PT\, MARTINI Shaken &\; Stirred Updat e\, Hadriel Kaplan (15 minutes)

\n\n

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

\n\n

< SPAN LANG="en-us">http://tools.iet f.org/html/draft-kaplan-martini-shaken-implicit-registrations

\n\n

Perspectives &\; Discussi on (30 minutes)

\n\n

9:10 AM – 9:20 AM  PT Service Provider Perspective\, TBD (10 minutes)

\n\n

9:20 AM – 9:40 AM PT Discussion:  Participants (20 minutes)< /FONT>

\n\n

Wr ap-up (20 minutes)

\n\n

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

\n\n

9:55 AM – 10:00 AM PT   Next Steps:  WG Chairs &\; ADs (5 minutes)

\n\n

\n\n

< SPAN LANG="en-us">

\n\n

Topic: MARTINI WG Virtual Meeting
\nDate: Tuesday\, February 9\, 2010
\nTi me: 8:00 am\, Pacific Standard Time (San Francisco\, GMT-08:00)
\nMeeti ng Number: 969 465 025
\nMeeting Password: martini
\n
\n
\n--- ----------------------------------------------------
\nTo join the onli ne meeting (Now from iPhones too!)
\n---------------------------------- ---------------------
\n1. Go to https://workgreen.webex.com/workgreen/j.php?ED=13132288 7&\;UID=1112097932&\;PW=NZjNiMTY2ODYx&\;RT=MiM0
\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:
\n< /SPAN> https://workgreen.webex.com/workgreen/j.php?ED=131 322887&\;UID=1112097932&\;PW=NZjNiMTY2ODYx&\;ORT=MiM0< /SPAN>
\n
\n-- -----------------------------------------------------
\nTo join the aud io conference only
\n-------------------------------------------------- -----
\nTo receive a call back\, provide your phone number when you joi n the meeting\, or call the number below and enter the access code.
\nC all-in toll number (US/Canada):  1-408-792-6300  1-408-792-6300
\nGlo bal call-in numbers: http s://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&\;ED= 131322887&\;tollFree=0< SPAN LANG="en-us">
\n
\nAccess code:969 465 025
\n
\n---- ---------------------------------------------------
\nFor assistance
\n-------------------------------------------------------
\n1. Go to https://workgre en.webex.com/workgreen/mc< SPAN LANG="en-us">
\n2. On the left navigation bar\, click "\; 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/workg reen/j.php?ED=131322887&\;UID=1112097932&\;ICS=MRS3&\;LD=1&\;R D=2&\;ST=1&\;SHA2=FKFrM/VXl6V1pDv1V4vEfINO/rCHPTwZP3yrb0IWfUc=&\; RT=MiM0
\n
\n
\nWebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time\, you can setup pr ior to the meeting by clicking this link:
\nhttps://workgreen. webex.com/workgreen/meetingcenter/mcsetup.php
\n
\n
\nThe playback of UCF (Universal Communications Format) rich media files requires appropr iate players. To view this type of rich media files in the meeting\, pleas e check whether you have the players installed on your computer by going t o https://workgreen.webex.com/workgreen/systemdiagnosis.php< /SPAN>
\n
\nSi gn up for a free trial of WebEx
\nhttp://www.webex.com/go/mcemfreetrial
\n
\n http://www.webex.com

\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:20100202T040440Z 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 Mon Feb 1 21:51: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 400083A6A64 for ; Mon, 1 Feb 2010 21:51: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=[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 5TNNWJ+0sd54 for ; Mon, 1 Feb 2010 21:51: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 D1ADE3A6A07 for ; Mon, 1 Feb 2010 21:51: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 o125pn0b078353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 23:51:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B67BD76.2030408@nostrum.com> Date: Mon, 01 Feb 2010 23:51: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: <4B6767A4.8000008@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] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 05:51:19 -0000 On 2/1/10 19:43, Feb 1, Dean Willis wrote: > I don't understand the difference between Cases 1 and 3. case 1 is a > result of a registration using a contact with a domain name (which > MUST resolve using RFC 3263 procedures) and case 3 is a result of > registration of a contact with an IP address. I think there's some confusion here, and it may well by my fault. When I asserted "RFC3263 for 'pan-am.com' is not relevant," I should have followed up by indicating that RFC3263 resolution procedures for "pan-am.com" cannot be assumed to result in an IP address belonging to Pan-Am's PBX. So the second INVITE (the one from CentricVoice to Pan-Am) cannot be routed according to RFC 3263 resolution rules. Make sense? /a From dean.willis@softarmor.com Mon Feb 1 21:59: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 85B843A6A60 for ; Mon, 1 Feb 2010 21:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 NMZX9AIgXmRq for ; Mon, 1 Feb 2010 21:59:32 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 670F93A699D for ; Mon, 1 Feb 2010 21:59: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 o12606er025476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Feb 2010 00:00:08 -0600 Message-Id: From: Dean Willis To: Bernard Aboba In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Feb 2010 00:00:01 -0600 References: 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: Tue, 02 Feb 2010 05:59:33 -0000 On Feb 1, 2010, at 8:29 PM, Bernard Aboba wrote: > > [BA] Yes, in the case you mentioned the domain in the To: would be =20= > the domain of the SSP, since only the Request-URI is remapped. As =20= > far as I can tell though, this doesn=92t lead to any of the problems =20= > referred to in the Problem Statement document. Are there other =20 > issues we should be thinking about? I have not yet thought through P-Associated-URI in the context of the =20= proposal. I'm pretty sure it blows chunks (dramatically doesn't work), =20= but I might be wrong. Path, Service-Route, and Outbound work =20 unmodified, AFAIK, with the restriction that the vectors are the same =20= for all contacts resulting from a single request. > > In terms of the security issues, I can understand the potential need =20= > to validate the remapping (e.g. you don=92t want to allow anyone to =20= > use =93pbx.com=94 as a contact domain). But that concern exists for =20= > single-AOR registration as well as multiple. Yes, the authorization problem is essentially the same as with =20 individual registration. Authorization is a provisioning problem, not =20= a registration problem. The SSP must be able to answer the question =20 "Is the identity asserted by the PBX allowed to register for every AOR =20= produced by expansion of the request?" Further, the SSP must be able =20 to authenticate the identity of the PBX. I believe the syntax I proposed works with an unmodified digest =20 authentication as well as mutual TLS and RFC 3274 (asserted by PBX). =20 I'm not certain about Adam's syntax with digest. > Is the concern that different AORs could be mapped to different =20 > contact domains and that this could intermingle requests among =20 > different =93virtual PBXes=94? If so, then each =93virtual PBX=94 = can just =20 > use its own separate connection, no? Yes, that's right. The PBX would need something like a virtual-domain =20= table showing which domain is in-use for each connection. If Outbound =20= is used with TLS, this is easy; for "conventional SIP", we need a =20 virtual-domain demuxer within the user-part of the contact, and such =20 could be constructed by PBX using either of the two syntaxes so far =20 suggested. The other open question is what, if any, security implications arise =20 from having multiple registrations sharing the same "flow" in =20 outbound. I cant see any as yet, but that doesn't mean they aren't =20 there. Obviously, PBX has the ability to spoof/mix/match/whatever the =20= identities of users on the PBX; it is the trust anchor for identity =20 assertion within the set of identities the PBX is authorized to =20 express, much as any UNIX host could lie about identd. -- Dean From bernard_aboba@hotmail.com Mon Feb 1 22:01: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 838373A6A72 for ; Mon, 1 Feb 2010 22:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.180, 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 hby8a4OU94XM for ; Mon, 1 Feb 2010 22:01:55 -0800 (PST) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by core3.amsl.com (Postfix) with ESMTP id 4FFA63A6A69 for ; Mon, 1 Feb 2010 22:01:55 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.72]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 22:02:31 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 1 Feb 2010 22:02:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01CAA38A.40616720" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqjvw/+ZDz6rln0Rfe4Pk9on1so4QADes8g Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 06:02:31.0662 (UTC) FILETIME=[4EA638E0:01CAA3CD] Subject: [martini] MARTINI Virtual Interim III Agenda -- 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, 02 Feb 2010 06:01:59 -0000 ------=_NextPart_000_009A_01CAA38A.40616720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim III February 9, 2010 8 AM - 10 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00238.html Agenda 8 AM - 8:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Usage Scenarios (30 minutes) 8:10 AM - 8:40 AM PT MARTINI Usage Scenarios, TBD (30 minutes) Solution Updates (30 minutes) 8:40 AM - 8:55 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (15 minutes) http://tools.ietf.org/html/draft-roach-martini-gin 8:55 AM - 9:10 AM PT, MARTINI Shaken & Stirred Update, Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-stirred-domain-registration http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s Perspectives & Discussion (30 minutes) 9:10 AM - 9:20 AM PT Service Provider Perspective, Martin Dolly (10 minutes) 9:20 AM - 9:40 AM PT Discussion: Participants (20 minutes) Wrap-up (20 minutes) 9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes) 9:55 AM - 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_009A_01CAA38A.40616720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim = III

February 9, = 2010

8 AM – 10 AM = Pacific Time

 

Conferencing Details: =

 

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

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/msg00238.html

 

Agenda

 

8 AM - 8:10 AM = PT:  Preliminaries

     Conference issues/debugging

     Agenda bash

 

Usage Scenarios (30 = minutes)

 

8:10 AM – 8:40 = AM  PT MARTINI Usage Scenarios, TBD (30 minutes)

 

Solution Updates (30 = minutes)

 

8:40 AM – 8:55 AM = PT, MARTINI with Globally Identifiable Numbers, Adam Roach (15 = minutes)

http://tools.ietf.org/html/draft-roach-martini-gin<= /span>

 

 

8:55 AM – 9:10 AM = PT, MARTINI Shaken & Stirred Update, Hadriel Kaplan (15 = minutes)

http://tools.ietf.org/html/draft-kaplan-martini-sti= rred-domain-registration

http://tools.ietf.org/html/draft-kaplan-martini-sha= ken-implicit-registrations

 

Perspectives & = Discussion (30 minutes)

 

9:10 AM – 9:20 AM =  PT Service Provider Perspective, Martin Dolly (10 minutes)

9:20 AM – 9:40 AM = PT Discussion:  Participants (20 minutes)

 

Wrap-up (20 = minutes)

 

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

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

 

------=_NextPart_000_009A_01CAA38A.40616720-- From christer.holmberg@ericsson.com Mon Feb 1 22:11: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 485FD3A6A7C for ; Mon, 1 Feb 2010 22:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[AWL=-2.559, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RblV6SdlAnZP for ; Mon, 1 Feb 2010 22:11:31 -0800 (PST) Received: from mailgw10.se.ericsson.net (unknown [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0E36F3A6A7B for ; Mon, 1 Feb 2010 22:11:29 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-db-4b67c235c2eb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CC.A5.02429.532C76B4; Tue, 2 Feb 2010 07:12:05 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 2 Feb 2010 07:12:04 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 2 Feb 2010 07:12:03 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjZCZrE6W+mIMJQAiuxCRq5NsVLQAah+ew Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <4B670F85.4030808@cisco.com> In-Reply-To: <4B670F85.4030808@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] 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: Tue, 02 Feb 2010 06:11:34 -0000 Hi,=20 >>I think that is wrong usage of the Contact header. You more=20 >>or less use it for carrying target information. We have other=20 >>mechanisms for that. >=20 >I beg to differ. The contact address is the ultimate target. >There have been many documents pointing that out. >And as long as you register each AOR independently it can be=20 >handled very cleanly. In my opinion Contact is not meant to be used for informing the UA about wh= at number was called etc in order to reach the UA. >>I also think it is a very "clumsy" solution, when you=20 >>mandate a 1-to-1 mapping of the R-URI/Contact userpart values=20 >>(maybe it could also have security impacts). >=20 >Its clumsy precisely because of implicit registration. >Adam's proposal provided a way to do that mapping under the=20 >control of the recipient so that only expected contact=20 >addresses are used. Again, as far as I understand, from a SIP network perspective the PBX only = has a single contact. Regards, Christer From christer.holmberg@ericsson.com Mon Feb 1 22:13: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 EC00F3A6A74 for ; Mon, 1 Feb 2010 22:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=-2.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQAkyo4h0ZsM for ; Mon, 1 Feb 2010 22:13:12 -0800 (PST) Received: from mailgw10.se.ericsson.net (unknown [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C15233A6818 for ; Mon, 1 Feb 2010 22:13:10 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-35-4b67c29a7350 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D5.E5.02429.A92C76B4; Tue, 2 Feb 2010 07:13:46 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 2 Feb 2010 07:13:46 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 2 Feb 2010 07:13:44 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjZCZrE6W+mIMJQAiuxCRq5NsVLQAaqBqw Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <4B670F85.4030808@cisco.com> In-Reply-To: <4B670F85.4030808@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] 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: Tue, 02 Feb 2010 06:13:15 -0000 Hi,=20 >>Last, my understanding is still that, from a SIP network=20 >>point of view, the PBX is seen as a single Contact, but in=20 >>your solution every PBX user explicitly (eventhough a=20 >>wildcard mechanism is used) registers with the SIP network. >=20 >The only clean way to treat the pbx as a single address is=20 >via loose routing. But there are issues with establishing=20 >loose routing tables via REGISTER. Well, then we have to work on those issues. Regards, Christer= From christer.holmberg@ericsson.com Mon Feb 1 22:16: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 363663A69BA for ; Mon, 1 Feb 2010 22:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-2.258, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl2xMxgt93e2 for ; Mon, 1 Feb 2010 22:16:16 -0800 (PST) Received: from mailgw9.se.ericsson.net (unknown [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C82D23A69EF for ; Mon, 1 Feb 2010 22:16:15 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-cf-4b67c353833c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 00.57.31641.353C76B4; Tue, 2 Feb 2010 07:16:51 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 2 Feb 2010 07:16:51 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 2 Feb 2010 07:16:51 +0100 From: Christer Holmberg To: Dean Willis Date: Tue, 2 Feb 2010 07:16:49 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjpwB+2Uw5IaxoQ2S90N/Jkss5pwAKCNUw Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> In-Reply-To: <82A960D0-7834-443A-883B-4EF0D25AE5C5@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 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" , Hadriel Kaplan 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: Tue, 02 Feb 2010 06:16:17 -0000 Hi,=20 >>Last, my understanding is still that, from a SIP network point of=20 >>view, the PBX is seen as a single Contact, but in your=20 >>solution every PBX user explicitly (eventhough a wildcard mechanism is us= ed)=20 >>registers with the SIP network. >> >=20 >Exactly. That's why this approach works. Absolutely nothing=20 >is "implicit", everything is explicit. But it has very little=20 >more overhead than the hackneyed implicit registrations, and=20 >entirely solves the "how does the PBX figure out which user"=20 >mess that happens if there is only one Contact for many=20 >different AORs. But, that is not how PBXs work. Regards, Christer From john.elwell@siemens-enterprise.com Mon Feb 1 23:51: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 F14B13A6ADA for ; Mon, 1 Feb 2010 23:51:58 -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.074, 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 SCvrRae-xfaH for ; Mon, 1 Feb 2010 23:51: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 D5F903A6ADB for ; Mon, 1 Feb 2010 23:51:57 -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-741691; Tue, 2 Feb 2010 08:52:33 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id C69AF23F0278; Tue, 2 Feb 2010 08:52:33 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 2 Feb 2010 08:52:33 +0100 From: "Elwell, John" To: Christer Holmberg , Dean Willis Date: Tue, 2 Feb 2010 08:52:32 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjpwB+2Uw5IaxoQ2S90N/Jkss5pwAKCNUwAAMQuKA= Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@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: Hadriel Kaplan , "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: Tue, 02 Feb 2010 07:51:59 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 02 February 2010 06:17 > To: Dean Willis > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 >=20 > Hi,=20 >=20 > >>Last, my understanding is still that, from a SIP network point of=20 > >>view, the PBX is seen as a single Contact, but in your=20 > >>solution every PBX user explicitly (eventhough a wildcard=20 > mechanism is used)=20 > >>registers with the SIP network. > >> > >=20 > >Exactly. That's why this approach works. Absolutely nothing=20 > >is "implicit", everything is explicit. But it has very little=20 > >more overhead than the hackneyed implicit registrations, and=20 > >entirely solves the "how does the PBX figure out which user"=20 > >mess that happens if there is only one Contact for many=20 > >different AORs. >=20 > But, that is not how PBXs work. [JRE] Taking the example from the "Implications" thread, the PBX would rece= ive: sip:1972519xxxx@pbx.org or sip:1972519xxxx@10.1.2.3 In either case, it is a contact URI as far as the SSP is concerned, but the= PBX can treat those as AORs from its own perspective. I think there are pr= actical examples of it working like this today. John >=20 > Regards, >=20 > Christer > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From christer.holmberg@ericsson.com Tue Feb 2 00:17: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 E5BB728C103 for ; Tue, 2 Feb 2010 00:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=-2.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYZRNKXDBGAs for ; Tue, 2 Feb 2010 00:17:53 -0800 (PST) Received: from mailgw9.se.ericsson.net (unknown [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id EA51F3A6AE3 for ; Tue, 2 Feb 2010 00:17:52 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-a5-4b67dfd4a9fe Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 2F.8A.31641.4DFD76B4; Tue, 2 Feb 2010 09:18:29 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 2 Feb 2010 09:18:29 +0100 From: Christer Holmberg To: "Elwell, John" , Dean Willis Date: Tue, 2 Feb 2010 09:18:26 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjpwB+2Uw5IaxoQ2S90N/Jkss5pwAKCNUwAAMQuKAAAPj5AA== Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@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: Hadriel Kaplan , "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: Tue, 02 Feb 2010 08:17:54 -0000 Hi,=20 >>>>Last, my understanding is still that, from a SIP network point of=20 >>>>view, the PBX is seen as a single Contact, but in your solution=20 >>>>every PBX user explicitly (eventhough a wildcard mechanism is used) >>>>registers with the SIP network. >>>> >>>=20 >>>Exactly. That's why this approach works. Absolutely nothing is=20 >>>"implicit", everything is explicit. But it has very little more=20 >>>overhead than the hackneyed implicit registrations, and entirely=20 >>>solves the "how does the PBX figure out which user" >>>mess that happens if there is only one Contact for many different=20 >>>AORs. >>=20 >>But, that is not how PBXs work. >[JRE] Taking the example from the "Implications" thread, the=20 >PBX would receive: >sip:1972519xxxx@pbx.org or >sip:1972519xxxx@10.1.2.3 >In either case, it is a contact URI as far as the SSP is=20 >concerned, but the PBX can treat those as AORs from its own=20 >perspective. I think there are practical examples of it=20 >working like this today. Ok, you probably know more about SIPConnect etc than I do. But, what if the PBX is using outbound? I assume the same instance id and g= r values are going to be used for all PBX users, eventhough each PBX user h= as a unique Contact within the SSP? Regards, Christer= From john.elwell@siemens-enterprise.com Tue Feb 2 00:31: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 E50A228C13A for ; Tue, 2 Feb 2010 00:31:37 -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.071, 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 oYcz1fpILT82 for ; Tue, 2 Feb 2010 00:31:34 -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 0377328C120 for ; Tue, 2 Feb 2010 00:31:33 -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-742294; Tue, 2 Feb 2010 09:32:09 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id DDFDA1EB82AB; Tue, 2 Feb 2010 09:32:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 2 Feb 2010 09:32:09 +0100 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Tue, 2 Feb 2010 09:32:08 +0100 Thread-Topic: [martini] Use Cases: what's important, what's not Thread-Index: AcqjmLIac5uHvewrSVGr1G6ZZskFLAARheiA Message-ID: References: <4B6767A4.8000008@nostrum.com> In-Reply-To: <4B6767A4.8000008@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_A444A0F8084434499206E78C106220CAB8FE9B25MCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 08:31:38 -0000 --_000_A444A0F8084434499206E78C106220CAB8FE9B25MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, That's great that you have taken the trouble to enumerate these different c= ases. Talking from a PBX perspective, I think you are correct in saying tha= t all would get the job done. Inevitably there are some I dislike. I dislike 5/5a because of the implications of making REGISTER work with tel= URIs (and also tel URIs tend not to be used so much today on PBXs, in my o= pinion). I dislike 6, because the PBX can't do anything with the received Request-UR= I - strictly speaking it would have to route it back to the SP. I dislike 7, for the same reason, plus the known difficulties with extracti= ng information from History-Info (I have my doubts whether the present effo= rt to revise History-Info will really solve its problems). I suppose you could have a use case 8, which is a kind of combination of 2 = and 6. So you start of with sip:+12145550105@pan-am.com and deliver the sam= e Request-URI, together with Route: sip:pbx@192.168.17.25. This was what I = had in mind pre-MARTINI. It solves the problem of 6, but still has the issu= es of 2. Ignoring use case 8, this leaves use cases 1 to 4. From a PBX point of view= , cases 1 and 2 are the same. The difference is how the request reaches the= SP. Is this an issue for MARTINI? Or put it another way, if we provide a s= olution for case 1, does this stop people implementing case 2? Similarly fo= r cases 3 and 4: if we provide a solution for case 3, does this stop people= implementing case 4? So this narrows it down to cases 1 and 3. The recent "Implications" thread = seemed to be homing in on a solution that would give both 1 and 3, which so= unds reasonable to me. I am not convinced that there is a problem with case= 1's by-passing RFC 3263 procedures. John ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 01 February 2010 23:46 To: martini@ietf.org Subject: [martini] Use Cases: what's important, what's not The more we talk about this, the further apart opinions seem to get. There = appears to be a lot of ocean boiling going on right now, such that even whe= n we can decide on a fairly narrow scope ("phone numbers only"), the system= behavior that people expect appears to vary literally from person to perso= n. I'm going to try to do something like I did before with the diagrams, this = time focusing on just what happens for E.164 numbers. I'll continue with us= ing the same dead companies as before (CentricVoice as the SSP, and Pan-Am = as the PBX). In particular, I'm assuming that the tentative (albeit far from unanimous) = agreement to do an initial batch of work towards E.164 numbers means that t= hese kinds of use cases are not under discussion at the moment: Internet CentricVoice Pan-= Am |INVITE | | |sip:not-a-number@centricvoice.com | | |--------------------------------->| | | |INVITE | | |sip:some-other-string@pan-am.com | | |--------------------------------->| Internet CentricVoice Pan-= Am |INVITE | | |sip:not-a-number@pan-am.com | | |--------------------------------->| | | |INVITE | | |sip:some-other-string@pan-am.com | | |--------------------------------->| So, ignoring those, we seem to still have a huge disconnect on what the SSP= needs to be able to do as a result of the MARTINI operations. Now, one of = the nice things we get from E.164 numbers is that usernames now become uniq= ue. We can specify transformations such that the username that arrives at t= he SSP stays the same as it passes through the SSP. Unlike my earlier examp= les, I'm going to assume that limiting to E.164 enables this kind of trivia= l transformation. Not in the *general* case, of course -- only for MARTINI-= routed E.164 numbers. As you read through these, try to place each use case in one of the followi= ng categories: 1. This use case by itself is sufficient for the architecture {I am/my cu= stomers are} trying to deploy 2. This use case is necessary for the architecture {I am/my customers are= } trying to deploy, but requires other use cases also. 3. This use case is neither necessary nor sufficient for the architecture= {I am/my customers are} trying to deploy. Frankly, I would expect almost everyone will be able to place each use case= in category #1. All of these solutions certainly allow the PBX to figure o= ut who the call is supposed to be sent to, and that appears to be the key c= riteria for the inbound messages. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. RFC3263 for "pan-am.com" is not relevant. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| In this use case, the SSP receives a URI indicating its own domain. The SSP= is provisioned to know that +12145550105 belongs to Pan-Am. Having receive= d information from Pan-Am about its PBX's IP address, it changes the domain= to "pan-am.com," keeps the user ID, ignores RFC 3263 procedures, and sends= the request to the MARTINI-registered IP address it has for Pan-Am. The key drawback for this use case is the disregard for RFC3263 procedures. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "pan-am.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| In this use case, the SSP receives a URI indicating the domain for pan-am.c= om. Having received information from Pan-Am about its PBX's IP address, it = leaves the Request-URI alone, ignores RFC 3263 procedures, and sends the re= quest to the MARTINI-registered IP address it has for Pan-Am. Note that this use case is predicated on an external entity -- something on= the other side of the "Internet" cloud -- being able to take the E.164 num= ber "+12145550105" and figure out that it needs to go to the domain "pan-am= .com". I emphasize this because I know some people are interested in models= in which is tenable to track "phone number to SSP" mapping, while the rela= tively larger number of "phone number to end customer" mappings might be un= palatable. The key drawbacks for this use case are: 1. The disregard for RFC3263 procedures 2. Ambiguity around which SIP nodes are "responsible for" pan-am.com (in = the RFC 3261 sense of that word). Cullen had a litmus test for this: is Cen= tricVoice allowed to redirect calls for pan-am.com to a voicemail server or= answering service? Given that 3261 lacks a formal description of "responsible for," we can pot= entially define the problem of "responsible for" away (as Keith has propose= d) -- but I'm pretty certain it's not within MARTINI's scope to clarify the= terms appearing in RFC 3261. I think that would need to go back to DISPATC= H, and I doubt we want to wait for such an effort to complete. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@192.168.17.25 | | |--------------------------------->| In this use case, the SSP receives a request for its own domain. The SSP is= provisioned to know that +12145550105 belongs to Pan-Am. Having received i= nformation from Pan-Am about its PBX's IP address, it changes the domain to= that registered IP address (192.168.17.25), keeps the user ID, correctly i= nvokes RFC 3263 procedures, and sends the request to the resulting host (19= 2.168.17.25). This use case does not suffer from any of the drawbacks discussed to date, = other than differing from the model that is currently deployed for bulk reg= istrations (even though it is functionally identical to the model deployed = for single registrations). ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "pan-am.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@192.168.17.25 | | |--------------------------------->| In this use case, the SSP receives a URI indicating the domain for pan-am.c= om. Having received information from Pan-Am about its PBX's IP address, it = changes the domain to that registered IP address (192.168.17.25), keeps the= user ID, correctly invokes RFC 3263 procedures, and sends the request to t= he resulting host (192.168.17.25). Like use case 3, this use case does not suffer from any of the drawbacks di= scussed to date, other than differing from the model that is currently depl= oyed for bulk registrations (even though it is functionally identical to th= e model deployed for single registrations). However, it is predicated on an= external entity -- something on the other side of the "Internet" cloud -- = being able to take the E.164 number "+12145550105" and figure out that it n= eeds to go to the domain "pan-am.com". ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |tel:+12145550105 | | |--------------------------------->| In this use case, the SSP receives a URI indicating its own domain. The SSP= is provisioned to know that +12145550105 belongs to Pan-Am. It changes the= R-URI to a tel: URI containing only the E.164 number in question. Having r= eceived information from Pan-Am about its PBX's IP address, it sends the re= quest to the resulting host (192.168.17.25). Since the URI in question is a= TEL URI, RFC3263 issues are avoided altogether, eliminating any alt-root c= onsiderations. The major drawback to this use case is that it (likely) requires the abilit= y to register TEL URIs, which is currently normatively forbidden by RFC 326= 1. While this is tractable, it would require companion work in SIPCORE to r= elax this normative requirement. It also would likely require more mechanis= m than other approaches, since we're effectively adding on a new URI-to-hos= t address resolution procedure. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 5a =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A variation on Use Case 5, this use case ends up with a R-URI of the PBX's = lead number, with an extension parameter that indicates the desired extensi= on on the PBX: Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |tel:+12145550100;extension=3D121455= 5| | | 0105| | |--------------------------------->| This is effectively the exact same procedure as Use Case 5; however, it may= make contact registration somewhat easier (depending on the exact mechanis= m used to communicate domain IP addresses). ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->|INVITE | | |sip:+12145550105@centricvoice.com | | |Route: | | |--------------------------------->| In this example, In this use case, the SSP receives a URI indicating its ow= n domain. The SSP is provisioned to know that +12145550105 belongs to Pan-A= m. It pushes the MARTINI-registered contact into the route set, leaves the = Request-URI unmodified, invokes RFC 3263 procedures (on the Route) and send= s the request to the resulting host. A key drawback to this use case is that it cannot be effected using REGISTE= R without radically changing the semantics of REGISTER (i.e., registering a= path towards an AOR instead of a contact for an AOR). These changes necess= arily require intermediaries who are a party to the REGISTER transaction (e= .g., using Path and/or Service-Route) to understand these changed semantics= , and would require the use of a Proxy-Require to avoid the ensuing problem= s. Using a method other than REGISTER eliminates this class of problems. A second major drawback to this approach pertains to domain responsibility:= unless the Pan-Am PBX is "responsible for" centricvoice.com, it is in viol= ation of SIP routing procedures if it fails to route it back to CentricVoic= e: "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 Forwardin= g." In practice, I imagine it wants to route it to one of its internal ext= ensions. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 7 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->|INVITE sip:pbx@192.168.17.25 | | |History-Info: sip:+12145550105@cen| | | tricvoice.com| | |--------------------------------->| Similar to use case 6, except the SSP swaps out the registered Contact URI = for the Request-URI, and squirrels the incoming R-URI (containing the phone= number) away in a History-Info header field. On the plus side, this looks a lot like normal proxy/registrar behavior. Dr= awbacks include defining concrete procedures around which History-Info entr= y to use (which is a problem the 4244bis draft is currently struggling with= ), especially in the case that there are intermediaries between the SSP and= the PBX. We would also be creating a normative dependency on the 4244bis d= ocument, which may delay a final delivery of MARTINI work substantially. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Now, I've heard and read things that imply that each these use cases are un= der consideration by at least one person. I think we need to focus. Clearly= just saying "phone numbers" is not sufficient. Look back over how you rate= d each of the use cases relative to the "sufficient," "necessary but not su= fficient," and "neither necessary nor sufficient" criteria. I think you'll = find that, if you were honest with yourself, all or most of these use cases= fall into the first category. I'm not saying you *like* them all -- merely= that they will get the job done, if push were to come to shove. So, I think we need to pick one and work on the mechanism required to enabl= e it. And I think we need to be vigilant against scope creep. As we get int= o mechanism, it will be overwhelmingly tempting to say, "oh, but we can add= on Use Case X if we just do *this* small thing!" But those small things ca= n spiral out of control. All other things being equal, I have a strong preference for Use Case 3, as= its only real drawback is that it varies from the demonstrably flawed [1] = mechanism that showed up on the IETF's doorstep. Any other approach is goin= g to require interested parties coming to consensus on the issues associate= d with the other use cases, and I think we've seen that won't be a very fas= t process. /a [1] Lest this offend anyone as being too general a criticism, I refer to th= e set of shortcomings enumerated here: http://www.ietf.org/mail-archive/web= /martini/current/msg00412.html --_000_A444A0F8084434499206E78C106220CAB8FE9B25MCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adam,
 
That's great that you have taken the trouble to en= umerate=20 these different cases. Talking from a PBX perspective, I think you are corr= ect=20 in saying that all would get the job done. Inevitably there are some I=20 dislike.
 
I dislike 5/5a because of the implications of maki= ng=20 REGISTER work with tel URIs (and also tel URIs tend not to be used so much = today=20 on PBXs, in my opinion).
 
I dislike 6, because the PBX can't do anything wit= h the=20 received Request-URI - strictly speaking it would have to route it back to = the=20 SP.
 
I dislike 7, for the same reason, plus the known=20 difficulties with extracting information from History-Info (I have my doubt= s=20 whether the present effort to revise History-Info will really solve its=20 problems).
 
I suppose you could have a use case 8, which is a = kind of=20 combination of 2 and 6. So you start of with sip:+12145550105@pan-am.com an= d=20 deliver the same Request-URI, together with Route: sip:pbx@192.168.17.25. T= his=20 was what I had in mind pre-MARTINI. It solves the problem of 6, but still h= as=20 the issues of 2.
 
Ignoring use case 8, this leaves use cases 1 to 4.= From a=20 PBX point of view, cases 1 and 2 are the same. The difference is how the re= quest=20 reaches the SP. Is this an issue for MARTINI? Or put it another way, if we= =20 provide a solution for case 1, does this stop people implementing case 2?=20 Similarly for cases 3 and 4: if we provide a solution for case 3, does this= stop=20 people implementing case 4?
 
So this narrows it down to cases 1 and 3. The rece= nt=20 "Implications" thread seemed to be homing in on a solution that would give = both=20 1 and 3, which sounds reasonable to me. I am not convinced that there is a= =20 problem with case 1's by-passing RFC 3263 procedures.
 
John

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: 01 February 2010 23:46
To:=20 martini@ietf.org
Subject: [martini] Use Cases: what's important= ,=20 what's not

The more we talk about this, the further apart opinions seem t= o=20 get. There appears to be a lot of ocean boiling going on right now, such = that=20 even when we can decide on a fairly narrow scope ("phone numbers only"), = the=20 system behavior that people expect appears to vary literally from person = to=20 person.

I'm going to try to do something like I did before with th= e=20 diagrams, this time focusing on just what happens for E.164 numbers. I'll= =20 continue with using the same dead companies as before (CentricVoice as th= e=20 SSP, and Pan-Am as the PBX).

In particular, I'm assuming that the= =20 tentative (albeit far from unanimous) agreement to do an initial batch of= work=20 towards E.164 numbers means that these kinds of use cases are not under=20 discussion at the moment:
<Out Of=20 Scope>

Internet   &n= bsp;            = ;        =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:not-a-number@centricvoice.= com=20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|     &nbs= p;            &= nbsp;           &nbs= p;  =20 |
   =20 |            =             &nb= sp;        =20 |INVITE           =             &nb= sp;   =20 |
   =20 |            =             &nb= sp;        =20 |sip:some-other-string@pan-am.co= m =20 |
   =20 |            =             &nb= sp;        =20 |--------------------------------->|


Internet = ;            &n= bsp;          =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:not-a-number@pan-am.com = ;     =20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|     &nbs= p;            &= nbsp;           &nbs= p;  =20 |
   =20 |            =             &nb= sp;        =20 |INVITE           =             &nb= sp;   =20 |
   =20 |            =             &nb= sp;        =20 |sip:some-other-string@pan-am.co= m =20 |
   =20 |            =             &nb= sp;        =20 |--------------------------------->|
</Out Of=20 Scope>

So, ignoring those, we seem to s= till=20 have a huge disconnect on what the SSP needs to be able to do as a result= of=20 the MARTINI operations. Now, one of the nice things we get from E.164 num= bers=20 is that usernames now become unique. We can specify transformations such = that=20 the username that arrives at the SSP stays the same as it passes through = the=20 SSP. Unlike my earlier examples, I'm going to assume that limiting to E.1= 64=20 enables this kind of trivial transformation. Not in the *general* case, o= f=20 course -- only for MARTINI-routed E.164 numbers.

As you read throu= gh=20 these, try to place each use case in one of the following categories:
  1. This use case by itself is sufficient for the architecture {I am/my= =20 customers are} trying to deploy

  2. This use case is necessary for the architecture {I am/my customers = are}=20 trying to deploy, but requires other use cases also.

  3. This use case is neither necessary nor sufficient for the architect= ure=20 {I am/my customers are} trying to deploy.

Frankly, I woul= d=20 expect almost everyone will be able to place each use case in category #1= . All=20 of these solutions certainly allow the PBX to figure out who the call is= =20 supposed to be sent to, and that appears to be the key criteria for the=20 inbound messages.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 1
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for=20 "centricvoice.com" resolves to the CentricVoice servers.
RFC3263 for=20 "pan-am.com" is not=20 relevant.

Internet       &n= bsp;            = ;    =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|     &nbs= p;            &= nbsp;           &nbs= p;  =20 |
   =20 |            =             &nb= sp;        =20 |INVITE           =             &nb= sp;   =20 |
   =20 |            =             &nb= sp;        =20 |sip:+12145550105@pan-am.com = ;     =20 |
   =20 |            =             &nb= sp;        =20 |--------------------------------->|


In this use case,= the=20 SSP receives a URI indicating its own domain. The SSP is provisioned to k= now=20 that +12145550105 belongs to Pan-Am. Having received information from Pan= -Am=20 about its PBX's IP address, it changes the domain to "pan-am.com," keeps = the=20 user ID, ignores RFC 3263 procedures, and sends the request to the=20 MARTINI-registered IP address it has for Pan-Am.

The key drawback = for=20 this use case is the disregard for RFC3263 procedures.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 2
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for=20 "pan-am.com" resolves to the CentricVoice=20 servers.


Internet       = ;            &n= bsp;    =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:+12145550105@pan-am.com = ;     =20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|     &nbs= p;            &= nbsp;           &nbs= p;  =20 |
   =20 |            =             &nb= sp;        =20 |INVITE           =             &nb= sp;   =20 |
   =20 |            =             &nb= sp;        =20 |sip:+12145550105@pan-am.com = ;     =20 |
   =20 |            =             &nb= sp;        =20 |--------------------------------->|


In this use case,= the=20 SSP receives a URI indicating the domain for pan-am.com. Having received= =20 information from Pan-Am about its PBX's IP address, it leaves the Request= -URI=20 alone, ignores RFC 3263 procedures, and sends the request to the=20 MARTINI-registered IP address it has for Pan-Am.

Note that this us= e=20 case is predicated on an external entity -- something on the other side o= f the=20 "Internet" cloud -- being able to take the E.164 number "+12145550105" an= d=20 figure out that it needs to go to the domain "pan-am.com". I emphasize th= is=20 because I know some people are interested in models in which is tenable t= o=20 track "phone number to SSP" mapping, while the relatively larger number o= f=20 "phone number to end customer" mappings might be unpalatable.

The = key=20 drawbacks for this use case are:
  1. The disregard for RFC3263 procedures
  2. Ambiguity around which SIP nodes are "responsible for" pan-am.com (= in=20 the RFC 3261 sense of that word). Cullen had a litmus test for this: is= =20 CentricVoice allowed to redirect calls for pan-am.com to a voicemail se= rver=20 or answering service?

Given that 3261 lacks a formal desc= ription=20 of "responsible for," we can potentially define the problem of "responsib= le=20 for" away (as Keith has proposed) -- but I'm pretty certain it's not with= in=20 MARTINI's scope to clarify the terms appearing in RFC 3261. I think that = would=20 need to go back to DISPATCH, and I doubt we want to wait for such an effo= rt to=20 complete.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 3
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for=20 "centricvoice.com" resolves to the CentricVoice=20 servers.

Internet       &nb= sp;            =     =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|     &nbs= p;            &= nbsp;           &nbs= p;  =20 |
   =20 |            =             &nb= sp;        =20 |INVITE           =             &nb= sp;   =20 |
   =20 |            =             &nb= sp;        =20 |sip:+12145550105@192.168.17.25   =20 |
   =20 |            =             &nb= sp;        =20 |--------------------------------->|


In this use case,= the=20 SSP receives a request for its own domain. The SSP is provisioned to know= that=20 +12145550105 belongs to Pan-Am. Having received information from Pan-Am a= bout=20 its PBX's IP address, it changes the domain to that registered IP address= =20 (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 procedures= , and=20 sends the request to the resulting host (192.168.17.25).

This use = case=20 does not suffer from any of the drawbacks discussed to date, other than=20 differing from the model that is currently deployed for bulk registration= s=20 (even though it is functionally identical to the model deployed for singl= e=20 registrations).


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 4
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for=20 "pan-am.com" resolves to the CentricVoice=20 servers.

Internet       &nb= sp;            =     =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:+12145550105@pan-am.com = ;     =20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|     &nbs= p;            &= nbsp;           &nbs= p;  =20 |
   =20 |            =             &nb= sp;        =20 |INVITE           =             &nb= sp;   =20 |
   =20 |            =             &nb= sp;        =20 |sip:+12145550105@192.168.17.25   =20 |
   =20 |            =             &nb= sp;        =20 |--------------------------------->|

In this use case, the= SSP=20 receives a URI indicating the domain for pan-am.com. Having received=20 information from Pan-Am about its PBX's IP address, it changes the domain= to=20 that registered IP address (192.168.17.25), keeps the user ID, correctly= =20 invokes RFC 3263 procedures, and sends the request to the resulting host= =20 (192.168.17.25).

Like use case 3, this use case does not suffer fr= om=20 any of the drawbacks discussed to date, other than differing from the mod= el=20 that is currently deployed for bulk registrations (even though it is=20 functionally identical to the model deployed for single registrations).=20 However, it is predicated on an external entity -- something on the other= side=20 of the "Internet" cloud -- being able to take the E.164 number "+12145550= 105"=20 and figure out that it needs to go to the domain "pan-am.com".


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 5
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for=20 "centricvoice.com" resolves to the CentricVoice=20 servers.

Internet       &nb= sp;            =     =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|     &nbs= p;            &= nbsp;           &nbs= p;  =20 |
   =20 |            =             &nb= sp;        =20 |INVITE           =             &nb= sp;   =20 |
   =20 |            =             &nb= sp;        =20 |tel:+12145550105         &n= bsp;       =20 |
   =20 |            =             &nb= sp;        =20 |--------------------------------->|


In this use case,= the=20 SSP receives a URI indicating its own domain. The SSP is provisioned to k= now=20 that +12145550105 belongs to Pan-Am. It changes the R-URI to a tel: URI=20 containing only the E.164 number in question. Having received information= from=20 Pan-Am about its PBX's IP address, it sends the request to the resulting = host=20 (192.168.17.25). Since the URI in question is a TEL URI, RFC3263 issues a= re=20 avoided altogether, eliminating any alt-root considerations.

The m= ajor=20 drawback to this use case is that it (likely) requires the ability to reg= ister=20 TEL URIs, which is currently normatively forbidden by RFC 3261. While thi= s is=20 tractable, it would require companion work in SIPCORE to relax this norma= tive=20 requirement. It also would likely require more mechanism than other=20 approaches, since we're effectively adding on a new URI-to-host address=20 resolution procedure.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Use Case=20 5a
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A variation= on Use Case 5, this use case ends up=20 with a R-URI of the PBX's lead number, with an extension parameter that=20 indicates the desired extension on the=20 PBX:

Internet        &= nbsp;           &nbs= p;   =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|     &nbs= p;            &= nbsp;           &nbs= p;  =20 |
   =20 |            =             &nb= sp;        =20 |INVITE           =             &nb= sp;   =20 |
   =20 |            =             &nb= sp;        =20 |tel:+12145550100;extension=3D1214555|
   =20 |            =             &nb= sp;        =20 |            =             &nb= sp;    =20 0105|
   =20 |            =             &nb= sp;        =20 |--------------------------------->|


This is effective= ly=20 the exact same procedure as Use Case 5; however, it may make contact=20 registration somewhat easier (depending on the exact mechanism used to=20 communicate domain IP addresses).


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 6
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for=20 "centricvoice.com" resolves to the CentricVoice=20 servers.

Internet       &nb= sp;            =     =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 |            =             &nb= sp;        =20 |
   =20 |--------------------------------->|INVITE    &nbs= p;            &= nbsp;         =20 |
   =20 |            =             &nb= sp;        =20 |sip:+12145550105@centricvoice.= com=20 |
   =20 |            =             &nb= sp;        =20 |Route: <sip:pbx@192.168.17.25> &nb= sp; =20 |
   =20 |            =             &nb= sp;        =20 |--------------------------------->|

In this example, In t= his=20 use case, the SSP receives a URI indicating its own domain. The SSP is=20 provisioned to know that +12145550105 belongs to Pan-Am. It pushes the=20 MARTINI-registered contact into the route set, leaves the Request-URI=20 unmodified, invokes RFC 3263 procedures (on the Route) and sends the requ= est=20 to the resulting host.

A key drawback to this use case is that it= =20 cannot be effected using REGISTER without radically changing the semantic= s of=20 REGISTER (i.e., registering a path towards an AOR instead of a contact fo= r an=20 AOR). These changes necessarily require intermediaries who are a party to= the=20 REGISTER transaction (e.g., using Path and/or Service-Route) to understan= d=20 these changed semantics, and would require the use of a Proxy-Require to = avoid=20 the ensuing problems. Using a method other than REGISTER eliminates this = class=20 of problems.

A second major drawback to this approach pertains to= =20 domain responsibility: unless the Pan-Am PBX is "responsible for"=20 centricvoice.com, it is in violation of SIP routing procedures if it fail= s to=20 route it back to CentricVoice: "If the domain of the Request-URI indicate= s a=20 domain this element is not responsible for, the Request-URI MUST be place= d=20 into the target set as the only target, and the element MUST proceed to t= he=20 task of Request Forwarding."  In practice, I imagine it wants to rou= te it=20 to one of its internal extensions.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 7
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for=20 "centricvoice.com" resolves to the CentricVoice=20 servers.

Internet       &nb= sp;            =     =20 CentricVoice          &= nbsp;           &nbs= p;  =20 Pan-Am
   =20 |INVITE           =             &nb= sp;   =20 |            =             &nb= sp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 |            =             &nb= sp;        =20 |
    |--------------------------------->|INVITE=20 sip:pbx@192.168.17.25 &n= bsp;   =20 |
   =20 |            =             &nb= sp;        =20 |History-Info: sip:+12145550105@cen|
 = ;  =20 |            =             &nb= sp;        =20 |            =         =20 tricvoice.com|  
   =20 |            =             &nb= sp;        =20 |--------------------------------->|


Similar to use ca= se 6,=20 except the SSP swaps out the registered Contact URI for the Request-URI, = and=20 squirrels the incoming R-URI (containing the phone number) away in a=20 History-Info header field.

On the plus side, this looks a lot like= =20 normal proxy/registrar behavior. Drawbacks include defining concrete=20 procedures around which History-Info entry to use (which is a problem the= =20 4244bis draft is currently struggling with), especially in the case that = there=20 are intermediaries between the SSP and the PBX. We would also be creating= a=20 normative dependency on the 4244bis document, which may delay a final del= ivery=20 of MARTINI work substantially.


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

Now,= =20 I've heard and read things that imply that each these use cases are under= =20 consideration by at least one person. I think we need to focus. Clearly j= ust=20 saying "phone numbers" is not sufficient. Look back over how you rated ea= ch of=20 the use cases relative to the "sufficient," "necessary but not sufficient= ,"=20 and "neither necessary nor sufficient" criteria. I think you'll find that= , if=20 you were honest with yourself, all or most of these use cases fall into t= he=20 first category. I'm not saying you *like* them all -- merely that they wi= ll=20 get the job done, if push were to come to shove.

So, I think we ne= ed to=20 pick one and work on the mechanism required to enable it. And I think we = need=20 to be vigilant against scope creep. As we get into mechanism, it will be= =20 overwhelmingly tempting to say, "oh, but we can add on Use Case X if we j= ust=20 do *this* small thing!" But those small things can spiral out of=20 control.

All other things being equal, I have a strong preference = for=20 Use Case 3, as its only real drawback is that it varies from the demonstr= ably=20 flawed [1] mechanism that showed up on the IETF's doorstep. An= y=20 other approach is going to require interested parties coming to consensus= on=20 the issues associated with the other use cases, and I think we've seen th= at=20 won't be a very fast process.

/a

[1] Lest this offend anyon= e as=20 being too general a criticism, I refer to the set of shortcomings enumera= ted=20 here: http://www.ietf.org/mail-archive/web/martini/current/msg00412.html
--_000_A444A0F8084434499206E78C106220CAB8FE9B25MCHP058Aglobala_-- From john.elwell@siemens-enterprise.com Tue Feb 2 00: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 24DC628C11A for ; Tue, 2 Feb 2010 00:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 cPun0fC0YinP for ; Tue, 2 Feb 2010 00:40:06 -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 EEAFE28C163 for ; Tue, 2 Feb 2010 00:40:05 -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-742852; Tue, 2 Feb 2010 09:40:41 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D7D6723F0278; Tue, 2 Feb 2010 09:40:41 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 2 Feb 2010 09:40:41 +0100 From: "Elwell, John" To: Christer Holmberg , Dean Willis Date: Tue, 2 Feb 2010 09:40:40 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjpwB+2Uw5IaxoQ2S90N/Jkss5pwAKCNUwAAMQuKAAAPj5AAABAjYg Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@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: Hadriel Kaplan , "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: Tue, 02 Feb 2010 08:40:07 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 02 February 2010 08:18 > To: Elwell, John; Dean Willis > Cc: martini@ietf.org; Hadriel Kaplan > Subject: RE: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 >=20 > Hi,=20 >=20 > >>>>Last, my understanding is still that, from a SIP network point of=20 > >>>>view, the PBX is seen as a single Contact, but in your solution=20 > >>>>every PBX user explicitly (eventhough a wildcard=20 > mechanism is used) > >>>>registers with the SIP network. > >>>> > >>>=20 > >>>Exactly. That's why this approach works. Absolutely nothing is=20 > >>>"implicit", everything is explicit. But it has very little more=20 > >>>overhead than the hackneyed implicit registrations, and entirely=20 > >>>solves the "how does the PBX figure out which user" > >>>mess that happens if there is only one Contact for many different=20 > >>>AORs. > >>=20 > >>But, that is not how PBXs work. > >[JRE] Taking the example from the "Implications" thread, the=20 > >PBX would receive: > >sip:1972519xxxx@pbx.org or > >sip:1972519xxxx@10.1.2.3 > >In either case, it is a contact URI as far as the SSP is=20 > >concerned, but the PBX can treat those as AORs from its own=20 > >perspective. I think there are practical examples of it=20 > >working like this today. >=20 > Ok, you probably know more about SIPConnect etc than I do. >=20 > But, what if the PBX is using outbound? I assume the same=20 > instance id and gr values are going to be used for all PBX=20 > users, eventhough each PBX user has a unique Contact within the SSP? [JRE] Yes - this was touched on in the other recent thread. John >=20 > Regards, >=20 > Christer= From dwsauder@dsauder.com Tue Feb 2 02:15: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 CEF7D28C248 for ; Tue, 2 Feb 2010 02:15: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 OOdQt2V7akAp for ; Tue, 2 Feb 2010 02:15:10 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 95A513A6AEC for ; Tue, 2 Feb 2010 02:15:10 -0800 (PST) Received: from [192.168.2.105] (c-68-50-30-250.hsd1.md.comcast.net [68.50.30.250]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MguSG-1NOy6X2Gfo-00MVWN; Tue, 02 Feb 2010 05:15:38 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Doug Sauder In-Reply-To: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> Date: Tue, 2 Feb 2010 05:15:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) X-Provags-ID: V01U2FsdGVkX196kwzLBjc4BCcp15OEi04KEtG25e46/NkUALi DKp1U5DkZPd3OFkiOL76tJxLrb7g2Bv03Vcmpfx+eHXohuwx4I bw1LR0Y3XfWKzK/ugPElTmotDS7xf7y Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 10:15:11 -0000 Dean, I disagree with the PBX claiming its AORs at the SSP through a = registration. I think this kind of "provisioning" is backwards compared = to what real SSPs want. In my experience, subscribers are provisioned = at the SSP, and it's a goal to have the PBX provisioned through some = kind of auto-provisioning. For example, the PBX uses HTTP or FTP to get = its configuration information from a server maintained by the SSP. This = is how the PBX discovers its AORs, extensions, and so forth. It might = not be this way in every deployment, but I believe it's where the = SMB-market service providers want to go. Your approach seems to suggest that provisioning happens at the PBX, and = it is then "pushed" to the SSP. I think the implicit registration is a better alternative, especially = when such auto-provisioning is deployed. -- Doug On Feb 1, 2010, at 20:45 , Dean Willis wrote: >=20 > On Feb 1, 2010, at 3:07 PM, Bernard Aboba wrote: >=20 >> Why couldn=92t this approach also be used to register = sip:+1972519XXX@sp.com and map it tosip:192519XXX@pbx.org or = sip:192519XXX@10.1.2.3 ? >>=20 >> Is it just the issue of the PBX proving that it actually owns = pbx.org? >>=20 >=20 >=20 > Yes, I think this could work: You would have a To: of = "sip:1972519XXXX@ssp.com" and a Contact of "sip:1972519XXX@10.1.2.3". >=20 > It requires that PBX know how to remap its own users to @ssp.com = domain users. >=20 >=20 > -- > Dean >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From christer.holmberg@ericsson.com Tue Feb 2 02:53: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 40FDE28C290 for ; Tue, 2 Feb 2010 02:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-1.919, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJVybQYlzCMS for ; Tue, 2 Feb 2010 02:53:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (unknown [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4BA5228C189 for ; Tue, 2 Feb 2010 02:53:00 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-bc-4b680430cddd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4B.A7.31641.034086B4; Tue, 2 Feb 2010 11:53:36 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 2 Feb 2010 11:53:36 +0100 From: Christer Holmberg To: "Elwell, John" , Dean Willis Date: Tue, 2 Feb 2010 11:53:35 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjpwB+2Uw5IaxoQ2S90N/Jkss5pwAKCNUwAAMQuKAAAPj5AAABAjYgAASdlJA= Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@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: Hadriel Kaplan , "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: Tue, 02 Feb 2010 10:53:01 -0000 =20 =20 > > >>>>Last, my understanding is still that, from a SIP=20 > network point of=20 > > >>>>view, the PBX is seen as a single Contact, but in your solution=20 > > >>>>every PBX user explicitly (eventhough a wildcard > > mechanism is used) > > >>>>registers with the SIP network. > > >>>> > > >>>=20 > > >>>Exactly. That's why this approach works. Absolutely nothing is=20 > > >>>"implicit", everything is explicit. But it has very little more=20 > > >>>overhead than the hackneyed implicit registrations, and entirely=20 > > >>>solves the "how does the PBX figure out which user" > > >>>mess that happens if there is only one Contact for many=20 > different=20 > > >>>AORs. > > >>=20 > > >>But, that is not how PBXs work. > > >[JRE] Taking the example from the "Implications" thread, the PBX=20 > > >would receive: > > >sip:1972519xxxx@pbx.org or > > >sip:1972519xxxx@10.1.2.3 > > >In either case, it is a contact URI as far as the SSP is=20 > concerned,=20 > > >but the PBX can treat those as AORs from its own=20 > perspective. I think=20 > > >there are practical examples of it working like this today. > >=20 > > Ok, you probably know more about SIPConnect etc than I do. > >=20 > > But, what if the PBX is using outbound? I assume the same=20 > instance id=20 > > and gr values are going to be used for all PBX users,=20 > eventhough each=20 > > PBX user has a unique Contact within the SSP? > [JRE] Yes - this was touched on in the other recent thread. In that case, why would we need to send a wildcarded Contact (as suggested = by Dean)? Why not simply register the IPX IP address, and the registrar the= n adds the user part for inbound requests? Regards, Christer From jsburton@cablevision.com Tue Feb 2 03:02: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 C079E28C283 for ; Tue, 2 Feb 2010 03:02:15 -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 IzJEYo-eRgdm for ; Tue, 2 Feb 2010 03:02:14 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 38ED528C277 for ; Tue, 2 Feb 2010 03:02:14 -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 o12B2p5P007367 for ; Tue, 2 Feb 2010 06:02:51 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o12B2p5P007367 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1265108571; bh=PErJjVj5EoXcqq7brYpP/f2nk/GUMuprAIWFjYA ztxQ=; h=Message-Id:Date:From:To:Cc:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=nFusJYf1dn+zZSHIVkStWLPKNLOAHionov0Ut U2kZgBQYkTTWDf2HRkp0x9+HdQN0O6Jg+zC/2NRy9fjT6YI6Ed7m69FtgiqbxFjGsId agJ1H7px7XyVmYGlOMytWQzBMibyh/aN1fzlM7YA4Fry+GLkE5P96NLwRWr3T4Ms7tI = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Tue, 02 Feb 2010 06:02:50 -0500 Message-Id: <4B680653.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Tue, 02 Feb 2010 06:02:43 -0500 From: "Jack Burton" To: "Doug Sauder" , "Dean Willis" References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> In-Reply-To: <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part0E242043.2__=" X-Auth-Type: Internal IP Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 11:02:15 -0000 --=__Part0E242043.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Doug, In our case, we have an IP-PBX that we provide to some customers. It is provisioned as you suggest - the IP-PBX pulls credentials and such from a config server we (the SSP) maintain. For other customers, who provide their own IP-PBXs, there is no such communication. We provide them with a manual list of their allowed e164 numbers, including all DIDs, which they (or their VAR/PBX Vendor) must manually provision in their switches. In either case, we require registration in order for our SBCs to learn the dynamic IP address of the customer. -Jack Jack Burton Dir. Systems Engineering Cablevision jsburton@cablevision.com 516-803-9733 >>> Doug Sauder 2/2/2010 10:15 >>> Dean, I disagree with the PBX claiming its AORs at the SSP through a registration. I think this kind of "provisioning" is backwards compared to what real SSPs want. In my experience, subscribers are provisioned at the SSP, and it's a goal to have the PBX provisioned through some kind of auto-provisioning. For example, the PBX uses HTTP or FTP to get its configuration information from a server maintained by the SSP. This is how the PBX discovers its AORs, extensions, and so forth. It might not be this way in every deployment, but I believe it's where the SMB-market service providers want to go. Your approach seems to suggest that provisioning happens at the PBX, and it is then "pushed" to the SSP. I think the implicit registration is a better alternative, especially when such auto-provisioning is deployed. -- Doug On Feb 1, 2010, at 20:45 , Dean Willis wrote: -------------------------------------------------------- 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. -------------------------------------------------------- --=__Part0E242043.2__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
Doug,
 
In our case, we have an IP-PBX that we provide to some customers. = ; It is provisioned as you suggest - the IP-PBX pulls credentials and such = from a config server we (the SSP) maintain.
 
For other customers, who provide their own IP-PBXs, there is no such c= ommunication.  We provide them with a manual list of their allowed e16= 4 numbers, including all DIDs, which they (or their VAR/PBX Vendor) mu= st manually provision in their switches.
 
In either case, we require registration in order for our SBCs to learn= the dynamic IP address of the customer.
 
-Jack
 
 
Jack Burton
Dir. Systems Engineering
Cablevision
jsburton@cab= levision.com
516-803-9733

>>> Doug Sauder <dwsauder@d= sauder.com> 2/2/2010 10:15 >>>
Dean,

I disagree with = the PBX claiming its AORs at the SSP through a registration.  I think = this kind of "provisioning" is backwards compared to what real SSPs want.&n= bsp; In my experience, subscribers are provisioned at the SSP, and it's a g= oal to have the PBX provisioned through some kind of auto-provisioning.&nbs= p; For example, the PBX uses HTTP or FTP to get its configuration informati= on from a server maintained by the SSP.  This is how the PBX discovers= its AORs, extensions, and so forth.  It might not be this way in ever= y deployment, but I believe it's where the SMB-market service providers wan= t to go.

Your approach seems to suggest that provisioning happens at= the PBX, and it is then "pushed" to the SSP.

I think the implicit r= egistration is a better alternative, especially when such auto-provisioning= is deployed.

--
Doug

On Feb 1, 2010, at 20:45 , Dean Will= is wrote:


--------------------------------------------------------
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.
-------------------------------------------------------- --=__Part0E242043.2__=-- From prvs=642ad67c6=Chris.Gatch@cbeyond.net Tue Feb 2 04:23: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 2768E3A6901 for ; Tue, 2 Feb 2010 04:23:41 -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 bg8UTvzieXLE for ; Tue, 2 Feb 2010 04:23:26 -0800 (PST) Received: from mx2.cbeyond.net (mx2.cbeyond.net [64.238.96.58]) by core3.amsl.com (Postfix) with ESMTP id B70D028C1B5 for ; Tue, 2 Feb 2010 04:22:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAEAGqoZ0tINoKr/2dsb2JhbACBbJhSrxEBAwQBjWKCUgaBbQQ X-IronPort-AV: E=Sophos;i="4.49,390,1262581200"; d="scan'208,217";a="13175451" Received: from exhub00.corp.cbeyond.net (HELO exchange.cbeyond.net) ([72.54.130.171]) by mx2.cbeyond.net with ESMTP/TLS/RC4-MD5; 02 Feb 2010 07:22:58 -0500 Received: from cbyexhub01.corp.cbeyond.net (10.6.180.30) by exhub00.corp.cbeyond.net (10.6.18.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 2 Feb 2010 07:22:58 -0500 Received: from CBYMBX01.corp.cbeyond.net ([10.6.180.15]) by cbyexhub01.corp.cbeyond.net ([10.6.180.30]) with mapi; Tue, 2 Feb 2010 07:22:57 -0500 From: Chris Gatch To: Jack Burton , Doug Sauder , Dean Willis Date: Tue, 2 Feb 2010 07:22:33 -0500 Thread-Topic: [martini] Implications of multiple AOR/contact mapping Thread-Index: Acqj90aPr/k/tQQJTsWEvQycFaPOWgACnwrQ Message-ID: References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> In-Reply-To: <4B680653.6D98.00CB.0@cablevision.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_A7FC8CE8C850E04B9081EAB2DEF441ED25D7C608CBYMBX01corpcbe_" MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 12:31:37 -0000 --_000_A7FC8CE8C850E04B9081EAB2DEF441ED25D7C608CBYMBX01corpcbe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > It might not be this way in every deployment, but I believe it's where th= e SMB-market service providers want to go. I am not aware of any standard approach for communicating provisioning rela= ted information to the IP PBX from the SSP. There are some proprietary imp= lementations supported on a limited number of PBXs, but not very many. A s= olution to implicit registration should avoid any approach that requires th= e customer to know the phone numbers associated with its service prior to r= egistering. The way it currently works under SIPconnect 1.0 is the SSP mak= es the association of the registered AOR to all other AORs such that the cu= stomer only needs to know the proxies' URL/address along with their usernam= e and password. From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Jack Burton Sent: Tuesday, February 02, 2010 6:03 AM To: Doug Sauder; Dean Willis Cc: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping Doug, In our case, we have an IP-PBX that we provide to some customers. It is pr= ovisioned as you suggest - the IP-PBX pulls credentials and such from a con= fig server we (the SSP) maintain. For other customers, who provide their own IP-PBXs, there is no such commun= ication. We provide them with a manual list of their allowed e164 numbers,= including all DIDs, which they (or their VAR/PBX Vendor) must manually pro= vision in their switches. In either case, we require registration in order for our SBCs to learn the = dynamic IP address of the customer. -Jack Jack Burton Dir. Systems Engineering Cablevision jsburton@cablevision.com 516-803-9733 >>> Doug Sauder 2/2/2010 10:15 >>> Dean, I disagree with the PBX claiming its AORs at the SSP through a registration= . I think this kind of "provisioning" is backwards compared to what real S= SPs want. In my experience, subscribers are provisioned at the SSP, and it= 's a goal to have the PBX provisioned through some kind of auto-provisionin= g. For example, the PBX uses HTTP or FTP to get its configuration informat= ion from a server maintained by the SSP. This is how the PBX discovers its= AORs, extensions, and so forth. It might not be this way in every deploym= ent, but I believe it's where the SMB-market service providers want to go. Your approach seems to suggest that provisioning happens at the PBX, and it= is then "pushed" to the SSP. I think the implicit registration is a better alternative, especially when = such auto-provisioning is deployed. -- Doug On Feb 1, 2010, at 20:45 , Dean Willis wrote: -------------------------------------------------------- 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. -------------------------------------------------------- --_000_A7FC8CE8C850E04B9081EAB2DEF441ED25D7C608CBYMBX01corpcbe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> It might not be this way in every deployment, but I believe it's where the SMB-market service providers want to go.

I am not aware of any standard approach for communicating provisioning relate= d information to the IP PBX from the SSP.  There are some proprietary im= plementations supported on a limited number of PBXs, but not very many.  A solution = to implicit registration should avoid any approach that requires the customer = to know the phone numbers associated with its service prior to registering.&nb= sp; The way it currently works under SIPconnect 1.0 is the SSP makes the associatio= n of the registered AOR to all other AORs such that the customer only needs to k= now the proxies’ URL/address along with their username and password.

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of = Jack Burton
Sent: Tuesday, February 02, 2010 6:03 AM
To: Doug Sauder; Dean Willis
Cc: Bernard Aboba; martini@ietf.org
Subject: Re: [martini] Implications of multiple AOR/contact mapping<= o:p>

 

Doug,

 

In our case, w= e have an IP-PBX that we provide to some customers.  It is provisioned as you suggest - the IP-PBX pulls credentials and such from a config server we (th= e SSP) maintain.

 

For other cust= omers, who provide their own IP-PBXs, there is no such communication.  We pro= vide them with a manual list of their allowed e164 numbers, including all DIDs, which they (or their VAR/PBX Vendor) must manually provision in their switches.

 

In either case= , we require registration in order for our SBCs to learn the dynamic IP address = of the customer.

 

-Jack

 

 

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

>>> Doug Sauder <dwsauder@dsauder.com> 2/2/2010 10:15 >>>
Dean,

I disagree with the PBX claiming its AORs at the SSP through a registration.  I think this kind of "provisioning" is backwa= rds compared to what real SSPs want.  In my experience, subscribers are provisioned at the SSP, and it's a goal to have the PBX provisioned through some kind of auto-provisioning.  For example, the PBX uses HTTP or FTP= to get its configuration information from a server maintained by the SSP. = ; This is how the PBX discovers its AORs, extensions, and so forth.  It might not be this way in every deployment, but I believe it's where the SMB-market service providers want to go.

Your approach seems to suggest that provisioning happens at the PBX, and it= is then "pushed" to the SSP.

I think the implicit registration is a better alternative, especially when = such auto-provisioning is deployed.

--
Doug

On Feb 1, 2010, at 20:45 , Dean Willis wrote:


--------------------------------------------------------
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 con= tain 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, th= is information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please conta= ct the sender immediately and delete and destroy the communication and all of = the attachments you have received and all copies thereof.
--------------------------------------------------------

--_000_A7FC8CE8C850E04B9081EAB2DEF441ED25D7C608CBYMBX01corpcbe_-- From jsburton@cablevision.com Tue Feb 2 05:21: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 909CC3A6931 for ; Tue, 2 Feb 2010 05:21:54 -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=[AWL=0.000, 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 M1uhVjw8onEC for ; Tue, 2 Feb 2010 05:21:53 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id C29993A6891 for ; Tue, 2 Feb 2010 05:21:51 -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 o12DMTm7028109 for ; Tue, 2 Feb 2010 08:22:29 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o12DMTm7028109 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1265116949; bh=7E+55V5yHxTO2NQmlmFSeJPPZY/nrQzm3sMmp04 Wy1U=; h=Message-Id:Date:From:To:Cc:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=OwwecpddgRakqZhjzwhqixsz55uV1F4PQj606 1pMs+8SSpBeDS9ixfHstSzkgMhdWzZrx9+F+qt3vNreZWOkDT3ZJ+S5yixh56K4Z99P F/7yhQ56GOg5PLfZvTzzqkaNW3iDyHoeNt351Eg9OkqKhISwweKAGSBzeM53Ak3fMYw = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Tue, 02 Feb 2010 08:22:29 -0500 Message-Id: <4B68270C.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Tue, 02 Feb 2010 08:22:20 -0500 From: "Jack Burton" To: "Doug Sauder" References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part705A5E1C.1__=" X-Auth-Type: Internal IP Cc: "martini@ietf.org" Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 13:21:54 -0000 --=__Part705A5E1C.1__= Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit How does the PBX learn its outbound numbers and DIDs when it registers? It needs to know this for more than just registration. I am not counting on registration as a configuration tool, just as a way to authenticate and identify the IP-PBX to the SSP. -Jack >>> Chris Gatch 2/2/2010 12:22 >>> >It might not be this way in every deployment, but I believe it's where the SMB-market service providers want to go. I am not aware of any standard approach for communicating provisioning related information to the IP PBX from the SSP. There are some proprietary implementations supported on a limited number of PBXs, but not very many. A solution to implicit registration should avoid any approach that requires the customer to know the phone numbers associated with its service prior to registering. The way it currently works under SIPconnect 1.0 is the SSP makes the association of the registered AOR to all other AORs such that the customer only needs to know the proxies* URL/address along with their username and password. From:martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Jack Burton Sent: Tuesday, February 02, 2010 6:03 AM To: Doug Sauder; Dean Willis Cc: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping Doug, In our case, we have an IP-PBX that we provide to some customers. It is provisioned as you suggest - the IP-PBX pulls credentials and such from a config server we (the SSP) maintain. For other customers, who provide their own IP-PBXs, there is no such communication. We provide them with a manual list of their allowed e164 numbers, including all DIDs, which they (or their VAR/PBX Vendor) must manually provision in their switches. In either case, we require registration in order for our SBCs to learn the dynamic IP address of the customer. -Jack Jack Burton Dir. Systems Engineering Cablevision jsburton@cablevision.com 516-803-9733 >>> Doug Sauder 2/2/2010 10:15 >>> Dean, I disagree with the PBX claiming its AORs at the SSP through a registration. I think this kind of "provisioning" is backwards compared to what real SSPs want. In my experience, subscribers are provisioned at the SSP, and it's a goal to have the PBX provisioned through some kind of auto-provisioning. For example, the PBX uses HTTP or FTP to get its configuration information from a server maintained by the SSP. This is how the PBX discovers its AORs, extensions, and so forth. It might not be this way in every deployment, but I believe it's where the SMB-market service providers want to go. Your approach seems to suggest that provisioning happens at the PBX, and it is then "pushed" to the SSP. I think the implicit registration is a better alternative, especially when such auto-provisioning is deployed. -- Doug On Feb 1, 2010, at 20:45 , Dean Willis wrote: -------------------------------------------------------- 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. -------------------------------------------------------- -------------------------------------------------------- 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. -------------------------------------------------------- --=__Part705A5E1C.1__= Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Content-Description: HTML
How does the PBX learn its outbound numbers and DIDs when it registers= ?  It needs to know this for more than just registration.  I am n= ot counting on registration as a configuration tool, just as a way to = authenticate and identify the IP-PBX to the SSP.
 
-Jack

>>> Chris Gatch <Chris.Gatch@cbeyond.net> = 2/2/2010 12:22 >>>

> It might not be this way in every deplo= yment, but I believe it's where the SMB-market service providers want to go= .

I am not aware of any standard approach for communicating pro= visioning related information to the IP PBX from the SSP.  There are s= ome proprietary implementations supported on a limited number of PBXs, but = not very many.  A solution to implicit registration should avoid any a= pproach that requires the customer to know the phone numbers associated wit= h its service prior to registering.  The way it currently works under = SIPconnect 1.0 is the SSP makes the association of the registered AOR to al= l other AORs such that the customer only needs to know the proxies' URL/add= ress along with their username and password.

 

From: martini-bounces@i= etf.org [mailto:martini-bounces@ietf.org] On Behalf Of Jack BurtonSent: Tuesday, February 02, 2010 6:03 AM
To: Doug Sauder= ; Dean Willis
Cc: Bernard Aboba; martini@ietf.org
Subject:<= /B> Re: [martini] Implications of multiple AOR/contact mapping

 

Doug,

 

In our case, we have an IP-PBX = that we provide to some customers.  It is provisioned as you suggest -= the IP-PBX pulls credentials and such from a config server we (the SSP) ma= intain.

 

For other customers, who provid= e their own IP-PBXs, there is no such communication.  We provide them = with a manual list of their allowed e164 numbers, including all DIDs, which= they (or their VAR/PBX Vendor) must manually provision in their switc= hes.

 

In either case, we require regi= stration in order for our SBCs to learn the dynamic IP address of the custo= mer.

 

-Jack

 

 

Jack Burton
Dir. Systems Engineering
C= ablevision
jsburton@cablevision.com
516-803-9733

>>> = Doug Sauder <dwsauder@dsauder.com> 2/2/2010 10:15 >>>
Dea= n,

I disagree with the PBX claiming its AORs at the SSP through a re= gistration.  I think this kind of "provisioning" is backwards compared= to what real SSPs want.  In my experience, subscribers are provisione= d at the SSP, and it's a goal to have the PBX provisioned through some kind= of auto-provisioning.  For example, the PBX uses HTTP or FTP to get i= ts configuration information from a server maintained by the SSP.  Thi= s is how the PBX discovers its AORs, extensions, and so forth.  It mig= ht not be this way in every deployment, but I believe it's where the SMB-ma= rket service providers want to go.

Your approach seems to suggest th= at provisioning happens at the PBX, and it is then "pushed" to the SSP.
=
I think the implicit registration is a better alternative, especially w= hen such auto-provisioning is deployed.

--
Doug

On Feb 1, = 2010, at 20:45 , Dean Willis wrote:


--------------------= ------------------------------------
The information transmitted in thi= s email and any of its attachments is intended only for the person or entit= y to which it is addressed and may contain Cablevision proprietary informat= ion, which is privileged, confidential, or subject to copyright belonging t= o Cablevision. Any review, retransmission, dissemination or other use of, o= r taking of any action in reliance upon, this information by persons or ent= ities other than the intended recipient is prohibited and may be unlawful. = If you received this in error, please contact the sender immediately and de= lete and destroy the communication and all of the attachments you have rece= ived and all copies thereof.
------------------------------------------= --------------


--------------------------------------------------------
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.
-------------------------------------------------------- --=__Part705A5E1C.1__=-- From dwsauder@dsauder.com Tue Feb 2 05:25: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 8D0D03A6925 for ; Tue, 2 Feb 2010 05:25: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=[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 pBVL3LOZ-YTJ for ; Tue, 2 Feb 2010 05:25:18 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5528E3A685E for ; Tue, 2 Feb 2010 05:25:18 -0800 (PST) Received: from [192.168.2.105] (c-68-50-30-250.hsd1.md.comcast.net [68.50.30.250]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MaJHc-1NIa162ZFg-00K3Qr; Tue, 02 Feb 2010 08:25:54 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-2--952861574 From: Doug Sauder In-Reply-To: <4B680653.6D98.00CB.0@cablevision.com> Date: Tue, 2 Feb 2010 08:25:47 -0500 Message-Id: <3DF106C5-3CAA-480C-9ACE-8909CA16E667@dsauder.com> References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> To: "Jack Burton" X-Mailer: Apple Mail (2.1077) X-Provags-ID: V01U2FsdGVkX1+xMQf0Ox1MuMzeuI94xZ0oypayPZKh1VTVeN1 UQRKNl4lDK/AGU2juI5EWQEfNxhFbjwBIAycG3NHKY0Iw/JcyO SFaRewEWXbper9cnHcl33uYJEUTYY40 Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 13:25:19 -0000 --Apple-Mail-2--952861574 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, Jack, for the feedback. I see two alternatives, where a registration is involved. In the alternative Dean proposes, the register indicates through a = regex-type expression the AORs that it wants routed to itself. In the alternative that I think makes more sense, the register does not = indicate all AORs, but registers a special AOR that represents the PBX = as a whole (which might also represent the main line of the business). = In this alternative, the register provides the necessary connectivity = information, but the decision about which AORs to route to the PBX is = made by the SSP based on provisioning at the SSP. For your deployments, which alternative works better? -- Doug On Feb 2, 2010, at 06:02 , Jack Burton wrote: > Doug, > =20 > In our case, we have an IP-PBX that we provide to some customers. It = is provisioned as you suggest - the IP-PBX pulls credentials and such = from a config server we (the SSP) maintain. > =20 > For other customers, who provide their own IP-PBXs, there is no such = communication. We provide them with a manual list of their allowed e164 = numbers, including all DIDs, which they (or their VAR/PBX Vendor) must = manually provision in their switches. > =20 > In either case, we require registration in order for our SBCs to learn = the dynamic IP address of the customer. > =20 > -Jack > =20 > =20 > Jack Burton > Dir. Systems Engineering > Cablevision > jsburton@cablevision.com > 516-803-9733 >=20 > >>> Doug Sauder 2/2/2010 10:15 >>> > Dean, >=20 > I disagree with the PBX claiming its AORs at the SSP through a = registration. I think this kind of "provisioning" is backwards compared = to what real SSPs want. In my experience, subscribers are provisioned = at the SSP, and it's a goal to have the PBX provisioned through some = kind of auto-provisioning. For example, the PBX uses HTTP or FTP to get = its configuration information from a server maintained by the SSP. This = is how the PBX discovers its AORs, extensions, and so forth. It might = not be this way in every deployment, but I believe it's where the = SMB-market service providers want to go. >=20 > Your approach seems to suggest that provisioning happens at the PBX, = and it is then "pushed" to the SSP. >=20 > I think the implicit registration is a better alternative, especially = when such auto-provisioning is deployed. >=20 > -- > Doug >=20 > On Feb 1, 2010, at 20:45 , Dean Willis wrote: >=20 >=20 > --------------------------------------------------------=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 > -------------------------------------------------------- --Apple-Mail-2--952861574 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Doug,
 
In our case, we have an IP-PBX that we provide to some = customers.  It is provisioned as you suggest - the IP-PBX pulls = credentials and such from a config server we (the SSP) maintain.
 
For other customers, who provide their own IP-PBXs, there is no = such communication.  We provide them with a manual list of their = allowed e164 numbers, including all DIDs, which they (or their VAR/PBX = Vendor) must manually provision in their switches.
 
In either case, we require registration in order for our SBCs to = learn the dynamic IP address of the customer.
 
-Jack
 
 
Jack Burton
Dir. Systems Engineering
Cablevision
jsburton@cablevision.com
5= 16-803-9733

>>> Doug Sauder <dwsauder@dsauder.com> = 2/2/2010 10:15 >>>
Dean,

I disagree with the PBX = claiming its AORs at the SSP through a registration.  I think this = kind of "provisioning" is backwards compared to what real SSPs = want.  In my experience, subscribers are provisioned at the SSP, = and it's a goal to have the PBX provisioned through some kind of = auto-provisioning.  For example, the PBX uses HTTP or FTP to get = its configuration information from a server maintained by the SSP.  = This is how the PBX discovers its AORs, extensions, and so forth.  = It might not be this way in every deployment, but I believe it's where = the SMB-market service providers want to go.

Your approach seems = to suggest that provisioning happens at the PBX, and it is then "pushed" = to the SSP.

I think the implicit registration is a better = alternative, especially when such auto-provisioning is = deployed.

--
Doug

On Feb 1, 2010, at 20:45 , Dean = Willis wrote:


--------------------------------------------------------
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.
= --------------------------------------------------------

= --Apple-Mail-2--952861574-- From jsburton@cablevision.com Tue Feb 2 05:41: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 5F5F628C0F2 for ; Tue, 2 Feb 2010 05:41:26 -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 HMC4m+kamko7 for ; Tue, 2 Feb 2010 05:41:24 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 391EF3A68A6 for ; Tue, 2 Feb 2010 05:41:23 -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 o12Dg1fh003647 for ; Tue, 2 Feb 2010 08:42:01 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o12Dg1fh003647 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1265118121; bh=EWECkRLYzk0GNg9A4QjScqoigFA07JQx/AZIfWa jELQ=; h=Message-Id:Date:From:To:Cc:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=zF86b0b98TxjHjZ2VDIiOBCDAjW3WbieHbvo8 31M77lDOK8rnYSd0NPtm+hVZSoPUHLkfF/lDWuNCM9ymRSkM6XZfERM43LRH6wYaP3K DPKsu/54afCW4nkpupNC9GbcRchA0s9PYqkP4Lso20/7nGJSzzOZrzPDp6jwXxz05cI = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Tue, 02 Feb 2010 08:42:00 -0500 Message-Id: <4B682BA2.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Tue, 02 Feb 2010 08:41:54 -0500 From: "Jack Burton" To: "Doug Sauder" References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> <3DF106C5-3CAA-480C-9ACE-8909CA16E667@dsauder.com> In-Reply-To: <3DF106C5-3CAA-480C-9ACE-8909CA16E667@dsauder.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD2F8FCB2.1__=" X-Auth-Type: Internal IP Cc: martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 13:41:26 -0000 --=__PartD2F8FCB2.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The SECOND alternative is exactly what we expect and is what we are doing today. Registration of the main number "implies" registration of the children (DID numbers for in and out bound) behind it. We tell the customer their main number and provide its credentials. In addition, we tell the customer their DIDs, so that they can map the DIDs to their internal extensions. When the IP-PBX registers, we allow calls in and out to/from the main number and all associated children from the customer's dynamic IP address. Dean's proposal is a bit ambitious, and probably better solved by a service provisioning method. When created, it could eliminate the need to manually provide the DID information. This would foster quicker implementation through backward compatibility. Thanks, Jack >>> Doug Sauder 2/2/2010 13:25 >>> Thanks, Jack, for the feedback. I see two alternatives, where a registration is involved. In the alternative Dean proposes, the register indicates through a regex-type expression the AORs that it wants routed to itself. In the alternative that I think makes more sense, the register does not indicate all AORs, but registers a special AOR that represents the PBX as a whole (which might also represent the main line of the business). In this alternative, the register provides the necessary connectivity information, but the decision about which AORs to route to the PBX is made by the SSP based on provisioning at the SSP. For your deployments, which alternative works better? -- Doug On Feb 2, 2010, at 06:02 , Jack Burton wrote: Doug, In our case, we have an IP-PBX that we provide to some customers. It is provisioned as you suggest - the IP-PBX pulls credentials and such from a config server we (the SSP) maintain. For other customers, who provide their own IP-PBXs, there is no such communication. We provide them with a manual list of their allowed e164 numbers, including all DIDs, which they (or their VAR/PBX Vendor) must manually provision in their switches. In either case, we require registration in order for our SBCs to learn the dynamic IP address of the customer. -Jack Jack Burton Dir. Systems Engineering Cablevision jsburton@cablevision.com 516-803-9733 >>> Doug Sauder 2/2/2010 10:15 >>> Dean, I disagree with the PBX claiming its AORs at the SSP through a registration. I think this kind of "provisioning" is backwards compared to what real SSPs want. In my experience, subscribers are provisioned at the SSP, and it's a goal to have the PBX provisioned through some kind of auto-provisioning. For example, the PBX uses HTTP or FTP to get its configuration information from a server maintained by the SSP. This is how the PBX discovers its AORs, extensions, and so forth. It might not be this way in every deployment, but I believe it's where the SMB-market service providers want to go. Your approach seems to suggest that provisioning happens at the PBX, and it is then "pushed" to the SSP. I think the implicit registration is a better alternative, especially when such auto-provisioning is deployed. -- Doug On Feb 1, 2010, at 20:45 , Dean Willis wrote: -------------------------------------------------------- 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. -------------------------------------------------------- -------------------------------------------------------- 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. -------------------------------------------------------- --=__PartD2F8FCB2.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
The SECOND alternative is exactly what we expect and is what we are do= ing today.  Registration of the main number "implies" registration of = the children (DID numbers for in and out bound) behind it.  We tell th= e customer their main number and provide its credentials.  In addition= , we tell the customer their DIDs, so that they can map the DIDs to their i= nternal extensions.
 
When the IP-PBX registers, we allow calls in and out to/from the main = number and all associated children from the customer's dynamic IP address.<= /DIV>
 
Dean's proposal is a bit ambitious, and probably better solved by a se= rvice provisioning method.  When created, it could eliminate the = need to manually provide the DID information.  This would foster quick= er implementation through backward compatibility.
 
Thanks,
Jack

>>> Doug Sauder <dwsauder@dsauder.com> 2/2/= 2010 13:25 >>>
Thanks, Jack, for the feedback.

I see two alternatives, where a registration is involved.

In the alternative Dean proposes, the register indicates through a reg= ex-type expression the AORs that it wants routed to itself.

In the alternative that I think makes more sense, the register does no= t indicate all AORs, but registers a special AOR that represents the PBX as= a whole (which might also represent the main line of the business).  = In this alternative, the register provides the necessary connectivity infor= mation, but the decision about which AORs to route to the PBX is made by th= e SSP based on provisioning at the SSP.

For your deployments, which alternative works better?

--
Doug

On Feb 2, 2010, at 06:02 , Jack Burton wrote:

Doug,
 
In our case, we have an IP-PBX that we provide to some customers. = ; It is provisioned as you suggest - the IP-PBX pulls credentials and such = from a config server we (the SSP) maintain.
 
For other customers, who provide their own IP-PBXs, there is no such c= ommunication.  We provide them with a manual list of their allowed e16= 4 numbers, including all DIDs, which they (or their VAR/PBX Vendor) mu= st manually provision in their switches.
 
In either case, we require registration in order for our SBCs to learn= the dynamic IP address of the customer.
 
-Jack
 
 
Jack Burton
Dir. Systems Engineering
Cablevision
jsburton@cablevision.com
516-803-973= 3

>>> Doug Sauder <dwsauder@dsauder.com> 2/2/2010 10:= 15 >>>
Dean,

I disagree with the PBX claiming its AORs a= t the SSP through a registration.  I think this kind of "provisioning"= is backwards compared to what real SSPs want.  In my experience, subs= cribers are provisioned at the SSP, and it's a goal to have the PBX provisi= oned through some kind of auto-provisioning.  For example, the PBX use= s HTTP or FTP to get its configuration information from a server maintained= by the SSP.  This is how the PBX discovers its AORs, extensions, and = so forth.  It might not be this way in every deployment, but I believe= it's where the SMB-market service providers want to go.

Your approa= ch seems to suggest that provisioning happens at the PBX, and it is then "p= ushed" to the SSP.

I think the implicit registration is a better alt= ernative, especially when such auto-provisioning is deployed.

--
= Doug

On Feb 1, 2010, at 20:45 , Dean Willis wrote:


--------------------------------------------------------
The info= rmation transmitted in this email and any of its attachments is intended on= ly for the person or entity to which it is addressed and may contain Cablev= ision proprietary information, which is privileged, confidential, or subjec= t to copyright belonging to Cablevision. Any review, retransmission, dissem= ination or other use of, or taking of any action in reliance upon, this inf= ormation by persons or entities other than the intended recipient is prohib= ited 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.
----------------= ----------------------------------------


--------------------------------------------------------
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.
-------------------------------------------------------- --=__PartD2F8FCB2.1__=-- From prvs=642ad67c6=Chris.Gatch@cbeyond.net Tue Feb 2 06:37: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 350ED3A6954 for ; Tue, 2 Feb 2010 06:37: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 s0AfUugypPEu for ; Tue, 2 Feb 2010 06:37:07 -0800 (PST) Received: from mx1.cbeyond.net (mx1.cbeyond.net [64.238.96.29]) by core3.amsl.com (Postfix) with ESMTP id 6DADB28C1FA for ; Tue, 2 Feb 2010 06:27:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFDFZ0tINoKs/2dsb2JhbACaPrAGAQMEAY1vgjYcBoFtBA X-IronPort-AV: E=Sophos;i="4.49,390,1262581200"; d="scan'208";a="15226282" Received: from exhub01.corp.cbeyond.net (HELO exchange.cbeyond.net) ([72.54.130.172]) by mx1.cbeyond.net with ESMTP/TLS/RC4-MD5; 02 Feb 2010 09:27:41 -0500 Received: from CBYMBX01.corp.cbeyond.net ([10.6.180.15]) by exhub01.corp.cbeyond.net ([10.6.18.36]) with mapi; Tue, 2 Feb 2010 09:27:41 -0500 From: Chris Gatch To: Jack Burton Date: Tue, 2 Feb 2010 09:27:39 -0500 Thread-Topic: [martini] Implications of multiple AOR/contact mapping Thread-Index: AcqkE+Br/O4x2zb4S/2SFG9zJbIN/w== Message-ID: <23E00349-B5D0-479B-A517-F80B71E1519A@cbeyond.net> References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> <4B68270C.6D98.00CB.0@cablevision.com> In-Reply-To: <4B68270C.6D98.00CB.0@cablevision.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] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 14:37:08 -0000 To the extent the numbers are needed to configure the PBX they are provided= to the customer through a process external to SIPconnect 1.0. I am personally a proponent of standardizing a method of communicating prov= isioning related data from the SSP to the PBX, but that is clearly out of s= cope for this working group. At Cbeyond we have a provisioning server that= will authenticate a request from a customer and return an XML file with pr= ovisioning data, and this is supported on a couple of PBXs. That being sai= d, there are many ways to handle this, and the value is in the agreement am= ong those of us in industry on a common approach. On Feb 2, 2010, at 8:22 AM, Jack Burton wrote: How does the PBX learn its outbound numbers and DIDs when it registers? It= needs to know this for more than just registration. I am not counting on = registration as a configuration tool, just as a way to authenticate and ide= ntify the IP-PBX to the SSP. -Jack >>> Chris Gatch > 2= /2/2010 12:22 >>> > It might not be this way in every deployment, but I believe it's where th= e SMB-market service providers want to go. I am not aware of any standard approach for communicating provisioning rela= ted information to the IP PBX from the SSP. There are some proprietary imp= lementations supported on a limited number of PBXs, but not very many. A s= olution to implicit registration should avoid any approach that requires th= e customer to know the phone numbers associated with its service prior to r= egistering. The way it currently works under SIPconnect 1.0 is the SSP mak= es the association of the registered AOR to all other AORs such that the cu= stomer only needs to know the proxies' URL/address along with their usernam= e and password. From: martini-bounces@ietf.org [mailto:mar= tini-bounces@ietf.org] On Behalf Of Jack Burton Sent: Tuesday, February 02, 2010 6:03 AM To: Doug Sauder; Dean Willis Cc: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping Doug, In our case, we have an IP-PBX that we provide to some customers. It is pr= ovisioned as you suggest - the IP-PBX pulls credentials and such from a con= fig server we (the SSP) maintain. For other customers, who provide their own IP-PBXs, there is no such commun= ication. We provide them with a manual list of their allowed e164 numbers,= including all DIDs, which they (or their VAR/PBX Vendor) must manually pro= vision in their switches. In either case, we require registration in order for our SBCs to learn the = dynamic IP address of the customer. -Jack Jack Burton Dir. Systems Engineering Cablevision jsburton@cablevision.com 516-803-9733 >>> Doug Sauder > 2/2/201= 0 10:15 >>> Dean, I disagree with the PBX claiming its AORs at the SSP through a registration= . I think this kind of "provisioning" is backwards compared to what real S= SPs want. In my experience, subscribers are provisioned at the SSP, and it= 's a goal to have the PBX provisioned through some kind of auto-provisionin= g. For example, the PBX uses HTTP or FTP to get its configuration informat= ion from a server maintained by the SSP. This is how the PBX discovers its= AORs, extensions, and so forth. It might not be this way in every deploym= ent, but I believe it's where the SMB-market service providers want to go. Your approach seems to suggest that provisioning happens at the PBX, and it= is then "pushed" to the SSP. I think the implicit registration is a better alternative, especially when = such auto-provisioning is deployed. -- Doug On Feb 1, 2010, at 20:45 , Dean Willis wrote: -------------------------------------------------------- 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. -------------------------------------------------------- -------------------------------------------------------- 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. -------------------------------------------------------- From john.elwell@siemens-enterprise.com Tue Feb 2 07:04: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 B043B3A6B15 for ; Tue, 2 Feb 2010 07:04:04 -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 udJ-Mu7zjuog for ; Tue, 2 Feb 2010 07:04:03 -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 3EECE3A6B11 for ; Tue, 2 Feb 2010 07:04:02 -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-749587; Tue, 2 Feb 2010 16:04:40 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 4CE931EB82B0; Tue, 2 Feb 2010 16:04:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 2 Feb 2010 16:04:40 +0100 From: "Elwell, John" To: Jack Burton , Doug Sauder Date: Tue, 2 Feb 2010 16:04:39 +0100 Thread-Topic: [martini] Implications of multiple AOR/contact mapping Thread-Index: AcqkDYPslZBHtvSBT8+C0Wj85j2X/AACxxuQ Message-ID: References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> <3DF106C5-3CAA-480C-9ACE-8909CA16E667@dsauder.com> <4B682BA2.6D98.00CB.0@cablevision.com> In-Reply-To: <4B682BA2.6D98.00CB.0@cablevision.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] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 15:04:04 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Jack Burton > Sent: 02 February 2010 13:42 > To: Doug Sauder > Cc: martini@ietf.org > Subject: Re: [martini] Implications of multiple AOR/contact mapping >=20 > The SECOND alternative is exactly what we expect and is what=20 > we are doing today. Registration of the main number=20 > "implies" registration of the children (DID numbers for in=20 > and out bound) behind it. We tell the customer their main=20 > number and provide its credentials. In addition, we tell the=20 > customer their DIDs, so that they can map the DIDs to their=20 > internal extensions. > =20 > When the IP-PBX registers, we allow calls in and out to/from=20 > the main number and all associated children from the=20 > customer's dynamic IP address. > =20 > Dean's proposal is a bit ambitious, and probably better=20 > solved by a service provisioning method. When created, it=20 > could eliminate the need to manually provide the DID=20 > information. This would foster quicker implementation=20 > through backward compatibility. [JRE] I agree. A single AOR in the REGISTER request should be sufficient to= cover the needs of MARTINI. John > =20 > Thanks, > Jack >=20 > >>> Doug Sauder 2/2/2010 13:25 >>> > Thanks, Jack, for the feedback. >=20 > I see two alternatives, where a registration is involved. >=20 > In the alternative Dean proposes, the register indicates=20 > through a regex-type expression the AORs that it wants routed=20 > to itself. >=20 > In the alternative that I think makes more sense, the=20 > register does not indicate all AORs, but registers a special=20 > AOR that represents the PBX as a whole (which might also=20 > represent the main line of the business). In this=20 > alternative, the register provides the necessary connectivity=20 > information, but the decision about which AORs to route to=20 > the PBX is made by the SSP based on provisioning at the SSP. >=20 > For your deployments, which alternative works better? >=20 > -- > Doug >=20 > On Feb 2, 2010, at 06:02 , Jack Burton wrote: >=20 >=20 > Doug, > =20 > In our case, we have an IP-PBX that we provide to some=20 > customers. It is provisioned as you suggest - the IP-PBX=20 > pulls credentials and such from a config server we (the SSP) maintain. > =20 > For other customers, who provide their own IP-PBXs,=20 > there is no such communication. We provide them with a=20 > manual list of their allowed e164 numbers, including all=20 > DIDs, which they (or their VAR/PBX Vendor) must manually=20 > provision in their switches. > =20 > In either case, we require registration in order for=20 > our SBCs to learn the dynamic IP address of the customer. > =20 > -Jack > =20 > =20 > Jack Burton > Dir. Systems Engineering > Cablevision > jsburton@cablevision.com > 516-803-9733 > =09 > >>> Doug Sauder 2/2/2010 10:15 >>> > Dean, > =09 > I disagree with the PBX claiming its AORs at the SSP=20 > through a registration. I think this kind of "provisioning"=20 > is backwards compared to what real SSPs want. In my=20 > experience, subscribers are provisioned at the SSP, and it's=20 > a goal to have the PBX provisioned through some kind of=20 > auto-provisioning. For example, the PBX uses HTTP or FTP to=20 > get its configuration information from a server maintained by=20 > the SSP. This is how the PBX discovers its AORs, extensions,=20 > and so forth. It might not be this way in every deployment,=20 > but I believe it's where the SMB-market service providers want to go. > =09 > Your approach seems to suggest that provisioning=20 > happens at the PBX, and it is then "pushed" to the SSP. > =09 > I think the implicit registration is a better=20 > alternative, especially when such auto-provisioning is deployed. > =09 > -- > Doug > =09 > On Feb 1, 2010, at 20:45 , Dean Willis wrote: > =09 > =09 >=20 > --------------------------------------------------------=20 > The information transmitted in this email and any of=20 > its attachments is intended only for the person or entity to=20 > which it is addressed and may contain Cablevision proprietary=20 > information, which is privileged, confidential, or subject to=20 > copyright belonging to Cablevision. Any review,=20 > retransmission, dissemination or other use of, or taking of=20 > any action in reliance upon, this information by persons or=20 > entities other than the intended recipient is prohibited and=20 > may be unlawful. If you received this in error, please=20 > contact the sender immediately and delete and destroy the=20 > communication and all of the attachments you have received=20 > and all copies thereof.=20 > -------------------------------------------------------- >=20 >=20 >=20 > --------------------------------------------------------=20 > The information transmitted in this email and any of its=20 > attachments is intended only for the person or entity to=20 > which it is addressed and may contain Cablevision proprietary=20 > information, which is privileged, confidential, or subject to=20 > copyright belonging to Cablevision. Any review,=20 > retransmission, dissemination or other use of, or taking of=20 > any action in reliance upon, this information by persons or=20 > entities other than the intended recipient is prohibited and=20 > may be unlawful. If you received this in error, please=20 > contact the sender immediately and delete and destroy the=20 > communication and all of the attachments you have received=20 > and all copies thereof.=20 > -------------------------------------------------------- > = From john.elwell@siemens-enterprise.com Tue Feb 2 07:05: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 C44E03A6B11 for ; Tue, 2 Feb 2010 07:05:19 -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.064, 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 ebm7p2Clszq2 for ; Tue, 2 Feb 2010 07:05:19 -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 A80683A6B15 for ; Tue, 2 Feb 2010 07:05:18 -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-750067; Tue, 2 Feb 2010 16:05:56 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4FCC623F0278; Tue, 2 Feb 2010 16:05:56 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 2 Feb 2010 16:05:56 +0100 From: "Elwell, John" To: Christer Holmberg , Dean Willis Date: Tue, 2 Feb 2010 16:05:55 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqjpwB+2Uw5IaxoQ2S90N/Jkss5pwAKCNUwAAMQuKAAAPj5AAABAjYgAASdlJAACH/mQA== Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@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: Hadriel Kaplan , "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: Tue, 02 Feb 2010 15:05:19 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 02 February 2010 10:54 > To: Elwell, John; Dean Willis > Cc: martini@ietf.org; Hadriel Kaplan > Subject: RE: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 > =20 > =20 > > > >>>>Last, my understanding is still that, from a SIP=20 > > network point of=20 > > > >>>>view, the PBX is seen as a single Contact, but in=20 > your solution=20 > > > >>>>every PBX user explicitly (eventhough a wildcard > > > mechanism is used) > > > >>>>registers with the SIP network. > > > >>>> > > > >>>=20 > > > >>>Exactly. That's why this approach works. Absolutely nothing is=20 > > > >>>"implicit", everything is explicit. But it has very=20 > little more=20 > > > >>>overhead than the hackneyed implicit registrations,=20 > and entirely=20 > > > >>>solves the "how does the PBX figure out which user" > > > >>>mess that happens if there is only one Contact for many=20 > > different=20 > > > >>>AORs. > > > >>=20 > > > >>But, that is not how PBXs work. > > > >[JRE] Taking the example from the "Implications" thread, the PBX=20 > > > >would receive: > > > >sip:1972519xxxx@pbx.org or > > > >sip:1972519xxxx@10.1.2.3 > > > >In either case, it is a contact URI as far as the SSP is=20 > > concerned,=20 > > > >but the PBX can treat those as AORs from its own=20 > > perspective. I think=20 > > > >there are practical examples of it working like this today. > > >=20 > > > Ok, you probably know more about SIPConnect etc than I do. > > >=20 > > > But, what if the PBX is using outbound? I assume the same=20 > > instance id=20 > > > and gr values are going to be used for all PBX users,=20 > > eventhough each=20 > > > PBX user has a unique Contact within the SSP? > > [JRE] Yes - this was touched on in the other recent thread. >=20 > In that case, why would we need to send a wildcarded Contact=20 > (as suggested by Dean)? Why not simply register the IPX IP=20 > address, and the registrar then adds the user part for=20 > inbound requests? [JRE] I think this is a second order discussion, whether plain substitution= of the user part will do or whether some sort of manipulation is required. John >=20 > Regards, >=20 > Christer > = From richard@shockey.us Tue Feb 2 07: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 DBC093A6B1B for ; Tue, 2 Feb 2010 07:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.507, 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 YvWLG5IVLtPk for ; Tue, 2 Feb 2010 07:25:17 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 68B1B3A6B19 for ; Tue, 2 Feb 2010 07:25:17 -0800 (PST) Received: (qmail 4866 invoked by uid 0); 2 Feb 2010 15:25:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 2 Feb 2010 15:25:54 -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=adQ7mmJL8XHbdFiMi/T1i5zqcCXNd/NnYJPIPhBkjAPRQPfhU6P0UH4l3zdvDMla9l253iVjec6BoHAgs8mbRN/qWsmiQxAnPyn3A52ov8k+Eiz/UUE5r81dz/o0m8cy; 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 1NcKdW-0004hz-2H; Tue, 02 Feb 2010 08:25:54 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Hadriel Kaplan'" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> In-Reply-To: Date: Tue, 2 Feb 2010 10:25:50 -0500 Message-ID: <012901caa41c$014921d0$03db6570$@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: AcqjpnBzP+IDx3LvRyOKtrMTbvnwZQAdPp2w 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: 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: Tue, 02 Feb 2010 15:25:19 -0000 You know Dean you have a good point here that a tightly written applicibality statement could bound these issues pretty well. First: as we all seem to agree its about telephone numbers. Second ..in general the deployments using this scheme are PRI swaps.. by that I mean the SSP is also responsible for the Layer 1 connection hence the security issues are bounded. This is why there has been little or no push to deploy TLS in these environments. And for what its worth .. I don't think using TEL URI's here is going to work. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, February 01, 2010 8:24 PM To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first On Jan 31, 2010, at 7:29 PM, Hadriel Kaplan wrote: > > So if I understand what you're proposing, on the wire the routed > request would look like draft-shaken or whatever except the real > registered Contact-URI is not inserted as a Route header. And the > description of the process taking place in the RP is that it is > doing rfc3261-style AoR->Contact resolution, instead of > "retargeting" to the domain/ip of the PBX. Right? > I believe that's correct. > 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. The problem with SIP URIs is: what domain would go in the To:? Clearly it has to be the domain of the SSP, for all of our domain- authority work to do what it is supposed to do. There are still some questions about the security implications of multiple registrations over one Outbound connection, but I'm thinking (hoping?) those could be resolved by a carefully worded applicability statement. -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Tue Feb 2 08:01: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 A67993A6B2A for ; Tue, 2 Feb 2010 08:01:35 -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 JS5nmwJhW12y for ; Tue, 2 Feb 2010 08:01:32 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 67D8E3A6B1B for ; Tue, 2 Feb 2010 08:01:32 -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 0Lk8Kw-1OA1K809MI-00bz0t; Tue, 02 Feb 2010 11:02:10 -0500 Message-ID: <9263B03D945A43B2A6C54D80728520B2@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" References: <4B6767A4.8000008@nostrum.com> Date: Tue, 2 Feb 2010 10:01:53 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E4F_01CAA3EE.BEBD2050" 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/l8BrWGDJKimvq+5EHuqHs2NRq1AVfNDhCuuL aKnllYZUFcVrw+y88NJz8JKAoO7CYqLOnph63YOBpOmgoaNgjy wu059y/etBkTLmkoItKle65gSNurR4k7CgHCKfg1uE= Cc: martini@ietf.org Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 16:01:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0E4F_01CAA3EE.BEBD2050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adam, I'm getting a late start this morning, and your use cases posting was at = the top of my queue (followed by, so far, about 40 other MARTINI = e-mails). Speaking as co-chair, I wanted to thank you for providing this = structure. I'm expecting it will be very helpful as we work through the = details. I probably won't follow up on anything else until I'm current (see you = guys in a bit). Spencer ----- Original Message -----=20 From: Adam Roach=20 To: martini@ietf.org=20 Sent: Monday, February 01, 2010 5:45 PM Subject: [martini] Use Cases: what's important, what's not The more we talk about this, the further apart opinions seem to get. = There appears to be a lot of ocean boiling going on right now, such that = even when we can decide on a fairly narrow scope ("phone numbers only"), = the system behavior that people expect appears to vary literally from = person to person. I'm going to try to do something like I did before with the diagrams, = this time focusing on just what happens for E.164 numbers. I'll continue = with using the same dead companies as before (CentricVoice as the SSP, = and Pan-Am as the PBX). In particular, I'm assuming that the tentative (albeit far from = unanimous) agreement to do an initial batch of work towards E.164 = numbers means that these kinds of use cases are not under discussion at = the moment: Internet CentricVoice = Pan-Am |INVITE | = | |sip:not-a-number@centricvoice.com | = | |--------------------------------->| = | | |INVITE = | | = |sip:some-other-string@pan-am.com | | = |--------------------------------->| Internet CentricVoice = Pan-Am |INVITE | = | |sip:not-a-number@pan-am.com | = | |--------------------------------->| = | | |INVITE = | | = |sip:some-other-string@pan-am.com | | = |--------------------------------->| So, ignoring those, we seem to still have a huge disconnect on what = the SSP needs to be able to do as a result of the MARTINI operations. = Now, one of the nice things we get from E.164 numbers is that usernames = now become unique. We can specify transformations such that the username = that arrives at the SSP stays the same as it passes through the SSP. = Unlike my earlier examples, I'm going to assume that limiting to E.164 = enables this kind of trivial transformation. Not in the *general* case, = of course -- only for MARTINI-routed E.164 numbers. As you read through these, try to place each use case in one of the = following categories: 1.. This use case by itself is sufficient for the architecture {I = am/my customers are} trying to deploy 2.. This use case is necessary for the architecture {I am/my = customers are} trying to deploy, but requires other use cases also. 3.. This use case is neither necessary nor sufficient for the = architecture {I am/my customers are} trying to deploy.=20 Frankly, I would expect almost everyone will be able to place each use = case in category #1. All of these solutions certainly allow the PBX to = figure out who the call is supposed to be sent to, and that appears to = be the key criteria for the inbound messages. -------------------------------------------------------------------------= ----- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. RFC3263 for "pan-am.com" is not relevant. Internet CentricVoice = Pan-Am |INVITE | = | |sip:+12145550105@centricvoice.com | = | |--------------------------------->| = | | |INVITE = | | |sip:+12145550105@pan-am.com = | | = |--------------------------------->| In this use case, the SSP receives a URI indicating its own domain. = The SSP is provisioned to know that +12145550105 belongs to Pan-Am. = Having received information from Pan-Am about its PBX's IP address, it = changes the domain to "pan-am.com," keeps the user ID, ignores RFC 3263 = procedures, and sends the request to the MARTINI-registered IP address = it has for Pan-Am. The key drawback for this use case is the disregard for RFC3263 = procedures. -------------------------------------------------------------------------= ----- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "pan-am.com" resolves to the CentricVoice servers. Internet CentricVoice = Pan-Am |INVITE | = | |sip:+12145550105@pan-am.com | = | |--------------------------------->| = | | |INVITE = | | |sip:+12145550105@pan-am.com = | | = |--------------------------------->| In this use case, the SSP receives a URI indicating the domain for = pan-am.com. Having received information from Pan-Am about its PBX's IP = address, it leaves the Request-URI alone, ignores RFC 3263 procedures, = and sends the request to the MARTINI-registered IP address it has for = Pan-Am. Note that this use case is predicated on an external entity -- = something on the other side of the "Internet" cloud -- being able to = take the E.164 number "+12145550105" and figure out that it needs to go = to the domain "pan-am.com". I emphasize this because I know some people = are interested in models in which is tenable to track "phone number to = SSP" mapping, while the relatively larger number of "phone number to end = customer" mappings might be unpalatable. The key drawbacks for this use case are: 1.. The disregard for RFC3263 procedures 2.. Ambiguity around which SIP nodes are "responsible for" = pan-am.com (in the RFC 3261 sense of that word). Cullen had a litmus = test for this: is CentricVoice allowed to redirect calls for pan-am.com = to a voicemail server or answering service?=20 Given that 3261 lacks a formal description of "responsible for," we = can potentially define the problem of "responsible for" away (as Keith = has proposed) -- but I'm pretty certain it's not within MARTINI's scope = to clarify the terms appearing in RFC 3261. I think that would need to = go back to DISPATCH, and I doubt we want to wait for such an effort to = complete. -------------------------------------------------------------------------= ----- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice = Pan-Am |INVITE | = | |sip:+12145550105@centricvoice.com | = | |--------------------------------->| = | | |INVITE = | | |sip:+12145550105@192.168.17.25 = | | = |--------------------------------->| In this use case, the SSP receives a request for its own domain. The = SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having = received information from Pan-Am about its PBX's IP address, it changes = the domain to that registered IP address (192.168.17.25), keeps the user = ID, correctly invokes RFC 3263 procedures, and sends the request to the = resulting host (192.168.17.25). This use case does not suffer from any of the drawbacks discussed to = date, other than differing from the model that is currently deployed for = bulk registrations (even though it is functionally identical to the = model deployed for single registrations). -------------------------------------------------------------------------= ----- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "pan-am.com" resolves to the CentricVoice servers. Internet CentricVoice = Pan-Am |INVITE | = | |sip:+12145550105@pan-am.com | = | |--------------------------------->| = | | |INVITE = | | |sip:+12145550105@192.168.17.25 = | | = |--------------------------------->| In this use case, the SSP receives a URI indicating the domain for = pan-am.com. Having received information from Pan-Am about its PBX's IP = address, it changes the domain to that registered IP address = (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 = procedures, and sends the request to the resulting host (192.168.17.25). Like use case 3, this use case does not suffer from any of the = drawbacks discussed to date, other than differing from the model that is = currently deployed for bulk registrations (even though it is = functionally identical to the model deployed for single registrations). = However, it is predicated on an external entity -- something on the = other side of the "Internet" cloud -- being able to take the E.164 = number "+12145550105" and figure out that it needs to go to the domain = "pan-am.com". -------------------------------------------------------------------------= ----- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice = Pan-Am |INVITE | = | |sip:+12145550105@centricvoice.com | = | |--------------------------------->| = | | |INVITE = | | |tel:+12145550105 = | | = |--------------------------------->| In this use case, the SSP receives a URI indicating its own domain. = The SSP is provisioned to know that +12145550105 belongs to Pan-Am. It = changes the R-URI to a tel: URI containing only the E.164 number in = question. Having received information from Pan-Am about its PBX's IP = address, it sends the request to the resulting host (192.168.17.25). = Since the URI in question is a TEL URI, RFC3263 issues are avoided = altogether, eliminating any alt-root considerations. The major drawback to this use case is that it (likely) requires the = ability to register TEL URIs, which is currently normatively forbidden = by RFC 3261. While this is tractable, it would require companion work in = SIPCORE to relax this normative requirement. It also would likely = require more mechanism than other approaches, since we're effectively = adding on a new URI-to-host address resolution procedure. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 5a =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A variation on Use Case 5, this use case ends up with a R-URI of the = PBX's lead number, with an extension parameter that indicates the = desired extension on the PBX: Internet CentricVoice = Pan-Am |INVITE | = | |sip:+12145550105@centricvoice.com | = | |--------------------------------->| = | | |INVITE = | | = |tel:+12145550100;extension=3D1214555| | | = 0105| | = |--------------------------------->| This is effectively the exact same procedure as Use Case 5; however, = it may make contact registration somewhat easier (depending on the exact = mechanism used to communicate domain IP addresses). -------------------------------------------------------------------------= ----- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice = Pan-Am |INVITE | = | |sip:+12145550105@centricvoice.com | = | |--------------------------------->|INVITE = | | = |sip:+12145550105@centricvoice.com | | |Route: = | | = |--------------------------------->| In this example, In this use case, the SSP receives a URI indicating = its own domain. The SSP is provisioned to know that +12145550105 belongs = to Pan-Am. It pushes the MARTINI-registered contact into the route set, = leaves the Request-URI unmodified, invokes RFC 3263 procedures (on the = Route) and sends the request to the resulting host. A key drawback to this use case is that it cannot be effected using = REGISTER without radically changing the semantics of REGISTER (i.e., = registering a path towards an AOR instead of a contact for an AOR). = These changes necessarily require intermediaries who are a party to the = REGISTER transaction (e.g., using Path and/or Service-Route) to = understand these changed semantics, and would require the use of a = Proxy-Require to avoid the ensuing problems. Using a method other than = REGISTER eliminates this class of problems. A second major drawback to this approach pertains to domain = responsibility: unless the Pan-Am PBX is "responsible for" = centricvoice.com, it is in violation of SIP routing procedures if it = fails to route it back to CentricVoice: "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." In = practice, I imagine it wants to route it to one of its internal = extensions. -------------------------------------------------------------------------= ----- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 7 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice = Pan-Am |INVITE | = | |sip:+12145550105@centricvoice.com | = | |--------------------------------->|INVITE sip:pbx@192.168.17.25 = | | |History-Info: = sip:+12145550105@cen| | | = tricvoice.com| =20 | = |--------------------------------->| Similar to use case 6, except the SSP swaps out the registered Contact = URI for the Request-URI, and squirrels the incoming R-URI (containing = the phone number) away in a History-Info header field. On the plus side, this looks a lot like normal proxy/registrar = behavior. Drawbacks include defining concrete procedures around which = History-Info entry to use (which is a problem the 4244bis draft is = currently struggling with), especially in the case that there are = intermediaries between the SSP and the PBX. We would also be creating a = normative dependency on the 4244bis document, which may delay a final = delivery of MARTINI work substantially. -------------------------------------------------------------------------= ----- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Now, I've heard and read things that imply that each these use cases = are under consideration by at least one person. I think we need to = focus. Clearly just saying "phone numbers" is not sufficient. Look back = over how you rated each of the use cases relative to the "sufficient," = "necessary but not sufficient," and "neither necessary nor sufficient" = criteria. I think you'll find that, if you were honest with yourself, = all or most of these use cases fall into the first category. I'm not = saying you *like* them all -- merely that they will get the job done, if = push were to come to shove. So, I think we need to pick one and work on the mechanism required to = enable it. And I think we need to be vigilant against scope creep. As we = get into mechanism, it will be overwhelmingly tempting to say, "oh, but = we can add on Use Case X if we just do *this* small thing!" But those = small things can spiral out of control. All other things being equal, I have a strong preference for Use Case = 3, as its only real drawback is that it varies from the demonstrably = flawed [1] mechanism that showed up on the IETF's doorstep. Any other = approach is going to require interested parties coming to consensus on = the issues associated with the other use cases, and I think we've seen = that won't be a very fast process. /a [1] Lest this offend anyone as being too general a criticism, I refer = to the set of shortcomings enumerated here: = http://www.ietf.org/mail-archive/web/martini/current/msg00412.html -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_0E4F_01CAA3EE.BEBD2050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Adam,
 
I'm getting a late start this morning, and your use = cases=20 posting was at the top of my queue (followed by, so far, about 40 other = MARTINI=20 e-mails).
 
Speaking as co-chair, I wanted to thank you for = providing this=20 structure. I'm expecting it will be very helpful as we work through the=20 details.
 
I probably won't follow up on anything else until = I'm current=20 (see you guys in a bit).
 
Spencer
----- Original Message -----
From:=20 Adam = Roach
Sent: Monday, February 01, 2010 = 5:45=20 PM
Subject: [martini] Use Cases: = what's=20 important, what's not

The more we talk about this, the further apart opinions = seem to=20 get. There appears to be a lot of ocean boiling going on right now, = such that=20 even when we can decide on a fairly narrow scope ("phone numbers = only"), the=20 system behavior that people expect appears to vary literally from = person to=20 person.

I'm going to try to do something like I did before with = the=20 diagrams, this time focusing on just what happens for E.164 numbers. = I'll=20 continue with using the same dead companies as before (CentricVoice as = the=20 SSP, and Pan-Am as the PBX).

In particular, I'm assuming that = the=20 tentative (albeit far from unanimous) agreement to do an initial batch = of work=20 towards E.164 numbers means that these kinds of use cases are not = under=20 discussion at the moment:
<Out Of=20 = Scope>

Internet   &n= bsp;           &nb= sp;        =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:not-a-number@centricvoice.= com=20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|     &nbs= p;            = ;            =    =20 |
   =20 = |            =             &= nbsp;        =20 = |INVITE           =             &= nbsp;   =20 |
   =20 = |            =             &= nbsp;        =20 |sip:some-other-string@pan-am.co= m =20 |
   =20 = |            =             &= nbsp;        =20 = |--------------------------------->|


Internet = ;            =            =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:not-a-number@pan-am.com = ;     =20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|     &nbs= p;            = ;            =    =20 |
   =20 = |            =             &= nbsp;        =20 = |INVITE           =             &= nbsp;   =20 |
   =20 = |            =             &= nbsp;        =20 |sip:some-other-string@pan-am.co= m =20 |
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|
</Out Of=20 Scope>

So, ignoring those, we seem = to still=20 have a huge disconnect on what the SSP needs to be able to do as a = result of=20 the MARTINI operations. Now, one of the nice things we get from E.164 = numbers=20 is that usernames now become unique. We can specify transformations = such that=20 the username that arrives at the SSP stays the same as it passes = through the=20 SSP. Unlike my earlier examples, I'm going to assume that limiting to = E.164=20 enables this kind of trivial transformation. Not in the *general* = case, of=20 course -- only for MARTINI-routed E.164 numbers.

As you read = through=20 these, try to place each use case in one of the following = categories:
  1. This use case by itself is sufficient for the architecture {I = am/my=20 customers are} trying to deploy

  2. This use case is necessary for the architecture {I am/my = customers are}=20 trying to deploy, but requires other use cases also.

  3. This use case is neither necessary nor sufficient for the = architecture=20 {I am/my customers are} trying to deploy.

Frankly, I = would=20 expect almost everyone will be able to place each use case in category = #1. All=20 of these solutions certainly allow the PBX to figure out who the call = is=20 supposed to be sent to, and that appears to be the key criteria for = the=20 inbound messages.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case = 1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for = "centricvoice.com" resolves to the CentricVoice servers.
RFC3263 = for=20 "pan-am.com" is not=20 = relevant.

Internet       &n= bsp;           &nb= sp;    =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|     &nbs= p;            = ;            =    =20 |
   =20 = |            =             &= nbsp;        =20 = |INVITE           =             &= nbsp;   =20 |
   =20 = |            =             &= nbsp;        =20 |sip:+12145550105@pan-am.com = ;     =20 |
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|


In this use = case, the=20 SSP receives a URI indicating its own domain. The SSP is provisioned = to know=20 that +12145550105 belongs to Pan-Am. Having received information from = Pan-Am=20 about its PBX's IP address, it changes the domain to "pan-am.com," = keeps the=20 user ID, ignores RFC 3263 procedures, and sends the request to the=20 MARTINI-registered IP address it has for Pan-Am.

The key = drawback for=20 this use case is the disregard for RFC3263 procedures.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case = 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for = "pan-am.com" resolves to the CentricVoice=20 = servers.


Internet       = ;            =      =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:+12145550105@pan-am.com = ;     =20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|     &nbs= p;            = ;            =    =20 |
   =20 = |            =             &= nbsp;        =20 = |INVITE           =             &= nbsp;   =20 |
   =20 = |            =             &= nbsp;        =20 |sip:+12145550105@pan-am.com = ;     =20 |
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|


In this use = case, the=20 SSP receives a URI indicating the domain for pan-am.com. Having = received=20 information from Pan-Am about its PBX's IP address, it leaves the = Request-URI=20 alone, ignores RFC 3263 procedures, and sends the request to the=20 MARTINI-registered IP address it has for Pan-Am.

Note that this = use=20 case is predicated on an external entity -- something on the other = side of the=20 "Internet" cloud -- being able to take the E.164 number "+12145550105" = and=20 figure out that it needs to go to the domain "pan-am.com". I emphasize = this=20 because I know some people are interested in models in which is = tenable to=20 track "phone number to SSP" mapping, while the relatively larger = number of=20 "phone number to end customer" mappings might be = unpalatable.

The key=20 drawbacks for this use case are:
  1. The disregard for RFC3263 procedures
  2. Ambiguity around which SIP nodes are "responsible for" = pan-am.com (in=20 the RFC 3261 sense of that word). Cullen had a litmus test for this: = is=20 CentricVoice allowed to redirect calls for pan-am.com to a voicemail = server=20 or answering service?

Given that 3261 lacks a formal = description=20 of "responsible for," we can potentially define the problem of = "responsible=20 for" away (as Keith has proposed) -- but I'm pretty certain it's not = within=20 MARTINI's scope to clarify the terms appearing in RFC 3261. I think = that would=20 need to go back to DISPATCH, and I doubt we want to wait for such an = effort to=20 complete.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case = 3
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for = "centricvoice.com" resolves to the CentricVoice=20 = servers.

Internet       &nb= sp;           &nbs= p;    =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|     &nbs= p;            = ;            =    =20 |
   =20 = |            =             &= nbsp;        =20 = |INVITE           =             &= nbsp;   =20 |
   =20 = |            =             &= nbsp;        =20 |sip:+12145550105@192.168.17.25   =20 |
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|


In this use = case, the=20 SSP receives a request for its own domain. The SSP is provisioned to = know that=20 +12145550105 belongs to Pan-Am. Having received information from = Pan-Am about=20 its PBX's IP address, it changes the domain to that registered IP = address=20 (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 = procedures, and=20 sends the request to the resulting host (192.168.17.25).

This = use case=20 does not suffer from any of the drawbacks discussed to date, other = than=20 differing from the model that is currently deployed for bulk = registrations=20 (even though it is functionally identical to the model deployed for = single=20 registrations).


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case = 4
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for = "pan-am.com" resolves to the CentricVoice=20 = servers.

Internet       &nb= sp;           &nbs= p;    =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:+12145550105@pan-am.com = ;     =20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|     &nbs= p;            = ;            =    =20 |
   =20 = |            =             &= nbsp;        =20 = |INVITE           =             &= nbsp;   =20 |
   =20 = |            =             &= nbsp;        =20 |sip:+12145550105@192.168.17.25   =20 |
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|

In this use case, = the SSP=20 receives a URI indicating the domain for pan-am.com. Having received=20 information from Pan-Am about its PBX's IP address, it changes the = domain to=20 that registered IP address (192.168.17.25), keeps the user ID, = correctly=20 invokes RFC 3263 procedures, and sends the request to the resulting = host=20 (192.168.17.25).

Like use case 3, this use case does not suffer = from=20 any of the drawbacks discussed to date, other than differing from the = model=20 that is currently deployed for bulk registrations (even though it is=20 functionally identical to the model deployed for single = registrations).=20 However, it is predicated on an external entity -- something on the = other side=20 of the "Internet" cloud -- being able to take the E.164 number = "+12145550105"=20 and figure out that it needs to go to the domain "pan-am.com".


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case = 5
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for = "centricvoice.com" resolves to the CentricVoice=20 = servers.

Internet       &nb= sp;           &nbs= p;    =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|     &nbs= p;            = ;            =    =20 |
   =20 = |            =             &= nbsp;        =20 = |INVITE           =             &= nbsp;   =20 |
   =20 = |            =             &= nbsp;        =20 = |tel:+12145550105         &n= bsp;       =20 |
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|


In this use = case, the=20 SSP receives a URI indicating its own domain. The SSP is provisioned = to know=20 that +12145550105 belongs to Pan-Am. It changes the R-URI to a tel: = URI=20 containing only the E.164 number in question. Having received = information from=20 Pan-Am about its PBX's IP address, it sends the request to the = resulting host=20 (192.168.17.25). Since the URI in question is a TEL URI, RFC3263 = issues are=20 avoided altogether, eliminating any alt-root = considerations.

The major=20 drawback to this use case is that it (likely) requires the ability to = register=20 TEL URIs, which is currently normatively forbidden by RFC 3261. While = this is=20 tractable, it would require companion work in SIPCORE to relax this = normative=20 requirement. It also would likely require more mechanism than other=20 approaches, since we're effectively adding on a new URI-to-host = address=20 resolution = procedure.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use= Case=20 5a
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A = variation on Use Case 5, this use case ends up=20 with a R-URI of the PBX's lead number, with an extension parameter = that=20 indicates the desired extension on the=20 = PBX:

Internet        &= nbsp;           &n= bsp;   =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|     &nbs= p;            = ;            =    =20 |
   =20 = |            =             &= nbsp;        =20 = |INVITE           =             &= nbsp;   =20 |
   =20 = |            =             &= nbsp;        =20 |tel:+12145550100;extension=3D1214555|
   =20 = |            =             &= nbsp;        =20 = |            =             &= nbsp;    =20 0105|
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|


This is = effectively=20 the exact same procedure as Use Case 5; however, it may make contact=20 registration somewhat easier (depending on the exact mechanism used to = communicate domain IP addresses).


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case = 6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for = "centricvoice.com" resolves to the CentricVoice=20 = servers.

Internet       &nb= sp;           &nbs= p;    =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 = |            =             &= nbsp;        =20 |
   =20 = |--------------------------------->|INVITE    &nbs= p;            = ;          =20 |
   =20 = |            =             &= nbsp;        =20 |sip:+12145550105@centricvoice.= com=20 |
   =20 = |            =             &= nbsp;        =20 |Route: <sip:pbx@192.168.17.25> &nb= sp; =20 |
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|

In this example, = In this=20 use case, the SSP receives a URI indicating its own domain. The SSP is = provisioned to know that +12145550105 belongs to Pan-Am. It pushes the = MARTINI-registered contact into the route set, leaves the Request-URI=20 unmodified, invokes RFC 3263 procedures (on the Route) and sends the = request=20 to the resulting host.

A key drawback to this use case is that = it=20 cannot be effected using REGISTER without radically changing the = semantics of=20 REGISTER (i.e., registering a path towards an AOR instead of a contact = for an=20 AOR). These changes necessarily require intermediaries who are a party = to the=20 REGISTER transaction (e.g., using Path and/or Service-Route) to = understand=20 these changed semantics, and would require the use of a Proxy-Require = to avoid=20 the ensuing problems. Using a method other than REGISTER eliminates = this class=20 of problems.

A second major drawback to this approach pertains = to=20 domain responsibility: unless the Pan-Am PBX is "responsible for"=20 centricvoice.com, it is in violation of SIP routing procedures if it = fails to=20 route it back to CentricVoice: "If the domain of the Request-URI = indicates a=20 domain this element is not responsible for, the Request-URI MUST be = placed=20 into the target set as the only target, and the element MUST proceed = to the=20 task of Request Forwarding."  In practice, I imagine it wants to = route it=20 to one of its internal extensions.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case = 7
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for = "centricvoice.com" resolves to the CentricVoice=20 = servers.

Internet       &nb= sp;           &nbs= p;    =20 = CentricVoice          &= nbsp;           &n= bsp;  =20 Pan-Am
   =20 = |INVITE           =             &= nbsp;   =20 = |            =             &= nbsp;        =20 |
    |sip:+12145550105@centricvoice.= com=20 = |            =             &= nbsp;        =20 |
    |--------------------------------->|INVITE=20 sip:pbx@192.168.17.25 &n= bsp;   =20 |
   =20 = |            =             &= nbsp;        =20 |History-Info: sip:+12145550105@cen|
 = ;  =20 = |            =             &= nbsp;        =20 = |            =         =20 tricvoice.com|   =
   =20 = |            =             &= nbsp;        =20 |--------------------------------->|


Similar to use = case 6,=20 except the SSP swaps out the registered Contact URI for the = Request-URI, and=20 squirrels the incoming R-URI (containing the phone number) away in a=20 History-Info header field.

On the plus side, this looks a lot = like=20 normal proxy/registrar behavior. Drawbacks include defining concrete=20 procedures around which History-Info entry to use (which is a problem = the=20 4244bis draft is currently struggling with), especially in the case = that there=20 are intermediaries between the SSP and the PBX. We would also be = creating a=20 normative dependency on the 4244bis document, which may delay a final = delivery=20 of MARTINI work substantially.


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

Now, = I've heard and read things that imply that each these use cases are = under=20 consideration by at least one person. I think we need to focus. = Clearly just=20 saying "phone numbers" is not sufficient. Look back over how you rated = each of=20 the use cases relative to the "sufficient," "necessary but not = sufficient,"=20 and "neither necessary nor sufficient" criteria. I think you'll find = that, if=20 you were honest with yourself, all or most of these use cases fall = into the=20 first category. I'm not saying you *like* them all -- merely that they = will=20 get the job done, if push were to come to shove.

So, I think we = need to=20 pick one and work on the mechanism required to enable it. And I think = we need=20 to be vigilant against scope creep. As we get into mechanism, it will = be=20 overwhelmingly tempting to say, "oh, but we can add on Use Case X if = we just=20 do *this* small thing!" But those small things can spiral out of=20 control.

All other things being equal, I have a strong = preference for=20 Use Case 3, as its only real drawback is that it varies from the = demonstrably=20 flawed [1] mechanism that showed up on the IETF's doorstep. = Any=20 other approach is going to require interested parties coming to = consensus on=20 the issues associated with the other use cases, and I think we've seen = that=20 won't be a very fast process.

/a

[1] Lest this offend = anyone as=20 being too general a criticism, I refer to the set of shortcomings = enumerated=20 here: http://www.ietf.org/mail-archive/web/martini/current/msg00412.html=

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_0E4F_01CAA3EE.BEBD2050-- From pkyzivat@cisco.com Tue Feb 2 08:23: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 18CEF3A68C5 for ; Tue, 2 Feb 2010 08:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 NhXo2yEBdGPa for ; Tue, 2 Feb 2010 08:23:06 -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 D4B813A682A for ; Tue, 2 Feb 2010 08:23:05 -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: ApoEAKvgZ0utJV2b/2dsb2JhbADBL5gihEUE X-IronPort-AV: E=Sophos;i="4.49,391,1262563200"; d="scan'208";a="83410260" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2010 16:23:43 +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 o12GNhtC022737; Tue, 2 Feb 2010 16:23:43 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); Tue, 2 Feb 2010 10:23:43 -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, 2 Feb 2010 10:23:43 -0600 Message-ID: <4B68518A.3080009@cisco.com> Date: Tue, 02 Feb 2010 11:23:38 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Feb 2010 16:23:43.0212 (UTC) FILETIME=[16396AC0:01CAA424] 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: Tue, 02 Feb 2010 16:23:07 -0000 Bernard Aboba wrote: > Dean said: > > “The problem with SIP URIs is: what domain would go in the To:? Clearly > it has to be the domain of the SSP, for all of our domain- authority > work to do what it is supposed to do. > > There are still some questions about the security implications of > multiple registrations over one Outbound connection, but I'm thinking > (hoping?) those could be resolved by a carefully worded applicability > statement.” > > [BA] Yes, in the case you mentioned the domain in the To: would be the > domain of the SSP, since only the Request-URI is remapped. As far as I > can tell though, this doesn’t lead to any of the problems referred to in > the Problem Statement document. Are there other issues we should be > thinking about? Then is the To used by the PBX *always* sip:@SSP, even when the call is intra-pbx??? Most likely the originating device doesn't know if the call is inter-pbx or not, so I guess it must be. And what about From? Typically you would want From to be an address at which you can be reached. If you cannot be reached externally via sip:@pbx.com, then you don't want that on calls that leave the pbx. So you end wanting to use From: sip:@SSP. Alternatively, all calls originating on the pbx could start out with To being sip:@pbx.com, but then any that aren't intra-pbx will need to have To, From, etc. all mapped before passing to the SSP. > In terms of the security issues, I can understand the potential need to > validate the remapping (e.g. you don’t want to allow anyone to use > “pbx.com” as a contact domain). But that concern exists for single-AOR > registration as well as multiple. Is the concern that different AORs > could be mapped to different contact domains and that this could > intermingle requests among different “virtual PBXes”? If so, then each > “virtual PBX” can just use its own separate connection, no? If security is hooked on From, then you can't really use sip:@SSP, because you can't sign that. Thanks, Paul From pkyzivat@cisco.com Tue Feb 2 08:32: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 DD2203A69A2 for ; Tue, 2 Feb 2010 08:32:44 -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 7ZVmDavHqzxX for ; Tue, 2 Feb 2010 08:32:44 -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 0DB6D28B23E for ; Tue, 2 Feb 2010 08:32:44 -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: ApoEAE/iZ0utJV2d/2dsb2JhbADBOpgjhEUE X-IronPort-AV: E=Sophos;i="4.49,391,1262563200"; d="scan'208";a="295019668" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2010 16:33:22 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o12GXMK8007352; Tue, 2 Feb 2010 16:33:22 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); Tue, 2 Feb 2010 10:33:22 -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, 2 Feb 2010 10:33:21 -0600 Message-ID: <4B6853CD.3080707@cisco.com> Date: Tue, 02 Feb 2010 11:33:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <4B670F85.4030808@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2010 16:33:21.0850 (UTC) FILETIME=[6F1E91A0:01CAA425] Cc: "martini@ietf.org" , Hadriel Kaplan 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: Tue, 02 Feb 2010 16:32:45 -0000 Christer Holmberg wrote: > Hi, > >>> 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 beg to differ. The contact address is the ultimate target. >> There have been many documents pointing that out. >> And as long as you register each AOR independently it can be >> handled very cleanly. > > In my opinion Contact is not meant to be used for informing the UA about what number was called etc in order to reach the UA. I will have to hunt to find the references, but there have been plenty of them discussing things like multi-line phones that have pointed out the importance of using distinct contacts when registering each "line" so that you can unambiguously distinguish which of your registrations a call is coming from. These have been discussed for many years, so IMO it falls into the category of "meant to be used that way". >>> I also think it is a very "clumsy" solution, when you >>> mandate a 1-to-1 mapping of the R-URI/Contact userpart values >>> (maybe it could also have security impacts). >> Its clumsy precisely because of implicit registration. >> Adam's proposal provided a way to do that mapping under the >> control of the recipient so that only expected contact >> addresses are used. > > Again, as far as I understand, from a SIP network perspective the PBX only has a single contact. That is why we are having this long discussion. For a SIP perspective the PBX *ought* to be reached via 3263 procedures. It is the desire to use REGISTER for a purpose outside its original intent that has introduced the complexity. Same for "implicit" registration as defined by IMS. Thanks, Paul From pkyzivat@cisco.com Tue Feb 2 08: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 3710A3A6A11 for ; Tue, 2 Feb 2010 08:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 DXoS+9DjxwTh for ; Tue, 2 Feb 2010 08:43: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 7F8ED3A69FD for ; Tue, 2 Feb 2010 08:43:07 -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: ApoEAKfkZ0utJV2Z/2dsb2JhbADBRpgjhEUE X-IronPort-AV: E=Sophos;i="4.49,391,1262563200"; d="scan'208";a="476955926" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 02 Feb 2010 16:43:46 +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 o12Ghjd1019895; Tue, 2 Feb 2010 16:43:45 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); Tue, 2 Feb 2010 10:43:45 -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, 2 Feb 2010 10:43:45 -0600 Message-ID: <4B68563B.5000006@cisco.com> Date: Tue, 02 Feb 2010 11:43:39 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2010 16:43:45.0413 (UTC) FILETIME=[E2CABB50:01CAA426] Cc: "martini@ietf.org" , Hadriel Kaplan 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: Tue, 02 Feb 2010 16:43:10 -0000 Christer Holmberg wrote: >>> But, what if the PBX is using outbound? I assume the same >> instance id >>> and gr values are going to be used for all PBX users, >> eventhough each >>> PBX user has a unique Contact within the SSP? >> [JRE] Yes - this was touched on in the other recent thread. > > In that case, why would we need to send a wildcarded Contact (as suggested by Dean)? Why not simply register the IPX IP address, and the registrar then adds the user part for inbound requests? This is really more a matter of perspective (or "spin") rather than substance: If the SSP is going to be retargetting to different "contact" addresses depending on the target phone number, we can describe that in two ways: 1) there is a single contact address registered and kept in the location database, but with permission to replace the user part according to some agreed upon algorithm 2) There is a single contact address registered. But something in the register causes it to be expanded into a number of distinct contact addresses that are placed in the location database. Incoming requests choose an appropriate entry from that db and use it without change. When you view the SSP as a black box these can be indistinguishable. Thanks, Paul From spencer@wonderhamster.org Tue Feb 2 09:23: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 43CC03A6898 for ; Tue, 2 Feb 2010 09:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, 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 vYX8u12y8Yjz for ; Tue, 2 Feb 2010 09:23:54 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 834783A67B1 for ; Tue, 2 Feb 2010 09:23:54 -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 0MTRwF-1NDqWq0EoJ-00SIqB; Tue, 02 Feb 2010 12:24:32 -0500 Message-ID: From: "Spencer Dawkins" To: "Richard Shockey" , "'Dean Willis'" , "'Hadriel Kaplan'" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> Date: Tue, 2 Feb 2010 11:24:14 -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+l1R07UoQpg5adkdJkriYQTjHX46qSx0bS5WK PUuxt77zsiTyZ1zK8Cj+dFlnCxW3/cuT9j8x8yzPvosAenDjxp jucfEm/34LpZNfpo4pHC6cSl4HoxbmFyjEcaqAv100= Cc: martini@ietf.org Subject: [martini] Culling tel URIs (was: Re: 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: Tue, 02 Feb 2010 17:23:55 -0000 Rich actually said this out loud, on the list: > And for what its worth .. I don't think using TEL URI's here is going to > work. Everyone I'm talking to is talking about SIP-URI-with-E.164-as-user-part, and not TEL URI, when they are talking about "telephone numbers". So, just to check consensus here ... is anyone willing to argue AGAINST dropping TEL URIs from consideration? I haven't seen support for basing a solution on TEL URIs on-list, and I don't want us to head down blind alleys if no one is following ... Thanks, Spencer From pkyzivat@cisco.com Tue Feb 2 09:31: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 950593A6828 for ; Tue, 2 Feb 2010 09:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.531 X-Spam-Level: X-Spam-Status: No, score=-10.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 rPvZCHrBzEOV for ; Tue, 2 Feb 2010 09:31:35 -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 871493A672E for ; Tue, 2 Feb 2010 09:31:35 -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: ApoEAF7wZ0utJV2Y/2dsb2JhbADBRoocCY4AglKBcwQ X-IronPort-AV: E=Sophos;i="4.49,391,1262563200"; d="scan'208";a="476981656" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 02 Feb 2010 17:32:14 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o12HWED0020343; Tue, 2 Feb 2010 17:32:14 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); Tue, 2 Feb 2010 11:32:13 -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, 2 Feb 2010 11:32:13 -0600 Message-ID: <4B68619D.1080307@cisco.com> Date: Tue, 02 Feb 2010 12:32:13 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Doug Sauder References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> <3DF106C5-3CAA-480C-9ACE-8909CA16E667@dsauder.com> In-Reply-To: <3DF106C5-3CAA-480C-9ACE-8909CA16E667@dsauder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2010 17:32:13.0566 (UTC) FILETIME=[A82FA9E0:01CAA42D] Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 17:31:36 -0000 ISTM that there are of necessity two (presumably manual) processes that must be coordinated one way or another: - the assignment, at the SSP, of numbers to the pbx - the mapping, at the pbx, of numbers to devices Its not so terrible if these get out of sync: - the pbx could have a forwarding rule for "unexpected" numbers to somebody that can deal with it. - if the pbx gets configured with a number that hasn't been configured for it by the SSP, it won't receive outside calls to that number. And if the SSP is clever, originating calls claiming to be from that number will be rejected, highlighting the problem. "Inside" calls will presumably work. So I also don't see a need to communicate the list of numbers via sip in either direction. Thanks, Paul Doug Sauder wrote: > Thanks, Jack, for the feedback. > > I see two alternatives, where a registration is involved. > > In the alternative Dean proposes, the register indicates through a > regex-type expression the AORs that it wants routed to itself. > > In the alternative that I think makes more sense, the register does not > indicate all AORs, but registers a special AOR that represents the PBX > as a whole (which might also represent the main line of the business). > In this alternative, the register provides the necessary connectivity > information, but the decision about which AORs to route to the PBX is > made by the SSP based on provisioning at the SSP. > > For your deployments, which alternative works better? > > -- > Doug > > On Feb 2, 2010, at 06:02 , Jack Burton wrote: > >> Doug, >> >> In our case, we have an IP-PBX that we provide to some customers. It >> is provisioned as you suggest - the IP-PBX pulls credentials and such >> from a config server we (the SSP) maintain. >> >> For other customers, who provide their own IP-PBXs, there is no such >> communication. We provide them with a manual list of their allowed >> e164 numbers, including all DIDs, which they (or their VAR/PBX >> Vendor) must manually provision in their switches. >> >> In either case, we require registration in order for our SBCs to learn >> the dynamic IP address of the customer. >> >> -Jack >> >> >> Jack Burton >> Dir. Systems Engineering >> Cablevision >> jsburton@cablevision.com >> 516-803-9733 >> >> >>> Doug Sauder 2/2/2010 10:15 >>> >> Dean, >> >> I disagree with the PBX claiming its AORs at the SSP through a >> registration. I think this kind of "provisioning" is backwards >> compared to what real SSPs want. In my experience, subscribers are >> provisioned at the SSP, and it's a goal to have the PBX provisioned >> through some kind of auto-provisioning. For example, the PBX uses >> HTTP or FTP to get its configuration information from a server >> maintained by the SSP. This is how the PBX discovers its AORs, >> extensions, and so forth. It might not be this way in every >> deployment, but I believe it's where the SMB-market service providers >> want to go. >> >> Your approach seems to suggest that provisioning happens at the PBX, >> and it is then "pushed" to the SSP. >> >> I think the implicit registration is a better alternative, especially >> when such auto-provisioning is deployed. >> >> -- >> Doug >> >> On Feb 1, 2010, at 20:45 , Dean Willis wrote: >> >> >> -------------------------------------------------------- >> 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. >> -------------------------------------------------------- > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Tue Feb 2 10:30: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 AFB863A65A6 for ; Tue, 2 Feb 2010 10:30:17 -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 mwG+RXtjvJ5W for ; Tue, 2 Feb 2010 10:30:16 -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 54F2D3A6952 for ; Tue, 2 Feb 2010 10:30:15 -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 o12IUqe8040594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 12:30:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B686F5C.50806@nostrum.com> Date: Tue, 02 Feb 2010 12:30:52 -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: <4B6767A4.8000008@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050906060801050300030609" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 18:30:17 -0000 This is a multi-part message in MIME format. --------------050906060801050300030609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/2/10 02:32, Feb 2, Elwell, John wrote: > Ignoring use case 8, this leaves use cases 1 to 4. From a PBX point of > view, cases 1 and 2 are the same. The difference is how the request > reaches the SP. Is this an issue for MARTINI? Or put it another way, > if we provide a solution for case 1, does this stop people > implementing case 2? Similarly for cases 3 and 4: if we provide a > solution for case 3, does this stop people implementing case 4? At this 10,000-mile high view, there is effectively no difference. I think that once we get into the syntax and semantics of what needs to go in the MARTINI deliverables, there will almost certainly be differences. Perhaps not. But I don't want to get caught up in analysis and discussions about whether doing case 3 *also* enables case 4 unless we come to an agreement that someone absolutely must have case 4. Even if all we need to do is the analysis that the solution works for both, that's still additional work. /a --------------050906060801050300030609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/2/10 02:32, Feb 2, Elwell, John wrote:
Ignoring use case 8, this leaves use cases 1 to 4. From a PBX point of view, cases 1 and 2 are the same. The difference is how the request reaches the SP. Is this an issue for MARTINI? Or put it another way, if we provide a solution for case 1, does this stop people implementing case 2? Similarly for cases 3 and 4: if we provide a solution for case 3, does this stop people implementing case 4?

At this 10,000-mile high view, there is effectively no difference. I think that once we get into the syntax and semantics of what needs to go in the MARTINI deliverables, there will almost certainly be differences. Perhaps not. But I don't want to get caught up in analysis and discussions about whether doing case 3 *also* enables case 4 unless we come to an agreement that someone absolutely must have case 4. Even if all we need to do is the analysis that the solution works for both, that's still additional work.

/a
--------------050906060801050300030609-- From adam@nostrum.com Tue Feb 2 10:36: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 2EBF63A6956 for ; Tue, 2 Feb 2010 10:36: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 80i68GSWPKLM for ; Tue, 2 Feb 2010 10:36: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 DB8583A65A6 for ; Tue, 2 Feb 2010 10:36:14 -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 o12IanZ9041032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 12:36:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6870C1.8090502@nostrum.com> Date: Tue, 02 Feb 2010 12:36:49 -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> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@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, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 18:36:16 -0000 On 2/2/10 11:24, Feb 2, Spencer Dawkins wrote: > > So, just to check consensus here ... is anyone willing to argue > AGAINST dropping TEL URIs from consideration? Although I was originally thinking this was the best way forward, I have concluded that we can achieve the same effect using SIP URIs, if *and* *only* *if* we use the PBX's IP address as the host portion. I think we can all agree that the PBX is uniquely responsible for URIs addressed to the PBX's IP address. However, if we decide (for whatever reason) that using IP addresses in the R-URIs from the SSP to the PBX is unacceptable, then it is my opinion that we're back to needing to use TEL URIs here. So, provisionally, I'm okay dropping TEL URIs from consideration as long as we can come up with a R-URI from the SSP to the PBX that is uncontroversially the PBX's responsibility. /a From D.Hancock@CableLabs.com Tue Feb 2 11:57: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 8C1953A698C for ; Tue, 2 Feb 2010 11:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.005 X-Spam-Level: X-Spam-Status: No, score=-0.005 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 i22Hmp16wJvj for ; Tue, 2 Feb 2010 11:57:40 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 0F4DA3A67A3 for ; Tue, 2 Feb 2010 11:57:39 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o12JwIvT029700; Tue, 2 Feb 2010 12:58:18 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 2 Feb 2010 12:58:18 -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; Tue, 2 Feb 2010 12:58:18 -0700 From: David Hancock To: Adam Roach , "martini@ietf.org" Date: Tue, 2 Feb 2010 12:58:17 -0700 Thread-Topic: [martini] Use Cases: what's important, what's not Thread-Index: AcqjmLFJek/s30BGSa6bI/XrUFniegAjhqOg Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4B2A867@srvxchg> References: <4B6767A4.8000008@nostrum.com> In-Reply-To: <4B6767A4.8000008@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_76AC5FEF83F1E64491446437EA81A61F7CD4B2A867srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 19:57:58 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CD4B2A867srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, Thanks for documenting these different use cases. Here is my understanding of John Elwell's use-case 8 (combination of 2 and = 6) and my use-case 9 (combination of 1 and 6). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@pan-am.com |= | |--------------------------------->| | | |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| | |Route: | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 9 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| | |Route: | I think that 9 would be the most common case in the real world. A user in t= he originating VoIP network dials a digit string identifying the Pan-Am ent= erprise user, the originating network converts the string to an E.164 numbe= r, and converts that to the SIP URI sip:+12145550105@centricvoice.com; user= =3Dphone (probably via ENUM). The CentricVoice network receives the request= , and converts the received E.164 number via its private database (possibly= ENUM), to sip:+12145550105@pan-am.com, and then routes the request using t= o the registered contact address for that URI using loose-routing Thanks David ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Monday, February 01, 2010 4:46 PM To: martini@ietf.org Subject: [martini] Use Cases: what's important, what's not The more we talk about this, the further apart opinions seem to get. There = appears to be a lot of ocean boiling going on right now, such that even whe= n we can decide on a fairly narrow scope ("phone numbers only"), the system= behavior that people expect appears to vary literally from person to perso= n. I'm going to try to do something like I did before with the diagrams, this = time focusing on just what happens for E.164 numbers. I'll continue with us= ing the same dead companies as before (CentricVoice as the SSP, and Pan-Am = as the PBX). In particular, I'm assuming that the tentative (albeit far from unanimous) = agreement to do an initial batch of work towards E.164 numbers means that t= hese kinds of use cases are not under discussion at the moment: Internet CentricVoice Pan-= Am |INVITE | | |sip:not-a-number@centricvoice.com | | |--------------------------------->| | | |INVITE | | |sip:some-other-string@pan-am.com | | |--------------------------------->| Internet CentricVoice Pan-= Am |INVITE | | |sip:not-a-number@pan-am.com | | |--------------------------------->| | | |INVITE | | |sip:some-other-string@pan-am.com | | |--------------------------------->| So, ignoring those, we seem to still have a huge disconnect on what the SSP= needs to be able to do as a result of the MARTINI operations. Now, one of = the nice things we get from E.164 numbers is that usernames now become uniq= ue. We can specify transformations such that the username that arrives at t= he SSP stays the same as it passes through the SSP. Unlike my earlier examp= les, I'm going to assume that limiting to E.164 enables this kind of trivia= l transformation. Not in the *general* case, of course -- only for MARTINI-= routed E.164 numbers. As you read through these, try to place each use case in one of the followi= ng categories: 1. This use case by itself is sufficient for the architecture {I am/my cu= stomers are} trying to deploy 2. This use case is necessary for the architecture {I am/my customers are= } trying to deploy, but requires other use cases also. 3. This use case is neither necessary nor sufficient for the architecture= {I am/my customers are} trying to deploy. Frankly, I would expect almost everyone will be able to place each use case= in category #1. All of these solutions certainly allow the PBX to figure o= ut who the call is supposed to be sent to, and that appears to be the key c= riteria for the inbound messages. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. RFC3263 for "pan-am.com" is not relevant. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| In this use case, the SSP receives a URI indicating its own domain. The SSP= is provisioned to know that +12145550105 belongs to Pan-Am. Having receive= d information from Pan-Am about its PBX's IP address, it changes the domain= to "pan-am.com," keeps the user ID, ignores RFC 3263 procedures, and sends= the request to the MARTINI-registered IP address it has for Pan-Am. The key drawback for this use case is the disregard for RFC3263 procedures. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "pan-am.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| In this use case, the SSP receives a URI indicating the domain for pan-am.c= om. Having received information from Pan-Am about its PBX's IP address, it = leaves the Request-URI alone, ignores RFC 3263 procedures, and sends the re= quest to the MARTINI-registered IP address it has for Pan-Am. Note that this use case is predicated on an external entity -- something on= the other side of the "Internet" cloud -- being able to take the E.164 num= ber "+12145550105" and figure out that it needs to go to the domain "pan-am= .com". I emphasize this because I know some people are interested in models= in which is tenable to track "phone number to SSP" mapping, while the rela= tively larger number of "phone number to end customer" mappings might be un= palatable. The key drawbacks for this use case are: 1. The disregard for RFC3263 procedures 2. Ambiguity around which SIP nodes are "responsible for" pan-am.com (in = the RFC 3261 sense of that word). Cullen had a litmus test for this: is Cen= tricVoice allowed to redirect calls for pan-am.com to a voicemail server or= answering service? Given that 3261 lacks a formal description of "responsible for," we can pot= entially define the problem of "responsible for" away (as Keith has propose= d) -- but I'm pretty certain it's not within MARTINI's scope to clarify the= terms appearing in RFC 3261. I think that would need to go back to DISPATC= H, and I doubt we want to wait for such an effort to complete. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@192.168.17.25 | | |--------------------------------->| In this use case, the SSP receives a request for its own domain. The SSP is= provisioned to know that +12145550105 belongs to Pan-Am. Having received i= nformation from Pan-Am about its PBX's IP address, it changes the domain to= that registered IP address (192.168.17.25), keeps the user ID, correctly i= nvokes RFC 3263 procedures, and sends the request to the resulting host (19= 2.168.17.25). This use case does not suffer from any of the drawbacks discussed to date, = other than differing from the model that is currently deployed for bulk reg= istrations (even though it is functionally identical to the model deployed = for single registrations). ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "pan-am.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@pan-am.com | | |--------------------------------->| | | |INVITE | | |sip:+12145550105@192.168.17.25 | | |--------------------------------->| In this use case, the SSP receives a URI indicating the domain for pan-am.c= om. Having received information from Pan-Am about its PBX's IP address, it = changes the domain to that registered IP address (192.168.17.25), keeps the= user ID, correctly invokes RFC 3263 procedures, and sends the request to t= he resulting host (192.168.17.25). Like use case 3, this use case does not suffer from any of the drawbacks di= scussed to date, other than differing from the model that is currently depl= oyed for bulk registrations (even though it is functionally identical to th= e model deployed for single registrations). However, it is predicated on an= external entity -- something on the other side of the "Internet" cloud -- = being able to take the E.164 number "+12145550105" and figure out that it n= eeds to go to the domain "pan-am.com". ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |tel:+12145550105 | | |--------------------------------->| In this use case, the SSP receives a URI indicating its own domain. The SSP= is provisioned to know that +12145550105 belongs to Pan-Am. It changes the= R-URI to a tel: URI containing only the E.164 number in question. Having r= eceived information from Pan-Am about its PBX's IP address, it sends the re= quest to the resulting host (192.168.17.25). Since the URI in question is a= TEL URI, RFC3263 issues are avoided altogether, eliminating any alt-root c= onsiderations. The major drawback to this use case is that it (likely) requires the abilit= y to register TEL URIs, which is currently normatively forbidden by RFC 326= 1. While this is tractable, it would require companion work in SIPCORE to r= elax this normative requirement. It also would likely require more mechanis= m than other approaches, since we're effectively adding on a new URI-to-hos= t address resolution procedure. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 5a =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A variation on Use Case 5, this use case ends up with a R-URI of the PBX's = lead number, with an extension parameter that indicates the desired extensi= on on the PBX: Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->| | | |INVITE | | |tel:+12145550100;extension=3D121455= 5| | | 0105| | |--------------------------------->| This is effectively the exact same procedure as Use Case 5; however, it may= make contact registration somewhat easier (depending on the exact mechanis= m used to communicate domain IP addresses). ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->|INVITE | | |sip:+12145550105@centricvoice.com | | |Route: | | |--------------------------------->| In this example, In this use case, the SSP receives a URI indicating its ow= n domain. The SSP is provisioned to know that +12145550105 belongs to Pan-A= m. It pushes the MARTINI-registered contact into the route set, leaves the = Request-URI unmodified, invokes RFC 3263 procedures (on the Route) and send= s the request to the resulting host. A key drawback to this use case is that it cannot be effected using REGISTE= R without radically changing the semantics of REGISTER (i.e., registering a= path towards an AOR instead of a contact for an AOR). These changes necess= arily require intermediaries who are a party to the REGISTER transaction (e= .g., using Path and/or Service-Route) to understand these changed semantics= , and would require the use of a Proxy-Require to avoid the ensuing problem= s. Using a method other than REGISTER eliminates this class of problems. A second major drawback to this approach pertains to domain responsibility:= unless the Pan-Am PBX is "responsible for" centricvoice.com, it is in viol= ation of SIP routing procedures if it fails to route it back to CentricVoic= e: "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 Forwardin= g." In practice, I imagine it wants to route it to one of its internal ext= ensions. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use Case 7 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. Internet CentricVoice Pan-= Am |INVITE | | |sip:+12145550105@centricvoice.com | | |--------------------------------->|INVITE sip:pbx@192.168.17.25 | | |History-Info: sip:+12145550105@cen| | | tricvoice.com| | |--------------------------------->| Similar to use case 6, except the SSP swaps out the registered Contact URI = for the Request-URI, and squirrels the incoming R-URI (containing the phone= number) away in a History-Info header field. On the plus side, this looks a lot like normal proxy/registrar behavior. Dr= awbacks include defining concrete procedures around which History-Info entr= y to use (which is a problem the 4244bis draft is currently struggling with= ), especially in the case that there are intermediaries between the SSP and= the PBX. We would also be creating a normative dependency on the 4244bis d= ocument, which may delay a final delivery of MARTINI work substantially. ________________________________ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Now, I've heard and read things that imply that each these use cases are un= der consideration by at least one person. I think we need to focus. Clearly= just saying "phone numbers" is not sufficient. Look back over how you rate= d each of the use cases relative to the "sufficient," "necessary but not su= fficient," and "neither necessary nor sufficient" criteria. I think you'll = find that, if you were honest with yourself, all or most of these use cases= fall into the first category. I'm not saying you *like* them all -- merely= that they will get the job done, if push were to come to shove. So, I think we need to pick one and work on the mechanism required to enabl= e it. And I think we need to be vigilant against scope creep. As we get int= o mechanism, it will be overwhelmingly tempting to say, "oh, but we can add= on Use Case X if we just do *this* small thing!" But those small things ca= n spiral out of control. All other things being equal, I have a strong preference for Use Case 3, as= its only real drawback is that it varies from the demonstrably flawed [1] = mechanism that showed up on the IETF's doorstep. Any other approach is goin= g to require interested parties coming to consensus on the issues associate= d with the other use cases, and I think we've seen that won't be a very fas= t process. /a [1] Lest this offend anyone as being too general a criticism, I refer to th= e set of shortcomings enumerated here: http://www.ietf.org/mail-archive/web= /martini/current/msg00412.html --_000_76AC5FEF83F1E64491446437EA81A61F7CD4B2A867srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam,

 

Thanks for documenting these different= use cases.

 

Here is my understanding of John Elwel= l’s use-case 8 (combination of 2 and 6) and my use-case 9 (combination of 1 and= 6).

=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 8
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /font>

 

 

= Internet      &nbs= p;            &= nbsp;     CentricVoice          &nb= sp;            =    Pan-Am

=     |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@pan-a= m.com       |      &n= bsp;            = ;            &n= bsp;  |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |sip:+12145550105@pan-am.com<= /a>       |
    |            &n= bsp;            = ;         |--------------------------------->|
    |            &n= bsp;            = ;         |Route: <sip:pbx@192.168.17.25>    |<= /font>

 

 

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Use Case 9
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /font>

=  

= Internet      &nbs= p;            &= nbsp;     CentricVoice          &nb= sp;            =    Pan-Am

=     |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@centr= icvoice.com |            &n= bsp;            = ;         |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |sip:+12145550105@pan-am.com<= /a>       |
    |            &n= bsp;            = ;         |--------------------------------->|
    |            &n= bsp;            = ;         |Route: <sip:pbx@192.168.17.25>    |<= /font>

 

 

 

I think that 9 would be the most commo= n case in the real world. A user in the originating VoIP network dials a digi= t string identifying the Pan-Am enterprise user, the originating network conv= erts the string to an E.164 number, and converts that to the SIP URI sip:+121455= 50105@centricvoice.com; user=3Dphone (probably via ENUM). The CentricVoice network receives the req= uest, and converts the received E.164 number via its private database (possibly ENUM), to sip:+12145550105@pan-am.com, and then routes the request using to= the registered contact address for that URI using loose-routing

 

Thanks

David

 

 

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.or= g] On Behalf Of Adam Roach
Sent: Monday, February 01, 2= 010 4:46 PM
To: martini@ietf.org
Subject: [martini] Use Cases= : what's important, what's not

=  

The more we talk = about this, the further apart opinions seem to get. There appears to be a lot of ocean boiling going on right now, such that even when we can decide on a fa= irly narrow scope ("phone numbers only"), the system behavior that peo= ple expect appears to vary literally from person to person.

I'm going to try to do something like I did before with the diagrams, this = time focusing on just what happens for E.164 numbers. I'll continue with using t= he same dead companies as before (CentricVoice as the SSP, and Pan-Am as the P= BX).

In particular, I'm assuming that the tentative (albeit far from unanimous) agreement to do an initial batch of work towards E.164 numbers means that t= hese kinds of use cases are not under discussion at the moment:

<= ;Out Of Scope>


Internet      =             &nb= sp;      CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:not-a-number@centricvoice.co= m |            &n= bsp;            = ;         |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |sip:some-other-string@pan-am.= com  |
    |            &n= bsp;            = ;         |--------------------------------->|


Internet      =             &nb= sp;      CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE   =             &nb= sp;            |            &n= bsp;            = ;         |
    |sip:not-a-number@pan-am.com &= nbsp;     |            &n= bsp;            = ;         |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |sip:some-other-string@pan-am.= com  |
    |            &n= bsp;            = ;         |--------------------------------->|

<= ;/Out Of Scope>

=
So, ignoring those, we seem to still have a huge disconnect on what the SSP needs to be able to do as a result of the MARTINI operations. Now, one of t= he nice things we get from E.164 numbers is that usernames now become unique. = We can specify transformations such that the username that arrives at the SSP stays the same as it passes through the SSP. Unlike my earlier examples, I'= m going to assume that limiting to E.164 enables this kind of trivial transfo= rmation. Not in the *general* case, of course -- only for MARTINI-routed E.164 numbe= rs.

As you read through these, try to place each use case in one of the followi= ng categories:

  1. This use case by itself is sufficient for t= he architecture {I am/my customers are} trying to deploy
  2. This use case is necessary for the architec= ture {I am/my customers are} trying to deploy, but requires other use cases also.
  3. This use case is neither necessary nor suff= icient for the architecture {I am/my customers are} trying to deploy.


Frankly, I would expect almost everyone will be able to place each use case= in category #1. All of these solutions certainly allow the PBX to figure out w= ho the call is supposed to be sent to, and that appears to be the key criteria= for the inbound messages.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for "centricvoice.com" resolves to the CentricVoice serve= rs.
RFC3263 for "pan-am.com" is not relevant.

Internet         &= nbsp;           &nbs= p;   CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@centricvoice.co= m |            &n= bsp;            = ;         |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |sip:+12145550105@pan-am.com&nb= sp;      |
    |            &n= bsp;            = ;         |--------------------------------->|


In this use case, the SSP receives a URI indicating its own domain. The SSP= is provisioned to know that +12145550105 belongs to Pan-Am. Having received information from Pan-Am about its PBX's IP address, it changes the domain t= o "pan-am.com," keeps the user ID, ignores RFC 3263 procedures, and sends the request to the MARTINI-registered IP address it has for Pan-Am.
The key drawback for this use case is the disregard for RFC3263 procedures.=

=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for "pan-am.com" resolves to the CentricVoice servers.

Internet         &= nbsp;           &nbs= p;   CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@pan-am.com &= nbsp;     |            &n= bsp;            = ;         |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |sip:+12145550105@pan-am.com&nb= sp;      |
    |            &n= bsp;            = ;         |--------------------------------->|


In this use case, the SSP receives a URI indicating the domain for pan-am.c= om. Having received information from Pan-Am about its PBX's IP address, it leav= es the Request-URI alone, ignores RFC 3263 procedures, and sends the request t= o the MARTINI-registered IP address it has for Pan-Am.

Note that this use case is predicated on an external entity -- something on= the other side of the "Internet" cloud -- being able to take the E.16= 4 number "+12145550105" and figure out that it needs to go to the domain "pan-am.com". I emphasize this because I know some people = are interested in models in which is tenable to track "phone number to SSP" mapping, while the relatively larger number of "phone number= to end customer" mappings might be unpalatable.

The key drawbacks for this use case are:

  1. The disregard for RFC3263 procedures
  2. Ambiguity around which SIP nodes are "responsible for" pan-am.com (in the RFC 3261 sense of that word). Cullen had a litmus test for this: is CentricVoice allowed to redirect calls for pan-am.com to a voicemail server or answering servi= ce?


Given that 3261 lacks a formal description of "responsible for," = we can potentially define the problem of "responsible for" away (as Keith has proposed) -- but I'm pretty certain it's not within MARTINI's sco= pe to clarify the terms appearing in RFC 3261. I think that would need to go b= ack to DISPATCH, and I doubt we want to wait for such an effort to complete.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 3
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for "centricvoice.com" resolves to the CentricVoice serve= rs.

Internet         &= nbsp;           &nbs= p;   CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@centricvoice.co= m |            &n= bsp;            = ;         |
    |------------------------= --------->|          &= nbsp;           &nbs= p;           |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |sip:+12145550105@192.168.17.25<= /a>    |
    |            &n= bsp;            = ;         |--------------------------------->|


In this use case, the SSP receives a request for its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having received information from Pan-Am about its PBX's IP address, it changes the domain t= o that registered IP address (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 procedures, and sends the request to the resulting host (192.168.17.25).

This use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrations (even though it is functionally identical to the model deploy= ed for single registrations).


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 4
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for "pan-am.com" resolves to the CentricVoice servers.
Internet         &= nbsp;           &nbs= p;   CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@pan-am.com &= nbsp;     |            &n= bsp;            = ;         |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |    =             &nb= sp;            =      |sip:+12145550105@192.168.17.25<= /a>    |
    |            &n= bsp;            = ;         |--------------------------------->|

In this use case, the SSP receives a URI indicating the domain for pan-am.c= om. Having received information from Pan-Am about its PBX's IP address, it chan= ges the domain to that registered IP address (192.168.17.25), keeps the user ID= , correctly invokes RFC 3263 procedures, and sends the request to the resulti= ng host (192.168.17.25).

Like use case 3, this use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrations (even though it is functionally identical t= o the model deployed for single registrations). However, it is predicated on = an external entity -- something on the other side of the "Internet" cloud -- being able to take the E.164 number "+12145550105" and figure out that it needs to go to the domain "pan-am.com".


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 5
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for "centricvoice.com" resolves to the CentricVoice serve= rs.

Internet         &= nbsp;           &nbs= p;   CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@centricvoice.co= m |            &n= bsp;            = ;         |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |tel:+12145550105         &nbs= p;        |
    |            &n= bsp;            = ;         |--------------------------------->|


In this use case, the SSP receives a URI indicating its own domain. The SSP= is provisioned to know that +12145550105 belongs to Pan-Am. It changes the R-U= RI to a tel: URI containing only the E.164 number in question. Having received information from Pan-Am about its PBX's IP address, it sends the request to= the resulting host (192.168.17.25). Since the URI in question is a TEL URI, RFC= 3263 issues are avoided altogether, eliminating any alt-root considerations.

The major drawback to this use case is that it (likely) requires the abilit= y to register TEL URIs, which is currently normatively forbidden by RFC 3261. Wh= ile this is tractable, it would require companion work in SIPCORE to relax this normative requirement. It also would likely require more mechanism than oth= er approaches, since we're effectively adding on a new URI-to-host address resolution procedure.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 5a
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A variation on Use Case 5, this use case ends up with a R-URI of the PBX's = lead number, with an extension parameter that indicates the desired extension on= the PBX:

In= ternet           &nb= sp;             CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@centricvoice.co= m |            &n= bsp;            = ;         |
    |--------------------------------->|      =             &nb= sp;            =    |
    |            &n= bsp;            = ;         |INVITE           &n= bsp;            = ;    |
    |            &n= bsp;            = ;         |tel:+12145550100;extension=3D1214555|
    |            &n= bsp;            = ;         |            &n= bsp;            = ;     0105|
    |            &n= bsp;            = ;         |--------------------------------->|


This is effectively the exact same procedure as Use Case 5; however, it may make contact registration somewhat easier (depending on the exact mechanism used to communicate domain IP addresses).


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for "centricvoice.com" resolves to the CentricVoice serve= rs.

Internet         &= nbsp;           &nbs= p;   CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@centricvoice.co= m |            &n= bsp;            = ;         |
    |------------------------= --------->|INVITE         &= nbsp;           &nbs= p;      |
    |            &n= bsp;            = ;         |sip:+12145550105@centricvoic= e.com |
    |            &n= bsp;            = ;         |Route: <sip:pbx@192.168.17.25>=     |
    |            &n= bsp;            = ;         |--------------------------------->|

In this example, In this use case, the SSP receives a URI indicating its ow= n domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am.= It pushes the MARTINI-registered contact into the route set, leaves the Request-URI unmodified, invokes RFC 3263 procedures (on the Route) and send= s the request to the resulting host.

A key drawback to this use case is that it cannot be effected using REGISTE= R without radically changing the semantics of REGISTER (i.e., registering a p= ath towards an AOR instead of a contact for an AOR). These changes necessarily require intermediaries who are a party to the REGISTER transaction (e.g., u= sing Path and/or Service-Route) to understand these changed semantics, and would require the use of a Proxy-Require to avoid the ensuing problems. Using a method other than REGISTER eliminates this class of problems.

A second major drawback to this approach pertains to domain responsibility: unless the Pan-Am PBX is "responsible for" centricvoice.com, it i= s in violation of SIP routing procedures if it fails to route it back to CentricVoice: "If the domain of the Request-URI indicates a domain thi= s element is not responsible for, the Request-URI MUST be placed into the tar= get set as the only target, and the element MUST proceed to the task of Request Forwarding."  In practice, I imagine it wants to route it to one = of its internal extensions.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Use Case 7
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RFC3263 for "centricvoice.com" resolves to the CentricVoice serve= rs.

Internet         &= nbsp;           &nbs= p;   CentricVoice          &nb= sp;            =    Pan-Am
    |INVITE           &n= bsp;            = ;    |            &n= bsp;            = ;         |
    |sip:+12145550105@centricvoice.co= m |            &n= bsp;            = ;         |
    |--------------------------------->|INVITE sip:pbx@192.168.17.25      |
    |            &n= bsp;            = ;         |History-Info: sip:+12145550105@cen|
    |            &n= bsp;            = ;         |            &n= bsp;        tricvoice.com|  
&n= bsp;   |            &n= bsp;            = ;         |--------------------------------->|


Similar to use case 6, except the SSP swaps out the registered Contact URI = for the Request-URI, and squirrels the incoming R-URI (containing the phone num= ber) away in a History-Info header field.

On the plus side, this looks a lot like normal proxy/registrar behavior. Drawbacks include defining concrete procedures around which History-Info en= try to use (which is a problem the 4244bis draft is currently struggling with), especially in the case that there are intermediaries between the SSP and th= e PBX. We would also be creating a normative dependency on the 4244bis docume= nt, which may delay a final delivery of MARTINI work substantially.

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

Now, I've heard and read things that imply that each these use cases are un= der consideration by at least one person. I think we need to focus. Clearly jus= t saying "phone numbers" is not sufficient. Look back over how you rated each of the use cases relative to the "sufficient," "necessary but not sufficient," and "neither necessary nor sufficient" criteria. I think you'll find that, if you were honest wit= h yourself, all or most of these use cases fall into the first category. I'm = not saying you *like* them all -- merely that they will get the job done, if pu= sh were to come to shove.

So, I think we need to pick one and work on the mechanism required to enabl= e it. And I think we need to be vigilant against scope creep. As we get into mechanism, it will be overwhelmingly tempting to say, "oh, but we can = add on Use Case X if we just do *this* small thing!" But those small thing= s can spiral out of control.

All other things being equal, I have a strong preference for Use Case 3, as= its only real drawback is that it varies from the demonstrably flawed [1]<= /sup> mechanism that showed up on the IETF's doorstep. Any other approach is goin= g to require interested parties coming to consensus on the issues associated wit= h the other use cases, and I think we've seen that won't be a very fast proce= ss.

/a

[1] Lest this offend anyone as being too general a criticism, I refer to th= e set of shortcomings enumerated here: http://www.ietf.org/mail-archive/web/martini/current/msg00412.html

--_000_76AC5FEF83F1E64491446437EA81A61F7CD4B2A867srvxchg_-- From richard@shockey.us Tue Feb 2 12:05: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 7DEA93A696D for ; Tue, 2 Feb 2010 12:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 1hJIGw4PRfO9 for ; Tue, 2 Feb 2010 12:05:49 -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 5BCA73A68C7 for ; Tue, 2 Feb 2010 12:05:49 -0800 (PST) Received: (qmail 30482 invoked by uid 0); 2 Feb 2010 20:06:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy8.bluehost.com.bluehost.com with SMTP; 2 Feb 2010 20:06:28 -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=GZK0pgWh4c+x+n3qN59fhS8kiEnbKQxLbx40IaT6j50YzAj/JIiah2Q26UCVriixFeqXqz7rjJn0XX8MkYN5He6Jj+E9vUqj5qFHJUZnX9F1a7NUogBPeT1u/vk3rY7I; 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 1NcP11-0005O8-Pa; Tue, 02 Feb 2010 13:06:28 -0700 From: "Richard Shockey" To: "'Adam Roach'" , "'Spencer Dawkins'" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> In-Reply-To: <4B6870C1.8090502@nostrum.com> Date: Tue, 2 Feb 2010 15:06:24 -0500 Message-ID: <003101caa443$331579d0$99406d70$@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: AcqkNrJMRd8TdeffRPWH82Ai9Pz2wQAC4nwg 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, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 20:05:50 -0000 Although I was originally thinking this was the best way forward, I have concluded that we can achieve the same effect using SIP URIs, if *and* *only* *if* we use the PBX's IP address as the host portion. I think we can all agree that the PBX is uniquely responsible for URIs addressed to the PBX's IP address. However, if we decide (for whatever reason) that using IP addresses in the R-URIs from the SSP to the PBX is unacceptable, then it is my opinion that we're back to needing to use TEL URIs here. So, provisionally, I'm okay dropping TEL URIs from consideration as long as we can come up with a R-URI from the SSP to the PBX that is uncontroversially the PBX's responsibility. RS> As in a domain like customerornumber.ssp.net where the delegation is unambiguous since I'm guessing 99.99% of these domains are getting their IP addressing from the SSP as well. RS> In general a very tight biding of the solution to an even tighter set of operational parameters certainly makes sense. As in ..use this technique ONLY if ..A. Only phone numbers are involved B. security bindings between PBX and SSP are inconsequential due to Layer One control C. SSP MUST issue the domain to the pbx? /a From richard@shockey.us Tue Feb 2 12:06: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 339363A6A46 for ; Tue, 2 Feb 2010 12:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, 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 pdDdXbmZ-KDk for ; Tue, 2 Feb 2010 12:06:57 -0800 (PST) Received: from outbound-mail-342.bluehost.com (outbound-mail-342.bluehost.com [66.147.249.3]) by core3.amsl.com (Postfix) with SMTP id 75CFB3A6A3C for ; Tue, 2 Feb 2010 12:06:57 -0800 (PST) Received: (qmail 17398 invoked by uid 0); 2 Feb 2010 20:07:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 2 Feb 2010 20:07:36 -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=S+fO6MrpavjhDvwf+8buOrxOtztiRHnAl0ILP/cAibTD/AkEnZwPyR+GNEeJD9v10cqkg9fIgk8uAIr/fi7vrqUm7Udki5FxnCgoMbNcNEafBxj2eSx6VfNuBNLXJKzW; 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 1NcP28-00062W-I8; Tue, 02 Feb 2010 13:07:36 -0700 From: "Richard Shockey" To: "'DOLLY, MARTIN C \(ATTLABS\)'" , "'Dean Willis'" , "'Christer Holmberg'" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> <14C85D6CCBE92743AF33663BF5D24EBA0582965C@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0582965C@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 2 Feb 2010 15:07:33 -0500 Message-ID: <003201caa443$5c12f1f0$1438d5d0$@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: AcqjpwYRGITiEhjHSEu0BvtvaH6LAwAAvPZAACZRy4A= 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, 'Hadriel Kaplan' 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: Tue, 02 Feb 2010 20:06:58 -0000 +1 Thank you Marty ..that is the central problem. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C (ATTLABS) Sent: Monday, February 01, 2010 8:50 PM To: Dean Willis; Christer Holmberg Cc: Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Proposed work split: tackletelephone-numberregistration first Every user registering is not implementable. From spencer@wonderhamster.org Tue Feb 2 12:53: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 94F8D3A6949 for ; Tue, 2 Feb 2010 12:53:36 -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.023, 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 2tTAvDY2y-g6 for ; Tue, 2 Feb 2010 12:53:35 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 9441F3A67A6 for ; Tue, 2 Feb 2010 12:53:35 -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 0LevHL-1O6pgm3D2d-00qi5Z; Tue, 02 Feb 2010 15:54:06 -0500 Message-ID: <33DE455546F146B7801F992740C11F85@china.huawei.com> From: "Spencer Dawkins" To: "Richard Shockey" , "'Adam Roach'" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> <003101caa443$331579d0$99406d70$@us> Date: Tue, 2 Feb 2010 14:53:46 -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: V01U2FsdGVkX18eZ8J0NJYCUUkSnTcMOYHw9ZyYL5PDnF5QyLg Ji2ZgkzzyynnP7RqRDE8agB6S5t+xPW5hpp4L2cptvrGSd/+Fl OzdNwAzJH/yeAHR0ARlRkusX/M+9O4zvrm0uIgKNpg= Cc: martini@ietf.org, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 20:53:36 -0000 (speaking as participant) > So, provisionally, I'm okay dropping TEL URIs from consideration as long > as we can come up with a R-URI from the SSP to the PBX that is > uncontroversially the PBX's responsibility. > > RS> As in a domain like customerornumber.ssp.net where the delegation is > unambiguous since I'm guessing 99.99% of these domains are getting their > IP > addressing from the SSP as well. We're obviously miles past the part where people get everything they need (including the parts that conflict with other parts they need, plus a pony), but SIPconnect 1.1 is also trying to wean carriers off using IP addresses (as in Adam's Use Cases 3 and 4, for example), as a way of preparing for IPv6 deployment. So I'd like to hear opinions about whether using per-PBX SP subdomains in the request URI between the SP and the SIP-PBX could have the same happy attributes that using an IP address would have in Use Cases 3 and 4. If the answer is "no", that's fine, and we can remove that advice, but I wanted to ask the question early in the MARTINI discussion. But I'm not asking us to violate physics, right? :D > RS> In general a very tight biding of the solution to an even tighter set > of > operational parameters certainly makes sense. As in ..use this technique > ONLY if ..A. Only phone numbers are involved B. security bindings between > PBX and SSP are inconsequential due to Layer One control C. SSP MUST issue > the domain to the pbx? I think this discussion (applicability statement) is going to be really important in getting this work approved, but I'm wondering (still speaking as a participant) if we should see what Use Cases we settle on, because I'm thinking the solution characteristics would affect where we can recommend using the solution. Richard, please make sure we return to that discussion at an appropriate time! Spencer From pkyzivat@cisco.com Tue Feb 2 12:54: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 61FC63A6996 for ; Tue, 2 Feb 2010 12:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.234 X-Spam-Level: X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 PyQBnvtTYXFU for ; Tue, 2 Feb 2010 12:54:19 -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 680B03A6970 for ; Tue, 2 Feb 2010 12:54:19 -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: ApoEAGsgaEutJV2b/2dsb2JhbADAfIodB44QglMLgWcE X-IronPort-AV: E=Sophos;i="4.49,393,1262563200"; d="scan'208";a="295149801" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2010 20:54:58 +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 o12KsvDM014375; Tue, 2 Feb 2010 20:54:58 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); Tue, 2 Feb 2010 14:54:32 -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, 2 Feb 2010 14:54:31 -0600 Message-ID: <4B689107.9060301@cisco.com> Date: Tue, 02 Feb 2010 15:54:31 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Hancock References: <4B6767A4.8000008@nostrum.com> <76AC5FEF83F1E64491446437EA81A61F7CD4B2A867@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4B2A867@srvxchg> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Feb 2010 20:54:31.0487 (UTC) FILETIME=[EAF36CF0:01CAA449] Cc: martini@ietf.org Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 20:54:21 -0000 David, A slight variant on these cases is using sip:+12145550105@pan-am.centricvoice.com. It that case the domain used by the pbx is a subdomain of the SSPs domain, and so it presumably owns and manages it on behalf of the pbx customer. Using pan-am.com would be just as goof, *if* centricvoice also owned and managed the domain name on behalf of the customer. But that wouldn't make sense for a company the size of pan-am (when it was a going concern.) Otherwise the SSP is put in the position of having to legally vouch for this particular pbx belonging to somebody who has rights to the domain name pan-am.com. It seems questionable whether an SSP could/would do that if the question came to their legal department. Thanks, Paul David Hancock wrote: > Adam, > > > > Thanks for documenting these different use cases. > > > > Here is my understanding of John Elwell’s use-case 8 (combination of 2 > and 6) and my use-case 9 (combination of 1 and 6). > > > ================ > Use Case 8 > ================ > > > > > > Internet CentricVoice > Pan-Am > > |INVITE | | > |sip:+12145550105@pan-am.com > | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@pan-am.com | > | |--------------------------------->| > | |Route: | > > > > > > ================ > Use Case 9 > ================ > > > > Internet CentricVoice > Pan-Am > > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@pan-am.com | > | |--------------------------------->| > | |Route: | > > > > > > > > I think that 9 would be the most common case in the real world. A user > in the originating VoIP network dials a digit string identifying the > Pan-Am enterprise user, the originating network converts the string to > an E.164 number, and converts that to the SIP URI > sip:+12145550105@centricvoice.com; user=phone (probably via ENUM). The > CentricVoice network receives the request, and converts the received > E.164 number via its private database (possibly ENUM), to > sip:+12145550105@pan-am.com, and then routes the request using to the > registered contact address for that URI using loose-routing > > > > Thanks > > David > > > > > > > > ------------------------------------------------------------------------ > > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Adam Roach > *Sent:* Monday, February 01, 2010 4:46 PM > *To:* martini@ietf.org > *Subject:* [martini] Use Cases: what's important, what's not > > > > The more we talk about this, the further apart opinions seem to get. > There appears to be a lot of ocean boiling going on right now, such that > even when we can decide on a fairly narrow scope ("phone numbers only"), > the system behavior that people expect appears to vary literally from > person to person. > > I'm going to try to do something like I did before with the diagrams, > this time focusing on just what happens for E.164 numbers. I'll continue > with using the same dead companies as before (CentricVoice as the SSP, > and Pan-Am as the PBX). > > In particular, I'm assuming that the tentative (albeit far from > unanimous) agreement to do an initial batch of work towards E.164 > numbers means that these kinds of use cases are not under discussion at > the moment: > > > > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:not-a-number@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:some-other-string@pan-am.com | > | |--------------------------------->| > > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:not-a-number@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:some-other-string@pan-am.com | > | |--------------------------------->| > > > > > So, ignoring those, we seem to still have a huge disconnect on what the > SSP needs to be able to do as a result of the MARTINI operations. Now, > one of the nice things we get from E.164 numbers is that usernames now > become unique. We can specify transformations such that the username > that arrives at the SSP stays the same as it passes through the SSP. > Unlike my earlier examples, I'm going to assume that limiting to E.164 > enables this kind of trivial transformation. Not in the *general* case, > of course -- only for MARTINI-routed E.164 numbers. > > As you read through these, try to place each use case in one of the > following categories: > > 1. This use case by itself is sufficient for the architecture {I > am/my customers are} trying to deploy > 2. This use case is necessary for the architecture {I am/my customers > are} trying to deploy, but requires other use cases also. > 3. This use case is neither necessary nor sufficient for the > architecture {I am/my customers are} trying to deploy. > > > Frankly, I would expect almost everyone will be able to place each use > case in category #1. All of these solutions certainly allow the PBX to > figure out who the call is supposed to be sent to, and that appears to > be the key criteria for the inbound messages. > > ------------------------------------------------------------------------ > > > ================ > Use Case 1 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > RFC3263 for "pan-am.com" is not relevant. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@pan-am.com | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating its own domain. The > SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having > received information from Pan-Am about its PBX's IP address, it changes > the domain to "pan-am.com," keeps the user ID, ignores RFC 3263 > procedures, and sends the request to the MARTINI-registered IP address > it has for Pan-Am. > > The key drawback for this use case is the disregard for RFC3263 procedures. > > ------------------------------------------------------------------------ > > > ================ > Use Case 2 > ================ > > RFC3263 for "pan-am.com" resolves to the CentricVoice servers. > > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@pan-am.com | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating the domain for > pan-am.com. Having received information from Pan-Am about its PBX's IP > address, it leaves the Request-URI alone, ignores RFC 3263 procedures, > and sends the request to the MARTINI-registered IP address it has for > Pan-Am. > > Note that this use case is predicated on an external entity -- something > on the other side of the "Internet" cloud -- being able to take the > E.164 number "+12145550105" and figure out that it needs to go to the > domain "pan-am.com". I emphasize this because I know some people are > interested in models in which is tenable to track "phone number to SSP" > mapping, while the relatively larger number of "phone number to end > customer" mappings might be unpalatable. > > The key drawbacks for this use case are: > > 1. The disregard for RFC3263 procedures > 2. Ambiguity around which SIP nodes are "responsible for" pan-am.com > (in the RFC 3261 sense of that word). Cullen had a litmus test for > this: is CentricVoice allowed to redirect calls for pan-am.com to > a voicemail server or answering service? > > > Given that 3261 lacks a formal description of "responsible for," we can > potentially define the problem of "responsible for" away (as Keith has > proposed) -- but I'm pretty certain it's not within MARTINI's scope to > clarify the terms appearing in RFC 3261. I think that would need to go > back to DISPATCH, and I doubt we want to wait for such an effort to > complete. > > ------------------------------------------------------------------------ > > > ================ > Use Case 3 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@192.168.17.25 | > | |--------------------------------->| > > > In this use case, the SSP receives a request for its own domain. The SSP > is provisioned to know that +12145550105 belongs to Pan-Am. Having > received information from Pan-Am about its PBX's IP address, it changes > the domain to that registered IP address (192.168.17.25), keeps the user > ID, correctly invokes RFC 3263 procedures, and sends the request to the > resulting host (192.168.17.25). > > This use case does not suffer from any of the drawbacks discussed to > date, other than differing from the model that is currently deployed for > bulk registrations (even though it is functionally identical to the > model deployed for single registrations). > > ------------------------------------------------------------------------ > > > ================ > Use Case 4 > ================ > > RFC3263 for "pan-am.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@192.168.17.25 | > | |--------------------------------->| > > In this use case, the SSP receives a URI indicating the domain for > pan-am.com. Having received information from Pan-Am about its PBX's IP > address, it changes the domain to that registered IP address > (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 > procedures, and sends the request to the resulting host (192.168.17.25). > > Like use case 3, this use case does not suffer from any of the drawbacks > discussed to date, other than differing from the model that is currently > deployed for bulk registrations (even though it is functionally > identical to the model deployed for single registrations). However, it > is predicated on an external entity -- something on the other side of > the "Internet" cloud -- being able to take the E.164 number > "+12145550105" and figure out that it needs to go to the domain > "pan-am.com". > > ------------------------------------------------------------------------ > > > ================ > Use Case 5 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |tel:+12145550105 | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating its own domain. The > SSP is provisioned to know that +12145550105 belongs to Pan-Am. It > changes the R-URI to a tel: URI containing only the E.164 number in > question. Having received information from Pan-Am about its PBX's IP > address, it sends the request to the resulting host (192.168.17.25). > Since the URI in question is a TEL URI, RFC3263 issues are avoided > altogether, eliminating any alt-root considerations. > > The major drawback to this use case is that it (likely) requires the > ability to register TEL URIs, which is currently normatively forbidden > by RFC 3261. While this is tractable, it would require companion work in > SIPCORE to relax this normative requirement. It also would likely > require more mechanism than other approaches, since we're effectively > adding on a new URI-to-host address resolution procedure. > > ================ > Use Case 5a > ================ > > A variation on Use Case 5, this use case ends up with a R-URI of the > PBX's lead number, with an extension parameter that indicates the > desired extension on the PBX: > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |tel:+12145550100;extension=1214555| > | | 0105| > | |--------------------------------->| > > > This is effectively the exact same procedure as Use Case 5; however, it > may make contact registration somewhat easier (depending on the exact > mechanism used to communicate domain IP addresses). > > ------------------------------------------------------------------------ > > > ================ > Use Case 6 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->|INVITE | > | |sip:+12145550105@centricvoice.com | > | |Route: | > | |--------------------------------->| > > In this example, In this use case, the SSP receives a URI indicating its > own domain. The SSP is provisioned to know that +12145550105 belongs to > Pan-Am. It pushes the MARTINI-registered contact into the route set, > leaves the Request-URI unmodified, invokes RFC 3263 procedures (on the > Route) and sends the request to the resulting host. > > A key drawback to this use case is that it cannot be effected using > REGISTER without radically changing the semantics of REGISTER (i.e., > registering a path towards an AOR instead of a contact for an AOR). > These changes necessarily require intermediaries who are a party to the > REGISTER transaction (e.g., using Path and/or Service-Route) to > understand these changed semantics, and would require the use of a > Proxy-Require to avoid the ensuing problems. Using a method other than > REGISTER eliminates this class of problems. > > A second major drawback to this approach pertains to domain > responsibility: unless the Pan-Am PBX is "responsible for" > centricvoice.com, it is in violation of SIP routing procedures if it > fails to route it back to CentricVoice: "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." In > practice, I imagine it wants to route it to one of its internal extensions. > > ------------------------------------------------------------------------ > > > ================ > Use Case 7 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->|INVITE sip:pbx@192.168.17.25 | > | |History-Info: sip:+12145550105@cen| > | | > tricvoice.com| > | |--------------------------------->| > > > Similar to use case 6, except the SSP swaps out the registered Contact > URI for the Request-URI, and squirrels the incoming R-URI (containing > the phone number) away in a History-Info header field. > > On the plus side, this looks a lot like normal proxy/registrar behavior. > Drawbacks include defining concrete procedures around which History-Info > entry to use (which is a problem the 4244bis draft is currently > struggling with), especially in the case that there are intermediaries > between the SSP and the PBX. We would also be creating a normative > dependency on the 4244bis document, which may delay a final delivery of > MARTINI work substantially. > > ------------------------------------------------------------------------ > > ====================================================================== > > Now, I've heard and read things that imply that each these use cases are > under consideration by at least one person. I think we need to focus. > Clearly just saying "phone numbers" is not sufficient. Look back over > how you rated each of the use cases relative to the "sufficient," > "necessary but not sufficient," and "neither necessary nor sufficient" > criteria. I think you'll find that, if you were honest with yourself, > all or most of these use cases fall into the first category. I'm not > saying you *like* them all -- merely that they will get the job done, if > push were to come to shove. > > So, I think we need to pick one and work on the mechanism required to > enable it. And I think we need to be vigilant against scope creep. As we > get into mechanism, it will be overwhelmingly tempting to say, "oh, but > we can add on Use Case X if we just do *this* small thing!" But those > small things can spiral out of control. > > All other things being equal, I have a strong preference for Use Case 3, > as its only real drawback is that it varies from the demonstrably flawed > ^[1] mechanism that showed up on the IETF's doorstep. Any other approach > is going to require interested parties coming to consensus on the issues > associated with the other use cases, and I think we've seen that won't > be a very fast process. > > /a > > [1] Lest this offend anyone as being too general a criticism, I refer to > the set of shortcomings enumerated here: > http://www.ietf.org/mail-archive/web/martini/current/msg00412.html > From pkyzivat@cisco.com Tue Feb 2 12:57: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 652D23A6B35 for ; Tue, 2 Feb 2010 12:57:24 -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 BpPocFOf6IHk for ; Tue, 2 Feb 2010 12:57:23 -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 6D8D23A6B6C for ; Tue, 2 Feb 2010 12:57:22 -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: ApoEALIgaEutJV2Y/2dsb2JhbADAfJgthEUE X-IronPort-AV: E=Sophos;i="4.49,393,1262563200"; d="scan'208";a="237263354" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2010 20:58:01 +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 o12Kw1H1001729; Tue, 2 Feb 2010 20:58:01 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); Tue, 2 Feb 2010 14:58:01 -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, 2 Feb 2010 14:58:00 -0600 Message-ID: <4B6891D8.8030801@cisco.com> Date: Tue, 02 Feb 2010 15:58: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> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> In-Reply-To: <4B6870C1.8090502@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2010 20:58:01.0011 (UTC) FILETIME=[67D64030:01CAA44A] Cc: martini@ietf.org, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 20:57:24 -0000 Adam, I just posted a reply to david that is a different spin, but getting at the same point. Specifically, if a domain name is used, the SSP needs a way to know, legally, that the pbx customer is entitled to that domain name, and that can be a problem. Thanks, Paul Adam Roach wrote: > On 2/2/10 11:24, Feb 2, Spencer Dawkins wrote: >> >> So, just to check consensus here ... is anyone willing to argue >> AGAINST dropping TEL URIs from consideration? > > Although I was originally thinking this was the best way forward, I have > concluded that we can achieve the same effect using SIP URIs, if *and* > *only* *if* we use the PBX's IP address as the host portion. I think we > can all agree that the PBX is uniquely responsible for URIs addressed to > the PBX's IP address. > > However, if we decide (for whatever reason) that using IP addresses in > the R-URIs from the SSP to the PBX is unacceptable, then it is my > opinion that we're back to needing to use TEL URIs here. > > So, provisionally, I'm okay dropping TEL URIs from consideration as long > as we can come up with a R-URI from the SSP to the PBX that is > uncontroversially the PBX's responsibility. > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From adam@nostrum.com Tue Feb 2 13:00: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 DCDE63A67ED for ; Tue, 2 Feb 2010 13:00: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=[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 bnuHBxGX+lAA for ; Tue, 2 Feb 2010 13:00: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 4FFC83A6979 for ; Tue, 2 Feb 2010 13:00:27 -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 o12L129E052576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 15:01:02 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B68928E.7060408@nostrum.com> Date: Tue, 02 Feb 2010 15:01: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: Spencer Dawkins References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> <003101caa443$331579d0$99406d70$@us> <33DE455546F146B7801F992740C11F85@china.huawei.com> In-Reply-To: <33DE455546F146B7801F992740C11F85@china.huawei.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, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 21:00:29 -0000 On 2/2/10 14:53, Feb 2, Spencer Dawkins wrote: > (speaking as participant) > >> So, provisionally, I'm okay dropping TEL URIs from consideration as long >> as we can come up with a R-URI from the SSP to the PBX that is >> uncontroversially the PBX's responsibility. >> >> RS> As in a domain like customerornumber.ssp.net where the delegation is >> unambiguous since I'm guessing 99.99% of these domains are getting >> their IP >> addressing from the SSP as well. > > We're obviously miles past the part where people get everything they > need (including the parts that conflict with other parts they need, > plus a pony), but SIPconnect 1.1 is also trying to wean carriers off > using IP addresses (as in Adam's Use Cases 3 and 4, for example), as a > way of preparing for IPv6 deployment. That's interesting -- we just did a lot of anthill kicking and apple-cart-overturning to get sip-ipv6-abnf-fix approved with the properly crossed t's and meticulously dotted i's (plus a multitude of other tiddles and dots in exactly the right places) to placate all interested parties. Admittedly, a lot of this went on behind the scenes, but this work didn't end up being the no-brainer that I think a lot of us assumed it would be. Anyway, my point is that some people have done a lot of work to make sure that IPv6 addresses in SIP URIs work just fine. > So I'd like to hear opinions about whether using per-PBX SP subdomains > in the request URI between the SP and the SIP-PBX could have the same > happy attributes that using an IP address would have in Use Cases 3 > and 4. If the answer is "no", that's fine... Unless application of RFC3263 to those domains somehow yields the IP address of the PBX, then the answer is a firm "no." /a From HKaplan@acmepacket.com Tue Feb 2 13:07: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 71B533A6B7D for ; Tue, 2 Feb 2010 13:07:51 -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.013, 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 tsIDdvojspPR for ; Tue, 2 Feb 2010 13:07:45 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 470563A6B79 for ; Tue, 2 Feb 2010 13:07: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, 2 Feb 2010 16:08:21 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 2 Feb 2010 16:08:21 -0500 From: Hadriel Kaplan To: "Elwell, John" , Adam Roach , "martini@ietf.org" Date: Tue, 2 Feb 2010 16:08:18 -0500 Thread-Topic: [martini] Use Cases: what's important, what's not Thread-Index: AcqjmLIac5uHvewrSVGr1G6ZZskFLAARheiAABqhspA= Message-ID: <430FC6BDED356B4C8498F634416644A917E5C9A280@mail> References: <4B6767A4.8000008@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: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A917E5C9A280mail_" MIME-Version: 1.0 Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 21:07:51 -0000 --_000_430FC6BDED356B4C8498F634416644A917E5C9A280mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline... ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Elwell, John Sent: Tuesday, February 02, 2010 3:32 AM To: Adam Roach; martini@ietf.org Subject: Re: [martini] Use Cases: what's important, what's not Adam, That's great that you have taken the trouble to enumerate these different c= ases. Talking from a PBX perspective, I think you are correct in saying tha= t all would get the job done. Inevitably there are some I dislike. I dislike 5/5a because of the implications of making REGISTER work with tel= URIs (and also tel URIs tend not to be used so much today on PBXs, in my o= pinion). I dislike 6, because the PBX can't do anything with the received Request-UR= I - strictly speaking it would have to route it back to the SP. I dislike 7, for the same reason, plus the known difficulties with extracti= ng information from History-Info (I have my doubts whether the present effo= rt to revise History-Info will really solve its problems). I agree with John on the above. I suppose you could have a use case 8, which is a kind of combination of 2 = and 6. So you start of with sip:+12145550105@pan-am.com and deliver the sam= e Request-URI, together with Route: sip:pbx@192.168.17.25. This was what I = had in mind pre-MARTINI. It solves the problem of 6, but still has the issu= es of 2. Same here, and in fact I don't think use-case 1 or 2 are tenable without ha= ving the Route header. (otherwise a downstream proxy won't know how to get = it to the PBX) Ignoring use case 8, this leaves use cases 1 to 4. From a PBX point of view= , cases 1 and 2 are the same. The difference is how the request reaches the= SP. Is this an issue for MARTINI? Or put it another way, if we provide a s= olution for case 1, does this stop people implementing case 2? Similarly fo= r cases 3 and 4: if we provide a solution for case 3, does this stop people= implementing case 4? Exactly my thoughts too - if we solve case 1 or 3, nothing stops 2 or 4. So this narrows it down to cases 1 and 3. The recent "Implications" thread = seemed to be homing in on a solution that would give both 1 and 3, which so= unds reasonable to me. I am not convinced that there is a problem with case= 1's by-passing RFC 3263 procedures. Agreed. BTW, Adam: for Case-3 you said "This use case does not suffer from any of t= he drawbacks discussed to date, other than differing from the model that is= currently deployed for bulk registrations (even though it is functionally = identical to the model deployed for single registrations)." Actually use-c= ase 3 is pretty common in current deployments, afaict. Arguably more commo= n than use-case 1. -hadriel --_000_430FC6BDED356B4C8498F634416644A917E5C9A280mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline…

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.or= g] On Behalf Of Elwell, John
Sent: Tuesday, February 02, = 2010 3:32 AM
To: Adam Roach; martini@ietf.org
Subject: Re: [martini] Use C= ases: what's important, what's not

=  

Adam,

=  

That's great that you have taken the trouble to enumerate these different cases. Talking from a PBX perspective,= I think you are correct in saying that all would get the job done. Inevitably there are some I dislike.

=  

I dislike 5/5a because of the implicat= ions of making REGISTER work with tel URIs (and also tel URIs tend not to be use= d so much today on PBXs, in my opinion).

I dislike 6, because the PBX can't do anything with the received Request-URI - strictly speaking it would have to route it back to the SP.

I dislike 7, for the same reason, plus= the known difficulties with extracting information from History-Info (I have my doubts whether the present effort to revise History-Info will really solve = its problems).

<= span style=3D'font-size:12.0pt;color:navy'> 

I agree with John on the above.<= /o:p>

 

I suppose you could have a use case 8, which is a kind of combination of 2 and 6. So you start of with sip:+12145550105@pan-am.com and deliver the same Request-URI, together with Route: sip:pbx@192.168.17.25. This was what I had in mind pre-MARTINI. It solves the problem of 6, but still has the issues of 2.<= /o:p>

<= span style=3D'font-size:12.0pt;color:navy'> 

Same here, and in fact I don’t think use-case 1 or 2 are tenable with= out having the Route header. (otherwise a downstream proxy won’t know how= to get it to the PBX)

=  

Ignoring use case 8, this leaves use c= ases 1 to 4. From a PBX point of view, cases 1 and 2 are the same. The differenc= e is how the request reaches the SP. Is this an issue for MARTINI? Or put it ano= ther way, if we provide a solution for case 1, does this stop people implementin= g case 2? Similarly for cases 3 and 4: if we provide a solution for case 3, d= oes this stop people implementing case 4?

<= span style=3D'font-size:12.0pt;color:navy'> 

Exactly my thoughts too – if we solve case 1 or 3, nothing stops 2 or 4.

 

So this narrows it down to cases 1 and= 3. The recent "Implications" thread seemed to be homing in on a solu= tion that would give both 1 and 3, which sounds reasonable to me. I am not convi= nced that there is a problem with case 1's by-passing RFC 3263 procedures.

=  

Agreed.

BTW, Adam: for Case-3 you said “= ;This use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrat= ions (even though it is functionally identical to the model deployed for single registrations).”  Actually use-case 3 is pretty common in curren= t deployments, afaict.  Arguably more common than use-case 1.=

 

-hadriel

--_000_430FC6BDED356B4C8498F634416644A917E5C9A280mail_-- From adam@nostrum.com Tue Feb 2 13:12: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 A56A53A6996 for ; Tue, 2 Feb 2010 13:12:34 -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 BSeabDX8Ijo3 for ; Tue, 2 Feb 2010 13:12: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 3C37828C10F for ; Tue, 2 Feb 2010 13:12: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 o12LCwOr053394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 15:12:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B68955A.5040305@nostrum.com> Date: Tue, 02 Feb 2010 15:12:58 -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: <4B6767A4.8000008@nostrum.com> <430FC6BDED356B4C8498F634416644A917E5C9A280@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5C9A280@mail> Content-Type: multipart/alternative; boundary="------------040705010504000201030604" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 21:12:36 -0000 This is a multi-part message in MIME format. --------------040705010504000201030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/2/10 15:08, Feb 2, Hadriel Kaplan wrote: > > BTW, Adam: for Case-3 you said "This use case does not suffer from any > of the drawbacks discussed to date, other than differing from the > model that is currently deployed for bulk registrations (even though > it is functionally identical to the model deployed for single > registrations)." Actually use-case 3 is pretty common in current > deployments, afaict. Arguably more common than use-case 1. > Excellent. I'm happy to hear that. /a --------------040705010504000201030604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/2/10 15:08, Feb 2, Hadriel Kaplan wrote:

BTW, Adam: for Case-3 you said “This use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrations (even though it is functionally identical to the model deployed for single registrations).”  Actually use-case 3 is pretty common in current deployments, afaict.  Arguably more common than use-case 1.



Excellent. I'm happy to hear that.

/a
--------------040705010504000201030604-- From spencer@wonderhamster.org Tue Feb 2 13:20: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 776C63A6996 for ; Tue, 2 Feb 2010 13:20:15 -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 xZgpK6-+haOV for ; Tue, 2 Feb 2010 13:20:14 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 35DD63A6B63 for ; Tue, 2 Feb 2010 13:20:14 -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 0MKpfU-1NcQAM0YpU-000A8b; Tue, 02 Feb 2010 16:20:16 -0500 Message-ID: <3B0CF6AC7DD54EE499F2667AF43D7F1E@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> <003101caa443$331579d0$99406d70$@us> <33DE455546F146B7801F992740C11F85@china.huawei.com> <4B68928E.7060408@nostrum.com> Date: Tue, 2 Feb 2010 15:19:57 -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: V01U2FsdGVkX18dOmQM9G4MwPdVsCs/S/g0dXCyjC+hpbKLNSE 7f/jtzTH+x/7yKQPGVWXAqD5E4YfkYNfLOka1XIm3F6K7pp2JG Gn+YjhmPB5Dl/SIVyGRLyMATOenudarp+qerhChSWw= Cc: martini@ietf.org, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 21:20:15 -0000 ----- Original Message ----- From: "Adam Roach" To: "Spencer Dawkins" Cc: "Richard Shockey" ; "'Dean Willis'" ; "'Hadriel Kaplan'" ; Sent: Tuesday, February 02, 2010 3:01 PM Subject: Re: [martini] Culling tel URIs > On 2/2/10 14:53, Feb 2, Spencer Dawkins wrote: >> (speaking as participant) >> >>> So, provisionally, I'm okay dropping TEL URIs from consideration as long >>> as we can come up with a R-URI from the SSP to the PBX that is >>> uncontroversially the PBX's responsibility. >>> >>> RS> As in a domain like customerornumber.ssp.net where the delegation is >>> unambiguous since I'm guessing 99.99% of these domains are getting their >>> IP >>> addressing from the SSP as well. >> >> We're obviously miles past the part where people get everything they need >> (including the parts that conflict with other parts they need, plus a >> pony), but SIPconnect 1.1 is also trying to wean carriers off using IP >> addresses (as in Adam's Use Cases 3 and 4, for example), as a way of >> preparing for IPv6 deployment. > > That's interesting -- we just did a lot of anthill kicking and > apple-cart-overturning to get sip-ipv6-abnf-fix approved with the properly > crossed t's and meticulously dotted i's (plus a multitude of other tiddles > and dots in exactly the right places) to placate all interested parties. > Admittedly, a lot of this went on behind the scenes, but this work didn't > end up being the no-brainer that I think a lot of us assumed it would be. > > Anyway, my point is that some people have done a lot of work to make sure > that IPv6 addresses in SIP URIs work just fine. Thanks for the pointer - the discussions in the SIP Forum happened, like, 14 months ago, and this was sufficiently behind-the-scenes that it hadn't fogged MY personal radar! >> So I'd like to hear opinions about whether using per-PBX SP subdomains in >> the request URI between the SP and the SIP-PBX could have the same happy >> attributes that using an IP address would have in Use Cases 3 and 4. If >> the answer is "no", that's fine... > > Unless application of RFC3263 to those domains somehow yields the IP > address of the PBX, then the answer is a firm "no." Thanks for the quick answer! Spencer From bernard_aboba@hotmail.com Tue Feb 2 13:52: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 270E53A685F for ; Tue, 2 Feb 2010 13:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, 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 DpdLtJGOcYzq for ; Tue, 2 Feb 2010 13:52:24 -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 D180B3A69A3 for ; Tue, 2 Feb 2010 13:52:23 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.72]) by blu0-omc2-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 13:53:03 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 2 Feb 2010 13:53:40 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0382_01CAA40F.209FAAC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqkUi55YQj7LkSbQi2vkiyC3ymRgg== Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 21:53:03.0370 (UTC) FILETIME=[18323EA0:01CAA452] Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 21:52:27 -0000 ------=_NextPart_000_0382_01CAA40F.209FAAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [BA] Speaking for myself, I'm fine with culling the TEL URI. Adam Roach said: "Unless application of RFC3263 to those domains somehow yields the IP address of the PBX, then the answer is a firm "no." " [BA] This certainly makes sense from a security point of view. However, this problem also exists with single AOR registration - so all the question is whether the requirement is "don't make things worse by circumventing RFC 3263" or whether we're adding a new requirement in addition to RFC 3263. Personally, I'm fine with requiring that use of domain names in contact URIs go along with provisioning of A/AAAA and SRV/NAPTR RRs since dynamic DNS services are widely available and inexpensive. ------=_NextPart_000_0382_01CAA40F.209FAAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[BA] Speaking for myself, I’m fine with = culling the TEL URI. 

 

Adam Roach said:

 

“Unless application of RFC3263 to those domains somehow yields the IP address of = the PBX, then the answer is a firm "no." = ”

 

[BA] This certainly makes sense from a security = point of view.   However, this problem also exists with single AOR = registration – so all the question is whether the requirement is “don’t = make things worse by circumventing RFC 3263” or whether we’re = adding a new requirement in addition to RFC 3263.   Personally, = I’m fine with requiring that use of domain names in contact URIs go along with provisioning of A/AAAA and SRV/NAPTR RRs since dynamic DNS services are = widely available and inexpensive.

------=_NextPart_000_0382_01CAA40F.209FAAC0-- From adam@nostrum.com Tue Feb 2 14:06: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 4BD5D3A6A1C for ; Tue, 2 Feb 2010 14:06: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, 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 wAvmnfGF6Fql for ; Tue, 2 Feb 2010 14:06: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 B09683A67A6 for ; Tue, 2 Feb 2010 14:06:29 -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 o12M761u057587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 16:07:06 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B68A20A.9090005@nostrum.com> Date: Tue, 02 Feb 2010 16:07:06 -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: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060102070509000504000603" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 22:06:35 -0000 This is a multi-part message in MIME format. --------------060102070509000504000603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/2/10 15:53, Feb 2, Bernard Aboba wrote: > > [BA] Speaking for myself, I'm fine with culling the TEL URI. > > Adam Roach said: > > "Unless application of RFC3263 to those domains somehow yields the IP > address of the PBX, then the answer is a firm "no." " > > [BA] This certainly makes sense from a security point of view. > However, this problem also exists with single AOR registration -- so > all the question is whether the requirement is "don't make things > worse by circumventing RFC 3263" or whether we're adding a new > requirement *in addition to* RFC 3263. > We're not adding anything new here. If I sent a REGISTER to my service provider with a Contact URI of "sip:adam@roach.at" -- but took no steps to guarantee that RFC3263 procedures applied to the domain "roach.at" resolved to me -- then I would be a fool to think that incoming requests would magically route to one of my devices. > Personally, I'm fine with requiring that use of domain names in > contact URIs go along with provisioning of A/AAAA and SRV/NAPTR RRs > since dynamic DNS services are widely available and inexpensive. > Right. So am I. If the PBX wants to keep DNS updated with its current IP address, then it would be free to use a domain name instead of an IP address. However, the MARTINI requirements currently make an assertion that we can't assume that such a record will exist and be kept up to date. But while you and I seem to agree on what would be required to use a domain name in the R-URI from the SSP to the PBX, that's not what (some? most?) MARTINI particpants have been arguing for. AFAICT, the argument has been that we don't bother putting any domain information in DNS that resolves to the PBX, but want to design a mechanism whereby -- as I put it above -- incoming requests with a domain in the R-URI magically route to a the right place. /a --------------060102070509000504000603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/2/10 15:53, Feb 2, Bernard Aboba wrote:

[BA] Speaking for myself, I’m fine with culling the TEL URI. 

 

Adam Roach said:

 

“Unless application of RFC3263 to those domains somehow yields the IP address of the PBX, then the answer is a firm "no." ”

 

[BA] This certainly makes sense from a security point of view.   However, this problem also exists with single AOR registration – so all the question is whether the requirement is “don’t make things worse by circumventing RFC 3263” or whether we’re adding a new requirement in addition to RFC 3263.


We're not adding anything new here. If I sent a REGISTER to my service provider with a Contact URI of "sip:adam@roach.at" -- but took no steps to guarantee that RFC3263 procedures applied to the domain "roach.at" resolved to me -- then I would be a fool to think that incoming requests would magically route to one of my devices.

   Personally, I’m fine with requiring that use of domain names in contact URIs go along with provisioning of A/AAAA and SRV/NAPTR RRs since dynamic DNS services are widely available and inexpensive.


Right. So am I. If the PBX wants to keep DNS updated with its current IP address, then it would be free to use a domain name instead of an IP address. However, the MARTINI requirements currently make an assertion that we can't assume that such a record will exist and be kept up to date.

But while you and I seem to agree on what would be required to use a domain name in the R-URI from the SSP to the PBX, that's not what (some? most?) MARTINI particpants have been arguing for. AFAICT, the argument has been  that we don't bother putting any domain information in DNS that resolves to the PBX, but want to design a mechanism whereby -- as I put it above -- incoming requests with a domain in the R-URI magically route to a the right place.

/a
--------------060102070509000504000603-- From bernard_aboba@hotmail.com Tue Feb 2 14:22: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 5A0F43A6B94 for ; Tue, 2 Feb 2010 14:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 5kZfB6cVM8vz for ; Tue, 2 Feb 2010 14:21:59 -0800 (PST) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by core3.amsl.com (Postfix) with ESMTP id 2AF603A6B91 for ; Tue, 2 Feb 2010 14:21:59 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.71]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 14:22:38 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Paul Kyzivat'" References: <4B6767A4.8000008@nostrum.com> <76AC5FEF83F1E64491446437EA81A61F7CD4B2A867@srvxchg> <4B689107.9060301@cisco.com> In-Reply-To: <4B689107.9060301@cisco.com> Date: Tue, 2 Feb 2010 14:23:15 -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: AcqkSeqpFKSXihWiQq6V9pMrxqvi8wACnE8g Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 22:22:38.0765 (UTC) FILETIME=[3A6A05D0:01CAA456] Cc: martini@ietf.org Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 22:22:00 -0000 [BA] I think we're conflating multiple distinct things here. One thing is the use of a domain name in the Contact URI. This is already legal in a single AOR registration; however before doing "Contact routing", the SSP should check that the A/AAAA RR corresponding to the domain name corresponds to the address from which the PBX registration arrived. Of course, the same check needs to be made if the PBX used an address within the domain portion of the Contact URI, so the domain name case only adds a name resolution step. The second (distinct) thing is "domain registration". Here there may be no RRs for the SSP to check against, so the SSP needs to validate the claim by other means. This may be very difficult if the domain in question is not delegated by the SSP and the SSP is not a registrar or in partnership with one. Paul said: "A slight variant on these cases is using sip:+12145550105@pan-am.centricvoice.com. It that case the domain used by the pbx is a subdomain of the SSPs domain, and so it presumably owns and manages it on behalf of the pbx customer. Using pan-am.com would be just as goof, *if* centricvoice also owned and managed the domain name on behalf of the customer. But that wouldn't make sense for a company the size of pan-am (when it was a going concern.) Otherwise the SSP is put in the position of having to legally vouch for this particular pbx belonging to somebody who has rights to the domain name pan-am.com. It seems questionable whether an SSP could/would do that if the question came to their legal department." From pkyzivat@cisco.com Tue Feb 2 14:25: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 0A6B128C0D7 for ; Tue, 2 Feb 2010 14:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.527 X-Spam-Level: X-Spam-Status: No, score=-10.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 rq2g6Jq58xdC for ; Tue, 2 Feb 2010 14:25:11 -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 EBBAA28B23E for ; Tue, 2 Feb 2010 14:25:10 -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: ApoEAAs1aEurR7Ht/2dsb2JhbADARoodB44JglMLgWcE X-IronPort-AV: E=Sophos;i="4.49,393,1262563200"; d="scan'208";a="144615966" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2010 22:25:50 +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 o12MPn4V022420; Tue, 2 Feb 2010 22:25:50 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, 2 Feb 2010 16:25:49 -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, 2 Feb 2010 16:25:49 -0600 Message-ID: <4B68A66C.50108@cisco.com> Date: Tue, 02 Feb 2010 17:25:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B6767A4.8000008@nostrum.com> In-Reply-To: <4B6767A4.8000008@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2010 22:25:49.0370 (UTC) FILETIME=[AC0609A0:01CAA456] Cc: martini@ietf.org Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 22:25:13 -0000 I'll echo others and thank Adam for focusing things. (I know some additional candidates have been added, but I think others are falling off the list.) I propose that we need some additional detail in all of these cases that hasn't been focused on much so far. Namely, the From and To addresses. I realize they aren't germane to routing the request, but they are potentially important for security and simply for a recipient deciding where to send a followup request. The choice made affects whether these values will have to be replaced by some middlebox along the way, and so is significant. Maybe we need to discuss P-Asserted-ID as well, for those that use it. Thanks, Paul Adam Roach wrote: > The more we talk about this, the further apart opinions seem to get. > There appears to be a lot of ocean boiling going on right now, such that > even when we can decide on a fairly narrow scope ("phone numbers only"), > the system behavior that people expect appears to vary literally from > person to person. > > I'm going to try to do something like I did before with the diagrams, > this time focusing on just what happens for E.164 numbers. I'll continue > with using the same dead companies as before (CentricVoice as the SSP, > and Pan-Am as the PBX). > > In particular, I'm assuming that the tentative (albeit far from > unanimous) agreement to do an initial batch of work towards E.164 > numbers means that these kinds of use cases are not under discussion at > the moment: > > > > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:not-a-number@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:some-other-string@pan-am.com | > | |--------------------------------->| > > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:not-a-number@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:some-other-string@pan-am.com | > | |--------------------------------->| > > > > So, ignoring those, we seem to still have a huge disconnect on what the > SSP needs to be able to do as a result of the MARTINI operations. Now, > one of the nice things we get from E.164 numbers is that usernames now > become unique. We can specify transformations such that the username > that arrives at the SSP stays the same as it passes through the SSP. > Unlike my earlier examples, I'm going to assume that limiting to E.164 > enables this kind of trivial transformation. Not in the *general* case, > of course -- only for MARTINI-routed E.164 numbers. > > As you read through these, try to place each use case in one of the > following categories: > > 1. This use case by itself is sufficient for the architecture {I > am/my customers are} trying to deploy > > 2. This use case is necessary for the architecture {I am/my customers > are} trying to deploy, but requires other use cases also. > > 3. This use case is neither necessary nor sufficient for the > architecture {I am/my customers are} trying to deploy. > > > Frankly, I would expect almost everyone will be able to place each use > case in category #1. All of these solutions certainly allow the PBX to > figure out who the call is supposed to be sent to, and that appears to > be the key criteria for the inbound messages. > > ------------------------------------------------------------------------ > > ================ > Use Case 1 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > RFC3263 for "pan-am.com" is not relevant. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@pan-am.com | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating its own domain. The > SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having > received information from Pan-Am about its PBX's IP address, it changes > the domain to "pan-am.com," keeps the user ID, ignores RFC 3263 > procedures, and sends the request to the MARTINI-registered IP address > it has for Pan-Am. > > The key drawback for this use case is the disregard for RFC3263 procedures. > > ------------------------------------------------------------------------ > > ================ > Use Case 2 > ================ > > RFC3263 for "pan-am.com" resolves to the CentricVoice servers. > > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@pan-am.com | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating the domain for > pan-am.com. Having received information from Pan-Am about its PBX's IP > address, it leaves the Request-URI alone, ignores RFC 3263 procedures, > and sends the request to the MARTINI-registered IP address it has for > Pan-Am. > > Note that this use case is predicated on an external entity -- something > on the other side of the "Internet" cloud -- being able to take the > E.164 number "+12145550105" and figure out that it needs to go to the > domain "pan-am.com". I emphasize this because I know some people are > interested in models in which is tenable to track "phone number to SSP" > mapping, while the relatively larger number of "phone number to end > customer" mappings might be unpalatable. > > The key drawbacks for this use case are: > > 1. The disregard for RFC3263 procedures > 2. Ambiguity around which SIP nodes are "responsible for" pan-am.com > (in the RFC 3261 sense of that word). Cullen had a litmus test for > this: is CentricVoice allowed to redirect calls for pan-am.com to > a voicemail server or answering service? > > > Given that 3261 lacks a formal description of "responsible for," we can > potentially define the problem of "responsible for" away (as Keith has > proposed) -- but I'm pretty certain it's not within MARTINI's scope to > clarify the terms appearing in RFC 3261. I think that would need to go > back to DISPATCH, and I doubt we want to wait for such an effort to > complete. > > ------------------------------------------------------------------------ > > ================ > Use Case 3 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@192.168.17.25 | > | |--------------------------------->| > > > In this use case, the SSP receives a request for its own domain. The SSP > is provisioned to know that +12145550105 belongs to Pan-Am. Having > received information from Pan-Am about its PBX's IP address, it changes > the domain to that registered IP address (192.168.17.25), keeps the user > ID, correctly invokes RFC 3263 procedures, and sends the request to the > resulting host (192.168.17.25). > > This use case does not suffer from any of the drawbacks discussed to > date, other than differing from the model that is currently deployed for > bulk registrations (even though it is functionally identical to the > model deployed for single registrations). > > ------------------------------------------------------------------------ > > ================ > Use Case 4 > ================ > > RFC3263 for "pan-am.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@192.168.17.25 | > | |--------------------------------->| > > In this use case, the SSP receives a URI indicating the domain for > pan-am.com. Having received information from Pan-Am about its PBX's IP > address, it changes the domain to that registered IP address > (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 > procedures, and sends the request to the resulting host (192.168.17.25). > > Like use case 3, this use case does not suffer from any of the drawbacks > discussed to date, other than differing from the model that is currently > deployed for bulk registrations (even though it is functionally > identical to the model deployed for single registrations). However, it > is predicated on an external entity -- something on the other side of > the "Internet" cloud -- being able to take the E.164 number > "+12145550105" and figure out that it needs to go to the domain > "pan-am.com". > > ------------------------------------------------------------------------ > > ================ > Use Case 5 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |tel:+12145550105 | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating its own domain. The > SSP is provisioned to know that +12145550105 belongs to Pan-Am. It > changes the R-URI to a tel: URI containing only the E.164 number in > question. Having received information from Pan-Am about its PBX's IP > address, it sends the request to the resulting host (192.168.17.25). > Since the URI in question is a TEL URI, RFC3263 issues are avoided > altogether, eliminating any alt-root considerations. > > The major drawback to this use case is that it (likely) requires the > ability to register TEL URIs, which is currently normatively forbidden > by RFC 3261. While this is tractable, it would require companion work in > SIPCORE to relax this normative requirement. It also would likely > require more mechanism than other approaches, since we're effectively > adding on a new URI-to-host address resolution procedure. > > ================ > Use Case 5a > ================ > > A variation on Use Case 5, this use case ends up with a R-URI of the > PBX's lead number, with an extension parameter that indicates the > desired extension on the PBX: > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |tel:+12145550100;extension=1214555| > | | 0105| > | |--------------------------------->| > > > This is effectively the exact same procedure as Use Case 5; however, it > may make contact registration somewhat easier (depending on the exact > mechanism used to communicate domain IP addresses). > > ------------------------------------------------------------------------ > > ================ > Use Case 6 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->|INVITE | > | |sip:+12145550105@centricvoice.com | > | |Route: | > | |--------------------------------->| > > In this example, In this use case, the SSP receives a URI indicating its > own domain. The SSP is provisioned to know that +12145550105 belongs to > Pan-Am. It pushes the MARTINI-registered contact into the route set, > leaves the Request-URI unmodified, invokes RFC 3263 procedures (on the > Route) and sends the request to the resulting host. > > A key drawback to this use case is that it cannot be effected using > REGISTER without radically changing the semantics of REGISTER (i.e., > registering a path towards an AOR instead of a contact for an AOR). > These changes necessarily require intermediaries who are a party to the > REGISTER transaction (e.g., using Path and/or Service-Route) to > understand these changed semantics, and would require the use of a > Proxy-Require to avoid the ensuing problems. Using a method other than > REGISTER eliminates this class of problems. > > A second major drawback to this approach pertains to domain > responsibility: unless the Pan-Am PBX is "responsible for" > centricvoice.com, it is in violation of SIP routing procedures if it > fails to route it back to CentricVoice: "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." In > practice, I imagine it wants to route it to one of its internal extensions. > > ------------------------------------------------------------------------ > > ================ > Use Case 7 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice > Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->|INVITE sip:pbx@192.168.17.25 | > | |History-Info: sip:+12145550105@cen| > | | > tricvoice.com| > | |--------------------------------->| > > > Similar to use case 6, except the SSP swaps out the registered Contact > URI for the Request-URI, and squirrels the incoming R-URI (containing > the phone number) away in a History-Info header field. > > On the plus side, this looks a lot like normal proxy/registrar behavior. > Drawbacks include defining concrete procedures around which History-Info > entry to use (which is a problem the 4244bis draft is currently > struggling with), especially in the case that there are intermediaries > between the SSP and the PBX. We would also be creating a normative > dependency on the 4244bis document, which may delay a final delivery of > MARTINI work substantially. > > > ------------------------------------------------------------------------ > ====================================================================== > > Now, I've heard and read things that imply that each these use cases are > under consideration by at least one person. I think we need to focus. > Clearly just saying "phone numbers" is not sufficient. Look back over > how you rated each of the use cases relative to the "sufficient," > "necessary but not sufficient," and "neither necessary nor sufficient" > criteria. I think you'll find that, if you were honest with yourself, > all or most of these use cases fall into the first category. I'm not > saying you *like* them all -- merely that they will get the job done, if > push were to come to shove. > > So, I think we need to pick one and work on the mechanism required to > enable it. And I think we need to be vigilant against scope creep. As we > get into mechanism, it will be overwhelmingly tempting to say, "oh, but > we can add on Use Case X if we just do *this* small thing!" But those > small things can spiral out of control. > > All other things being equal, I have a strong preference for Use Case 3, > as its only real drawback is that it varies from the demonstrably flawed > ^[1] mechanism that showed up on the IETF's doorstep. Any other approach > is going to require interested parties coming to consensus on the issues > associated with the other use cases, and I think we've seen that won't > be a very fast process. > > /a > > [1] Lest this offend anyone as being too general a criticism, I refer to > the set of shortcomings enumerated here: > http://www.ietf.org/mail-archive/web/martini/current/msg00412.html > From pkyzivat@cisco.com Tue Feb 2 14:46: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 095B328C0D7 for ; Tue, 2 Feb 2010 14:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 rJGi3iziOsXv for ; Tue, 2 Feb 2010 14:46: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 0DB773A69B1 for ; Tue, 2 Feb 2010 14:46:52 -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: ApoEALo5aEutJV2b/2dsb2JhbADASZgvhEUE X-IronPort-AV: E=Sophos;i="4.49,393,1262563200"; d="scan'208";a="83471827" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2010 22:47:31 +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 o12MlVhU005271; Tue, 2 Feb 2010 22:47:31 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); Tue, 2 Feb 2010 16:47: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); Tue, 2 Feb 2010 16:47:31 -0600 Message-ID: <4B68AB81.6050408@cisco.com> Date: Tue, 02 Feb 2010 17:47:29 -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> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2010 22:47:31.0230 (UTC) FILETIME=[B3FE1BE0:01CAA459] Cc: martini@ietf.org, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 22:46:54 -0000 Spencer Dawkins wrote: > Rich actually said this out loud, on the list: > >> And for what its worth .. I don't think using TEL URI's here is going to >> work. > > > > Everyone I'm talking to is talking about > SIP-URI-with-E.164-as-user-part, and not TEL URI, when they are talking > about "telephone numbers". > > > > > > So, just to check consensus here ... is anyone willing to argue AGAINST > dropping TEL URIs from consideration? I haven't seen support for basing > a solution on TEL URIs on-list, and I don't want us to head down blind > alleys if no one is following ... I realize this isn't used much currently, and so I suppose there may need to be a solution that doesn't require it. But I still think this solves problems that people currently just sweep under the rug, so I would hate to take it off the table. For instance, if my UA receives a request with From: sip:+12125551212@pan-am.com, what is it supposed to display as the caller, and in my call history? The whole thing? Or just the phone number? Common practice is often to just display the phone number. Then If I want to make a followup call, how do I address it? To that same full URI, or to sip:+12125551212@my-pbx.com or to sip:+12125551212@my-SSP.com? None of those questions even arise if the From: contains a TEL. Thanks, Paul From bernard_aboba@hotmail.com Tue Feb 2 14: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 AEABD3A6B9B for ; Tue, 2 Feb 2010 14:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.123, 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 QW6qkmZ+euHn for ; Tue, 2 Feb 2010 14:48:39 -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 A16B23A6B99 for ; Tue, 2 Feb 2010 14:48:38 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.73]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 14:49:18 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Adam Roach'" References: <4B68A20A.9090005@nostrum.com> In-Reply-To: <4B68A20A.9090005@nostrum.com> Date: Tue, 2 Feb 2010 14:49:55 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A5_01CAA416.FC38B110" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqkVA8JrTrcpSgyRoaYlyps+/C2WwAA0A3A Content-Language: en-us X-OriginalArrivalTime: 02 Feb 2010 22:49:18.0326 (UTC) FILETIME=[F3D3A960:01CAA459] Cc: martini@ietf.org Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 02 Feb 2010 22:48:44 -0000 ------=_NextPart_000_03A5_01CAA416.FC38B110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Adam Roach said: "Right. So am I. If the PBX wants to keep DNS updated with its current IP address, then it would be free to use a domain name instead of an IP address." [BA] Yes. "However, the MARTINI requirements currently make an assertion that we can't assume that such a record will exist and be kept up to date." [BA] Right - but not having the RRs in place has consequences - using a domain name has requires a demonstration of authorization to do so. "But while you and I seem to agree on what would be required to use a domain name in the R-URI from the SSP to the PBX, that's not what (some? most?) MARTINI particpants have been arguing for. " [BA] There are two distinct types of proposals that are being discussed, and at times it is hard to figure out which one is being referred to. One is "domain registration" in which it is assumed that there are no RRs in place. The other (which seems like it could be relevant to either the MARTINI up or "shaken" proposals) is use of a domain name in a Contact URI, where there may be RRs in place. Since these approaches have different security properties, it would be helpful to be clear about which one we're talking about. For example, with respect to "domain registration" discussion seems to have concluded that the domain needs to be delegated by the SSP. However, for a Contact URI, we only need the RRs to be in place and correct in order for the SSP to verify ownership. AFAICT, the argument has been that we don't bother putting any domain information in DNS that resolves to the PBX, but want to design a mechanism whereby -- as I put it above -- incoming requests with a domain in the R-URI magically route to a the right place. [BA] Clearly there will be limits to what can be allowed in order to prevent security problems. To prevent confusion though, it would be helpful to be clear about which restrictions apply to which proposals and in what circumstances. ------=_NextPart_000_03A5_01CAA416.FC38B110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam Roach = said:


“Right. So am I. If the PBX wants to keep DNS updated with its current IP = address, then it would be free to use a domain name instead of an IP = address.” =

 

[BA] Yes.

 

“However, the MARTINI requirements currently make an assertion that we can't = assume that such a record will exist and be kept up to date.”

 

[BA] Right – but not having the RRs in place has consequences – using a domain name has requires a demonstration of authorization to do so.  

“But while you and I seem to agree on what would be required to use a domain = name in the R-URI from the SSP to the PBX, that's not what (some? most?) MARTINI particpants have been arguing for. “

 

[BA] There are two distinct types of proposals that are = being discussed, and at times it is hard to figure out which one is being referred to. = One is “domain registration” in which it is assumed that there are no RRs in = place.  The other (which seems like it could be relevant to either the MARTINI = up or “shaken” proposals) is use of a domain name in a Contact URI, where there may be = RRs in place.   Since these approaches have different security = properties, it would be helpful to be clear about which one we’re talking = about.  For example, with respect to “domain registration” = discussion seems to have concluded that the domain needs to be delegated by the = SSP.  However, for a Contact URI, we only need the RRs to be in place and = correct in order for the SSP to verify ownership.  =    

 

AFAICT, the argument has been  that we don't bother putting any domain = information in DNS that resolves to the PBX, but want to design a mechanism whereby = -- as I put it above -- incoming requests with a domain in the R-URI magically = route to a the right place.

[BA] Clearly there will be limits to what can be allowed = in order to prevent security problems.  To prevent confusion though, = it would be helpful to be clear about which restrictions apply to which proposals = and in what circumstances.    

------=_NextPart_000_03A5_01CAA416.FC38B110-- From pkyzivat@cisco.com Tue Feb 2 16:04: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 8D6D73A6869 for ; Tue, 2 Feb 2010 16:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 9rUBb1Lcwi5e for ; Tue, 2 Feb 2010 16:04:52 -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 319233A6998 for ; Tue, 2 Feb 2010 16:04:49 -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: ApoEACFMaEutJV2d/2dsb2JhbADAZ5gwhEUE X-IronPort-AV: E=Sophos;i="4.49,394,1262563200"; d="scan'208";a="237312589" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-2.cisco.com with ESMTP; 03 Feb 2010 00:05:29 +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 o1305SUK025612; Wed, 3 Feb 2010 00:05:28 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); Tue, 2 Feb 2010 18:05:29 -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, 2 Feb 2010 18:05:28 -0600 Message-ID: <4B68BDC5.9060106@cisco.com> Date: Tue, 02 Feb 2010 19:05:25 -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> <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: 03 Feb 2010 00:05:28.0337 (UTC) FILETIME=[97C40010:01CAA464] 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: Wed, 03 Feb 2010 00:04:53 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Friday, January 29, 2010 9:45 AM >> To: Adam Roach >> >> 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 ultimately > destined to the PBX containing SIP URI's in req-URI, To, Refer-To, etc. I said "when TEL URIs are used...there is no need to", and you just stated that they won't be used. You haven't made my statement false. > Thus they will either show up at the PBX, or the SSP will have to perform > the "mapping" function we claim isn't going to be necessary with Tel-URI's. > There is no getting away from this "mapping" function. The purpose of standards is to get people to do things in a consistent way. The need for a mapping function is evidence that standards are lacking or not being used. I guess you don't want usage to change in such a way as to put you out of business. :-) But you are right - it is true that a pbx can live in blissful ignorance, assuming that all SIP URIs are of the form sip:@my-name.com as long as its only communication with the external world is via an SBC that preserves that myth. It could equally well live with the expectation that all those URIs are TEL:. Then it wouldn't have to be configured with something different for each deployment. Thanks, Paul From adam@nostrum.com Tue Feb 2 16:08: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 91C913A6869 for ; Tue, 2 Feb 2010 16:08:48 -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 sN1C9iua26vA for ; Tue, 2 Feb 2010 16:08:47 -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 4FDFD3A6A44 for ; Tue, 2 Feb 2010 16:08:47 -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 o1309OWx067020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Feb 2010 18:09:24 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B68BEB4.2020207@nostrum.com> Date: Tue, 02 Feb 2010 18:09: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: MARTINI Content-Type: multipart/alternative; boundary="------------000308020408090501070208" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Subject: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 00:08:48 -0000 This is a multi-part message in MIME format. --------------000308020408090501070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have put together a draft to address Globally Identifiable Numbers for PBX registration. (Sorry, "Identifiable" was the best near-synonym I could find for "Unique" starting with I -- and everyone knows real martinis are made with gin. ;-) ) The contents of this draft are based on several factors from the phone calls and mailing list; in particular: * The (tentative) agreement to move forward with phone numbers as an initial, narrowed scope. * A perceived consensus to use REGISTER for the phone number use case. * A perceived consensus to have the specific phone numbers being registered to be "implicit" (i.e., provisioned in both the SSP and the PBX, and not exchanged on the wire). * A perceived consensus not to carry the registered extensions in the REGISTER response * A perceived consensus _not_ to use TEL URIs between the SSP and the PBX I have also started an analysis (in the document) of how this kind of mechanism can play nicely with GRUU and reg-event. We need to do the same thing for Path, Service-Info, and Outbound, but I think they may be less problematic than the other two. The document is available here: http://www.ietf.org/id/draft-roach-martini-gin-00.txt If I have time, I plan to flesh this out a bit more before the virtual interim meeting on Tuesday. But I wanted to make sure I got an early version out there for everyone to look at so I don't spring it on you the day before the call like last time. /a --------------000308020408090501070208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have put together a draft to address Globally Identifiable Numbers for PBX registration. (Sorry, "Identifiable" was the best near-synonym I could find for "Unique" starting with I -- and everyone knows real martinis are made with gin. ;-) )

The contents of this draft are based on several factors from the phone calls and mailing list; in particular:

  • The (tentative) agreement to move forward with phone numbers as an initial, narrowed scope.
  • A perceived consensus to use REGISTER for the phone number use case.
  • A perceived consensus to have the specific phone numbers being registered to be "implicit" (i.e., provisioned in both the SSP and the PBX, and not exchanged on the wire).
  • A perceived consensus not to carry the registered extensions in the REGISTER response
  • A perceived consensus _not_ to use TEL URIs between the SSP and the PBX

I have also started an analysis (in the document) of how this kind of mechanism can play nicely with GRUU and reg-event. We need to do the same thing for Path, Service-Info, and Outbound, but I think they may be less problematic than the other two.

The document is available here:

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

If I have time, I plan to flesh this out a bit more before the virtual interim meeting on Tuesday. But I wanted to make sure I got an early version out there for everyone to look at so I don't spring it on you the day before the call like last time.

/a
--------------000308020408090501070208-- From D.Hancock@CableLabs.com Tue Feb 2 16:38: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 81F073A6BAF for ; Tue, 2 Feb 2010 16:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.066 X-Spam-Level: X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_45=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 CxA3JTDPaxam for ; Tue, 2 Feb 2010 16:38:50 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 89E123A6BA8 for ; Tue, 2 Feb 2010 16:38:50 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o130dS2h019393; Tue, 2 Feb 2010 17:39:29 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 2 Feb 2010 17:39:29 -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; Tue, 2 Feb 2010 17:39:29 -0700 From: David Hancock To: Paul Kyzivat Date: Tue, 2 Feb 2010 17:39:27 -0700 Thread-Topic: [martini] Use Cases: what's important, what's not Thread-Index: AcqkSfyyClAhQH5bSMeefr+07J+S9QAFLfmQ Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4B2A8CA@srvxchg> References: <4B6767A4.8000008@nostrum.com> <76AC5FEF83F1E64491446437EA81A61F7CD4B2A867@srvxchg> <4B689107.9060301@cisco.com> In-Reply-To: <4B689107.9060301@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-Approved: ondar Cc: "martini@ietf.org" Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 00:38:52 -0000 Paul, I agree, it's possible for the PBX to use a subdomain of the SSP. In fact I= expect this to be a common case for operators targeting small businesses t= hat don't have their own domains. Regarding the security issue you raised -- does the same security issue exi= st for the "peering" model, where the SSP network (say SSPt in the diagram)= acts as a transit network to provide connectivity between the enterprise-p= eer and the global network? UAx---SSPx---+ |-----SSPt---PBXpanam---UApa UAy---SSPy---+ Thanks David > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 02, 2010 1:55 PM > To: David Hancock > Cc: Adam Roach; martini@ietf.org > Subject: Re: [martini] Use Cases: what's important, what's not > > David, > > A slight variant on these cases is using > sip:+12145550105@pan-am.centricvoice.com. > > It that case the domain used by the pbx is a subdomain of the SSPs > domain, and so it presumably owns and manages it on behalf of the pbx > customer. Using pan-am.com would be just as goof, *if* centricvoice also > owned and managed the domain name on behalf of the customer. But that > wouldn't make sense for a company the size of pan-am (when it was a > going concern.) > > Otherwise the SSP is put in the position of having to legally vouch for > this particular pbx belonging to somebody who has rights to the domain > name pan-am.com. It seems questionable whether an SSP could/would do > that if the question came to their legal department. > > Thanks, > Paul > > David Hancock wrote: > > Adam, > > > > > > > > Thanks for documenting these different use cases. > > > > > > > > Here is my understanding of John Elwell's use-case 8 (combination of 2 > > and 6) and my use-case 9 (combination of 1 and 6). > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 8 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > Internet CentricVoice > > Pan-Am > > > > |INVITE | > | > > |sip:+12145550105@pan-am.com > > | | > > |--------------------------------->| > | > > | |INVITE > | > > | |sip:+12145550105@pan-am.com > | > > | |-------------------------------= - > ->| > > | |Route: > | > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 9 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Internet CentricVoice > > Pan-Am > > > > |INVITE | > | > > |sip:+12145550105@centricvoice.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | |sip:+12145550105@pan-am.com > | > > | |-------------------------------= - > ->| > > | |Route: > | > > > > > > > > > > > > > > > > I think that 9 would be the most common case in the real world. A user > > in the originating VoIP network dials a digit string identifying the > > Pan-Am enterprise user, the originating network converts the string to > > an E.164 number, and converts that to the SIP URI > > sip:+12145550105@centricvoice.com; user=3Dphone (probably via ENUM). Th= e > > CentricVoice network receives the request, and converts the received > > E.164 number via its private database (possibly ENUM), to > > sip:+12145550105@pan-am.com, and then routes the request using to the > > registered contact address for that URI using loose-routing > > > > > > > > Thanks > > > > David > > > > > > > > > > > > > > > > -----------------------------------------------------------------------= - > > > > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > > Behalf Of *Adam Roach > > *Sent:* Monday, February 01, 2010 4:46 PM > > *To:* martini@ietf.org > > *Subject:* [martini] Use Cases: what's important, what's not > > > > > > > > The more we talk about this, the further apart opinions seem to get. > > There appears to be a lot of ocean boiling going on right now, such tha= t > > even when we can decide on a fairly narrow scope ("phone numbers only")= , > > the system behavior that people expect appears to vary literally from > > person to person. > > > > I'm going to try to do something like I did before with the diagrams, > > this time focusing on just what happens for E.164 numbers. I'll continu= e > > with using the same dead companies as before (CentricVoice as the SSP, > > and Pan-Am as the PBX). > > > > In particular, I'm assuming that the tentative (albeit far from > > unanimous) agreement to do an initial batch of work towards E.164 > > numbers means that these kinds of use cases are not under discussion at > > the moment: > > > > > > > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:not-a-number@centricvoice.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | |sip:some-other-string@pan-am.co= m > | > > | |-------------------------------= - > ->| > > > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:not-a-number@pan-am.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | |sip:some-other-string@pan-am.co= m > | > > | |-------------------------------= - > ->| > > > > > > > > > > So, ignoring those, we seem to still have a huge disconnect on what the > > SSP needs to be able to do as a result of the MARTINI operations. Now, > > one of the nice things we get from E.164 numbers is that usernames now > > become unique. We can specify transformations such that the username > > that arrives at the SSP stays the same as it passes through the SSP. > > Unlike my earlier examples, I'm going to assume that limiting to E.164 > > enables this kind of trivial transformation. Not in the *general* case, > > of course -- only for MARTINI-routed E.164 numbers. > > > > As you read through these, try to place each use case in one of the > > following categories: > > > > 1. This use case by itself is sufficient for the architecture {I > > am/my customers are} trying to deploy > > 2. This use case is necessary for the architecture {I am/my customer= s > > are} trying to deploy, but requires other use cases also. > > 3. This use case is neither necessary nor sufficient for the > > architecture {I am/my customers are} trying to deploy. > > > > > > Frankly, I would expect almost everyone will be able to place each use > > case in category #1. All of these solutions certainly allow the PBX to > > figure out who the call is supposed to be sent to, and that appears to > > be the key criteria for the inbound messages. > > > > -----------------------------------------------------------------------= - > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 1 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > RFC3263 for "pan-am.com" is not relevant. > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:+12145550105@centricvoice.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | |sip:+12145550105@pan-am.com > | > > | |-------------------------------= - > ->| > > > > > > In this use case, the SSP receives a URI indicating its own domain. The > > SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having > > received information from Pan-Am about its PBX's IP address, it changes > > the domain to "pan-am.com," keeps the user ID, ignores RFC 3263 > > procedures, and sends the request to the MARTINI-registered IP address > > it has for Pan-Am. > > > > The key drawback for this use case is the disregard for RFC3263 > procedures. > > > > -----------------------------------------------------------------------= - > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 2 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RFC3263 for "pan-am.com" resolves to the CentricVoice servers. > > > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:+12145550105@pan-am.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | |sip:+12145550105@pan-am.com > | > > | |-------------------------------= - > ->| > > > > > > In this use case, the SSP receives a URI indicating the domain for > > pan-am.com. Having received information from Pan-Am about its PBX's IP > > address, it leaves the Request-URI alone, ignores RFC 3263 procedures, > > and sends the request to the MARTINI-registered IP address it has for > > Pan-Am. > > > > Note that this use case is predicated on an external entity -- somethin= g > > on the other side of the "Internet" cloud -- being able to take the > > E.164 number "+12145550105" and figure out that it needs to go to the > > domain "pan-am.com". I emphasize this because I know some people are > > interested in models in which is tenable to track "phone number to SSP" > > mapping, while the relatively larger number of "phone number to end > > customer" mappings might be unpalatable. > > > > The key drawbacks for this use case are: > > > > 1. The disregard for RFC3263 procedures > > 2. Ambiguity around which SIP nodes are "responsible for" pan-am.com > > (in the RFC 3261 sense of that word). Cullen had a litmus test fo= r > > this: is CentricVoice allowed to redirect calls for pan-am.com to > > a voicemail server or answering service? > > > > > > Given that 3261 lacks a formal description of "responsible for," we can > > potentially define the problem of "responsible for" away (as Keith has > > proposed) -- but I'm pretty certain it's not within MARTINI's scope to > > clarify the terms appearing in RFC 3261. I think that would need to go > > back to DISPATCH, and I doubt we want to wait for such an effort to > > complete. > > > > -----------------------------------------------------------------------= - > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 3 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:+12145550105@centricvoice.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | |sip:+12145550105@192.168.17.25 > | > > | |-------------------------------= - > ->| > > > > > > In this use case, the SSP receives a request for its own domain. The SS= P > > is provisioned to know that +12145550105 belongs to Pan-Am. Having > > received information from Pan-Am about its PBX's IP address, it changes > > the domain to that registered IP address (192.168.17.25), keeps the use= r > > ID, correctly invokes RFC 3263 procedures, and sends the request to the > > resulting host (192.168.17.25). > > > > This use case does not suffer from any of the drawbacks discussed to > > date, other than differing from the model that is currently deployed fo= r > > bulk registrations (even though it is functionally identical to the > > model deployed for single registrations). > > > > -----------------------------------------------------------------------= - > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 4 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RFC3263 for "pan-am.com" resolves to the CentricVoice servers. > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:+12145550105@pan-am.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | |sip:+12145550105@192.168.17.25 > | > > | |-------------------------------= - > ->| > > > > In this use case, the SSP receives a URI indicating the domain for > > pan-am.com. Having received information from Pan-Am about its PBX's IP > > address, it changes the domain to that registered IP address > > (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 > > procedures, and sends the request to the resulting host (192.168.17.25)= . > > > > Like use case 3, this use case does not suffer from any of the drawback= s > > discussed to date, other than differing from the model that is currentl= y > > deployed for bulk registrations (even though it is functionally > > identical to the model deployed for single registrations). However, it > > is predicated on an external entity -- something on the other side of > > the "Internet" cloud -- being able to take the E.164 number > > "+12145550105" and figure out that it needs to go to the domain > > "pan-am.com". > > > > -----------------------------------------------------------------------= - > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 5 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:+12145550105@centricvoice.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | |tel:+12145550105 > | > > | |-------------------------------= - > ->| > > > > > > In this use case, the SSP receives a URI indicating its own domain. The > > SSP is provisioned to know that +12145550105 belongs to Pan-Am. It > > changes the R-URI to a tel: URI containing only the E.164 number in > > question. Having received information from Pan-Am about its PBX's IP > > address, it sends the request to the resulting host (192.168.17.25). > > Since the URI in question is a TEL URI, RFC3263 issues are avoided > > altogether, eliminating any alt-root considerations. > > > > The major drawback to this use case is that it (likely) requires the > > ability to register TEL URIs, which is currently normatively forbidden > > by RFC 3261. While this is tractable, it would require companion work i= n > > SIPCORE to relax this normative requirement. It also would likely > > require more mechanism than other approaches, since we're effectively > > adding on a new URI-to-host address resolution procedure. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 5a > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > A variation on Use Case 5, this use case ends up with a R-URI of the > > PBX's lead number, with an extension parameter that indicates the > > desired extension on the PBX: > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:+12145550105@centricvoice.com | > | > > |--------------------------------->| > | > > | |INVITE > | > > | > |tel:+12145550100;extension=3D1214555| > > | | > 0105| > > | |-------------------------------= - > ->| > > > > > > This is effectively the exact same procedure as Use Case 5; however, it > > may make contact registration somewhat easier (depending on the exact > > mechanism used to communicate domain IP addresses). > > > > -----------------------------------------------------------------------= - > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 6 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:+12145550105@centricvoice.com | > | > > |--------------------------------->|INVITE > | > > | > |sip:+12145550105@centricvoice.com | > > | |Route: > | > > | |-------------------------------= - > ->| > > > > In this example, In this use case, the SSP receives a URI indicating it= s > > own domain. The SSP is provisioned to know that +12145550105 belongs to > > Pan-Am. It pushes the MARTINI-registered contact into the route set, > > leaves the Request-URI unmodified, invokes RFC 3263 procedures (on the > > Route) and sends the request to the resulting host. > > > > A key drawback to this use case is that it cannot be effected using > > REGISTER without radically changing the semantics of REGISTER (i.e., > > registering a path towards an AOR instead of a contact for an AOR). > > These changes necessarily require intermediaries who are a party to the > > REGISTER transaction (e.g., using Path and/or Service-Route) to > > understand these changed semantics, and would require the use of a > > Proxy-Require to avoid the ensuing problems. Using a method other than > > REGISTER eliminates this class of problems. > > > > A second major drawback to this approach pertains to domain > > responsibility: unless the Pan-Am PBX is "responsible for" > > centricvoice.com, it is in violation of SIP routing procedures if it > > fails to route it back to CentricVoice: "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." In > > practice, I imagine it wants to route it to one of its internal > extensions. > > > > -----------------------------------------------------------------------= - > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Use Case 7 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > > > Internet CentricVoice > > Pan-Am > > |INVITE | > | > > |sip:+12145550105@centricvoice.com | > | > > |--------------------------------->|INVITE sip:pbx@192.168.17.25 > | > > | |History-Info: > sip:+12145550105@cen| > > | | > > tricvoice.com| > > | |-------------------------------= - > ->| > > > > > > Similar to use case 6, except the SSP swaps out the registered Contact > > URI for the Request-URI, and squirrels the incoming R-URI (containing > > the phone number) away in a History-Info header field. > > > > On the plus side, this looks a lot like normal proxy/registrar behavior= . > > Drawbacks include defining concrete procedures around which History-Inf= o > > entry to use (which is a problem the 4244bis draft is currently > > struggling with), especially in the case that there are intermediaries > > between the SSP and the PBX. We would also be creating a normative > > dependency on the 4244bis document, which may delay a final delivery of > > MARTINI work substantially. > > > > -----------------------------------------------------------------------= - > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Now, I've heard and read things that imply that each these use cases ar= e > > under consideration by at least one person. I think we need to focus. > > Clearly just saying "phone numbers" is not sufficient. Look back over > > how you rated each of the use cases relative to the "sufficient," > > "necessary but not sufficient," and "neither necessary nor sufficient" > > criteria. I think you'll find that, if you were honest with yourself, > > all or most of these use cases fall into the first category. I'm not > > saying you *like* them all -- merely that they will get the job done, i= f > > push were to come to shove. > > > > So, I think we need to pick one and work on the mechanism required to > > enable it. And I think we need to be vigilant against scope creep. As w= e > > get into mechanism, it will be overwhelmingly tempting to say, "oh, but > > we can add on Use Case X if we just do *this* small thing!" But those > > small things can spiral out of control. > > > > All other things being equal, I have a strong preference for Use Case 3= , > > as its only real drawback is that it varies from the demonstrably flawe= d > > ^[1] mechanism that showed up on the IETF's doorstep. Any other approac= h > > is going to require interested parties coming to consensus on the issue= s > > associated with the other use cases, and I think we've seen that won't > > be a very fast process. > > > > /a > > > > [1] Lest this offend anyone as being too general a criticism, I refer t= o > > the set of shortcomings enumerated here: > > http://www.ietf.org/mail-archive/web/martini/current/msg00412.html > > From D.Hancock@CableLabs.com Tue Feb 2 20: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 4542F3A67FA for ; Tue, 2 Feb 2010 20:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[AWL=0.252, 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 FongNfZ8ovk2 for ; Tue, 2 Feb 2010 20:38:26 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 66EE73A635F for ; Tue, 2 Feb 2010 20:38:26 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o134d6e3031582; Tue, 2 Feb 2010 21:39:06 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 2 Feb 2010 21:39:06 -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; Tue, 2 Feb 2010 21:39:06 -0700 From: David Hancock To: Adam Roach , MARTINI Date: Tue, 2 Feb 2010 21:39:05 -0700 Thread-Topic: [martini] GIN Draft Thread-Index: AcqkZSkta2/rmnqITB2xbY4XOcWwXQAIfo0Q Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4B2A8EA@srvxchg> References: <4B68BEB4.2020207@nostrum.com> In-Reply-To: <4B68BEB4.2020207@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_76AC5FEF83F1E64491446437EA81A61F7CD4B2A8EAsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 04:38:32 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CD4B2A8EAsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, Interesting mechanism - I like the fact it uses REGISTER, and therefore can= take advantage of already defined REGISTER extensions. I still prefer the = "shaken" mechanism since it's more aligned with IMS, and, I reckon, closer = to the majority of PBX implementations. Question is - does this mechanism offer sufficient advantages to warrant it= s adoption over "shaken"? A couple of comments on GRUU... - The PBX doesn't have sufficient info to coin public GRUUs for its endpoi= nts until it registers with the SSP. So how to handle the case where the PB= X endpoints register with the PBX before the PBX registers with the SSP? - I don't understand the restriction for temp-GRUUs, where the PBX must be= able to accept requests destined for its own self-made GRUUs from sources = other than the SSP. Wouldn't these GRUUs have the domain of the PBX, and th= erefore route via the SSP? The problem with temp-GRUUs is that the user par= t could be anything (and therefore not an E.641 number). Thanks David ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Tuesday, February 02, 2010 5:09 PM To: MARTINI Subject: [martini] GIN Draft I have put together a draft to address Globally Identifiable Numbers for PB= X registration. (Sorry, "Identifiable" was the best near-synonym I could fi= nd for "Unique" starting with I -- and everyone knows real martinis are mad= e with gin. ;-) ) The contents of this draft are based on several factors from the phone call= s and mailing list; in particular: * The (tentative) agreement to move forward with phone numbers as an ini= tial, narrowed scope. * A perceived consensus to use REGISTER for the phone number use case. * A perceived consensus to have the specific phone numbers being registe= red to be "implicit" (i.e., provisioned in both the SSP and the PBX, and no= t exchanged on the wire). * A perceived consensus not to carry the registered extensions in the RE= GISTER response * A perceived consensus _not_ to use TEL URIs between the SSP and the PB= X I have also started an analysis (in the document) of how this kind of mecha= nism can play nicely with GRUU and reg-event. We need to do the same thing = for Path, Service-Info, and Outbound, but I think they may be less problema= tic than the other two. The document is available here: http://www.ietf.org/id/draft-roach-martini-gin-00.txt If I have time, I plan to flesh this out a bit more before the virtual inte= rim meeting on Tuesday. But I wanted to make sure I got an early version ou= t there for everyone to look at so I don't spring it on you the day before = the call like last time. /a --_000_76AC5FEF83F1E64491446437EA81A61F7CD4B2A8EAsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam,

 

Interesting mechanism – I like t= he fact it uses REGISTER, and therefore can take advantage of already defined REGISTER extensions. I still prefer the “shaken” mechanism sinc= e it’s more aligned with IMS, and, I reckon, closer to the majority of PBX implementations.

 

Question is – does this mechanis= m offer sufficient advantages to warrant its adoption over “shaken”?

 

A couple of comments on GRUU…

 - The PBX doesn’t have sufficient info to coin public GRUUs for its endpoints until it registers w= ith the SSP. So how to handle the case where the PBX endpoints register with th= e PBX before the PBX registers with the SSP?

 - I don’t understand the restriction for temp-GRUUs, where the PBX must be able to accept requests destined for its own self-made GRUUs from sources other than the SSP. Would= n’t these GRUUs have the domain of the PBX, and therefore route via the SSP? Th= e problem with temp-GRUUs is that the user part could be anything (and theref= ore not an E.641 number).

 

Thanks

David

 

 

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.or= g] On Behalf Of Adam Roach
Sent: Tuesday, February 02, = 2010 5:09 PM
To: MARTINI
Subject: [martini] GIN Draft=

=  

I have put togeth= er a draft to address Globally Identifiable Numbers for PBX registration. (Sorry= , "Identifiable" was the best near-synonym I could find for "U= nique" starting with I -- and everyone knows real martinis are made with gin. ;-) = )

The contents of this draft are based on several factors from the phone call= s and mailing list; in particular:

  • The (tentative) agreement to move forward w= ith phone numbers as an initial, narrowed scope.<= /li>
  • A perceived consensus to use REGISTER for t= he phone number use case.
  • A perceived consensus to have the specific = phone numbers being registered to be "implicit" (i.e., provisioned= in both the SSP and the PBX, and not exchanged on the wire).
  • A perceived consensus not to carry the regi= stered extensions in the REGISTER response
  • A perceived consensus _not_ to use TEL URIs between the SSP and the PBX

=
I have also started an analysis (in the document) of how this kind of mecha= nism can play nicely with GRUU and reg-event. We need to do the same thing for P= ath, Service-Info, and Outbound, but I think they may be less problematic than t= he other two.

The document is available here:

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

If I have time, I plan to flesh this out a bit more before the virtual inte= rim meeting on Tuesday. But I wanted to make sure I got an early version out th= ere for everyone to look at so I don't spring it on you the day before the call like last time.

/a

--_000_76AC5FEF83F1E64491446437EA81A61F7CD4B2A8EAsrvxchg_-- From spencer@wonderhamster.org Tue Feb 2 20:52: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 E6DCA3A6879 for ; Tue, 2 Feb 2010 20:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, 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 0ePT3gBf5Zan for ; Tue, 2 Feb 2010 20:52:31 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id DD3E73A68BD for ; Tue, 2 Feb 2010 20:52:30 -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 0MTj7Q-1NCEwv1o6i-00QvmA; Tue, 02 Feb 2010 23:52:31 -0500 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" , "MARTINI" References: <4B68BEB4.2020207@nostrum.com> Date: Tue, 2 Feb 2010 22:52:16 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_132D_01CAA45A.5E2363F0" 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+WPHlyPZlrkJiYwcHX6L6IOEHJvWvP4vxr8Hn MMF6gcfQDyBzprjLR/dOdWu3aNf11h6KnsnSn06Z9eFG/Y6j9T n5sbR9YVMBAQAU4XJ9CLgXIxMJAFR4GfKODvhdn370= Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 04:52:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_132D_01CAA45A.5E2363F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adam,=20 Thank you for producing this very helpful draft. We need to work through = it as a group, including what you've identified as open issues and = analysis that needs to be performed, but I'm feeling better about us = converging in finite time (and I believe Bernard is, as well). Spencer ----- Original Message -----=20 From: Adam Roach=20 To: MARTINI=20 Sent: Tuesday, February 02, 2010 6:09 PM Subject: [martini] GIN Draft I have put together a draft to address Globally Identifiable Numbers = for PBX registration. (Sorry, "Identifiable" was the best near-synonym I = could find for "Unique" starting with I -- and everyone knows real = martinis are made with gin. ;-) ) The contents of this draft are based on several factors from the phone = calls and mailing list; in particular: a.. The (tentative) agreement to move forward with phone numbers as = an initial, narrowed scope. b.. A perceived consensus to use REGISTER for the phone number use = case.=20 c.. A perceived consensus to have the specific phone numbers being = registered to be "implicit" (i.e., provisioned in both the SSP and the = PBX, and not exchanged on the wire). d.. A perceived consensus not to carry the registered extensions in = the REGISTER response=20 e.. A perceived consensus _not_ to use TEL URIs between the SSP and = the PBX=20 I have also started an analysis (in the document) of how this kind of = mechanism can play nicely with GRUU and reg-event. We need to do the = same thing for Path, Service-Info, and Outbound, but I think they may be = less problematic than the other two. The document is available here: http://www.ietf.org/id/draft-roach-martini-gin-00.txt If I have time, I plan to flesh this out a bit more before the virtual = interim meeting on Tuesday. But I wanted to make sure I got an early = version out there for everyone to look at so I don't spring it on you = the day before the call like last time. /a -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_132D_01CAA45A.5E2363F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Adam,
 
Thank you for producing this very helpful draft. We = need to=20 work through it as a group, including what you've identified as open = issues and=20 analysis that needs to be performed, but I'm feeling better about us = converging=20 in finite time (and I believe Bernard is, as well).
 
Spencer
----- Original Message -----
From:=20 Adam = Roach
To: MARTINI
Sent: Tuesday, February 02, = 2010 6:09=20 PM
Subject: [martini] GIN = Draft

I have put together a draft to address Globally = Identifiable=20 Numbers for PBX registration. (Sorry, "Identifiable" was the best = near-synonym=20 I could find for "Unique" starting with I -- and everyone knows real = martinis=20 are made with gin. ;-) )

The contents of this draft are based = on=20 several factors from the phone calls and mailing list; in = particular:

  • The (tentative) agreement to move forward with phone numbers as = an=20 initial, narrowed scope.
  • A perceived consensus to use REGISTER for the phone number use = case.=20
  • A perceived consensus to have the specific phone numbers being=20 registered to be "implicit" (i.e., provisioned in both the SSP and = the PBX,=20 and not exchanged on the wire).
  • A perceived consensus not to carry the registered extensions in = the=20 REGISTER response=20
  • A perceived consensus _not_ to use TEL URIs between the SSP and = the PBX=20

I have also started an analysis (in the document) of = how this=20 kind of mechanism can play nicely with GRUU and reg-event. We need to = do the=20 same thing for Path, Service-Info, and Outbound, but I think they may = be less=20 problematic than the other two.

The document is available=20 here:

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

If=20 I have time, I plan to flesh this out a bit more before the virtual = interim=20 meeting on Tuesday. But I wanted to make sure I got an early version = out there=20 for everyone to look at so I don't spring it on you the day before the = call=20 like last time.

/a

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_132D_01CAA45A.5E2363F0-- From bernard_aboba@hotmail.com Tue Feb 2 22:08: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 856213A6880 for ; Tue, 2 Feb 2010 22:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=-1.122, 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 wm4atReIawgH for ; Tue, 2 Feb 2010 22:08:33 -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 5C54B3A6835 for ; Tue, 2 Feb 2010 22:08:33 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.73]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 22:09:14 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 2 Feb 2010 22:09:51 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0400_01CAA454.71A3D190" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqkl3928zt6Ms83SGyXln5xIe+/zg== Content-Language: en-us X-OriginalArrivalTime: 03 Feb 2010 06:09:14.0255 (UTC) FILETIME=[6906C9F0:01CAA497] Subject: [martini] Yet another Doodle Poll: Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 06:08:37 -0000 ------=_NextPart_000_0400_01CAA454.71A3D190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The schedule of virtual interims has been somewhat grueling, but it has been brought to our attention that just one more Virtual Interim might help. So in that spirit, we're taking a Doodle poll to find an appropriate meeting time during the week of February 22-26, 2010: http://www.doodle.com/gfd9ramt42v5cxbd ------=_NextPart_000_0400_01CAA454.71A3D190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The schedule of virtual interims has been somewhat = grueling, but it has been brought to our attention that just one more Virtual = Interim might help.

 

So in that spirit, we’re taking a Doodle poll = to find an appropriate meeting time during the week of February 22-26, = 2010:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

 

------=_NextPart_000_0400_01CAA454.71A3D190-- From john.elwell@siemens-enterprise.com Wed Feb 3 00:01: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 075D63A69FB for ; Wed, 3 Feb 2010 00:01:22 -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.061, 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 9mSfmcGOHXf8 for ; Wed, 3 Feb 2010 00:01:18 -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 5AF1B3A6991 for ; Wed, 3 Feb 2010 00:01:16 -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-757677; Wed, 3 Feb 2010 09:01:56 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B83B81EB82CB; Wed, 3 Feb 2010 09:01:56 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 3 Feb 2010 09:01:56 +0100 From: "Elwell, John" To: Bernard Aboba , "martini@ietf.org" Date: Wed, 3 Feb 2010 09:01:55 +0100 Thread-Topic: [martini] Yet another Doodle Poll: Virtual Interim IV Thread-Index: Acqkl3928zt6Ms83SGyXln5xIe+/zgAD2bFA 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_A444A0F8084434499206E78C106220CAB8FEA127MCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 08:01:22 -0000 --_000_A444A0F8084434499206E78C106220CAB8FEA127MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am guessing these times are EST (GMT-5). If not, my response will be wron= g. John ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: 03 February 2010 06:10 To: martini@ietf.org Subject: [martini] Yet another Doodle Poll: Virtual Interim IV The schedule of virtual interims has been somewhat grueling, but it has bee= n brought to our attention that just one more Virtual Interim might help. So in that spirit, we're taking a Doodle poll to find an appropriate meetin= g time during the week of February 22-26, 2010: http://www.doodle.com/gfd9ramt42v5cxbd --_000_A444A0F8084434499206E78C106220CAB8FEA127MCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am guessing these times are EST (GMT-5). If not,= my=20 response will be wrong.
 
John

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 03 February 2010 06:10
To:=20 martini@ietf.org
Subject: [martini] Yet another Doodle Poll: Vi= rtual=20 Interim IV

The schedule of virtual interims has been somewhat=20 grueling, but it has been brought to our attention that just one more Vir= tual=20 Interim might help.

 

So in that spirit, we’re taking a Doodle poll = to find an=20 appropriate meeting time during the week of February 22-26,=20 2010:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

 

--_000_A444A0F8084434499206E78C106220CAB8FEA127MCHP058Aglobala_-- From md3135@att.com Wed Feb 3 00:06: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 1408F3A6A65 for ; Wed, 3 Feb 2010 00:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkpp0mJ9E1Jy for ; Wed, 3 Feb 2010 00:06:27 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 70E163A6A5F for ; Wed, 3 Feb 2010 00:06:27 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-5.tower-129.messagelabs.com!1265184427!25556173!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 14629 invoked from network); 3 Feb 2010 08:07:07 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Feb 2010 08:07:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o13870wW009088; Wed, 3 Feb 2010 03:07:00 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1386vhw009077; Wed, 3 Feb 2010 03:06:57 -0500 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_01CAA4A7.DE82DBC3" Date: Wed, 3 Feb 2010 03:07:01 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA058BC87C@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Yet another Doodle Poll: Virtual Interim IV Thread-Index: Acqkl3928zt6Ms83SGyXln5xIe+/zgAEEX2A References: From: "DOLLY, MARTIN C (ATTLABS)" To: "Bernard Aboba" , Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 08:06:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA4A7.DE82DBC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The week of the 22nd is 3GPP, so it would be hit or miss for me =20 From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, February 03, 2010 1:10 AM To: martini@ietf.org Subject: [martini] Yet another Doodle Poll: Virtual Interim IV =20 The schedule of virtual interims has been somewhat grueling, but it has been brought to our attention that just one more Virtual Interim might help.=20 =20 So in that spirit, we're taking a Doodle poll to find an appropriate meeting time during the week of February 22-26, 2010: http://www.doodle.com/gfd9ramt42v5cxbd =20 =20 =20 ------_=_NextPart_001_01CAA4A7.DE82DBC3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The week of the = 22nd is 3GPP, so it would be hit or miss for me

 

From:= martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba
Sent: Wednesday, February 03, 2010 1:10 AM
To: martini@ietf.org
Subject: [martini] Yet another Doodle Poll: Virtual Interim = IV

 

The schedule of virtual interims has been somewhat = grueling, but it has been brought to our attention that just one more Virtual = Interim might help.

 

So in that spirit, we’re taking a Doodle poll = to find an appropriate meeting time during the week of February 22-26, = 2010:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

 

------_=_NextPart_001_01CAA4A7.DE82DBC3-- From HKaplan@acmepacket.com Wed Feb 3 00:35: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 A668C3A6A6B for ; Wed, 3 Feb 2010 00:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, 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 OC74MMGN7yxM for ; Wed, 3 Feb 2010 00:35:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B54D43A68F0 for ; Wed, 3 Feb 2010 00:35:30 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 3 Feb 2010 03:36:10 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 3 Feb 2010 03:36:11 -0500 From: Hadriel Kaplan To: "Elwell, John" , Bernard Aboba , "martini@ietf.org" Date: Wed, 3 Feb 2010 03:36:08 -0500 Thread-Topic: [martini] Yet another Doodle Poll: Virtual Interim IV Thread-Index: Acqkl3928zt6Ms83SGyXln5xIe+/zgAD2bFAAAEmjAA= Message-ID: <430FC6BDED356B4C8498F634416644A917E5C9A2C2@mail> 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_430FC6BDED356B4C8498F634416644A917E5C9A2C2mail_" MIME-Version: 1.0 Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 08:35:34 -0000 --_000_430FC6BDED356B4C8498F634416644A917E5C9A2C2mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oh, I was assuming PDT, otherwise my answers are wrong. (every other poll w= as PDT, 'cause Bernard's in PDT) -hadriel ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Elwell, John Sent: Wednesday, February 03, 2010 3:02 AM To: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV I am guessing these times are EST (GMT-5). If not, my response will be wron= g. John ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: 03 February 2010 06:10 To: martini@ietf.org Subject: [martini] Yet another Doodle Poll: Virtual Interim IV The schedule of virtual interims has been somewhat grueling, but it has bee= n brought to our attention that just one more Virtual Interim might help. So in that spirit, we're taking a Doodle poll to find an appropriate meetin= g time during the week of February 22-26, 2010: http://www.doodle.com/gfd9ramt42v5cxbd --_000_430FC6BDED356B4C8498F634416644A917E5C9A2C2mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Oh, I was assuming PDT, otherwise my answers are wrong. (every other poll was PDT, ‘cause Bernard’s = in PDT)

-hadriel

 

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John
Sent: Wednesday, February 03= , 2010 3:02 AM
To: Bernard Aboba; martini@ietf.org
Subject: Re: [martini] Yet a= nother Doodle Poll: Virtual Interim IV=

 

I am guessing these times are EST (GMT= -5). If not, my response will be wrong.

 

John

 

From:= martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 03 February 2010 06:10=
To: martini@ietf.org
Subject: [martini] Yet anoth= er Doodle Poll: Virtual Interim IV=

The schedule of virtual interims has been somewhat grueling, but it has been brought to our attention that just one more Virtual Interim might help.

 

So in that spirit, we’re taking a Doodle poll to find an appropriate mee= ting time during the week of February 22-26, 2010:

http://www.doodle.com/gfd9r= amt42v5cxbd

 

 

 

--_000_430FC6BDED356B4C8498F634416644A917E5C9A2C2mail_-- From HKaplan@acmepacket.com Wed Feb 3 00:45: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 D75CA3A6AA6 for ; Wed, 3 Feb 2010 00:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 TRzZIv02pjVi for ; Wed, 3 Feb 2010 00:45:34 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E85E43A6AA3 for ; Wed, 3 Feb 2010 00:45:33 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 3 Feb 2010 03:46:14 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 3 Feb 2010 03:46:14 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Wed, 3 Feb 2010 03:46:12 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-number registrationfirst Thread-Index: AcqkZKdL0eNRfmsAQFe9h3a3JnGHigAR26cg Message-ID: <430FC6BDED356B4C8498F634416644A917E5C9A2C3@mail> 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> <4B68BDC5.9060106@cisco.com> In-Reply-To: <4B68BDC5.9060106@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: Wed, 03 Feb 2010 08:45:35 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 02, 2010 7:05 PM > To: Hadriel Kaplan >=20 > The purpose of standards is to get people to do things in a consistent > way. The need for a mapping function is evidence that standards are > lacking or not being used. I think we were talking past each other. I meant that since the SIP reques= t had SIP URI's to begin with when it reach the SSP, mandating a TEL URI do= esn't avoid mapping, because something has to map it to the TEL URI before = sending it to the PBX. =20 > I guess you don't want usage to change in such a way as to put you out > of business. :-) >=20 > But you are right - it is true that a pbx can live in blissful > ignorance, assuming that all SIP URIs are of the form > sip:@my-name.com as long as its only communication with the > external world is via an SBC that preserves that myth. Actually, I've been pretty consistently trying to advocate for things so th= at SBC's don't have to do "mappings" or interop fix-its. If I wanted to ke= ep having to fix stuff to make SIP work, I'd ignore the IETF and SIP-Forum. -hadriel From john.elwell@siemens-enterprise.com Wed Feb 3 01:04: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 18A213A6ABD for ; Wed, 3 Feb 2010 01:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 BqQZ5ZsVu7C1 for ; Wed, 3 Feb 2010 01:04:07 -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 40EEB3A69BB for ; Wed, 3 Feb 2010 01:04:02 -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-758067; Wed, 3 Feb 2010 10:04:43 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 69DD623F02C3; Wed, 3 Feb 2010 10:04:43 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 3 Feb 2010 10:04:43 +0100 From: "Elwell, John" To: Paul Kyzivat , Adam Roach Date: Wed, 3 Feb 2010 10:04:41 +0100 Thread-Topic: Further details around use case 3 Thread-Index: AcqkVrZYjYznVRegT2OBCnVMrEcBAQAUgqdA Message-ID: References: <4B6767A4.8000008@nostrum.com> <4B68A66C.50108@cisco.com> In-Reply-To: <4B68A66C.50108@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: [martini] Further details around use case 3 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 09:04:08 -0000 Notwithstanding dicusssions about use of domain names instead of IP address= es in certain circumstances, there seems to be some convergence on Adam's u= se case 3 (not necessarily as the only solution, but let's focus on that). To Paul's questions about From, To and PAI, I think we should also add Cont= act. In the following examples I will show only the flows between the SSP and th= e PBX 1. Inbound call to PBX. PBX SSP INVITE sip:123456789@10.1.2.3 To: Q1 (see below) From: Not relevant PAI: Not relevant Contact: Not relevant <------------------------- 180 Contact: Q2 (see below) --------------------------> 2. Outbound call from PBX. =20 PBX SSP INVITE Any off-PBX value To: Q3 (see below) From: Q4 (see below) PAI: Q5 (see below) Contact: Q6 (see below) -------------------------> 180 Contact: Not relevant <-------------------------- Questions raised: Q1: Value of To URI in inbound INVITE request: In principle, it could be any value, since the request may have been retarg= eted to the PBX. However, in the most common case I would expect it to have= a URI of the form sip:+123456789@ssp.net;useer=3Dphone. Q2: Value of Contact URI sent by PBX in response to inbound INVITE request: Option 1: It must be one of the registered contact URIs (i.e., correspondin= g to one of the registered E.164 numbers). This is not viable for two reaso= ns: a) because this would fail to identify the particular UA on the PBX that ha= s accepted the call; b) because the call might have been retargeted by the PBX to a destination = that is not one of the registered E.164 numbers. Option 2: Any value ending in @10.1.2.3. The PBX could then choose a value = that identifies the specific UA that accepted the call. The SSP would proba= bly need to record-route to ensure inbound mid-dialog requests can reach th= e PBX, and would probably need to act as a B2BUA and map to a globally rout= able contact URI if it needs a URI with gruu properties for functions like = transfer. Option 3: I don't think the PBX would necessarily be able claim gruu proper= ties for a contact URI in accordance with option 2, in which case if it nee= ded a gruu, it would need to obtain one from the SSP using the REGISTER tra= nsaction. I really don't know if and how this would work. Q3: Value of To URI in outbound INVITE request: In most cases it would reflect the value of the Request-URI. In some cases = it could differ, if the request has already been retargeted. If the origina= l target was an on-PBX E.164 number, similar considerations to From (Q4) ap= ply. Q4: Value of From URI in outbound INVITE request: Option 1: Of the form sip:123456789@10.1.2.3. But this is a contact URI. Option 2: Of the form sip:+123456789@ssp.net;user=3Dphone. Option 3: Of the form sip:+123456789@pbx.com;user=3Dphone. But this brings = back the whole argument about domain names. Option 4: Of the form tel:+123456789 Also, what if the request comes from a source that is not reachable by inbo= und requests, i.e., it is not from a registered E.164 number? If you want to use RFC 4474, I think only option 3 would be viable, so perh= aps we have to rule out the ability to use RFC 4474 except under certain co= nditions. Q5: Value of PAI in outbound INVITE request: Similar considerations to Q5: In addition, option 2 looks suspect, because = it would require the PBX to make an assertion on behalf of the SSP. Q6: Value of Contact URI in outbound INVITE request: Similar considerations to Q2, bearing in mind the source of the request mig= ht not be a UA bound to one of the registered E.164 numbers. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 02 February 2010 22:26 > To: Adam Roach > Cc: martini@ietf.org > Subject: Re: [martini] Use Cases: what's important, what's not >=20 > I'll echo others and thank Adam for focusing things. > (I know some additional candidates have been added, but I=20 > think others=20 > are falling off the list.) >=20 > I propose that we need some additional detail in all of these=20 > cases that=20 > hasn't been focused on much so far. Namely, the From and To=20 > addresses. I=20 > realize they aren't germane to routing the request, but they are=20 > potentially important for security and simply for a recipient=20 > deciding=20 > where to send a followup request. The choice made affects=20 > whether these=20 > values will have to be replaced by some middlebox along the=20 > way, and so=20 > is significant. Maybe we need to discuss P-Asserted-ID as well, for=20 > those that use it. >=20 > Thanks, > Paul From john.elwell@siemens-enterprise.com Wed Feb 3 01:10: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 151BF3A6ADB for ; Wed, 3 Feb 2010 01:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.058, 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 hbMGJ6AOmE+i for ; Wed, 3 Feb 2010 01:10:23 -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 B3F3A3A6AD2 for ; Wed, 3 Feb 2010 01:10:22 -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-758530; Wed, 3 Feb 2010 10:11:03 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 863ED23F02C3; Wed, 3 Feb 2010 10:11:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 3 Feb 2010 10:11:03 +0100 From: "Elwell, John" To: Hadriel Kaplan , Bernard Aboba , "martini@ietf.org" Date: Wed, 3 Feb 2010 10:11:01 +0100 Thread-Topic: [martini] Yet another Doodle Poll: Virtual Interim IV Thread-Index: Acqkl3928zt6Ms83SGyXln5xIe+/zgAD2bFAAAEmjAAAAU4xIA== Message-ID: References: <430FC6BDED356B4C8498F634416644A917E5C9A2C2@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5C9A2C2@mail> 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_A444A0F8084434499206E78C106220CAB8FEA193MCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 09:10:28 -0000 --_000_A444A0F8084434499206E78C106220CAB8FEA193MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, I changed mine on assumption of GMT-8. John ________________________________ From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: 03 February 2010 08:36 To: Elwell, John; Bernard Aboba; martini@ietf.org Subject: RE: [martini] Yet another Doodle Poll: Virtual Interim IV Oh, I was assuming PDT, otherwise my answers are wrong. (every other poll w= as PDT, 'cause Bernard's in PDT) -hadriel ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Elwell, John Sent: Wednesday, February 03, 2010 3:02 AM To: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV I am guessing these times are EST (GMT-5). If not, my response will be wron= g. John ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: 03 February 2010 06:10 To: martini@ietf.org Subject: [martini] Yet another Doodle Poll: Virtual Interim IV The schedule of virtual interims has been somewhat grueling, but it has bee= n brought to our attention that just one more Virtual Interim might help. So in that spirit, we're taking a Doodle poll to find an appropriate meetin= g time during the week of February 22-26, 2010: http://www.doodle.com/gfd9ramt42v5cxbd --_000_A444A0F8084434499206E78C106220CAB8FEA193MCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ok, I changed mine on assumption of=20 GMT-8.
 
John

From: Hadriel Kaplan=20 [mailto:HKaplan@acmepacket.com]
Sent: 03 February 2010=20 08:36
To: Elwell, John; Bernard Aboba;=20 martini@ietf.org
Subject: RE: [martini] Yet another Doodle Poll= :=20 Virtual Interim IV

Oh, I was assu= ming=20 PDT, otherwise my answers are wrong. (every other poll was PDT, ‘ca= use=20 Bernard’s in PDT)

-hadriel<= /o:p>

 

 

From:=20 martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John
Sent: Wednesday, February 03, 2010= 3:02=20 AM
To: Bernard Aboba; martini@ietf.org
Subject: Re: [martini] Yet another= Doodle=20 Poll: Virtual Interim IV

 

I am guessing = these=20 times are EST (GMT-5). If not, my response will be wrong.

 

John

 

From:= =20 martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 03 February 2010=20 06:10
To: martini@ietf.org
Subject: [martini] Yet another D= oodle=20 Poll: Virtual Interim IV

The schedule of virtual interims has been som= ewhat=20 grueling, but it has been brought to our attention that just one more=20 Virtual Interim might help.

 

So in that spirit, we’re taking a Doodl= e poll to=20 find an appropriate meeting time during the week of February 22-26,=20 2010:

http://www.doodle.com/g= fd9ramt42v5cxbd

 

 

 

--_000_A444A0F8084434499206E78C106220CAB8FEA193MCHP058Aglobala_-- From drage@alcatel-lucent.com Wed Feb 3 01:58: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 86BAB28C146 for ; Wed, 3 Feb 2010 01:58:42 -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 2PEclRQyJaUJ for ; Wed, 3 Feb 2010 01:58:41 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id C6C903A686D for ; Wed, 3 Feb 2010 01:58:40 -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.14.3/8.14.3/ICT) with ESMTP id o139m9k2029648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Feb 2010 10:59:15 +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; Wed, 3 Feb 2010 10:58:02 +0100 From: "DRAGE, Keith (Keith)" To: "DOLLY, MARTIN C (ATTLABS)" , Bernard Aboba , "martini@ietf.org" Date: Wed, 3 Feb 2010 10:58:01 +0100 Thread-Topic: [martini] Yet another Doodle Poll: Virtual Interim IV Thread-Index: Acqkl3928zt6Ms83SGyXln5xIe+/zgAEEX2AAALCUaA= Message-ID: References: <14C85D6CCBE92743AF33663BF5D24EBA058BC87C@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA058BC87C@gaalpa1msgusr7e.ugd.att.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_EDC0A1AE77C57744B664A310A0B23AE20AF60AF4FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 09:58:42 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE20AF60AF4FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As Martin indicates, this is a week when virtually every 3GPP working group= is meeting. Spare hours do not exist in that week. Please find another week. Keith ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of DOLLY, MARTIN C (ATTLABS) Sent: Wednesday, February 03, 2010 8:07 AM To: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV The week of the 22nd is 3GPP, so it would be hit or miss for me From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: Wednesday, February 03, 2010 1:10 AM To: martini@ietf.org Subject: [martini] Yet another Doodle Poll: Virtual Interim IV The schedule of virtual interims has been somewhat grueling, but it has bee= n brought to our attention that just one more Virtual Interim might help. So in that spirit, we=92re taking a Doodle poll to find an appropriate meet= ing time during the week of February 22-26, 2010: http://www.doodle.com/gfd9ramt42v5cxbd --_000_EDC0A1AE77C57744B664A310A0B23AE20AF60AF4FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
As Martin indicates, this is a week when virtually= every=20 3GPP working group is meeting. Spare hours do not exist in that=20 week.
 
Please find another week.
 
Keith

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C=20 (ATTLABS)
Sent: Wednesday, February 03, 2010 8:07 AM
To:<= /B>=20 Bernard Aboba; martini@ietf.org
Subject: Re: [martini] Yet anot= her=20 Doodle Poll: Virtual Interim IV

The week of the=20 22nd is 3GPP, so it would be hit or miss for=20 me

 

From:=20 martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf O= f=20 Bernard Aboba
Sent: Wednesday, February 03, 2010 1:10=20 AM
To: martini@ietf.org
Subject: [martini] Yet anothe= r=20 Doodle Poll: Virtual Interim IV

 

The schedule of virtual interims has been somewhat=20 grueling, but it has been brought to our attention that just one more Vir= tual=20 Interim might help.

 

So in that spirit, we=92re taking a Doodle poll to f= ind an=20 appropriate meeting time during the week of February 22-26,=20 2010:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

 

--_000_EDC0A1AE77C57744B664A310A0B23AE20AF60AF4FRMRSSXCHMBSC3d_-- From john.elwell@siemens-enterprise.com Wed Feb 3 02:12: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 5F65B28C159 for ; Wed, 3 Feb 2010 02:12:22 -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.057, 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 loJcgQhS8Y1v for ; Wed, 3 Feb 2010 02:12:21 -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 9D0E83A6C05 for ; Wed, 3 Feb 2010 02:12:18 -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-759176; Wed, 3 Feb 2010 11:12:56 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id AFE8223F02CA; Wed, 3 Feb 2010 11:12:56 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 3 Feb 2010 11:12:56 +0100 From: "Elwell, John" To: Adam Roach , MARTINI Date: Wed, 3 Feb 2010 11:12:55 +0100 Thread-Topic: [martini] GIN Draft Thread-Index: AcqkZSlrmJQiV4kwQeO2lb4i93AEqwAUf31w Message-ID: References: <4B68BEB4.2020207@nostrum.com> In-Reply-To: <4B68BEB4.2020207@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] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 10:12:22 -0000 Adam, Thanks for this. It is a well-thought-through draft that reflects use case = 3 in your earlier proposal, leaving open the possibility of the PBX using a= domain name under certain conditions. It clear differs from some current p= ractices, but it has some similarity to other current practices, and we can= 't please everyone. Some initial questions: 1. I think more work is needed on how to populate other fields in non-REGIS= TER inbound and outbound requests, as discussed in the thread I started "Fu= rther details around use case 3". 2. I am pleased to see the proposals for GRUU in there. I think we also nee= d to discuss the use of non-GRUU contact URIs (see also that other thread). 3. I have a concern about the public GRUU solution. Suppose a UA registered= with the PBX uses one of these permanent GRUUs, and some other on-PBX UA e= nds up making an out-of-dialog request back to that GRUU. It seems the PBX = would be required to route via the SSP, resulting in a hairpin. 4. Concerning the registration event package for individual extension regis= tration state: "If the SSP receives a SUBSCRIBE request for the registration event package with a Request-URI that indicates a contact registered via the "Bulk Number Contact" mechanism defined in this document, " This assumes subscription would use the contact URI, rather than the AOR fo= r subscription. This would imply a two-step approach, i.e., first subscribe= to the single AOR that the PBX uses to register and get back a list of con= tacts, and then subscribe to the individual contact(s). Would it also be po= ssible, knowing a given telephone number, to subscribe to that number and g= et the same result? I don't have a strong opinion either way - just curious= . John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 03 February 2010 00:09 > To: MARTINI > Subject: [martini] GIN Draft >=20 > I have put together a draft to address Globally Identifiable=20 > Numbers for PBX registration. (Sorry, "Identifiable" was the=20 > best near-synonym I could find for "Unique" starting with I=20 > -- and everyone knows real martinis are made with gin. ;-) ) >=20 > The contents of this draft are based on several factors from=20 > the phone calls and mailing list; in particular: >=20 >=20 >=20 > * The (tentative) agreement to move forward with phone=20 > numbers as an initial, narrowed scope. > =09 > * A perceived consensus to use REGISTER for the phone=20 > number use case.=20 > * A perceived consensus to have the specific phone=20 > numbers being registered to be "implicit" (i.e., provisioned=20 > in both the SSP and the PBX, and not exchanged on the wire). > =09 > * A perceived consensus not to carry the registered=20 > extensions in the REGISTER response=20 > * A perceived consensus _not_ to use TEL URIs between the=20 > SSP and the PBX=20 >=20 >=20 > I have also started an analysis (in the document) of how this=20 > kind of mechanism can play nicely with GRUU and reg-event. We=20 > need to do the same thing for Path, Service-Info, and=20 > Outbound, but I think they may be less problematic than the other two. >=20 > The document is available here: >=20 > http://www.ietf.org/id/draft-roach-martini-gin-00.txt >=20 > If I have time, I plan to flesh this out a bit more before=20 > the virtual interim meeting on Tuesday. But I wanted to make=20 > sure I got an early version out there for everyone to look at=20 > so I don't spring it on you the day before the call like last time. >=20 > /a >=20 > = From pkyzivat@cisco.com Wed Feb 3 06:36: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 D39003A6A19 for ; Wed, 3 Feb 2010 06:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 E9WKjpodtHbS for ; Wed, 3 Feb 2010 06:36:30 -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 E6DC33A693F for ; Wed, 3 Feb 2010 06:36:30 -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: ApoEANsYaUutJV2a/2dsb2JhbADBD5gWhEUE X-IronPort-AV: E=Sophos;i="4.49,398,1262563200"; d="scan'208";a="295426283" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 03 Feb 2010 14:37:13 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o13EbDDu001343; Wed, 3 Feb 2010 14:37:13 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); Wed, 3 Feb 2010 08:37:13 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:37:12 -0600 Message-ID: <4B698A21.8060001@cisco.com> Date: Wed, 03 Feb 2010 09:37:21 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Feb 2010 14:37:12.0677 (UTC) FILETIME=[5F94E950:01CAA4DE] Cc: martini@ietf.org Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 14:36:31 -0000 what is the timezone used in the poll? Bernard Aboba wrote: > The schedule of virtual interims has been somewhat grueling, but it has > been brought to our attention that just one more Virtual Interim might > help. > > > > So in that spirit, we’re taking a Doodle poll to find an appropriate > meeting time during the week of February 22-26, 2010: > > http://www.doodle.com/gfd9ramt42v5cxbd > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Wed Feb 3 06:45: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 122AC3A6C3F for ; Wed, 3 Feb 2010 06:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.537 X-Spam-Level: X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 V7ZIjIs+xx31 for ; Wed, 3 Feb 2010 06:45:54 -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 E310C3A68A7 for ; Wed, 3 Feb 2010 06:45: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: ApoEALsaaUutJV2d/2dsb2JhbADBGZgWhEUE X-IronPort-AV: E=Sophos;i="4.49,398,1262563200"; d="scan'208";a="83663287" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2010 14:46:33 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o13EkWCG005080; Wed, 3 Feb 2010 14:46:32 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); Wed, 3 Feb 2010 08:46:32 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:46:32 -0600 Message-ID: <4B698C52.9000609@cisco.com> Date: Wed, 03 Feb 2010 09:46:42 -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> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> <4B621432.8040901@nostrum.com> <4B62F45D.1010707@cisco.com> <4B68BDC5.9060106@cisco.com> <430FC6BDED356B4C8498F634416644A917E5C9A2C3@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5C9A2C3@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2010 14:46:32.0460 (UTC) FILETIME=[AD3D04C0:01CAA4DF] 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: Wed, 03 Feb 2010 14:45:55 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, February 02, 2010 7:05 PM >> To: Hadriel Kaplan >> >> The purpose of standards is to get people to do things in a consistent >> way. The need for a mapping function is evidence that standards are >> lacking or not being used. > > I think we were talking past each other. I meant that since the SIP request had SIP URI's to begin with when it reach the SSP, mandating a TEL URI doesn't avoid mapping, because something has to map it to the TEL URI before sending it to the PBX. If everybody used TEL URIs in From/To when it was a phone number they are calling from or trying to reach, then no mapping of the From/To would be needed, end to end. >> I guess you don't want usage to change in such a way as to put you out >> of business. :-) >> >> But you are right - it is true that a pbx can live in blissful >> ignorance, assuming that all SIP URIs are of the form >> sip:@my-name.com as long as its only communication with the >> external world is via an SBC that preserves that myth. > > Actually, I've been pretty consistently trying to advocate for things so that SBC's don't have to do "mappings" or interop fix-its. If I wanted to keep having to fix stuff to make SIP work, I'd ignore the IETF and SIP-Forum. Yes, I know you have. I was just pulling your chain. Thanks, Paul From john.elwell@siemens-enterprise.com Wed Feb 3 06:51: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 A20723A6C48 for ; Wed, 3 Feb 2010 06:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEFwRaV4GTNH for ; Wed, 3 Feb 2010 06:51: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 5AA4F3A6C43 for ; Wed, 3 Feb 2010 06:51:01 -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-764313 for martini@ietf.org; Wed, 3 Feb 2010 15:51:43 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2241F23F02CA for ; Wed, 3 Feb 2010 15:51: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, 3 Feb 2010 15:51:43 +0100 From: "Elwell, John" To: "martini@ietf.org" Date: Wed, 3 Feb 2010 15:51:42 +0100 Thread-Topic: New draft-elwell-martini-reqs-00 Thread-Index: Acqk4GX9BEwemIghShOl4iFo7zj0Lg== 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] New draft-elwell-martini-reqs-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, 03 Feb 2010 14:51:02 -0000 I have attempted to capture the requirements more formally in a draft: http://tools.ietf.org/id/draft-elwell-martini-reqs-00.txt Basically the requirements are derived from the list we debated on the mail= ing list prior to the last virtual meeting. I have reworded it in terms of = telephone numbers, and also for the time being limited to E.164 (without ne= cessarily precluding a system that would support other forms of telephone n= umbers or even AORs that are not based on telephone numbers). The first few= requirements have been reworded substantially, and a few requirements have= been added (e.g., concerning security). Some of the requirements were deba= ted without real conclusion, and likewise there were a couple of requiremen= ts proposed for which we didn't have consensus, so feel free to raise these= again if you are concerned about what I have written. John From pkyzivat@cisco.com Wed Feb 3 06:51: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 4F49C3A6C50 for ; Wed, 3 Feb 2010 06:51:31 -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 msbNAK4p-deG for ; Wed, 3 Feb 2010 06:51:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 12C2B3A6A15 for ; Wed, 3 Feb 2010 06:51:29 -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: ApoEAOcbaUutJV2Z/2dsb2JhbADBKJgVhEUE X-IronPort-AV: E=Sophos;i="4.49,398,1262563200"; d="scan'208";a="83665386" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2010 14:52:11 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o13EqB8S019107; Wed, 3 Feb 2010 14:52:11 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); Wed, 3 Feb 2010 08:52:11 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:52:11 -0600 Message-ID: <4B698DA6.10201@cisco.com> Date: Wed, 03 Feb 2010 09:52:22 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: <4B698A21.8060001@cisco.com> In-Reply-To: <4B698A21.8060001@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Feb 2010 14:52:11.0105 (UTC) FILETIME=[77162510:01CAA4E0] Cc: martini@ietf.org Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 14:51:31 -0000 never mind. I should have read the following messages. I have voted based on PT. Paul Kyzivat wrote: > what is the timezone used in the poll? > > Bernard Aboba wrote: >> The schedule of virtual interims has been somewhat grueling, but it >> has been brought to our attention that just one more Virtual Interim >> might help. >> >> >> >> So in that spirit, we’re taking a Doodle poll to find an appropriate >> meeting time during the week of February 22-26, 2010: >> >> http://www.doodle.com/gfd9ramt42v5cxbd >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Feb 3 06:57: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 5ACFD28C119 for ; Wed, 3 Feb 2010 06:57:05 -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, 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 pkHaj7e+gO1R for ; Wed, 3 Feb 2010 06:57: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 09AE23A6C50 for ; Wed, 3 Feb 2010 06:56:59 -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 o13EvbTh036618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 08:57:38 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B698EE1.3050108@nostrum.com> Date: Wed, 03 Feb 2010 08:57:37 -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: David Hancock References: <4B68BEB4.2020207@nostrum.com> <76AC5FEF83F1E64491446437EA81A61F7CD4B2A8EA@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD4B2A8EA@srvxchg> Content-Type: multipart/alternative; boundary="------------080608090405020808010704" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 14:57:05 -0000 This is a multi-part message in MIME format. --------------080608090405020808010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/2/10 10:39 PM, David Hancock wrote: > A couple of comments on GRUU... > > - The PBX doesn't have sufficient info to coin public GRUUs for its > endpoints until it registers with the SSP. So how to handle the case > where the PBX endpoints register with the PBX before the PBX registers > with the SSP? > To be clear: the PBX doesn't have sufficient information to coin public GRUUs for its endpoints until it registers with the SSP /for the first time/. There's actually normative language around this in GRUU, but the non-normative summary it includes is: "The intent is that the registrar make every attempt to retain validity of the GRUU for as long as the AOR itself is known within the domain." So, after the PBX makes first contact with the SSP, it can cache the resulting GRUU, and use it to mint public GRUUs for its own endpoints (even if, due to some set of circumstances, it doesn't happen to be registered at the moment). Of course, those GRUUs won't actually work until it registers with the SSP, but that's the nature of being a MARTINI-attached PBX anyway. Finally, since we're assuming some out-of-band provisioning mechanism: if implementations absolutely need the ability to create public GRUUs when a PBX is first switched on for the very first time, it would be perfectly fine to provision this public GRUU -- the one the PBX would be caching above -- into the PBX before it is put into service. > - I don't understand the restriction for temp-GRUUs, where the PBX > must be able to accept requests destined for its own self-made GRUUs > from sources other than the SSP. Wouldn't these GRUUs have the domain > of the PBX, and therefore route via the SSP? > No. They'll need to have something in the machineport portion of the URI that resolves to the PBX via RFC 3263 mechanisms. /a --------------080608090405020808010704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/2/10 10:39 PM, David Hancock wrote:
 A couple of comments on GRUU…

 - The PBX doesn’t have sufficient info to coin public GRUUs for its endpoints until it registers with the SSP. So how to handle the case where the PBX endpoints register with the PBX before the PBX registers with the SSP?


To be clear: the PBX doesn't have sufficient information to coin public GRUUs for its endpoints until it registers with the SSP for the first time. There's actually normative language around this in GRUU, but the non-normative summary it includes is: "The intent is that the registrar make every attempt to retain validity of the GRUU for as long as the AOR itself is known within the domain."

So, after the PBX makes first contact with the SSP, it can cache the resulting GRUU, and use it to mint public GRUUs for its own endpoints (even if, due to some set of circumstances, it doesn't happen to be registered at the moment).

Of course, those GRUUs won't actually work until it registers with the SSP, but that's the nature of being a MARTINI-attached PBX anyway.

Finally, since we're assuming some out-of-band provisioning mechanism: if implementations absolutely need the ability to create public GRUUs when a PBX is first switched on for the very first time, it would be perfectly fine to provision this public GRUU -- the one the PBX would be caching above -- into the PBX before it is put into service.

 - I don’t understand the restriction for temp-GRUUs, where the PBX must be able to accept requests destined for its own self-made GRUUs from sources other than the SSP. Wouldn’t these GRUUs have the domain of the PBX, and therefore route via the SSP?


No. They'll need to have something in the machineport portion of the URI that resolves to the PBX via RFC 3263 mechanisms.

/a
--------------080608090405020808010704-- From adam@nostrum.com Wed Feb 3 07:08: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 4AB793A6A32 for ; Wed, 3 Feb 2010 07:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.077, 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 a2Lx4zcv26bw for ; Wed, 3 Feb 2010 07:08:58 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id CAC623A6867 for ; Wed, 3 Feb 2010 07:08:57 -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 o13F9b1E037505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 09:09:37 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6991B1.1040806@nostrum.com> Date: Wed, 03 Feb 2010 09:09:37 -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: <4B68BEB4.2020207@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 15:08:59 -0000 On 2/3/10 4:12 AM, Elwell, John wrote: > 1. I think more work is needed on how to populate other fields in non-REGISTER inbound and outbound requests, as discussed in the thread I started "Further details around use case 3". > Thanks. I'll comment in that thread. > 2. I am pleased to see the proposals for GRUU in there. I think we also need to discuss the use of non-GRUU contact URIs (see also that other thread). > Ditto. > 3. I have a concern about the public GRUU solution. Suppose a UA registered with the PBX uses one of these permanent GRUUs, and some other on-PBX UA ends up making an out-of-dialog request back to that GRUU. It seems the PBX would be required to route via the SSP, resulting in a hairpin. > Yes, a naïve implementation would do that, and the signaling (but not the media) would end up going through the SSP. Everything would work okay, although the SSP would have to suffer through one (!) additional SIP message and its responses. But this hairpinning isn't necessary. I'm assuming that all of those terminals will send outgoing requests through the PBX. This would give the PBX the opportunity, if it wanted, to optimize this hairpin: it would trivially be able to recognize the R-URI as matching the public GRUU it received from the SSP (there will be only one, so it's not an expensive comparison), and process it locally without sending it to the SSP. It's pretty much the same behavior as recognizing a normal, non-GRUU URI as one of its own extensions and handling it locally instead of routing to the SSP. > 4. Concerning the registration event package for individual extension registration state: > "If the SSP receives a SUBSCRIBE request for the registration event > package with a Request-URI that indicates a contact registered via > the "Bulk Number Contact" mechanism defined in this document, " > This assumes subscription would use the contact URI, rather than the AOR for subscription. Sorry -- that was sloppy writing on my part. The intention is that they're subscribing to the AOR. It makes no sense to subscribe to the contact value. /a From bernard_aboba@hotmail.com Wed Feb 3 08:21: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 3916E28C16D for ; Wed, 3 Feb 2010 08:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118, 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 5a4EeAA+kOf8 for ; Wed, 3 Feb 2010 08:21:03 -0800 (PST) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by core3.amsl.com (Postfix) with ESMTP id 4BF8B3A6946 for ; Wed, 3 Feb 2010 08:21:03 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.71]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 08:21:45 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'DRAGE, Keith \(Keith\)'" , "'DOLLY, MARTIN C \(ATTLABS\)'" , References: <14C85D6CCBE92743AF33663BF5D24EBA058BC87C@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: Date: Wed, 3 Feb 2010 08:22:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_049A_01CAA4AA.035777E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqkl3928zt6Ms83SGyXln5xIe+/zgAEEX2AAALCUaAADoLfcA== Content-Language: en-us X-OriginalArrivalTime: 03 Feb 2010 16:21:45.0894 (UTC) FILETIME=[FAB5DC60:01CAA4EC] Subject: [martini] Doodle Poll Revision X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 16:21:08 -0000 ------=_NextPart_000_049A_01CAA4AA.035777E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Due to conflicts with 3GPP, I've added some additional dates before and after the week of February 22. Let's see if those work better. And also, the times are in PT (GMT -8). Sorry for the conflict and confusion. Doodle poll: http://www.doodle.com/gfd9ramt42v5cxbd From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Wednesday, February 03, 2010 1:58 AM To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org Subject: RE: [martini] Yet another Doodle Poll: Virtual Interim IV As Martin indicates, this is a week when virtually every 3GPP working group is meeting. Spare hours do not exist in that week. Please find another week. Keith _____ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C (ATTLABS) Sent: Wednesday, February 03, 2010 8:07 AM To: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV The week of the 22nd is 3GPP, so it would be hit or miss for me From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, February 03, 2010 1:10 AM To: martini@ietf.org Subject: [martini] Yet another Doodle Poll: Virtual Interim IV The schedule of virtual interims has been somewhat grueling, but it has been brought to our attention that just one more Virtual Interim might help. So in that spirit, we're taking a Doodle poll to find an appropriate meeting time during the week of February 22-26, 2010: http://www.doodle.com/gfd9ramt42v5cxbd ------=_NextPart_000_049A_01CAA4AA.035777E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Due to conflicts with = 3GPP, I’ve added some additional dates before and after the week of February = 22.  Let’s see if those work better.

 

And also, the times = are in PT (GMT -8). 

 

Sorry for the = conflict and confusion.

 

Doodle poll:  = http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

 

From:= DRAGE, = Keith (Keith) [mailto:drage@alcatel-lucent.com]
Sent: Wednesday, February 03, 2010 1:58 AM
To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; = martini@ietf.org
Subject: RE: [martini] Yet another Doodle Poll: Virtual Interim = IV

 

As Martin indicates, this is a week when virtually every = 3GPP working group is meeting. Spare hours do not exist in that = week.

 

Please find another week.

 

Keith

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C = (ATTLABS)
Sent: Wednesday, February 03, 2010 8:07 AM
To: Bernard Aboba; martini@ietf.org
Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim = IV

The week of the = 22nd is 3GPP, so it would be hit or miss for me

 

From:= martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba
Sent: Wednesday, February 03, 2010 1:10 AM
To: martini@ietf.org
Subject: [martini] Yet another Doodle Poll: Virtual Interim = IV

 

The schedule of virtual interims has been somewhat = grueling, but it has been brought to our attention that just one more Virtual = Interim might help.

 

So in that spirit, we’re taking a Doodle poll = to find an appropriate meeting time during the week of February 22-26, = 2010:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

 

------=_NextPart_000_049A_01CAA4AA.035777E0-- From adam@nostrum.com Wed Feb 3 08:26: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 C4A6128C15A for ; Wed, 3 Feb 2010 08:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 F2M9ml0SJxYL for ; Wed, 3 Feb 2010 08:26: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 0D00928C119 for ; Wed, 3 Feb 2010 08:26:22 -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 o13GQwf5043478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 10:26:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B69A3D2.6060309@nostrum.com> Date: Wed, 03 Feb 2010 10:26:58 -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: <4B6767A4.8000008@nostrum.com> <4B68A66C.50108@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010205020301030302040003" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Further details around use case 3 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 16:26:27 -0000 This is a multi-part message in MIME format. --------------010205020301030302040003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John: Thanks for taking a deeper dive into these issues. Some comments inline. On 2/3/10 3:04 AM, Elwell, John wrote: > To Paul's questions about From, To and PAI, I think we should also add Contact. > In the following examples I will show only the flows between the SSP and the PBX > > 1. Inbound call to PBX. > > PBX SSP > INVITE sip:123456789@10.1.2.3 > To: Q1 (see below) > From: Not relevant > PAI: Not relevant > Contact: Not relevant > <------------------------- > > 180 > Contact: Q2 (see below) > --------------------------> > > 2. Outbound call from PBX. > PBX SSP > INVITE Any off-PBX value > To: Q3 (see below) > From: Q4 (see below) > PAI: Q5 (see below) > Contact: Q6 (see below) > -------------------------> > > 180 > Contact: Not relevant > <-------------------------- > > Questions raised: > Q1: Value of To URI in inbound INVITE request: > In principle, it could be any value, since the request may have been retargeted to the PBX. However, in the most common case I would expect it to have a URI of the form sip:+123456789@ssp.net;useer=phone. > I would agree that it can have pretty much any value. I'm not sure we need to make any assumptions about the form it actually takes in practice, since the value of the "To" header field is generally useless for processing purposes. > Q2: Value of Contact URI sent by PBX in response to inbound INVITE request: > > Option 1: It must be one of the registered contact URIs (i.e., corresponding to one of the registered E.164 numbers). This is not viable for two reasons: > a) because this would fail to identify the particular UA on the PBX that has accepted the call; > b) because the call might have been retargeted by the PBX to a destination that is not one of the registered E.164 numbers. > I agree that this approach has shortcomings. We might not see eye-to-eye on what those shortcomings are, but as long as we all agree that this approach is sub-optimal, we can discard it and move on. > Option 2: Any value ending in @10.1.2.3. The PBX could then choose a value that identifies the specific UA that accepted the call. > I think you're making some (not universally true) assumptions here about the way the PBX behaves. In particular, you're assuming it will act as a B2BUA for all calls. And I acknowledge that the vast majority of PBXes do exactly this. For these PBXes, the approach you're describing would work fine. Now, if someone wanted to deploy a PBX that acted as a proxy for some of its calls (which is exactly how the PBX we're using for our office works), then the contact URI would be whatever the terminal itself generated. Based on the relatively broad range of terminals I've played with, this contact URI will end up being some kind of cookie (like a line identifier) in the user part, and the phone's own IP address in the hostport part. Since the PBX, in these kinds of environments, is often straddling a NAT boundary, it will usually need to Record-Route so that it stays in the call. How all this works becomes much clearer if you look at the whole interaction instead of just the interaction between the PBX and the SSP: PBX Terminal Internet SSP 192.0.2.3 10.20.30.127 | | | | | | | | | | | | |INVITE sip:+9919990@ssp.example.com | | |------------------>| | | | | | | | | | | | |INVITE sip:+9919990@192.0.2.3 | | |Record-Route: | |------------------>| | | | | | | | |INVITE sip:+9919990@10.20.30.127 | | |Record-Route: | | |Record-Route: | | |------------------>| | | |200 OK | | | |Record-Route: | | |Record-Route: | | |Contact: | | |<------------------| | |200 OK | | | |Record-Route: | | |Record-Route: | |Contact: | | |<------------------| | |200 OK | | | |Record-Route: | | |Record-Route: | |Contact: | | |<------------------| | | | | | | |ACK sip:line-1@10.20.30.127 | | |Route: | | |Route: | | |------------------>| | | | | | | | | | | | |ACK sip:line-1@10.20.30.127 | | |Route: | | |------------------>| | | | | | | | | | | | | | | | |ACK sip:line-1@10.20.30.127 | | |------------------>| I'll admit that's a bit hard to look at; here it is in a somewhat less cluttered form: The thing that's kind of nice here is that this works for both the B2BUA case and for the proxy case. In any case, I don't think we need to be proscriptive about this -- in general, having the PBX Record-Route will work; and, if B2BUA PBXes want to use a Contact that indicates their own IP address, they can do that. > Option 3: I don't think the PBX would necessarily be able claim gruu properties for a contact URI in accordance with option 2, in which case if it needed a gruu, it would need to obtain one from the SSP using the REGISTER transaction. I really don't know if and how this would work. > I go over GRUUs in the GIN draft. These GRUUs do actually have GRUU properties (which is the point) and can be used accordingly (including use in Contact header fields). > Q3: Value of To URI in outbound INVITE request: > In most cases it would reflect the value of the Request-URI. In some cases it could differ, if the request has already been retargeted. Yes. > Q4: Value of From URI in outbound INVITE request: > Option 1: Of the form sip:123456789@10.1.2.3. But this is a contact URI. > Option 2: Of the form sip:+123456789@ssp.net;user=phone. > Option 3: Of the form sip:+123456789@pbx.com;user=phone. But this brings back the whole argument about domain names. > Option 4: Of the form tel:+123456789 > Keep in mind that an unauthenticated "From" URI cannot generally be used for anything. Really. It can't. So, it only makes sense to evaluate this question in the context of RFC 4474, which actually gives some meaning to this value. In other words, the question about what we want to put in "From" comes down to how we want to treat identity. I'm not sure MARTINI has to open that particular can of worms. However, I will make the following observations: 1. Option 1 would be effectively impossible to apply RFC 4474 to, as I seriously doubt any legitimate CA will issue a cert asserting ownership of an IP address. 2. Given the types of business relationships we're talking about, the entity that seems in the best position to make an assertion about the value in the "From" header field, which would mean that Option 2 makes the most sense. 3. Option 3 gets us mired back down into the domain conversation. Also, it would require the PBX operator to operate as a 4474 authentication service, which seems extremely unlikely for these kinds of deployments. 4. For option 4: we haven't even begun to get any kind of a grip on how to apply identity to naked phone numbers. > Also, what if the request comes from a source that is not reachable by inbound requests, i.e., it is not from a registered E.164 number? > Using an analog to deployed ISDN-connected PBXes: if I call out from an internal extension that cannot be direct-dialed, the calling party ID presented to the called party will generally be the PBX's lead number. I would assume this is treated in the same way: if the request comes from a source that is not directly reachable by inbound requests, then the "From" header field will generally be the PBX's lead number. Subject to policy, configuration, etc. > Q5: Value of PAI in outbound INVITE request: > Similar considerations to Q4: In addition, option 2 looks suspect, because it would require the PBX to make an assertion on behalf of the SSP. > I would really rather leave this out of scope for MARTINI. If some external body -- like SIPForum -- wants to define how this is done to be "SIP Connect 1.2 Compliant," then that's great. But I don't think the answer has an impact on the solution we choose, and I don't think we want to tackle those issues in MARTINI. > Q6: Value of Contact URI in outbound INVITE request: > Similar considerations to Q2, bearing in mind the source of the request might not be a UA bound to one of the registered E.164 numbers. > The answer here is pretty much identical to the answer I gave for Q2: the contact will come from the phone itself. The PBX can either Record-Route, or it can act as a B2BUA and mint a new contact with a state cookie that gives it a handle back to the correct device. I prefer the latter, but acknowledge that both can work -- and, as before, I see no reason to be proscriptive about how this works. Really, once we've figured out how to route the first dialog-establishing request, all the Contact/Route/Record-Route shenanigans will Just Work. Making sure this particular thing works is one of the things we did pretty well in SIP. /a --------------010205020301030302040003 Content-Type: multipart/related; boundary="------------040308090004080203020701" --------------040308090004080203020701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit John:

Thanks for taking a deeper dive into these issues. Some comments inline.

On 2/3/10 3:04 AM, Elwell, John wrote: 
To Paul's questions about From, To and PAI, I think we should also add Contact.
In the following examples I will show only the flows between the SSP and the PBX

1. Inbound call to PBX.

PBX                     SSP
      INVITE sip:123456789@10.1.2.3
      To: Q1 (see below)
      From: Not relevant
      PAI: Not relevant
      Contact: Not relevant
<-------------------------

      180
      Contact: Q2 (see below)
-------------------------->

2. Outbound call from PBX.       
PBX                     SSP
      INVITE Any off-PBX value
      To: Q3 (see below)
      From: Q4 (see below)
      PAI: Q5 (see below)
      Contact: Q6 (see below)
------------------------->

      180
      Contact: Not relevant
<--------------------------

Questions raised:
Q1: Value of To URI in inbound INVITE request:
In principle, it could be any value, since the request may have been retargeted to the PBX. However, in the most common case I would expect it to have a URI of the form sip:+123456789@ssp.net;useer=phone.

I would agree that it can have pretty much any value. I'm not sure we need to make any assumptions about the form it actually takes in practice, since the value of the "To" header field is generally useless for processing purposes.

Q2: Value of Contact URI sent by PBX in response to inbound INVITE request:

Option 1: It must be one of the registered contact URIs (i.e., corresponding to one of the registered E.164 numbers). This is not viable for two reasons:
a) because this would fail to identify the particular UA on the PBX that has accepted the call;
b) because the call might have been retargeted by the PBX to a destination that is not one of the registered E.164 numbers.

I agree that this approach has shortcomings. We might not see eye-to-eye on what those shortcomings are, but as long as we all agree that this approach is sub-optimal, we can discard it and move on.

Option 2: Any value ending in @10.1.2.3. The PBX could then choose a value that identifies the specific UA that accepted the call.

I think you're making some (not universally true) assumptions here about the way the PBX behaves. In particular, you're assuming it will act as a B2BUA for all calls. And I acknowledge that the vast majority of PBXes do exactly this. For these PBXes, the approach you're describing would work fine.

Now, if someone wanted to deploy a PBX that acted as a proxy for some of its calls (which is exactly how the PBX we're using for our office works), then the contact URI would be whatever the terminal itself generated. Based on the relatively broad range of terminals I've played with, this contact URI will end up being some kind of cookie (like a line identifier) in the user part, and the phone's own IP address in the hostport part.

Since the PBX, in these kinds of environments, is often straddling a NAT boundary, it will usually need to Record-Route so that it stays in the call.

How all this works becomes much clearer if you look at the whole interaction instead of just the interaction between the PBX and the SSP:

                                           PBX              Terminal
Internet               SSP              192.0.2.3         10.20.30.127
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |INVITE sip:+9919990@ssp.example.com    |                   |
    |------------------>|                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |INVITE sip:+9919990@192.0.2.3          |
    |                   |Record-Route:<sip:+9919990@ssp.example.com>
    |                   |------------------>|                   |
    |                   |                   |                   |
    |                   |                   |INVITE sip:+9919990@10.20.30.127
    |                   |                   |Record-Route: <sip:+9919990@192.0.2.3>
    |                   |                   |Record-Route:<sip:+9919990@ssp.example.com>
    |                   |                   |------------------>|
    |                   |                   |200 OK             |
    |                   |                   |Record-Route: <sip:+9919990@192.0.2.3>
    |                   |                   |Record-Route:<sip:+9919990@ssp.example.com>
    |                   |                   |Contact: <sip:line-1@10.20.30.127>
    |                   |                   |<------------------|
    |                   |200 OK             |                   |
    |                   |Record-Route: <sip:+9919990@192.0.2.3> |
    |                   |Record-Route:<sip:+9919990@ssp.example.com>
    |                   |Contact: <sip:line-1@10.20.30.127>     |
    |                   |<------------------|                   |
    |200 OK             |                   |                   |
    |Record-Route: <sip:+9919990@192.0.2.3> |                   |
    |Record-Route:<sip:+9919990@ssp.example.com>                |
    |Contact: <sip:line-1@10.20.30.127>     |                   |
    |<------------------|                   |                   |
    |                   |                   |                   |
    |ACK sip:line-1@10.20.30.127            |                   |
    |Route:<sip:+9919990@ssp.example.com>   |                   |
    |Route: <sip:+9919990@192.0.2.3>        |                   |
    |------------------>|                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |ACK sip:line-1@10.20.30.127            |
    |                   |Route: <sip:+9919990@192.0.2.3>        |
    |                   |------------------>|                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |ACK sip:line-1@10.20.30.127
    |                   |                   |------------------>|



I'll admit that's a bit hard to look at; here it is in a somewhat less cluttered form:




The thing that's kind of nice here is that this works for both the B2BUA case and for the proxy case.

In any case, I don't think we need to be proscriptive about this -- in general, having the PBX Record-Route will work; and, if B2BUA PBXes want to use a Contact that indicates their own IP address, they can do that.


Option 3: I don't think the PBX would necessarily be able claim gruu properties for a contact URI in accordance with option 2, in which case if it needed a gruu, it would need to obtain one from the SSP using the REGISTER transaction. I really don't know if and how this would work.

I go over GRUUs in the GIN draft. These GRUUs do actually have GRUU properties (which is the point) and can be used accordingly (including use in Contact header fields).

Q3: Value of To URI in outbound INVITE request:
In most cases it would reflect the value of the Request-URI. In some cases it could differ, if the request has already been retargeted.

Yes.

Q4: Value of From URI in outbound INVITE request:
Option 1: Of the form sip:123456789@10.1.2.3. But this is a contact URI.
Option 2: Of the form sip:+123456789@ssp.net;user=phone.
Option 3: Of the form sip:+123456789@pbx.com;user=phone. But this brings back the whole argument about domain names.
Option 4: Of the form tel:+123456789

Keep in mind that an unauthenticated "From" URI  cannot generally be used for anything. Really. It can't.

So, it only makes sense to evaluate this question in the context of RFC 4474, which actually gives some meaning to this value. In other words, the question about what we want to put in "From" comes down to how we want to treat identity.

I'm not sure MARTINI has to open that particular can of worms. However, I will make the following observations:
  1. Option 1 would be effectively impossible to apply RFC 4474 to, as I seriously doubt any legitimate CA will issue a cert asserting ownership of an IP address.

  2. Given the types of business relationships we're talking about, the entity that seems in the best position to make an assertion about the value in the "From" header field, which would mean that Option 2 makes the most sense.

  3. Option 3 gets us mired back down into the domain conversation. Also, it would require the PBX operator to operate as a 4474 authentication service, which seems extremely unlikely for these kinds of deployments.

  4. For option 4: we haven't even begun to get any kind of a grip on how to apply identity to naked phone numbers.


Also, what if the request comes from a source that is not reachable by inbound requests, i.e., it is not from a registered E.164 number?

Using an analog to deployed ISDN-connected PBXes: if I call out from an internal extension that cannot be direct-dialed, the calling party ID presented to the called party will generally be the PBX's lead number. I would assume this is treated in the same way: if the request comes from a source that is not directly reachable by inbound requests, then the "From" header field will generally be the PBX's lead number. Subject to policy, configuration, etc.

Q5: Value of PAI in outbound INVITE request:
Similar considerations to Q4: In addition, option 2 looks suspect, because it would require the PBX to make an assertion on behalf of the SSP.

I would really rather leave this out of scope for MARTINI. If some external body -- like SIPForum -- wants to define how this is done to be "SIP Connect 1.2 Compliant," then that's great. But I don't think the answer has an impact on the solution we choose, and I don't think we want to tackle those issues in MARTINI.

Q6: Value of Contact URI in outbound INVITE request:
Similar considerations to Q2, bearing in mind the source of the request might not be a UA bound to one of the registered E.164 numbers.

The answer here is pretty much identical to the answer I gave for Q2: the contact will come from the phone itself. The PBX can either Record-Route, or it can act as a B2BUA and mint a new contact with a state cookie that gives it a handle back to the correct device. I prefer the latter, but acknowledge that both can work -- and, as before, I see no reason to be proscriptive about how this works.

Really, once we've figured out how to route the first dialog-establishing request, all the Contact/Route/Record-Route shenanigans will Just Work. Making sure this particular thing works is one of the things we did pretty well in SIP.

/a
--------------040308090004080203020701 Content-Type: image/png; x-mac-type="504E4766"; x-mac-creator="0"; name="contact-2.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename="contact-2.png" iVBORw0KGgoAAAANSUhEUgAAAxEAAAM+CAYAAABlnYyFAAACLmlDQ1BJQ0MgUHJvZmlsZQAA 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+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AeydB7glRbW2T5ocGIKA mAYBEyoqiGBAxCzqNYuRoF5zzjnniDnrVVF/r4o5omLWq6goohJERJEcJocT/u9dXV+f2j17 77NPGmbOqXqe3mvVSlW9anV3VVd17b6+kooHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oH2nugvz25UIsH igeKB4oHigcm5YHyPGnvruKX9n6ZDepYG6PtaG3Epkwq7dvedcUv7f0yG9R2Md6ONuNll0ae cZcWg8UDxQPFA/PCA+2eH6YBje+IztiR67a9/DVZH0xWvt15TKVjM1mdXH40VcI0w3Z165XW zg+mAY33am97yu3IddtefpisDyYr3+48phJ3k9XJ5Wcj7tud1w4d7G0rXIjFA8UDxQPFA9eo B/KHKrgPKtXEe6lobq+TfC8ynXR7pU+3jOnq5/WcSVu5XfDZtN0saybyeeeomz3kLOtOFNC4 +YbdbLXj5X4D94FsE2+n36Tl9po853uRsexU4XTLmK5+Xu+ZtJXbBZ9N282yZiLvWJ7IVh7P jvWZjPuu5Q915RZm8UDxQPFA8UDxwLgH/CAG5sdAyg+OiwZmmQa55rWjT4fm+tlGM2/6ZGE7 O+1oTbu9yDR1es3btmGver3KzZbdZvm9dpaaes7nnShwd6RGhDsPDt15ofWAA3yiZF8A82Mu x73PuembTvRcrheZXH4yuG0bTka3F9nZstssm1icTkLfNvK4nsm4n7B+ZRAxoYuKQPFA8UDx QPGAPOCHK5CDDhTHgqc97WkH3exmNzti2bJl116wYMHy0dHRgX4l8foEkOkbGxvrHxwc7Eu8 yCeZAegphd2kCgmR/oGBgbBFPsmFgui1DDzKUKrLND/To1592HM9UFCK+qRyKIMyw3b8VDax H3WlHGSy8iKPHaUoAz5HZifyCESBNajOMemGTdcjp6GjVKvnmVQPk6h4CLoo9JCRn8O++dQN P7iOyX5UCHnoPkcKVvK5RSbTjbx/RMfH7sxjI1iyP5rwMWRSqjtD4oVggnUWOWWsEHT0Zc+6 0Gj8gMPDw1euWbPmrNNPP/1zz3ve834g9S060KeDRaptVdmuv7UvJQWOfznmRdync41rFxcr X+J+/JqRO8bTHIv78RPrgvni6CJSWMUDxQPFA8UD89wDfla4EwWkI7/wZS972UMPO+ywg69z netsVieODmn/1q1bB4eGhvrUmVO/dXyAkDqlyPSNjIxEZ1cdk7pjbj465kPDLv4XTKDKQ/Ih Xo1Lp+7omI8dcHhA7Ke6RT7Xh4856oZeZboeFNQdcfgNXihaF6ijrhd288N8ZOigpSSRSo18 Lp/oIet6uY7WyeuEPnbhIW9eZXa8LjkPPCV04/xyG/DIZ3KWbwslGwMDd/qrKtVjhUAqk2PY jYFAGmDQ0a91MSPd0aQfgxDVoR6UZLo2PnrJJZf0/+IXv/j8cccdd6JsrdUxrAO7HlB4MCFS 24TvSMCIV8ES91OI+2bMKR+pavJAw8/C2l4zSCBL3CEjXKhvC1UeuhKiJe6nF/f4sadU3917 ki5CxQPFA8UDxQPz0QPREdWJ89Tm4Nmx6GEPe9jhxxxzzB1333133vAOavAwpA7goDrog4Z6 2IMPOC84lPPh6Zk/wIDDdDoI5ClLNGbM0Q8b2ElHnacMdKwvPvUIHXSTndATHuUgn+yGruWh c1CGccuZlsnWMkk26mw5aNTJdgxlLzro2IVG3rhlgC4n5yOXOkmhazlBt1HYsj2g9RN02SGv jljMypiHbXSwaxqwIo8PwsyD0ZRNPIFKj7qhD8xw+EFDTvTI84Owzj1kkYeWQ3DnEQdHHn8h 67R8+fKx613vejfTgPaCn//85+eL3m7QMF6wFcdh+EhZ7HLMq7iXX32t1ddIu3hGDv/I/3Ws 53Li0UZ1vCJLHrrxnE87pras+cgRF0055d1GIWt7QB2mhUxWZrxMyMrAdMjmMuhX5HkX9zr1 3hJOK6l4oHigeKB4oHigkwf8nMg7UnTs9/jEJz7x0Fvd6lb7bNmyZUgP2wEGEXRKPQMBZEZC D2sexvEgh09BPKyVQOOHzgAJOjME1nEeQaUWG+RJpgOT/SgDnssBV4qlTJQFnXyy4d5C01bw cxmMoI8uNvLZDOSSbPCzvNBWXhKoy0u+sH4uH3VGnzJtJ8+bwbnnMsZTfYOXBOpykDEt4XFe 4C7L9CQHnRQ2KjQqh56zgZNXnaLjDq6DRHkB4yfNNkiRbCSMqP0BGIzZCXVKI29d88mDUw4y yqOIXsxaKD/yl7/85XeHH374y0W7WMfWdHhWwkucRG5J4QBR5mXcqyHi+pD/Ij4EI+7lj7h2 HPfwoXGklOcDb8S2ZUPBukk/5G2TeM7pljWf8lBAzrS83sKhk1rKSvma5rx183IyXYoiRZ0q NE56rsW9T60nONvfREQD91ST+SVU/LL92nv8qTZeZjvaOHf6WGnf9j4sfmnvl9mgtovxdrRe y6btOPIO1SotYdqdgQKDBz1sWwYRovtNegwI3JFAjod7nk+ViDLg0xlMHQAe9NiJfCcdOhG2 gTx1Vao7CbIXttHnwDYdBnBkm/Km5XzT6Dy5bqJxLgLjNjI87H7zm99c9sxnPnOfxYsX1/7X 8q8N+o7k6tve9rZb3vOe9+zyzne+c1d9T8LSHJZZ9d3ylrfc8q53vevK6173uqO//vWvF2rG Z4/Pfe5zlx9xxBF0gPsvuOCCwSOPPHJ36a15wAMesIWTVQo/Z+Vz/sqO1w37Wd1rvHGe1vF5 hhGIuT62M/uwnQdKdCwGAoI4OQYCiCQ67R/nix40eGpnoVUmgZCxPUQ9eAhBnQ+8RIvyOBd4 ogfEsPx4Q4FddVypg8I80ACnfjFiEWymaEMRkeHgjfu8jfv/+q//OuCcc85ZLB/EckP52u3a 98UvfvEfN7/5zSMWxaZdEAvI9ZeloMPjyGMPHeRovpe85CW76JoYe+UrX8kytJCFn+PIKm0T 9widdtppQyeccMKyP/7xj2uxV4VEpW88LxsdpRBI/MAh5vqUx2HZQKo8dInOibjntHpKMz2I qJ2elW4a0HjG3qHQHb1+s+msXs69F5np1LF+yPZopFf5XA7cB8XkvB6L3UasnV9MAxrfRnEH Iezo9ZtNN/Vy7r3ITKeOk43BXuVzOXAf1DXn9VJ3fJB3pHh2LNFykWWahRhkIKF8PZggrwd0 LC+hA8FDWPzoMOhBix2SaeFf0ZGT2viAABnLY0Mp3jpCJ++3oepEhi3o0JTPZxlqnvXz+rge 8MBJOa2ZRyjVJeTowDZlxOc8EKWegxpsDf/oRz/6F+cmfw289rWvXfXqV796969+9auXIHuH O9xh06c+9anLkd+0aVP/gx70oD3e8pa37KKBxJpDDz105Pjjj1//7Gc/e5VsXCGf92lQsstd 73rXLfe73/2G0dcRVXA9BKOO2AOnLmqH+s1yLp/LUuGUwhnC3XaQ7aAaB0nJ8pRrGoV7IEE9 osMJn4M2kiADAHTHlaoyJRJyISOcWAo92aHDT71I0FoGERQOTXEAIDugzuhugst0LNDBzANH 2BHslqgbdeAgxudl3Ou88XcMFGhI8ne84x33VxxfpDjcQB6yrntmIpWtru1KdHx2kLxp1pHd sGe6IKlPH8SvB1HcDpJv2oSnFPYCaZQpu1ER6yNLWUknyuSckl0gKQoCpnrVNPQyPjjJ8hGb FUlEyaZ4pbydMe59KhPCmRpE1I5MTiVvWhOfsFJJwPrd5HuR6abfC286ZUxHt1m3mbSV254t u3kZs4HnD51O9pGxnN80AY2bb9jJTid67jtwH8g38U42mvTcZpPnfC8ylp0qnE4Z09F1fWfC hm11gtujjE5lT5XueO6mn8ezY32qcW8fATnyDhXfFsQ6aGYixKsHETy46TDTUQSmBzIP1EhU HgQAn7xkYk1Cotd85aMzkFSiM4M96dFpCRvoKIUN8bYZRMBDn8MzCeDImg5MqYVGOZZBlzJz eznfcvCpI3l8gAF8Ak02+vUdyYYHPvCBK9auXYvfQg4++MKFC/v0RlfFDIcutl7wghdsOvXU Uxe/4hWvWHHggQeO6G3w4Ec/+tF1shezNOhRD+znZUNT+XHyqRyBSFEmGHx0lOInt4F+zrNM g1brBqJOE3KyQ5YBTN3JT7aD4XKQsSzQR6Jjp6UTpixx4sEHYsxWRJsjq4TffM6cnGc8Fkp2 kQ6WMXkgQdv4GhFaJ+sDOZDjiMHyfIh7+Y2kU66u0Wbcw5Cv45sfZM4888yFr3/963e/8MIL FxxyyCGbXvWqV125yy67jJ599tkL3vve9+6iZY9bvv/97y+5y13usok20gzBQi0zW6BZtg0a ZI+8+93vXsFsnQbPa25961uP/L//9/+WKPU99rGP3fzIRz5y5aMf/ehNmrVbcuWVVw488YlP 3PTf//3fm7Hzn//8Z0CzFUs0Yzd0oxvdaOTpT3/6Fg1sRuClOtbQ5wNdKeiGyMMHzuO4D8dM 5mcmBhF5Q4D74IID56KLm4qgE7xOyfY68adCb9ps5mfCJjZ6sduLzFTq4/Jnw/5s2OzlHKun UC+SrTLWA3L4IcGDw3m/iXIeC+C9JvsEmB8l7rf1oH21LWfqlKbNZn7qlsc1Z8PmuPXO2GTi MLdiPSDHTMW9/QAkvnluxEEHmSN1kOODZT2II28eHW9w6fjhHPbiiS1a4oldd+LpOIZsovl5 gUp0TuFLL5mo9JJsdGzcIchsCq3k4JFRarFBPqXgkaczoXND3kfwJFfLyF5NE+63/ZanvlF/ QfzTrx2DBj7+8Y+vVEdpy6JFi2IW4aKLLhr87Gc/uwxb//rXvwbV2Vr8sY997Gp8Q50YWGjp 0noNPFZ+5Stf6fvgBz+4buXKlXX9qQ+6lAWejuBTOXhKUWnhcV5AiErVyWQdKNPaycDDHr6B 7/IwRLKO6EJby63YrQMFaDrCpmDUNdmwvgdCdR6+M4JeUiZ3VR9jywx4DDaoIPKiMYggbpmN YCARMSlIgh+VjVz1k/sH2XkV98ln+MD+Czy1d/gG33PtazA88IQnPOHaxx577Jp73vOeV374 wx9eqZmE3RWnV6xfv37opz/96ZLLLrts6PGPf/y6n/3sZ4u//vWvL9GAeM3973//TZpVW3XQ QQdtffvb377mS1/60hLB5ZqVW/vPf/5ziOVM1OOss84aet/73rf0bW972wYGCxqgLH3Uox61 denSpf0f+chHFu25555jp5xyynrN1A29+MUvXvzLX/5yo+sP5Ej1ruOT86KZocMnnk1LunUe GXiiz4e451x7TlwU00nhWRkActAKHAue8Yxn3FKjwjtrJLqX8iv9IImWFEEwWgw03Ywinxo7 bKGTUuTd2JV6v6eyEXGQhA30UlDUwe/ys0DBZjw1AKJHXnpCx2+OSQReHNRfqb5JI+/ykEn1 d6DFDd024IGn86ptilbXA9tkqY/lE61+OMCHh4zlx03UbRE8/eCTMGoZdNBXPZplRJ1QVJK4 q1Wfe4tfLYS/krA7C/YP8nEkfv1GSTf40NEPN26JVdv3JfnIJ4F4y2QZwcirbMvUfGyir/rU NIQkO6olBFfpRve32d43vMR9XDsl7ude3Me9QdefIRd9zETQidBBR65lEMH9CR6XoGRJdGpF ru8XYQu5JBPPAl2vISDdtnxkOZIdy4R9ymjas214JPSgpRR6woOZ6KZRf8Qij751wa2T7mVR D8vmZYL/+9//XqD/0bgOhkjq9IzwxlU8zrX/iiuuGFBHayH6vGkVvU9vdheocxUdW2zc+MY3 Hr32ta89evXVV/frWwoVWy/ZwiS+DciPUlVp2UNXvKgveDqHkEn1DRkIPj/oyBpCB+dwMt90 8vCUFxr3fZDIWyfxK4FERC/JB1t4PBOUCTrEijQO29HwRyUaLnNFHXM4h8EDB/2emPURDP8L dkrYyQ/k50Xcc96pvYG0Rfgh0cJv+JzjG9/4xnLF5vDjHve49ehp6d3au93tbntrABG7Nen5 26+Zhqt22223MQYRminYpAEE30/0iTaqmbnNGlTL1OhmDT5WZD6v+xSib9Is3KiOrRpQLNZs 3NAtbnGLUZUzAmSZ301vetOxv//974Pr1q1zmzm2OQXHUeAqw7wS9zhjimk6gwgaiQT0hciF uVAjwYdqvdxtdKPkTcuYpsHW6SbEDVmg6qyrFdEhxU3NeWSgKWDrzjk3MOdzPrt+hAEFB3aR SXmCxEEUMPGbtBDXD3Vw/XyjDNmmHWQ58oFAbps6VEWHHE/MsGc69ki2A6yy1TmDQyA1ZHgK WLht3SqVqn7UibzKjfJtyzIJihwV4K6LzbiYgEro8xSpLzTj6ZziTp3kQl5loRPlcb4QSaLF 0w0+WR0xvQ1dR+DU07yEByHDPSUOPXi64UTdMjsSrwYR8FRPbkoBFTcrxTv4Bje4wSF77LFH vm+4y6VenqmA1imFn8QERqwKlrjvEPfJT2qiKjnfhOJGwCGV85QtcV91DneEuCfeOYh3juhA 6LqKjppg5NVmpjsfHYGqaetrJu4TstFy39Z1GvdibMJLOtGBIcP1LBD3FvAkU3f2k0zURzj8 eHaAwyMvvdpeIgUr8RMI8ZY6cN/LdDFlO4Fji3rbDnxowL333ntYyzOuANef8fWtWLEi7rXI c2iAMXziiSeyBjyUfvvb3w7phcRyLfXY6nu5lnIs1vO0b7/99hvVspElb3zjGzdhPKXqZFOZ yX/BSnVy3QLCoCzLuZ7KBysU9QOf8yblsqZbD37Cc7kwZl6yTZbEeQeSYC0LEftKQQOHpKPW gZfoyKISEJx6mIdO4gHpMHgA4TiOD9WR6ZDQQ9by8yru8SPJcS8/RDyIXgWF8uIN6EP/Beed d96CO9/5zte2H2mLyy+/fAgbiv8RvVCu7TBzAJ2D6+GAAw6I5Ucqis0Z6oGDZbApnfo+ohmI vo0bN4Y+94zjjjtuyZ///OcBDbTrmEEXPaBSHRNNXCKOq5C3zjyPe9zQU5rOIIIC8guMoGLf 8MPufve731Kjy80aPLBGNvb7ptNNnhtiKGaDCOwo1UFJJtmOj8ESnwCMfGpc7NYBwlt1ghnV TD+h1f7C5if9ePCkcuoHF2W4vKoacY7YcZ0MKZs6+6IyPR9E1A83ymzayPOV+fGyXEfXz9By +DNdJFEu9DwPbhs5PZ2bH2BRV/i225CVeH0RxoWWlQMr9Jo65FPZyNQ3BKFc4BSGYtQ36QYd HDpJeAskA482FM83CqNxMyGjhEwc6OgGA8BeGN9rr73GFJ8P1RrjM/Um8DtibdTB1DapKlRV rrIdf6kkbe9jXsW9zht/q4mrN7rk8UVqu4hHbuzkkQmkkgke+X/84x8LtGPKCA+QpA85Evnz zz9/SPu7j3Bdk1cKuWbc5zxwmjnFXuDQfGAj1bnE/eTiPu5z8iPJ/oTGHvJx303XJddmxIba v/4mAr8nOu3odgka9tQmQQumZLFFQUpRFmW4XRO0fMjk7Z1s1Hx0k52QtT4ZcKBSOxnzaxls KdXn4nIrE1XshUBFCJuUkcrsW7VqFYHMPca8pFrp5vXRLP6oOmADF1988SCzD3/9618HP/Sh Dy36zGc+s0EdqDHtyLRMH18Pa0aCC811jXskdnIahZiWys7zUYeMH3l+cloTt1BOT2WaVUNk MAchyfs+2yIjXuQTFAjfJbU4p9pGIuby2I4j8ep2U73Cluj14Fe4YzraIgxt+2MZOJabN3GP /1Ob5vfLGAgkf0R7Sm6A/+NgpzHNNrD7FXr9it0BYlcza/g9ZJNe3KO5zrFvHvnISJ+yk6zb zvfuSkFMZNQH7NcuZ4tf+MIXbv3CF76wWf3N/n333Xdp0g9z4Hk5xmHmvBBu0HJ+J5vYE8/q NUzydcxKbhshZKyboEBNC9x60DEuGGXkMMPtH6lNOe7rc+gFmeogoq6oCgGn8bG1633ve9+b 6y3LaBpAQItBBA8KggSIM1KeE0U/8oI4CBnQ+IGPPHk6hOlGHnnkUEfHnYukGzalg3ptH134 dHDQgZXzRRe7LjZsm48tH5SFrPWxm+oYdt/61rfuqVHx0k9/+tPnpzpQx9BHx3a+9a1vLV+9 evUw03M5nTpY3rI5vxPussR3feqysPf+979/8ZOe9KTNmsEJfrITMvBJOpfaJzBS2sYedOTN T/kWcrKJYc4niVYXLvnEZ+kR9msZcFI7Gr6GVbErHcnRFv7QTtn6Y8N6MAExVXeMdZZaW3x/ DSJ+IzvsG07CJoMHnxO0ZjIPyFHivoob2qq+dpJv5O66cxM4dK1p3UPrYXeRPMs2hg4++OAN b37zmy/lYYOQ+Ku0Yw3T2bzFGtTONJvVTlckft8+++xzPV1/FMZLiT69eRp+zGMes+Fxj3vc RvRpZnSV3EaQI1Z9nZJPyddBifvucW9/AWu/gsunHjiEU8njcNohO2JgkPze0kaWxXCj7SDl ZdU2bDcEZIB2tW3rJJltbMDvUk4tn9tE3vdk4VHPVG/LB3Qlkv2oe1avlvODntUj7lO8WYWu AfTgBz7wgcU3uclNhnnpwfNK210u0T1rq64X3or0sx5cHadF3/nOdzYyO5HKyW2GLZcB3zj6 TXnnOZFek+zRseO+GW1PvlPqxst1VI8wQl1zXDIitXauoOW6xpNc6Gc4bDqz0ScR5N4d9Rbs JeWxOC/iXk6pz1l+dPzgV+P4La4nxeVWDXCXa9nekO7Ro1retFjfRSwTvJI2QBCIbp5yXqLX ss43ZBxvIo/1X3XVVf16jvTrxWBcF5rtq/u01sOOcEBdvnnN+iA0UcLWPIr7idwRF9SEQh0E HGBcjBxcoKv0sN+DAQR5rYOLvcPJq7FialvO900cnRhdCtC48TDiZu08iFKUA7/KVm/+hceg AkVkaNj0AEMMsvWcD/uQzUOOgzKhWR9cyXrbyDsgM32fk+tCXRklE9AtZZC37c9//vO7aqeC DXpYtOyDzAMMOfsi18noQscvctvM+OGTVFiM2F/2spct104Hw6wdxHa6kELEeWguN8dTWVGm y0r6QeNHqdatslG/hFYg6XBFx1VNXikGAMJxjkB90wkl6Mkn8bCVjAceyCKDEXAygUg+dA3h pXMM2ZneN3w+x718TyzVg2raABoQn6dMvz58W6aPR3dTx+ef+ofjUX1gOvTSl750Dx176uO4 S3/wgx8s0YNoF31UepGWnMEf1NLIXcXfTfwrbVQfll6u9bPMHvX/+Mc/XqidO3Y96qijhlev Xh2DQMLAZbou5EWP+gBNL3EfA2dfj9y3us3Chd8kE/c3wUhcm/apoXnkdThruZZ7T9KhzYJu KCWaDd34AUn26jw0EnRSgjVNCOQ6bzwI+rEeeXCBtvK2m2QQr5N5EJo2RGqpq2UNraN/U16o jhgf/vbpJceodmca0fImts7s++QnP7lIH1vzMXZ8LMo5aH34Fr2EWqq14Que85znsCSna8rL 6yRIO6br1ecRotApk6OZZLdJQheaQMuLIZTNoJ1q3HSUuqWk0k0k6q161rZdZ+lSvuMWSDLN eOgFp/UHOcsCI82HuPe5Jv/FuSfcrIC6H2/VzNgGtibWs3Bk8+bN/dr+dU2LkDK5LrjbJ8nV vm3qdcprxUvfQx7ykGF9zL2YmT5dQ6P6j5VR7da0QH2dahlCQ7lZbon79oPxhts6ZutRW0eJ zgxfVFyQHuEv0SzEUg8evO2f3qTE1DaDCd2k4kZvSBARSUr5hc3NLAIKhhpd2SqvsqC3yIvn 2QXoJGptJOSZPVCwREenySOP/Sy44maa5ATGbWFUckGDzpHrUlcO6AwitDvBrnwX8pvf/GbJ n/70pyXa5myj9v6+VLMUK7XudYmmqRcR/JrB2fg///M/K0SPt7APf/jD1z/5yU9ehx11oNjf uv/3v//9wv3333/4d7/73QJtd7ZRU4fLNRIf0FZnG3Rs4rz1QdGAOl3L1LlasHr16hHtgLCJ fcb15gobfbrYVnzve99bpweV/Vhf2OhTjh8a4D5XeMJDByElkUI+MvBoB6DpwKSzzc0Zuo7Q 9Q/5nG4+9dFBgSKFDP7NBx71oAJbCCFPMoSW6+v8Z3Tf8PkY9579k5vrWAInJRiDvyCIpCVM i7QUgw/gWOY3qIFCnwYJV+tj94Vqp0HxFzJLxHpx+Bpo9CuW1/7hD39YmO4hMhvtGzuCUMyd 7nSnEX3nMqKP9RZp+VN8qAedMqkDR5aP+phGSAhHIIDqELKQxEusOoZDqBI3Wj0U50nchz/4 SQknxIsZE3qF9jvy1WVZ+TPHbasdTY0kcjXTkdrO4m1hbgO8rVArsZbJdRHhfkJ7TybpI9It +vgzvodop6cdazbp2My5pPPJv7nrO/7447eccMIJEdvSj7pxneiZEvvoN236HDv5RnyX01Sl PVp4eR6cJLsgcU/GFynvtgwhy4ZC+jHN9+ScZ7wbz/qWNRQdnwhU0PQ2MJ7LiY5O3c5tZHNS Lgde4l5O0Mugi9O1EP7RLkvrNCu8kd3H+G6HGTLajC2J9YeLV0kl5HRP3+A4x8k//OEP15Dn /qv+0chPfvITXqr2vfzlL49rAvwXv+2J0O8AACAASURBVPhFfC+EDM8dybAMOexppnqLlk71 852EvrsIO9pEheWD/drJaQv6KTYith2/0J2oZ6pTkPI8OMl6xOg8ifs474l+pjKIiIbDp+ng wuSI2QcGChzk6UTL8fW/mHowQYOqEWo7kgGPO3PCa75kY3o80WnIKFcg5KUHqe7AZkEddP0Q QFz0BFfLIAIe+hzUiQMaP8ibR16pzqe61zTrWl556hYdJe1hvEBvjFaoM3+ZOv7rNBuwx8kn n7xSa1o3qqO/jOUa+gh9i6b9lmmwsFJbl13F0g1dkLsqjT30oQ/drO3/hrTeb6l2M9iof4zc rH8uXap9lwff8Y53rP3Vr361QH9atFxvY7fowdL33Oc+dznT4prWW3/GGWcMPuIRj1iuC2md PsTbrDfBC7Wkienv8Ad19DlzvsbTeQiMd6bImJ9D6ErhHGwkP9UXbcWuftHTEQ8gUaorE2Sc bjwUKtHgQ2/SwhZ0HbSrlzMhF7sz0d7ikTwwqjKpEyK5Gds3fL7EfX4d4Gh8KxAHPB3b5KEp 0eHfrAH00IMf/OB9NP288fa3v/1mtva7/vWvH99Pic82f4O6NvbUYHeT/oBrq/jD4m9JbRlx Bq5jjD/l+u53v7tQg49Bzejxp1sRz9wDXC/KBTctuz9ErFoHuXQeAUWv88jYjiFMpVBCNum7 3IqbflMZO2vct5zLdDPyE85s66fp2u5Fn/IlF+3Wi3wu4zjIaZPB8ziZTj1cZm7PtBx24lO2 Uj0IyHXA0SPRTgl29JllgclurW+ertWaZnvmkQfP89DyBM91yek5nuu7HvBF52Sb+lNq/7y8 yeLUiXOgPpPVnQl5ypedWS+bnZb08ifONSvPZRtO+ZQ4D8WTB9m1HS37q9uYe7z6Ti0x5fMn FojH9Byo9UHgkWinBDvW17JAbANzGvrzJe6nMogI//KTEh1m7MQhx8WyJcHYBk302PYvo0fn n3zSVxtUiTwYIOercZJE1bpkRIvvIJJK3CiQkx5smwpb5JFPdmpeLgfPfAwohZzt53kYSmEb mOsKjwEENAZN4g8cddRRG44++mh20ug/8sgjN5577rkL1ZHaxB+rMFDQCHrgpJNOWqHZhw3i 831EPzMNGnwskdxWbGk0P/ya17wm/hlSdhgsbGA7Mx1sdzYmm0P6w5YxDUYWamp8rd7OjrFe XMtDRtXRWqDBSHw8LDrqtZ84L+zLb/Z98PlRCro7YBCQRQc/+0JUXuTq5iiImC8sZOH5AquY yY5lq2x1s0dXCR0UQy/J1bQkkPPAo6AkSwxyoxCo/nQIZbUHgw0veaH9prpvOFWY93Gf2qG+ DuTbiCGg3B0D9ny2QoOBMQ2gL9aAeJneTC3Tco1dVuubIL1xWqMBxVZiVt9LXC7+kq997Wvs F75i3333HdEgeZ0GFPzDF0Uya7drIPrhGtIuNpuYtaCtSbS9EmjEBdBxkGRCXXUMmfgJSv2Q LXFf+WOH+NV125fiKO4ryntQGA9q2pdjeyXiRofrFOHjWOqhDm07JjLSQsc+qXle7eSaMnkd sAO/qWeZicqBbxnrAG3PfMpoJ8e1mOhxQunaNA1YnWhuPOGwOFJZ20iYvw0jEdCbSKaT7o5A n8m4lx9m4gLBn3JrZSq1S692I74n0qG9SC7D7dDUQ64pY1lg4keZOd34ROXAt4x1gK6H+dSh ndx8ivupDiLCn/qJDjO+TXgMHNJMRCw5EJ0dPJALqI4dV7Z8X80k0Ahkkr7xkMlkxe6rP54W jnwcyRY3dOsgG7zUyTUefHjQ0bMc5UOjnsCqOlVV4LkM5Ek6v4D6CYL0atswbBd76F7rWteK D82xrU5PP29Qk09CFlxbpA3qz4WWa0lTLF1SGX2rtRzJ9WQQgVxlvq9PW6ZFfcmzW8eGDRsG tMVadH7uc5/7LFcdIjEr0fz3RtmMc0y2kaMe4RMe1sZdlsqNepI3Lcm0yPrhHsTqR0W0DASw E3cJ6MaT/eruAVE+Ew2+L9D8ZlDPONh2COoHHWjUEag8cSe0HqDEeYjm9vK+4THYg67DMS20 bcpljM+buCeGleTiqrOOb8lzwHM+tUH42TrI6KO7Me0hvl7ruNfzZ0L6A63lWt+9SsuRLkdH A+E+8Tbq2KRrYkAfWi971rOetfL//u//YtcP2ejTkr+1TJFTB01Zs9YxyqH9wZFRasKguV4h MS4TJwSN+iNDkr04L/KmQZcMoJadJ3Ef5zzNn/w67miKzlOKpRYZtUFHfdqEg3YiDvL26qbX UsAEmaYd4iMvZwJ16hT1d/w4300PWfmi43mjm9nraMo+6VTf5DuB8c5mLuu6uiwKgoY8cjnd lYCW6NQ/UtJxtgXCo562Bd5M1m/Ha8pm51yX35TJ8r5fZKQZQ7u2n0uZzbjHbypnm3OUr8Xa huwq1YyGfltbVhIMfkOnbtdMriNKDEw17vNyiQHuJZ3OkXKQxw+uTC5rW8g5WR65nG4+tESv lZKORVogPOppW+1i2/rteC3GlEGGuqHT5LXJ1+fdhtcTaTqDCAqgAvQq6kMnEB1nIAc8XRzx YTVQeZxFhyMe/MpG5wM5cB0keORDVs6AHge6ZPmR/bBBkMg2JN7+By/hgFqW+pBPdgMPARFs C5hkAqZMTot6UKZSlA+TepHPcGyGEHRwyaBD8vkFRFfrwMee+tSnrtOHSZvh82GSBxvJdvgC Hgagme681gOO8d8ZrB/0x9P8cVFam5jroU9l7d8acv6+6DL7nBbFhJ5Anq/xjF/bb0dTGZBb UiorBgiJXzsLHvXV4QFE8KDLCOQaCg+7DWj9iDsJ2HfEow/aqm6vMNL5h/IsHzC1b7QzOPy5 GPe4hAZPPsf5bv+Y/UnsnM41iUy/BgO7aj/8rdohbAN6+oZhVAOKDRr0LlmzZs2AlvqtYLCs b4Hi+x59/M4HpBu1nnyR/mBrkPimfP1Tb0xXg2PXdSEv3/t+UgWsRKCnFHEglbp+1iXmuCeZ Z3nyJMkBgp/yNZ7ygJBr6NQ0ymimVP7OEPf2YxM2T6ltXj7BgdZtkcG3+Cz5uIVHppvuNsIZ IbeH/ana6VYHl4H9TqlZLnnHKXrt+LJVG0z+6eg/l+u6KI47yloGnXZl21aCYSddG3U9cxuS Q4a2q+ub8pYnG21rvQwKrTtc0fkJ4Q4/1uvArsmpD1DnOyB5fblft/0IV3TLNWEHs63kZtvm XM6HNuh0Xt10cztNPLfXro3FF9mn09TuLe8ybEewbcw16SmWQrbJa+Ypo0mjdqYZNuuSn0FT JunXNnLZDC9xnzljInQ6gwii0JHIRQg+oA9ahrT3ez2QgKbA0X2tekMILlp0sB3MooUtNbg7 BKAtgwTJRqcfnaQXMskWOIERtkVzHlinZnnImeb6kcemUtSpQis5yfhmGR2jNMXOuQWdgpJ+ 6GZ48Mmnc43zR88DBe2xvFXLjhbd6173iu1e9cHpcjpZz3/+8/mAyKm2j61kP3jg6nSN8Scu X/7ylxfoA6dhvcntv9/97rdEsxub2bGA6ukfJPvZ05mOHeVTZwwAsJFgjSe2y887aTXNiGRl ourw2455QPg6f2zHAQkFpcjnZYkW9Uq8eFAl3yEv0WqUneSCph/bpbicFrZSeXnbxBI80fOZ iOBjoEPK+fMu7mk/xU34wLFMG5DwF4A8KEfiBe02t7kNe3kv1TcPm9m6Ep52YlokfISPqcXn D7kWaSC9BT62tAnAQv6oCH6yGzDhUWYqSyAS11i8fUImVSt0wOFBzK7Zmif5GreejXKu6LRL kpXqnI/7dqceNM69ExPfiNeWn/wdMdP0d2avo34m0wmtdR0TCOZ4B8Vaz3zOMa8j/9+gDzp3 1XdpfDBN3PRB09asK3TfHWIp6fHHH79ecczIsV9bfg996lOfWsp/P+gPubbovrxZGwtIjaIk oNjUMcY/+2oXpsX82Rz3/6c85Smb9Y1cJSQ55BWHzDz3a7nfIv5gi3/r1TUzzD0eW7YJrjr1 aTZvgbaN7T/kkEPGtJPNCH/IRVlKca3k52U6uk7wbRO+6CibbbgtQTKWS1BgGzHrt0DaCFkO yic/UUIG2QnShAIT6Nds1a2jLfupFs6Q/Ly61Df8nKlNBq1181jP8aYxvrvUrPAeiulLXCfF Yh+75Wlji8WaIebfqNekeK7Vsak+TJ++tVzxt7/9bSHLq/VSaJN2F4vd8/j3aH3DuUS7iw0q /rbKxqZ07w0blIWv9KH0gi996UuLKJOlq4rTrbwIJcnGgPowCzVzPXDYYYeN6CXUFq+YQFci AlU8I68XTwtPOOGEYdWhDjYtFx/U8vCBJUuW9GmJ+Ki+uRvVddqn7cV5wY0aCTt8uzd23HHH xfOHtkqMKMf5IFY/dRmmuX3JJ3mBbcQs3gLxp/WpC/mJEjLZOXQSr0+yk8BU6e2fihNbyysE zoGtjbpZhbZOLAYScgity82qzue4OrO8sY3OtWUxAB6GEm6e6YZih33nLWe6ymqxbb4hZTR1 mzzn83pDo+6CoW8ZIDZTqvGMHvWBrwtiq3ZvWvbtb3970ROf+MSNets6oODeVW9edwVnx6Vc L8PDvPIEWV0GF5ZuAuyrv/DII49cctRRRy1lS9c0gOjXw2uEt7oMJDCAPWyko7YTxtMPvEp0 vCzrULZxQ2QV0C1XDHkOybusZH1bkNlBlhT1tKTydd2z8qMeyLhs5NAlJbzl/DRDww4Q8YAX hNfCV75dymWsM6/iXj7npUAdw6k98HXLIefVvjLvmGOO2ahY3KpvGvbQjXw3xfpuDJzf9KY3 rUNG3wFtEn/kHve4xyptILBS8buLbvwL1VmKrS5TWdEu1AEkp+VlOjZyGdcDmvkNfViRRAcK lLivPDK1X1+PubZ8n2drPJfN8VqgB6Sp18znJmjb1L45ucbRbepz79TW3Mtf9KIX7aGNKxbV wkL07c4qyfdpdm3twoUL+VZnVz0j+jTL1q/BwCqWtbKMT9+vDeqbttiFz/qui66FJT/60Y+G uPfrG6JRXRPL+AdfEjKGKmOxOm0DsrNFHbdR/YfEEu2Ko+Jb7716mbQIf2tHnGE9H8ZUj/h3 xzCUfpo6TZ7rZii+0Pq5ER2dPN/EkbeObWNAKT+nlrzlcpjXM9d1POX8XA8c+e2Z2tXF9WzW I5fN8aZct3xTr5nPde076qPdHNmEZRd9l7a3BqSLczkNKnbT95VL1Ie4WstQhxU7ezoWcznN IK8655xzFqgPs1Z/kshAYbdLL710QAPdPm0Qs4vK6X/605++QbtLLtC9fGmuS12kO6CXpsvY tlurMTZpA5gFGnDHdsfU7wlPeMIS6qpY36wdyQa1SQzX3TYNqmcJ19VCDVqG+P8It7m+w2NZ 7JCeO6PaBW2EgYMGR4Psinnve997jEMDH45RbVTTz0AD/9lPhpRpHEid8nwTT3UUebyqZJTq eKyy4/ncN8bztsx1KZ+U861jiPxsp+nMROR1c03XqvEuE2Ov5omlRqk7FnxXQKc3yUUHxAZ1 4iLXbzRNriF83saI0DIIgm4h28jygeL4Tm8ULWuY7EVdTGtCZHTUZM5HF9M66q/Urz8EWmsc AtugYRAdfUi9iTdS+k6ij2VICuw1jLaRX716NU7AP32ajYjRO/awwYfT0CkbqC3S1punnZ6G daGN6EHFv0WO6YNTVCJoNRrfopmi2AotiK0/Mle9mfIov5VdB2vUnXJ1cOIt55/p1E7hXDlI DahsK8/8zI7LqfUp2xdQLmccG9QNGWTJp3ixSN9ZZ531H2W8TVxd11qgN8R68y7ucU/WVhGr ItXXX+LL/eMkYvx1r3vdWr0pWq8/JRq84Q1vOMLbJgsRd+pErdc1syHxR1m6lNv4y1/+wt7j YdTlZ3zaI3iiBd5GhqrlSSIl7nOHzBbutsB+1mYdi3MbdhTowkCXdm0nktfD/JzWrW5soa17 9JDeyA5feOGF8fykHLba1hbeC/UC52J2yWMmQv9nslQdpCH+70SzCsO6j8eW3fqH3Q3anWw3 zUr0+/5MPRhw/O///u8idYbW6M3v6OGHHz6iHfsW/fKXvxzSC6DYGAM56iraoOQ28I3R7W53 u1ENbNgFcEhvUOsNCDR4oZPITMRWri02NmB3NL1AqZcDYs/3SXBS03fNfCXVfhkTPPsSPedN sy5503wvz/PCSSEO37jtJTvbgFTXkBcOrOuQhCuj22jOHiGvO3WaKCW/TSzYxlA6/7a6eT2s SjzrjfxCDXC3aifJOp6RVTytUFz9WzE2wr9Rq3POt2mL1MdgyXUk5LTl/CLJxR+GitivTvtS Zpi1UxPbdY9pZ8r4H6xjjz12ozr5K3X/35D3MTQYH9ILpS2K3djSldUY2j52gQYtW7SD5ZCe AWP6z4lY4qpBwBbRF2tQvNk27FNtl9/P1sccqkfdzqeeeuqA+mTD2qky/pBOA/MRXZuDmikc 0eCbFRpxP1L/a0AvrkYf9rCHxe6OHXzpeNrGx/YvejiHvGnklZQdp82VuJ+pQUQ4SD+b1KH9 i0aj10mdg2hMdeAYMjFtRMcu/vQLXAdeFQinuyOCLVLQ4acMtoKGPIjy0Vig6Yi85ZMM2UiV inPVzVI5Ou217cRFNepjHnThcSSZGodOIkCEk+pzEQ4raIamocLexmlQEwOjfbUbTZITqDro 2Et+iPMmn2RcTm2fOvC/FFpbXl8clgVyQQpG3bN6QIIWdrGRJ+RMQyblfWK1vVTHXLXGrQ8B G+R9JKF6psJ587Pyo2zXATlkyPtBg6xTkkMnDtvTx+Z9H/3oR/9PcnRI8Tfn0P71qBgTJHTn Vdzjj+RngSo2s0Fa0Joy5Eno6eEywlaACCoFzRAZ8frUuYrOkNrMcYYsvg6IfAOv89DJOKGH HWAbvaBLFiGrBETWNOtiByb5BJFpKS+U04/1k6yycybu89PcBk/+Cb/QOfYDfxvBaRDyMqZh pkUVm0ot7SlaLaPBw8gLXvCCq/74xz8u1JvVxcjC9/3H58kbWw4txRhiq2K91V1D2yOrpUoL +G8TxXhLPGpQMsgmGeq0xb0IeWYjWM6hQYRjLuJUu5dt8DInBgpnnnnmgN7QshFH1FXl0IHr 1/dxm3hhp/ryZ3WDDDh4A9tMyIsWJ5rqKTDuB/h5PtOPAsXLSBUKLacnXGCcDp5s5/q1sTa8 FpsoIYP/BWMgBkx27bMa5oXMBk5dqBK2d8S4l1/cxqpqfx/xrNmxyzQAXqwYWYLfSFp+tEAv N0cVY/W3IsxGaKXJAsVz/PdCCOrZqaVGl2rJacSsYrGfgbNmFrZqidKiAw44gN0lo20UyyN6 iTnAP0xr0BJ+wl+add6iJa5b+H5Ts2uDn/jEJxZp9mMzeipvQH/GWz+bdd2M8v3cFVdcgY2o guusF7RM2fVrADIIzeXqpdSwY57yNNswoAF62CSPjq69vje84Q2DGrSwVXg6tSq2lB+/AdSc ehA9TkmYyzYj2ROYm3Hf8ibfJ90DtJeBHDRIHGqEM7U85yzW+jN48AGfBuMwLYfmZbDWRS7X s0xTv5m3nHWzfNh23UV3/ev6ZbJB65Cv7cCn/OSHXCdkzAdSbptzQjfXq2WaZTflzDc9BWuL LfG2uZFGVFftF7LopfoFNG46eXAOyjIOTDfx2k7OA3cdhdcd/ga9lnE51qEw7JOgAdEFpHzz XE2vbVIushpAcNP7hR7Cv5U+b/fqNsOeDpJhlRv/NR3IYd3ReRb3js36usS/+MRx7bZr5k0H puuFdqnvDaYDcTvQB/aNA20bOrJK7ky0yOU6IURlVV0OeIbwLJvk6rzlRQ955+dJ3Ic7+JlM ohM1lUQbbE89l9Wp3KytowNveaB1NCAY1ezDVv1/zwrtkjekbyOW830Dy594G8s/sCP/1a9+ dZE6+8v1RnWD72nQSfwrdXqLWhH0yxp0Xnq4DjBUZh+dKXCWguh7iCXMVLCsCRpJ8nXHh0GG 1pEv+OIXvzikP/Pie7iwV4lV14HrQjlZUrbiJzrMoCGT8zrhuS3rJlvb1KFpkzz1SvJRsbwc 84FTSPmJ5njTVDdeUzbyO1vctzsJzQQPMaDF32qDiHvF8Ai7PSLvuNc9mFiMC50BM0uZNFDd ohfJw5rZGOD7S6XQTwON+J6nWSYy2qFvSJtvLLvsssv6991334hlrglsIE9dZAM8vu0EQndd wPMEHR0G2yxRYnmVBkxDp5122gCzEfAc95qhG9Ry21G+KZWN0IPPQd60yCS6+e0gcinVuslW bdN6yBm3zA4Q967/hHA6MxE0cjgog9A2aD3bKWefffblWmt2gEafu2kUGG9sFHDxcBeMQCQA 5TRwBhzVFi66QSoxuIEWfAUDic44URHyiR/C4CnFoEi4xKo/IIOe8SMwIZmeeMwGhBz2KRc6 R47n+cpsJYMtEroAlNFL+aDxg74S/Mjyo4Q45YQyGeE1XYjlA4odEHlkM0Gy5Guo8iMPLcNt r5bLdSxL/Uk5L8tzrvCiDqZD00EFOJfQTTSXH3Tkkz5oXMjY8gUNG33ypnO+zme6Ub7ytV3k 0bUNeGS0dGC9YvIiveX4jf6jgFkIloDxRiUfSBAfjmuhbZP52PUBbd7FPW0iX+dxH0vx8At0 QUA0hgC+Mq1iiBUClUzoWM4w2RDYNu4rtdYYRa8Kh36uoxrHgOWNOw/kIFRK3OOdySX5jrbD 1/gx4GQsoCN5YsNwMupRZlKIWJuMcioblZ51OU+nDO9XB2WN1lvvomVGS/S922bNBm/dt5pZ jg009B3FSr6HeM973nO11n9HxyvT79N3FPH9hG0D6bQxG2Ea8qpzZLXVMWvMF2od+VatG6/f +OY2keW/iPT2dbP+lJHv4hYdddRRI0cccYTExs8Dg7q/MjCnAcN+Kge5Ft/gM2SgI5PkQqf5 E4IiIk8yzO/lpgGpQwjqx+U4D7QsvJye48jApwxmhgxzmQaOrY72GrJ1ljJcR8Oa2QOCjsTw rWEPWuMiSR9CS/uMS0wek+9ktj9WMzBrYAvQ2TFSm7e0vKmnbOT1XcWSD33oQyu1JGmdZhFi Mxh2heTbTvHj/IhllrQymHA72j42tLR7q46rP/nJTy7Ssqel+pPcter8j/n7BmT4iBsbzNbl NuDleds11DLYftVrgf68dEyrZbbkf0anOlL/AQ1i6mtIejJX4t7+6wanOojwBQfkBscNkc6Y j41as3m6jn+KtlIHH+zkW2k66A3FjgvBeaBx84Ckdrxctg78SrzFTs7L7eT6zTLMawdtwzzs 5zi2XKah7QNJttHEg5l+niz4wZyQ8FwXUp7Py2ujWpNc35owgZ1O8ujnvBy3beLFsZPTjAPN z2GOW9a0PA8tP4hNpjgZLPBnf1fp4JsdljGxrhOeYxZZjqZdkepkHnA+x70dQhu7nXPYxMn7 2sh52MnjFJ758DrFPbxmauqan9NzPOfnuMvP6wXfdMvmtJyX45Z1TDoPdCyZ5nwOc7wpl+eR y4+ZjnuXBWxXp+D7DWzqIOY6HXF3MDoKzCJjsmVbvtlZobPBuatzM6aXFJeryhED2iBgT333 o9VEw3zXtpLZCu2ct4bOlWXy09N3ECP83w/LPej4U47eCA9oSQjt2ZL4BkJruBdoZmPD6tWr q55fJUH7qKr9Y6effjpLQ4be/e53byEvub6DDz54lJ2aMC5adLaRR5Xy6MSjTN4JXcSdRy6J RCyQb5dyeo6n+BCpftMbZQdBhqBTJnLgkOInySc+vDgH5Mw3pH7YIG8IPo3kkzSsTe1McW9f 4Lr6BBoIPL29H1aHnWVDg2np6Zh2cBrcf//9q6/8k45k+Y5nqeJ6GbGvGONlMFz+E2hEM/T1 5gPMKrCkiUFAnvTdz2Jm6vhjXej3v//9t+o7niV07hksqNNfbwYgG/0qY7RpQ2q0i4qu2px6 cZDn+1B9j7FA32YMyzaz3tApKn60K9SAth4f4z+K0HFCV6n2U7IHO4RyWesEM7ORy+ykcZ+f Wlu8tTXbimxDjMZKVK5eH/lAgk4bD2FoV+sgCJqDiPwh7YYy7MazTDtomoqLAGnmm3T4nWSQ JeUyE+GudxO6DOvneZeRwyZO/gJ+UrIdsrZlPM+bBiTlvBzvxMtlwJv5ph55Ui47flVWPOcN K2r1mz8szTdEArxb3vrIgDsmiUcGDbwhYQYCyKACugcSyFovL0PkSNB8/o75vAwGI/Mh7nGG 4xvcKacZdxx0gujmPNuyn8k34x5aziefJ/MM4Rk3NI18k2YekNSLTCXZKtuMIecNrQN03IKb b2hat7z1kcljcibinvI7Jr25Hm23Y0tHhYzBQ1rZ3P8ZtzOa9BDgKR9vmlOnwB2HujPQfIjr zbT9ONlyu9aV8rUb0+764PNq1oxr6dCS/fbbbyvfoLE2XB+vsqvMWr5PSJ0J/ng0TlIzows1 czGspUtj6swMq1O2ULszbRZ9AW9h1WmKPx3Vv7kv0D+7D2swwgYEi/TnpBtZW84yDRIzGRyS G2TNt5ZXjWqL5EG9YR3Qx7Cj6kz1a+0730ZskV/q88ef5DMf1ucKDR8iQxm5Xsq7Q0a2Tug4 GW/YaWkj8Uh1WR5AQMvqFSZdF9sHQss7aTkPHDszmeZ63POthAYMmxVLy9QBX6vvDJbqW4RB BgH4UUvWlxx66KG80R/T9q4r2epYscggOOKKgbJmvTa/733vW843EgwG9B3i0rT1ax9LnRSL fFC9VZsOjGgAspjYZrmSPnpeoCVRfMcwpj/K3Srbi4lddfIpaxGzeLSnbPRr+9nBo48+OupE nOTtbJzNBDR4GJGtUa4V5JhxZpZDqV/XZ782OmBmo8T9FC6SqQwiXIyvyvyhReeBwYJvUObR yNDh+7AM0LjQGjfNEJ47J+Ckpm47WlOmme+kY7phXg9oeV1sswmbcu3y1oGX4+TzxGCMlJdb UVpp7fjIYdspx00DNsu3nKFlPzo/gQAAIABJREFUrNOJbv5EkBhyHFnWeUPoTTnzDC1jSNzB I+7cuWcQwcET1wMJ05BB1npCt6kXNJLLdGyji8/nS9x3ixHHQzvouMz1cxzfWgbcqd6NyYQu sGkP0XY2J6I1648d07rh8HpJxJDjyPLOG0JvyplnaBlDx+9sxD1l5CnqpjX/g7wVdMfOMBec Cl49z+WA1Pmjg8iD33kg+U4JPp0FUlanGHRAa2ePpS+2L5G6V5308/bHREuiLlrKsfbEE09c oW27x9j1Rh0oZj77NCOwgB2djjzyyD1yJXXQrmCpkrbIXC6dtXobO6yBxnrtcb+C/0tha1h1 gDbof5dCTR+ILtEAYIN2expjqYl2kVmW29OuN5u1leZWbf+6SEudNmkwM8oyJ+0CuEjl6NTG 2H52mKUcSuTrc1L9W/K53RzPfWk6drsl+NYDz+WdN8ROzrdem0GFxMZtWScfSEi3XsoEHdPZ QX4qaaePe/xifwGb1xV80kte8pLLFS976fvB5cTza17zmss9A6CPkHfTUrrL9Qego7oHsPtR S2yzQ6Vib4N2IlunbYZX0WFnJk6DhaspkwGE7C3XIOJKDTa2agn8YuG7aCAyykBCSwN5yRc7 imlp0ybtorScbzR0jYxpFi5GzfoQfFDXziINIqpRdNW+dUyjT+IbCH2nxPVYz2hoMDP6gx/8 YAtxr80HBvhfCfuk0mr9dRyKWtvvJo82fOuB5/LOG1oeSLLeDhT3VcXa/NYOacPrRrIeHScG Iobs7UtD5dA85Ljrc6Df7gnQCw1dly+0JeX6uYzxJkTZtBxvR2vHR64p63zOy3HskJo061Xc 6te0zyj7mIzR1DWrGz2XMQ50Gd3wiXjm57agtUt+4hhaplO+SUceWk5vl887+XT0PWDg5sTB jQfIrITf2DIrQQeMI7evbCSfn2PaMI93x795czHucUanWMuvwVwul89xywBJ9jF4HvemG8Lv lJr2LWfdThA585o67XimNXWsm0PHk6F5nfJNOvLQcnq7/EzHPedGLHM4tnmFvkTH9bXr0LF6 485uKEOakYA/qLftQ3o4s8RnEKgH4YB3LRJfz8d+vgGjQ4/tgOSVlK3jqpaBDhMZBJRCL8/D Nx1cKXSggZsnnRpPg4ZaDx6yqld825PbR5+864zRlFp0dM79fJS6WrMH6CjFDzDLh47zrpNl 6DhoydEgH08zgMAIKRkIkHQSqXqzSt2gI5rLs5MNhz52JV6ClWRCFj3y6Bq3YcuRJ5HPYWQy OnnZMDmg84Zmkte5hnDGE1p3uGqeO1MqH1otgyw0+InOySDjzRpGdF6jmtG5St+ovEn0v+ng xQTb7fIM8P2fZ0QYESRxonMy7uWPuCZTWwpEo3K+gTsOyONfDYAXeBkSvBCqYiy/ViReXZeV OYv197G5gOJvgHjOeH4JgLmIO5buMYPBjBy2XBaG2fUJG/umD67ho4cMiYxSRazyQTY/icAP eoKRR0bnGfpmJltkI+XypgFNB8dXeXLe0DzyO3Dcu5o9Qzo4U0nRyFKMizUzUN1hxuncSCnD HSkuygjWho71IDf5meiEPMt2suFyDC0PbOr0ImP9XDfHc77LaNJyersyLX+lkE5805vQujm0 DLQct0xOy/Gc345u/lShr0BD2+mU70aHx0H88WBgcOClS0APJMBNt2zTrkTqBI9zBzYfOAiZ Pl/innMmdRo4VNzqt50MHPzZLp5Mi7e5lYkJf9vZsh0rO2/YpJNv8kxrR7f+VKHjzdB2OuW7 0eFxOJZnKu7b1YlyrtK65Uv1IN2LcgWj/AQFIk9ngGulbv/0EI0HMHiSo4zwL3kl6we9nYzl ESBZRjBsA5P9SqD6rctABRJ6STfqmPC6EpWaTrC1rlEGPOoK0MF/H42ps8RbTc4bWui5M0Od OJB1OSkT+tBko18DM9owBOErUUeg9WocOuUphQ0YSjWuN8DxBle0qGeqbwjxgx40OuJZnUMW frId9RYOKc6Jcp1Mdz6HTR55HSSLxbmR9yFGMFPe5x519YACXqo7dpStDCZ6EFIdx7SpBv8L xAw0sYhtH0InTHVFJQm+08S9fCEXtMRF+Axa8k20qz0ALdMhHvr1XQ/3EbEqHjGCTNLBH/US PclEXjRkopPPdv/aoaz+ViKTibqgj03+oZ0yyGcyUU/p92lpYCzrQwY+kHoAs+TybTvs6Yf6 2Dgy8EPfcW8+svBtO8lBghZ6kUl5402IbJ7I6yCZ7HMIu4nuskPW5yZYfyOEHHnLZ4jPKeyq kOnGvevZFU51EGGjnDA3Oye3JnQuVkb3+QDCDxJDy6Of4+TzZPmc1g5vJ2e7hk29Jn0y+U6y OT3HXXa7eppnaD3DTp0p89EzbmhbhpOlT8emy+wE6yupg0DeSe8gUl3sYjZtWRdIfBKHQHeq PHAwhIesj6Y9sVoS/Pkc9zijXSyZZmin5fmJYh/ZXJ7Bc7eUy+Y4OpPN5+VY1zDntbPd5HfK TxRbjt1O+tBtw9Cy1gXOZNxTjssCYh+4mf8F0tr7fbwNIw83H+oYRKdADzl8WD8whUfKOiPw pVY9GAXJUEbs7AJdR8iIFnbIQg9DlbJlMlLNRz1k0UspaInu8qlvCEBX8s4yoQLNfBsRhJTX A4LrVovLVv3WFH+ggxx0Duzgj8xu2CGf+FEQ2USr5W1P9LpnAZ7bswxl5gk6eeoDnjpUrj9l w3eZcQ5NG+jbDji2gE6Wl0wsLwKmNI4knnWBmVz4IKOFXrIbchZO+rQjMviYpWV9Wgbm/wUi rnyETLMuKQ9o8ne6uOca1HnIDePtDm46J5nznM9p4DrwRW0k0RCPZBlBx1PQaUOVZRx227iX XPAQTCbaxn2Db508WOq4x2aSjzLBnXIeuAcSDT7nHPXgHFwvyyRe7pOQN9/ysr+zxb1PoSc4 nUGEHYYTCVQSnTXo5D0VCI0o4kDWnYja+aI1k3mGOX86tNwOuG0ZNvnO5/wcNx+Y03PcMu1o 7Xid5PxNRCd+sw7t8u3KM82wm/1cphc5y/cCiRvHVDv5bjzkzTf0DR/IQRzmgwkGFM4DLS+0 a7J9zh8dEvrQyc+3uNcpTxj7TRnypDyGcrziVr/EfSdeLtdOplcadtrJ5vYt04tcU69bnrhx TLWT68ZD3nxDxzGQg9h0nBPzU417qUZZlGPbo/oo8c+rV6++nrZmvLHWS8egIe+g6AHKtqHx Fo0HMQ9s6XPEkiFBJ7bwDj5QiQ6CeYHrh3LNoLMQeUgmS4b6IR9JOJmqh6KHOTh1kK6NIxf0 NjZiUIEOvMQPWwnHGPoklytWXb5p1rcwMORUjxaZRMdAXadkEGB98Dol2VreNugYeRkZtFRX 9OrywW1IMmFfckGiHYzbJnnZjcrDJ8FDNzKNnyRf85G1zaSrbKWayoi6JVqN4ydolJNglKS6 +Fxcfg2R1Ye0YyeddNLPta7/NCnw0ojBdf7SCDvWAW+X4HPs7HEvN9Zbw/si47zkKjVMinHn 8V/CQ0B4+J92VxuETi6TyVovoOgWdlu5o4+NkEn1Ik8xlJND6wfNP8ikw+UFK4v70Et1hef6 GA952bBc5NP5mReQmJuHcR/nPtFP1VITSXXnY4OANDTupUuG5udl5rhLaUczDzgRP5fN5XvR a8o0803bzk9Wrld51/88Ifu6sAxOZKcTvxM9M12jk5GtlYTkely800kT6Tf55E3jxp8/NPJO lemGud5E9eX8HOtA4453w1zONnPfdKOZB2ynk/ObuOUNm/w835Rp5nPZHJ+s3GTlz1Nh++YF JnyydnIT09HN7XTCc/uOwU6yE9En0m/yyZs2U3HP+XAQz3zzwMG2jRx8G8GxUrsB3fpe97rX jbSUZ1f+F4jvIvRwHtCDN76HMOSBLnmxqpR1RnhjmXfK6zzyHPAFowMDrkSW6y4MYsvfOSTz oZf4AA9cQtcyTb0kH3ZThyLKdl3DUFWXsJOfWxAkALTdZC8qC13JDqhZ0JJa8IznEAHXJztP 5K1TQ8vBM55DbCmJHeWGDfIQkXOyjvOpLGcDcp4tBGUk5zisWfJTjcNXqgcU8KwDXSl+rJPR Qg+BxEMuaMjIBoWM6X+B1mkJ08X6z4HffOtb3/qNaJfq4IXEWh3N7yEYWPMMyOvMOXHMtbiX i6pmlr9arhfO18wEm/m4JpNcXIdZHIZR6ytuWvJhKMWpcJmIsvgxbtVtIAKOw6y80G0KWw67 xnOILSWrteDIOVnHeexx5An/5XlwyeQxFGzHsPnEKQdpB4z7qNdkfrZxwmSUM1ns5AetQR7o ljF0mYYS6TnZRs8KPQhOph69yvYq5+oh303nYvFZdzyZ1M1eJzu96vQq16mcJn2bC68p0Cbf SSeng8dDJUFwDj8wnLdMriuxCRN+yA/ikzzQsWponxlKpOdkGz0r9CA4mXr0KturHNWzrGG7 Kk8l7nPb7Wy2o3WrQy7fq1yu0w2fbLxhq5NOTgd3TOcxPpW49znTmWLmOh9IeBDBR9bsFMS2 P73+L1Ae05ThcoRugzd5eT63gy7JfGCON3nknSxreehNWjNP2bm862Jo28286bmuacg+Vcf7 EiHXbSfvOlnfsEnP7VimCdvZt0wn/W466OZx2cx347lc61gWaLzJI755ScSggI+mGTT4f4EY OPBBNYMIeN5Yw7Nzvl7EiuTzmktx73PiBN2eTYiMD+Ry3Hmgk/XJN2VznuUtl+fBkXXc53rY 7JaaZSKb03JbtjORTdvIoXUNJ7KRxyg6eT7HmzzbN92yQONN3kzGfV5+T/h0ljPlBfjkgDQa J4WTuTDzRswdn+MSC3ngTKWm/Zmy26ud/Lx71ekmxy4SU0lNPzTzU7GZ68yEPcdPbneyeG7D eA79kIDG4c4V5YBPJeX2S9xXHixx33skOX5619hWMrdhPIfTjXts+Rr3NQP0g4tOG8tEHP90 3GKXJkE6YNDRz+OCvG0K3YYHzXxD05wHGm/ynG9Cyxuan+ehdaqr6cjnR1Mnl4NHsnyVq36b 5eb5f2WCphvCMt6EOa8bDo/UTj+nh1Am1ylvehM6FrvRmzLkJ0NDNo9JBgbeeY/nJgd5duhr DhrQa5ewad/Mhbj3uXCu4M47VpsQOdPALZ9D4+Y7b2h6DsFJTRnnHffOG1Za43q90C3TCTbr 4TIMref8RPK5XDN+zcvpOQ6f/GRoyM503FOPSaWZGkRQqE/eFyUNwOE8MiTTq9z0f9s19PSt 7jgWfH48qJ1Mc77AbT3QjDvn8wvVtG21e6eUuO/dV5ORdIyXuJ+M17a93zrGpxv3eZx7AEEn g4GC24qy4HHwbIFHQg4ZyxnCM96E8EjNjozlKm6rXdNynaaNdjK2aYgMeKe8eeY7bz1gsw45 z3rQ8pTrMBjL85bLyzLNsCnfzFsO6DoY5jzjOS/Hc33LTgQdP4a5fJOW53McHedzCM5B3HmQ wIDBu/B5K1doze8irGt7EmlJpju2GTTj150x7mlDt+NUcDsm121Hcxk5D7xJNz+PU2aKmqld eU2Z3Aa8Zh7aRHba1a9Ja+ax2y05fgxz2SYtz+c4Os7nEJxjNuKeMntKMzmIcIH5SU7W4bYB nI5ubqcXfHuW1Ut92slw8ypp8h7whZZrOkZz2nRx2wROJ56mozvZc9ieZU22bpYvcW9PTA7O dNzTiSJeeDi7Q8XDy4M8l0d70ZHj2YIsh/WEtqR2D/peaRjKZZux7HwTomdajrejmZ/z8jLh N/PIWr4JkXcyj3yOm88ggpTzjDdhJTn+C98y49RxLOflOBJ5PsfHtWcey++duXXHVE4znvPA iUnHJTHJwaCBw0uXwD3IIE6J39yOstukuRj3blegcU48z+e4ndKOZl5+HXSTg+eU46Z5Nz7z DOEbN7RODuG145tmiE6ON23k+dnCiT2SYZXrHpN5vILPVty7LhPC2RhE5IU2nZPzJsKnozuR 7Z2Rzw2vpJ3DA9OJ3eno7hzemVwtS9xPzl+zIU1M8sAF8tBy8kPYdNqKZ4oHEH5bazn08s4G eXg5H1qemvLm5TrGDS0DNM2wycvpOW45aL3Q29XTeoa2adikkzct39LbNEPr59A8Q/OaedMN c36Omw/sRM9lpoI373XNPDabtHZ5aBzEpgcH+UCCGQkPKoCWQb5pT6Q6wePcbdsM+8P0nSnu qbvrz/nkOPlOcdyU6yQL3bKG0PLUpJM3bbJxj13rGuY08Dz1ImP5XNa0mYDNmGvmKaNJa5eH xjHTcU/5PafZHkT0XJEiWDxQPFA8UDywQ3uAB1Y+qPNDNn+Q5QMId0gMLc9J5njzpOF141ve dp03nEi/aXsy+W6yOS/HXS/DTvU2H+g/F+1mx/JNGecNLZfDqfJyG7OBE0t5auZzXj6gBffB IMEHgwbPPhiHZ1lgtzLEDv5cj/s8HnKc88/znXDkSDm/ooz/bq+471SPTnXrRB+v+exjzRhs 5vMaELNOeRw75oGOdWLf+GTj3mV0hWUQ0dU9hVk8UDxQPFA8IA/4ocYD1w8xHkrQyTPrwAGN zgIHsu44dHtQm2cotTr1SkOhnWxtKCGWMWzync/5OW4+sElv5i3biW5+O1vt1oa3k+tmw7xu 5XfjWd9wMrLWyaFjKKf1gud6OW5daD7cqSIOOehEGQcyGPDRzpbYLckynPvOHvcTtV+T38zj mCatmc+d141nuabMVOK+Xb060brRXacmbNaxyZ8o7xiaSK7Jz/Vy3HLQfMx03LuMCWEZREzo oiJQPFA8UDxQPCAP8MDiYcXAwB0qoYGTp5OWL2HyQAIZUruHcTtaJV39TsTPZY1bx9D0drAp 08y304HWq5z1c/kcN78J3ZnqJtuNl9vrJteNl9vY3ni7TlNeh5xv3B0px6ljMh88QGMQAUTO ukI7Jtub73E/lVjJdXK8k7NL3HfyTEXP49X4bMV995okbhlE9OSmIlQ8UDxQPFA8IA/kHSp3 xty5MsRR4CR3HAwram+/6ExFbyLrk7XZq3yvcq6f5Q1NB051S+/cRju7Ob8XfCZsdCvHHaFu Mu147fQcm4buXBGnTRp5jl6T9YnrEvetXptsjFjeMLdW4j73xrZ4u5h1bBrOZNxvW4MGpQwi Gg4p2eKB4oHigeKBrh7wwwohd6roEPDw8uABXt5JyPEmj/x0U9P+dO1NRZ86zFQ9ZqIz5XNo 1qmZt9yOCtt1nKhrk06+0+GOFXrgU0nYtm6J+3EPlrgf98VMYs34tu0mvVPMO14ds4a2MyOw DCJmxI3FSPFA8UDxwLzygB9kfjC5I+G8nWG689OFO1sHeKrny3ak7c61HW2qZcwVPXei8vNx HOY803K5yeIl7ifrscnJl7jv3V95bFvLMZ7zTLPMjMIyiJhRdxZjxQPFA8UD88oD7lQBp9PB nY7uVBy+vcubbB1ZMlPS5D2Qd57QdnxO3lJ3Ddstcd/dT5PllrifrMcq+e0V91OrXdG6xj3g G9Y1XpFSgeKB7eiBEvfb0dmlqB3GAyXud5imKBXZjh4ocb8dnT1TReXrV2fKZrFTPFA8UDxQ PFA8UDxQPFA8UDxQPDCHPVAGEXO4ccupFQ8UDxQPFA8UDxQPFA8UDxQPzIYHyiBiNrxabBYP FA8UDxQPFA8UDxQPFA8UD8xhD5RBxBxu3HJqxQPFA8UDxQPFA8UDxQPFA8UDs+GBMoiYDa8W m8UDxQPFA8UDxQPFA8UDxQPFA3PYA2UQMYcbt5xa8UDxQPFA8UDxQPFA8UDxQPHAbHigDCJm w6vFZvFA8UDxQPFA8UDxQPFA8UDxwBz2QBlEzOHGLadWPFA8UDxQPFA8UDxQPFA8UDwwGx4o g4jZ8GqxWTxQPFA8UDxQPFA8UDxQPFA8MIc9UAYRc7hxy6kVDxQPFA8UDxQPFA8UDxQPFA/M hgfKIGI2vFpsFg8UDxQPFA8UDxQPFA8UDxQPzGEPlEHEHG7ccmrFA8UDxQPFA8UDxQPFA8UD xQOz4YEyiJgNrxabxQPFA8UDxQPFA8UDxQPFA8UDc9gDZRAxhxu3nFrxQPFA8UDxQPFA8UDx QPFA8cBseKAMImbDq8Vm8UDxQPFA8UDxQPFA8UDxQPHAHPZAGUTM4cYtp1Y8UDxQPFA8UDxQ PFA8UDxQPDAbHiiDiNnwarFZPFA8UDxQPFA8UDxQPFA8UDwwhz1QBhFzuHHLqRUPFA8UDxQP FA8UDxQPFA8UD8yGB8ogYja8WmwWDxQPFA8UDxQPFA8UDxQPFA/MYQ+UQcQcbtxyasUDxQPF A8UDxQPFA8UDxQPFA7PhgTKImA2vFpvFA8UDxQPFA8UDxQPFA8UDxQNz2ANlEDGHG7ecWvFA 8UDxQPFA8UDxQPFA8UDxwGx4YGg2jBabO44HxsbGdldt9taxVEf/jlOzUpPige4euN3tbtf3 61//+tDuUjsMd0w12aDjov7+/st3mFqVihQPFA8UDxQPFA/MkgfKIGKWHHtNm9XgYRfV4Sgd +1zTdSnlFw9MxQO3ve1tUYufqehfUzq69i5U2T/UYOLqa6oOpdzigeKB4oHigeKB2fZAWc40 2x6+BuyrE3OAij1GRxlAXAP+315FrlmzZvArX/nKXj/5yU923bp1a5ll2l6On7gcrrtj0nU4 sXSRKB4oHigeKB4oHtgJPVAGETtho3WrcjYDUc8yXeta13rxs571rEPQu8ENbvDMlStXvubi iy9eYDtXXXXVkN6avvfPf/7zsnvd6173k8yzzDM86KCDjrv1rW99LHnbe8hDHnK3wcHBEzmk /24O5+973/ve++Uvf/ktsNs8hoaG3mm7E8EPfvCD++6+++4vn0iuVz6d7Yc97GFH3fCGN3za bW5zm8e+/e1vZ8AV6fe///2Kww8//Jh99933GXe5y10e+Jvf/GaleYaHHXbYMZ/73Oeu4/xU 7VHugQce+Pgb3ehGT37kIx955OjoqE32vfSlL73FLW95yxN0HPfGN77xJjUjIZ///Of3uelN b/rfd7rTnR4j/9z22c9+9tF77rnny+6jRFs25ed6ftWqVa866aST6jbZQc6XdjgqXY87SJVK NYoHigeKB4oHigdmzgNlEDFzvtxRLLGEqWtHcvPmzYuPPfbYe7Wr8OMe97jf/vOf/7zh6aef vtx83nj/5S9/OfABD3jAb0wDfvGLXzxlZGTkmRx3vOMdf6LlJ79y/hvf+Ma3kdljjz3+o47U 0/JjeHj42fB6Scccc8wFX//619/Ti2wvMs94xjMO/elPf3rwU5/61O/e4x73OP2Vr3zlse6A PvzhD3/0wMDA2Ktf/eqTFy1aNHy/+93vSRs3boxr5BWveMXNNYB4hNbo31EDsCUuayr2zj77 7CUveclLnnDEEUf86TnPec53fvGLX9xSvr0nNt/1rnftf+KJJz5Cg5kzTzjhhJ+94Q1veNT7 3//+fV3eW97ylhu99rWvvc8XvvCFz37ve987SXp//v73v/954Sfe5CY3uVjjiAdbtsBr3AMx kLjGa1EqUDxQPFA8UDxQPDALHiiDiFlw6jVlUh11PqKecAnT0Ucffcqpp556p29961vXatb1 oQ996H/U8b/o3e9+90HmqVN7Y3WuR5773Of+1bTZgBow3EWzHC/dZZddXq3ZgrtShjrI13ry k5/8APD73//+99bg504HHHDAk5cvX/76O9/5zg92J1/13e/ggw9+DHJO3/zmN/eUTnTOTZO9 QzRY+KHO5ew3velNp+uN/l80s3CQBknL/vGPf+ynzvnJj33sYy/QAOmbequ/BzbQ/eMf/7iP BhabFyxYsMm2gFOxp4HArTUTcvYHPvCBXz/pSU86TwO3UzSQiJmij3/840doIHDKhz70oV9p 9ugczUb88ZOf/ORhlMW5apDxX1/72tdO0mzO2K1udatn//znP7+e/HYfzSA9421ve9tp//73 v/e+4oorYhCpdttPvnrKkiVL3nSLW9zihHPPPTcGP53ozFI9/elPv61mNV606667vuKFL3zh rSi3mf7zn/8sPPTQQx+5YsWK165evfoZH/3oR2+AjGLnrmqDR1teM1ePfcpTnnI78hr43CzN gr2WGS1mvaCr7kehR/2YUWB2S+d9sMp/uWZc+j7xiU9cH7lubQ/fiVkaZtKoG3U5//zzF5uX Qw0UD2SGCznN6Dzksssui5k5Zn6IwYULF76VmSJmp9DrVk/568WuZ15GwvdJ12UbViEVDxQP FA8UDxQP7LweKIOInbft2tV873bEJu0617nOlep0nqK36A9t8sirU/XbH//4x3UHUjMBB6nj 9wd13MfX3LRTbEPbtGnTYr1tPzg/1Cm+XlNUHeO9fvCDHxyust6rDuenvv3tbx9JB/7yyy9f /K9//SvkL7jggj3VSby/ZhG+LxvvUUf0pnpTfyC21KkeVQd/OLerTvOKP/zhDzfLaZopGVQH ccQ01W+RZl723rJlC98U9KvDHee4fv36QckOaUlT+FTfHnxPPvmy+OzAU6ep2NMSqAHVta7D 2rVrF1555ZV7Mki49NJL9zjkkEP+5QKud73rXaaZjxjIyCd77rXXXhfvt99+GzUAOlgzP3/6 9Kc//ZNrX/vaV6kz/w8N9PqWLVu2/pxzzokO+utf//qHPeEJTzhFs0Jv1XKpfg2cjsBuJ7r8 vK98ftinPvWpjz7+8Y//ugYsj2QWynUx1CDnEarzMpX93gc96EE/f9rTnvbUv/3tb0tf9apX /UptcnPNshxEe//973+/oWZ6fsdSLQ3yHnj88cf/QLNAb8bO8573vLsANSBZpba/593vfvfT 1a5f/tKXvvRfOo5461vf+imdV5/a92jkurU9fBIDBpXxDM3i/FE234mPFeePrbjjvxpA7/q6 173uBJV3Mueget5Ag7kjf/azn63SOZwgP31Jg4dXadnfOg1mY1DUrZ4aqJ3reo6X0oL1dF22 aJRM8UDxQPFA8UDxwA549L0DAAAgAElEQVTuga7LXnbwupfqbesBtnHtKakT/kN1PA+nw/eC F7zgz7mSOlenaanP0Sy7uf71r7/pT3/60y31hvZjuUyvuDrpS08++eQ75PLqFJ9+3HHHXZDT zjrrrF3UcV+hjv9yDW7OVUf67RrsbFLnMTrEltW2n7/mDT35H/3oR9/TTMCBGnT8SW+8z+Ow XCeo2YvfaSByF81AXKFO50p1fm8mP5yrbz7Wqbzz1Wm8rzrAP3/nO995uJZdDakTvaiTLehT sffMZz7zdHV07/f85z//1npbfrHqwzcRA3zPoMHEbnoTvsllyv9XavASdVDH9lp77733FfDU Eb613qZ/GfyMM864gepxJp11Bm2aJbh63bp1Axs2bFihTv1e8ss5mnU6SbMUizvRsUNSB/qb 6nhfxqGO+KGaLdlfMxJ/q7h9fcSElrodrAHfq/TdyBVaTnUx7fve9773wPe85z2/USf+5Pe9 730P1uBqQN92fEaDnq1q7wX6PubztCuDEvn50r/+9a+rbVO+/8M73vGO08hrlmTtAx/4wJ9q EHP+d77znb5TTjklBlDwOrU9PJIGBrfRDMZl8ucPyX/sYx/7mmZy3sDMiQYkW6CRNDg6dP/9 9//ba17zmjPIy+f/q5mo3TSTc6j8fd6LXvSiv0LXMrJv6ruZN3o2o1M9FScD0tlmsIKNlHq+ Lq1QYPFA8UDxQPFA8cCO7oEyE7Gjt9Dk6tfzDj1aOjKsD3K/SIdPb7/rj6wp7q53vevl6qz+ U52tW6gTuZ/e8g+rAxgd98lVp69P5Vxx3nnnvTs/9A3Cj5t29Gb6LH1z8Gt1Qp/Nsha9aT98 n3322dyU01KVS0y78Y1vfLkGHfs5b6iO4/EsSVHH9THqQF4PnIPvCTQY+j8tP7lUy3ae9JGP fORe6sz/QuVcjK54X9Sg4oZaXvNsdSxXahbgPHUc6/JsP4dTsadZnbWPetSjvqZlQPfXG/D/ Vuf4T5rluZqOrmZJtqqzXw+c1OlfpLpfSpl6432Vlt2wdW/f0qVLN1x44YXLtQxqFT7Q0ptL NStwj5vf/OZnw2fWSIOhz2ogcNRuu+321gc/+MEP0UzHYCc6OiR921Kfr/x0hWYOblhxql8t n9pDy3P6NRvxfM3KvJFDMxirNVCIZT8s0RK/T535K1784hdHZ1z136p6Xp/lQ/L1a3/729/e PLepcq5yXrMpw5phuYi8Psjv08CoftExUdtrOdoel1xyyT6ulwaiL6OuGvjU/sSu/Lab2jbK IK+Y+6di4w+i766YOh8aiXZS7G9WTMT3QZ3qySxYXs9Ku+W35+uyRatkigeKB4oHigeKB3Zg D5RBxA7cOFOoGn941XPSUpM/603xhU984hNbvhvAwJFHHvlbvW2+ld4yH6RO3e9YKjObSYOM xfo24ZvqBL5Ib8O/oM7roarfLZtlaraiXuN+2mmn7aNO8ZqmjN7wf/9lL3vZ57WO/ocakFwK zqEPpf995plnrvjqV7/6BXXOX6LO+tu0jGmhvk+4mKVEixcvHtHMxztUxkt++ctfnqTB1Z4a UNWdzWY55KdiT53SpVpmdIYGKq/W7MOrNIi4QB3tGMjoe5ArtLxmN5elpVa7aaYk6qC3/heq w74Pb8Y1O/AdfT9xF53r3eWnkzRgeriWfq387Gc/+310eeP/iEc84jzK0PKkt+s8F2hQcb9O dJenQVftX5W9jzrOLf7V4HKjYmFUdXylfPZiDvngpZqF+Ck21Ha3ofOvQcU+GqDGAES8/bRM 7e5q3w/gdw1oTkXGSfZ6ituJ2l7fN2zSQOuvrhfwV7/61cs1MLrSZQFpb3xlGt8G8U2NZicu UvytMl26u2hJ1Ja73e1ul0HrtZ7Wz2BP55fJF7R4oHigeKB4oHhgh/fA7PYMd/jTn3MVbFmv 38vZqfP0Ra0Fv1NTVh3O3+kN943VUb+1PjT+bZPfa15vaPvpNDcP0VtMaE35bfTB98O1pn9E HeIz9ab4fL1132YZiDr3B6lzOKABwEL9P8KttCzpXAzxXwlsjQr+mMc85l9aMnSuBj//1lvp TeAckl2vJSxHqhP7IOQ0SNpdy30O1C5If9bb5DHpPe3Nb37zjeFphuD2mhn4lzqlG8l3SlOx p3L3Usf0BXzMy6EZkbscddRRsZyH9fzf/e53D2PrWDq3evN/6B3ucIe/U77W6I88+tGPPuXe 9773o0W7TN8+vF/8/9WM0tkaXLxVsxAX6BuO6ARrMLRYg5MXMTjTR8EXasvd36kTvrQT3een LWNvA65O/556M38DLWuLJWIaHNyaHbu0hOlyDdyuUhvFh+B8R6A39i/T7lB7sdRJ+g9Rfb6g Ac+3NbiJbyr0Ufre8uW/Zesy2k5L0A5mtmKyqVPb284973nPsxSzBxAL0NjWWLRnMgBmQMDS Pehq5zO0fO7GfBuhncr6FRsPkf9WKM7/pGVWN4GOnM7lFtqC96/oTzNN+rqcZnlFvXigeKB4 oHigeGDWPVAvFZj1kkoB28MDXd+at6sAa9/VgT1VHdeW2Qit1V+rjvw/9CZ7VfP7hXZ2OtG0 U9De2nr0LU2+lp48T8tT6rX/6uD9Tp3Re2hnqFerk3q1OvUjWvN/mmYNWvb/Z4ckvQ1/hdbc L9Tb+/9oV5x48y651R/+8IcfpI+G/9QsK8+rw/hzfSPwWP4L4qKLLrq2BhAn6011LKfR9xDf 0br4h2hd/hZ1dpdoFmbCrWWnYo9vN7Te/u9advUsvZlfobr8XXX/BfXUEqdT5fsbaznQa9XB XaqP3H+af5OgD45/ryVB6zQIeaLO/zKt4b9Eb/1XadZkdw0azrz97W8fb921vGm9BhVnqBP8 hute97r/UDnLZOdLnej2kQZV+8vuIZqx2FWDle8xAIGnpW3HKh7eq+Vd52i7289owPY4fWx+ FHJa2vQ9Bm76FuNRKut8fZx8hvx3pup2qP4D4x76vuTUL3/5y0ep3V6gwdEifb/xK33vcJQH fS57Itip7a2nGbV/qM1+rIHOK/k2glkmfSfxP/D1wfj1VY9jNFg9XYPVS7Qb1Bny4Ss0aL1a /rxQ39WcLvtjitW/afbplarrBfLZSg0kPmz704CTvi6nUVZRLR4oHigeKB4oHtguHhhfU7Bd iiuFTNEDvLbtqa30hveBkp1wm9cp1mNW1Vhqo8HMnlpWso716M3CRDtWndhz+Q5Bb9SX8AFx U6bXvN6G766Ziqv5NiTX4U25PmTejcFVTp8In4o9Zmf08fNgu3Plbbre3rM8p+NMCPr61mAP DRwu01r+tm+79fH5bldfffUCPoDOz6EdXX8U+C7NGrxUMxZDGjBs5BuNXCfH+QhcA4E91Rm/ moFJzuuEa7ZiDw2KrtDs0ChLsrT8aFjfa7T4P9fVrk/6Xvu9T4M2mbbXQGiZzmOVBgsXMXuT 28xx/KdvUEY1iKsHs/D5k0HNdC3RIOoSBha5zhTwC7V06+Qp6BWV+euBnu/389dF5cznoAdK 3O+EjdpTx3QnPK+5VuWeLy4NInbRyR+jY87NMrkjqZ2lfjbXGnhHOB8PInodFEy3zlr+tJtm K65WR71tR7/dIGIna3sGSJ/XIGLKg93p+rjo75Qe6Pl+v1OeXal08UB7D5S4b++XHZo65zqa O7S3t0Pl6LBoIMEWl0fpmFPtq/Xtf9Ab91iusx1cOe+K0Jv772g5WcfZh5l2iD64fgW7GunD 8Z/r37t/ppmllm1/8/J2wrZnAPHDMoDIW7HgxQPFA8UDxQNzyQNlJmLnaM1Jj9DTjAQDiZ1y adPO0SylltPxgD58fqv+Y2GJOtoj+nh5WEuL1unj95/oG4tf6ZuE9flMxHTKuQZ0+Y6kDCCu AcfPkSInfb+fI+ddTmN+e6DE/U7Y/mUQsXM0GhfXlJL25u9Th4z/FYh996dkpCgVD2wnD2gw sUGzE0v/P3tnAm9T1f5x8zx1cemWWZR5SqKMIZXeEhEiovQm8ja8KWN6NYgGmmdSKlEoY1Ia EDJFkXnmmuf5/312rfs/Tveee+69OOfc+zufz7b32XtN+7vWPZ5nPc+z1ty5c4kTv4rT3Ksu UNUprcb+Ri0uZRtK0a6UFqb8aZqAhKk03f1p9uU17tNs1+vFzzeBZCsR57thKl8EUkDAVsWy sX2CwwLpbSnbhzjyc9hH4/4vDvo3bRHQuE9b/a23/YuAxr1GggicJwL64zpPYFVsSAnYjuQ2 e/8Gh7c/hV9rNO79gOhrmiCgcZ8mulkv6UdA494PiL6KwLkioD+uc0VS5YQTgeI0JkuABmnc B4CjR6mWgMZ9qu1avVgAAhr3AeDokQikhID+uFJCT3kjlYDGfaT2nNqdEgIa9ymhp7yRSkDj PgJ7LkMEtllNFgEREAEREAEREAEREAERCCEBKREhhK+qRUAEREAEREAEREAERCASCUiJiMRe U5tFQAREQAREQAREQAREIIQEpESEEL6qFgEREAEREAEREAEREIFIJCAlIhJ7TW0WAREQAREQ AREQAREQgRASkBIRQviqWgREQAREQAREQAREQAQikYCUiEjsNbVZBERABERABERABERABEJI QEpECOGrahEQAREQAREQAREQARGIRAJSIiKx19RmERABERABERABERABEQghASkRIYSvqkVA BERABERABERABEQgEglIiYjEXlObRUAEREAEREAEREAERCCEBKREhBC+qhYBERABERABERAB ERCBSCQgJSISe01tFgEREAEREAEREAEREIEQEpASEUL4qloEREAEREAEREAEREAEIpGAlIhI 7DW1WQREQAREQAREQAREQARCSEBKRAjhq2oREAEREAEREAEREAERiEQCUiIisdfUZhEQAREQ AREQAREQAREIIQEpESGEr6pFQAREQAREQAREQAREIBIJSImIxF5Tm0VABERABERABERABEQg hASkRIQQvqoWAREQAREQAREQAREQgUgkICUiEntNbRYBERABERABERABERCBEBKQEhFC+Kpa BERABERABERABERABCKRgJSISOw1tVkEREAEREAEREAEREAEQkhASkQI4atqERABERABERAB ERABEYhEAlIiIrHX1GYREAEREAEREAEREAERCCEBKREhhK+qRUAEREAEREAEREAERCASCUiJ iMReU5tFQAREQAREQAREQAREIIQEpESEEL6qFgEREAEREAEREAEREIFIJCAlIhJ7TW0WAREQ AREQAREQAREQgRASkBIRQviqWgREQAREQAREQAREQAQikYCUiEjsNbVZBERABERABERABERA BEJIQEpECOGrahEQAREQAREQAREQARGIRAJSIiKx19RmERABERABERABERABEQghASkRIYSv qkVABERABERABERABEQgEglIiYjEXlObRUAEREAEREAEREAERCCEBKREhBC+qhYBERABERAB ERABERCBSCQgJSISe01tFgEREAEREAEREAEREIEQEpASEUL4qloEREAEREAEREAEREAEIpGA lIhI7DW1WQREQAREQAREQAREQARCSEBKRAjhq2oREAEREAEREAEREAERiEQCUiIisdfUZhEQ AREQAREQAREQAREIIQEpESGEr6pFQAREQAREQAREQAREIBIJSImIxF5Tm0VABERABERABERA BEQghAQyhbBuVS0CIiAC54XAmTNn8lNwYY4cHOnPSyUqVATOA4Grrroq3dy5c2ueh6JVZMIE zvDoMMe29OnT70o4mZ6IgAj4EpAS4UtD1yIgAhFNAOUhLy/QkCMmol9EjU+zBK688kp7d++f NAshhC/Ob8gWqp+JMrEvhM1Q1SIQEQTkzhQR3aRGioAIJEaA//wvI00bDikQicGK4Of79+/P +MUXXxT6/vvvLzpx4oSsTBHcl2HadPv9aPP370mYNlHNEoHwICAlIjz6Qa0QARFIAQEfC0Sc dbVgwYK9H3zwwRpWbLFixXrmyZPnye3bt2d21ezduzcTs40jfvvtt5zXX399c9I86J65c+XK le+qWrVqR/vuymvZsuV1GTNmfMkO8r9sh/t+0003Nevbt29FK9f/yJQp0wuu3MTOr7/+eon8 +fP3TSxdsM9N2L799tsblixZsnu1atU6DB061BQu7/Prr7/mvvrqq9uUKFGiR4MGDW795Zdf 8rhn7lyrVq02H3/88SXue3LLs3rLly/fpUyZMve1bdu2/unTp12R6Z544omKlSpV6sxx19NP P3153IO/L8aMGRNzxRVX3HPttdfeCZ8re/XqdWN0dHSfG/hYX/qnt763OnzvB6r/3nvvrVW2 bNl7rQ20pdLBgwfj/f8xsXa6+oIpzzi2aNGicenSpe+H8R0DBgyo4PLrHFICNp4a/v27EtKG qHIRCGcC8f5IhnOD1TYREAERiIdAQ+79Q5D0TXfs2LFsHTt2vN73nru+++6752/YsKHk4sWL c7l7NuO9YsWK8rfccssv7p6dx44dO+PUqVM97bjmmmu+x/1kjvs+adKkyZamQIECWxFAuvse J0+e7GXPgvm0adNm48SJE4cHkzaYND169Kg5e/bs6vfff//UJk2aLO7fv3/H0aNHe0pB69at 22fIkOHMwIEDx2fNmvVk8+bNux05csT7v6Ffv34VTLjFR/8aFLDsrq7klLdq1arsjz/+eNe6 desu/c9//jPlp59+qgTbplbmiy++WPqll166A2VmeefOnX8YPHhwu1dffbWEq++5554rM2jQ oBs+/fTTj6ZNmzaafL9Nnz59DNcvXX755dvRI25zaceNG1fYykXRaLl+/fqC7n6g+h966KFq KEk3NGzYcFGXLl2+e+utt27kHa92ed05sXa6dMGWB/vr5syZU+XOO+/89uabb170zDPPdEAh csXoHFoCniIR2iaodhEIbwIB/9MN76ardSIgAiKQLh2CugVRJ+rCdOONN874+uuvr+OYg9C5 05ddq1attiL4b3v55Zcrv/POOz/aM4TasgjXpxAIf/dNe66vURgafPPNN7WPHz+epWnTpt8j KH+DgFzwqaeeaopS8z7CZbOLLrroIEJ3ha1bt15avXr1hVOmTBmfPXv207S31AcffFB7wYIF o1y7vvrqq+g33nij6oQJE6a6e5RXA4F1Ju+yyu5RXwWE5spYJfauW7eu1LfffvvOJZdccpxZ 8c1wuNbKwOKybcmSJTEoFscyZ8581JVl5+SUN3XqVAwhJVe99tprc62MnTt3zoDxrVxOfffd d+vSJzNo9xx79tlnny15//33a/373/9eawoNwvu/UIJGwChDlSpVel133XVzUBYq8t6VKOcp rCjX7N69O1NUVNTJpUuXRu3ZsycnzHZbWe6DIlI1ofop+3KsSN+6tmGN+Qkm1cjrjQVXRqB2 ujR2Dra8P//885IHHnhgYu/evb0x9vbbb2/ctGlTWd+ydB1SAjH2+4JVUcHWIe0GVR6uBGSJ CNeeUbtEQASCJVA4mIQIyXtwW5rBDHOr+NLjJjP/u+++q+KeYQmojCvToly5cv2/z417mMj5 6NGj2Zhtr+57IBQX8c+GoF8Igf5q6hrBTPvIyZMn1zcBfteuXdkQJr30GzdujMaV52asCNMp YzjuV1cwU1/eysJF6jQC/knfclevXp170aJF5XzvYSnJmCVLllPuHu3LiuWlMEK5xRSkN4XE nh06dCgjaTMhRHtMiT2YBpNxPLeVa+I+ySkP150MtDWuDQcOHMiCsB9tSgKKQIEaNWpschUU KVIkFstHtH2HSXShQoW2lypV6ggz9dWx/CwdNWrU9xdffPHe4sWLr0PRS5czZ85DCOQ5LT1W luXWZlyfVtp39wlU/4gRI77C1SlOYYBfKdyuVru87hyonS6NnYMtDyXtfVMgUMryd+vWrRZ9 Xrxo0aK+Rek69ASC+n0JfTPVAhG48ASkRFx45qpRBETg3BKwZVyD+iCEz4yNjS2IW01l/wwI 6QvWrl1bxtxecH1Kz4x2JWbv5/unC+Y7QnqO8ePH1/E9EBRL+udduXJlXgT33Aj+uVBuVjNb P7RChQr7/dOx7OdcfPz/NOsAbZpGWZ4SYTP1uMN87J/e/3u9evUWoog0eO+994qa3/0ff/xR zhQJYj4OolytJ17iJiw0Bdu3b98Mt6tMuHJl9S/D93tyyuvZs+di3rfsI488UtXiGzgsJiKD xTOgTEQRc3LU1YEgvQcFx2sDMRsFCxcu7FkVZs2aVRVryTJLt2zZsmK0Y4XFVZjSVrNmzYCr 6QSq3/KilBy3mBmLD8ENqvhjjz32k2uPOwdqp0tj52DLc3lQJJrhQtXG3OCIr3G3dQ4PAkH/ voRHc9UKEbhwBOTOdOFYqyYREIHzQyDoFXry5ct3koDcscOGDWvdqVOns2aqGzVqtAthdQOu MxUvu+yy3czyn0Sw/zM5Taae3SgkLyeW9+GHH16J8D6XtvRCiTlIvMDczz//fIp/PoK+d7h7 BP/uwuWpsfvuzgQEd8LdKQbhO/Phw4fzIJQ/Yc8Q2j8jUHkesQ7FcZ3pljdv3t0Iyj/houFl 5dlY0rTBpasms/fLsQKsRbmIq8+V73tOTnlYdQ60a9duAi47NyMwp2/cuPFshPICJrxjJTmx efNmz5Jg9RDUnJX277Rr+mIv7luV7DpHjhyHt2zZkgvXrnwoXqVQor5DqWiC4uW5aVmahD6B 6rc8xLoUJjbmPt5/A5aYZ+B8lvXF0gRqpz33/QRTnks/f/78D1FgPiH+pBt1u9s6hweBoH9f wqO5aoUIXDgCskRcONaqSQREIAwI4O7yG+4xW1g9p6l/c+rXrz8f96IqWBAq4zaz0FxlzucH RSMbsQlf7dix4zHiFT7Fl74m7fMEZt96sVZkc9+JA4jBxeof1goUgel9+vQZQwzFTJSYnXZt B8rD5uXLl+f+8ssvP0U4fxxh/XkUjSzEB2w3V6Js2bKdwmVqGHU8/vPPP4/GZScahWqbqy++ c3LKw/qRo2vXrstQHAZifRiAdWUjisJ2K98UmzVr1kS5unC1isJVyWsDQdJbcPOJwTqQ7b// /e8U4hIa8K6N4TSalbBa4/qV56OPPpru8iZ0DlQ/SkoBAqq7MSbGY+F4Jz4FwsoN1E7feoMt z1apMoXI8jImT6BELsIK5FuUrkVABEQgbAmc3/8hw/a11TAREIG0TICA5LE//PDDtf4MiGFY yAx3WQT1qh06dEiWK5OViYtNehNa/Q/fJU0tHbEN1Qj4bo1P/ykEYrMCrMfd6h/uEwj3lU3g RwHIwv4IVbAYeP76tleCLTlqZbHCzyZcdlaj/GwmhuGoXdtB2kNPPvlk/dtuu62FpUNJyk9c RXlWQfoNa8sZ8nV/9tlny9oz/PJrYxnYxOz/Efue0Cc55VFvIQKiH+X9MtuBNaIBqyEtsDqw jCzBlauWLXlqblU//vhjzTp16qyxZyzNewo3qxnNmjVrz71YYh9e5flnWJRWoVwMwQqxkdl7 TxC39Al9AtWPsnU9LkgLUOR+M5cmOyxQ28qy5XbNDcyuA7XTN12w5aHAHUEZqmsuXVYn/VmV 5V6tKn1EQAREIOwJyJ0p7LtIDRQBETjXBAiwjkWAnYXgepY1gpWPDiDIr2O2PN9dd921Mbn1 IoAWZunR5/zzsxLSw7gmxfn+E5uxEDebJvjCD8S6sA+h/hRLrS7AanCJb15bIQlXq34ENGdh 9n4rQq0380664m+++WaL//3vf0t90/tfo0z8iOtPB9sLYtu2bRejQIxneVpvLVHiIaY8//zz LVkp6TiKSnasMIkuLZuc8ix+g2Vb1+B29SAWkdy0ZQ1t9+IOcHGaBfuyrKg0iHiUHAS5z8bq 8Id7jyFDhvwaExNzECXkXt4/lpiJHQjd+bCa5Meisbx27dp7XNqEzoHqxyJUAsWxEIzjxgOW gQ2weo4Vo+riRnUEl7MNgdrpmy7Y8swdi1iXey+99NJatPsMCsRKKREJ9aDui4AIhBsB+fqF W4/E354z3FZfxc9Gd1MvgaDGPUsw1gTBlZGKwfajQJmJRng8aH77/u/BvY7EKKy2OATcjrIn FkDsn9/3u60ChKVin8WG+N43KwcrGkWZcuV7P7Hr5JRn1hliNjLG965mWcEScjSQJcTy4wJU AMUhNiG3o0DtDlR/oHy+z4Jpp2/6QNdm8Zg5c2YBXOl2oUye6N69O4s7jegeKI+eXVACvxA/ NO+C1pg2Kwvq9z5tognft5ZgGr5949sy/XH50tB1WiEQ1LiPdCUisc50SgQrS/2QWFo9j3wC UiLCrg+lRFyYLgnq9/7CNEW1BEtA7kzBklI6ERABEQgBATagW8SMe6LuOiFomqoUAREQARFI wwSkRKThzteri4AIhD8BNlhbHP6tVAtFQAREQATSGgGtzpTWelzvKwIiEBICFvsQkopVacgI WJ+z63chi6GwladC1hBVLAIiIALngYCUiPMAVUWKgAiEngAbgw1htaMXMmfOPNQOllEdzLr8 3Uygu9CtY6fli9gZekB89bLM6xUEbg537bQzgc/9WYnoFgt4ji9PMPe++uqraJaN9ZZ/DSZ9 ctPY0qb58+fvm9z8/vlM2GbFqIbsY9G9WrVqHYYOHXqZS8Pu1bltR2lbZapBgwa3srRrHvfM ndmwrQ17b8StbpXc8qze8uXLd7G9HNq2bWu7a7sq0tmyuqwy1ZnjLgLeL4978PeF7cjN0rr3 sMrUnfC5kuVob4yOju5zAx9bztU/fWr/zngeMHr06Lg+Se3vq/cTgbRCINn/QaUVQHpPERCB yCXwyiuvvIQQ+ZAdbFbW/+jRo9nuueee28PtjVjeda9rp50Jon7922+/rffoo49WT25bWTmp CMLsP/bCSG55CeVr06bNxokTJya6LGxC+f3vs0t4TTbdq84O3lObNGmymH0UOjoBtHXr1u3Z APAMy+COZ9nbk9f/n7YAACAASURBVGyk180pWv369auAAnHH3Llzr2H51+yu3OSUt2rVquws v9uVzd+WsnfIFFaDqsSmd97yr+xoXprlcO9AmVnOUrk/oAS2Y+naEq6+5557rsygQYNuYFfx j6ZNmzaafL/RF2O4follf7ejR9zm0uosAiIgApFMQEpEJPee2i4CIhA0AVs+s169egv37dsX N3t999131+F+HzvatWtXzxU2Z86cvCy5ej+bgT1Xrly5Lm5m22a+zZphVg5mlh974YUXvFny CRMmFKpSpUpHNm6rxz4QPa2cAQMGVGC50kc5HmE/hCqu7GDOCJ7b2TtgPfsUeG1NqF6UjSI2 I+7KtE3RbDUnaw/XzVGcSjAb3sqe2+w4bXswd+7cg9iTob3tAO3ysaTqfZbHffc9mxUFq8i/ UG7SozA0YJ+GJ9i5eSDWgkaWDgG54H333XeLXbNbdrOOHTtea+WhGP0P3rc5IZ8N/kpR752W zn3MWkKeuL0Z7D7l1UBZmMnGb6ssHoQZ/RXwr7xixYqc7LNRCuF8PBsBbhw7duxXzOoXsDIs 35IlS2JsPw0sOXH7cCS3PBSBqlhCVr322mtz2YBvLeNkBopEDSuPHbProgjMYF+IOezx8Cf8 l9APts9DOntXlIx/wXK0beTHmOjFxnhF4HYDy+f2YD+OBWwYWNhtZIcyUgpW/2ZzwGcqVqzY mY0OPeUnofs2th544IErbeyxp0Y/9tKId1xt3bo1C0sBt7W+ZufvHuxvUcza16pVq0bW93Zt H8ZKB/aquMquUXzKWfls7jfIxhAbEua0+7S9oeWz9plFoWXLltfx3tWpvy/t6O024gvU91aO +wQahy6NnVEUy5uFy96BMdzSNii0+2b5sTFof4NmKTLrlN0Ppp02llu0aNHYxpLl0UcERCBl BKREpIyfcouACIQxATY1y2wClR0m7MyYMaMW+yQssyabSwqCaBNmmj9nJvndKVOmXMustSco IjR1ZnOz7aQfzHknadpZHnZ97oxQtgUBqx+b0U3p3bt3FzYpy40wm2X58uWV2AW7cpcuXabb XgTMUHdC+FmAoDee3ZI9Qc3KSOCT3rXTZsFpWyWEzaIIPL9b+gD1ZiVfYVcm7ciK4lGIPQdi 2Qn7OxSYzcOGDZtqCgObpfWwHZcRcM3F6xRCbQeXj+8nMmbMaEssxn3MnccUKKwBj8Mxhwnr vMfVWB1GIHCOnDx5cn27t2vXrmzsHF3EMrKPRTRC4s1YEaYjWA+H0xVwKG/PEKpPU89Z+1Mg NOdetGhROXvuPmyolxEB8ZT7jvUo64YNGwofP37cYgrSI3B7fkWHDh3KSNpMKFje+xN7MI29 Lsbx/LDLa+fklIfClMEYuXIOHDiQhQ0Io01JYIO7AjVq1NjknrE5YSyWD0+RgUk0m9RtL1Wq 1BEUoOqMtaWjRo36nn7Yy7hZhxUlHW51h9h12xNi2STw9q5du86YNGnSENvlHMWprpWb0H04 l4B5rZEjR77NOJuIwtI2vlgblJw7aHNO6h7BGPqRZWPvtzGJYjuHPqmAlaUyY7r6mjVrSmLp WWiuWih5tzJGvsEK9Ky14eGHH25gZ8ZXPsZM08aNGy+mX8d9/vnn/+KoywaAI1GAVtO/N1q6 QH1vz+2T2Dj8K1W6dCbsP/XUU52pb7y9A+0shjJXn7+vfLxDZzh9jvIwAIXnIMqspxQF0076 4djKlSuLsu/KQJSsds7C5erVWQREIGkE0pxvZtLwKLUIiEAkE0AQ6skR9woIcPsQjmfZDWa3 67J86vcIVCvsOwLgLFxOqiGkbTBhbfHixcOjoqJOIhR/jdvKMQS9gghKJRGyXmfG9iiz1Ys+ +eST+sxIV2D3500nT57M9PXXX7/DzPkh3JCqEAOxnlnzb6xsFIOZCH7N7doCbRHwvFnVW2+9 dYvdQ0jPh7IyzK7dh3iAuXfcccdmykywXoT8nS697xnh6hSzxPsRxo8jyO5HUK3NzHEs7zLT 0r3zzjsTmEEfjOCVBcHqOArQ23YfYTgzPGoiNNZj/40MzZo1mw2PD4lBOMosehkE99wI/rlQ tlYjSA/lHY/CxBOILb992EF6rs3Q2zUuWdOwLJRH6VhqO0bbYfcDfcxaRDsbwHE3QmcehN9y COCrEfwOGlOExpsQgH/ECnS1MUeIznquy2NH7sUoXM0feeSRqszcb6c9FhORweIZUCaimAk/ 6upk9+w9KC9eGxBsC7Lr9W57hiBcldn0cXa9bNmyYrzXchPWzaXONgykzzOw6V5uhPpCcPmT fh6N4pgNobl5fPetHPsgQH9lmwLaQT/VxFpS2nd3b1NCGbvVUfgGEDey26xa7EJehw3syg8f PvwXFIXxuPndhnKVAWX1Q5SeE9bvxM+MsX41pQTOO3///ffiXoX8A/tFKKML7DtWkgOM29ko Mevhn+Gxxx6LU0YT6ntXDopBtUDj0KVDOaqJJfCPJ5980lP4Yf4Z1oMoxmBNeK+lTk+5Rvn/ ir+Tp51VLbF22uaE9MU7ZtljTNZBMenGRMAuLF/fUddip6C6dugsAiIQmIAsEYH56KkIiEAE E0BwGoZA1sMOdgXuRwDzaVxvmtgrMYNe8Msvv2yK4PC0HR999NHNCPe5cYuJwl1nlykQls7c oBDWpixduhTvivzbTYGw+/ZBmMTLItZzpyDPblMg7D4uLGXwf19j1/ZhZnidd8E/CPR3447z qB0I715eXH/2uHbSrgdRQt5euHDhVeauhEAYsF5Xrp2ZrY/3Nx03oAI7duyIce+KAtAHJSE9 AudZCgBCWK9x48Zdh5D2Ge/1FALtd6ZAWNkoYyuJOZiLENrL3FqYab8axeeYPfP9wGeH+47Q tgulo5T77s4oMJ3MJQXB9U4UmSJ2bYfFE9jO3ChAO3Hb6fbWW29djzD/E/Vst7w8G4tSURJL US8EyzxYAdbS5rj6XPm+5+SUhzvPAdzbJuAGdDNy5j0Ix0vpo32mcKGYnUDYj+OGMpCVtnvK HDPze+GW1+rPkSPH4S1btuTCDSqfMcD1ZidWgSYVKlRYZc8p7zTK0EeMrYaMtSFYm1pi6cAg lDFdfPctj31QWOPeF067UWpL/vXkr38ZewWsbxlzj7j+RikujqLgjTVz0eJ5OoT53QjQnjBO +0/QzqIMtL6wHjR//vwKvmVSz173HWvKSRTTbfbdrEt84iYjE+v7YMch3KLoW68Oq4cxt8GU du7nZ0ytt3v2sX6iDccYE7nse7DtNMUa7pPpq36Mpe9Qrlozzu60MvQRAREInkC8/+EEn10p RUAERCDkBM5yw/FtjQk5CFLeYbOyHD/gGhNjaYh3OHrvvfd+iuDW2w6E2cdRNF6rU6fOdpsJ PnbsmLnPmJUgg/mhk3cr13ktNsDu2wfXoWhclv4xu85MbixCe76/UqVLh1BW0F3jDjMYIa6H HTYj7e67dpry8uyzzy5CedlMkHBMYvWawOjKwO3jIhMQ/T/4lR9FwP3dvaudifvoi0B61iZ2 CM4z4HIYF5U2tiIRwm9cgPLatWuzYb35ivd6jNnwTxFea+IKU8m/LqwVcbEWuHrFICzv90/D DP/0Pn36jMGPfiYKyU67toNA6c2mWKHcfQrrxxHWn0cxykJ8wnbanIG2ncLyMYw6Hv/5559H wzK6UaNGccKmfz32PTnlIZTmQNlbhqIyEOvDAJSIjQjaniJjyiKco1xdjKcoLCVeG5j134LA HmMz41gHphA/0YB3bQyn0ShMrVEQ86CsTre8NuOPpWmt1YGVaijvmRnloTkWgnTx3Xf1MU7j +NpYRnA+iy+WkCMI+qdpY3/X3zB4AkF5tpVB31VDmTarUwwWCU8B4Vkp3NQa07+vGXcUmlmW xn0smN1dBzon1vfBjkPrb2Pl6jJrnMXUYJ3Y5vt3ZbFLuJ0dJ2Yn1tIG205LO2/evLy8ZzPi lW5DOdzMeP/Z7sfzCerd48mnWyKQ6glIiUj1XawXFIFUT+AsH/hAb4sgeBDlwHM9wRXoD9yX qluQqx3EEbTHjaURK/LsQbDdhVtPVSuL5Tlr4a5SkVn4fX/f94JZzT8bQSeaoNs4i4Orm+Di Zfhel6X8Aib8IhQneZUlBK4DCHRZA9XLLPxuAsWjcBuKMuUG16G4ehCuTptgam3CbWslCsFl bnlb3I1qcK8nQpfXZAuUtWBTXL0WIqQOQYkZiTtLUWbPzXf8DoTcIigW1YizaI1L2CkE4uXM FK9nJjeHe2d3RrivbO+MApCF+qpgnVltz6xui0OxawLQN8F6NTPCm1Gejtq1HWbJwa2kPsJd C0uHS05+3H3K4072GwrhGfJ1p21l7RkWgtoIf5tQjo7Y94Q+ySmPegshmD7K+2W2A4tIg4YN Gy6wOiyuZOrUqbWMtwm3zPzXRPH0xoC5kbVv334GbmDtuRdL7MOrPP+MMbQK5WIIVoiNuNJ4 yiXKUDaUk8dMOSMoeMtNN920ECE8B31mLmH/uO/ejyVjq9k1Qn80M/PFiFnxlFiUg6pYrXKh dO5CcdtLH3nxPTZOmbHvw1gsZK5O5G9Jez5F4ZmMcuPFVGB9K2yCNGXFWt/ZOIpPGXVtSOic UN+79IHGoSkEFqthaeln7+/HYiNMmWdstIRfbqx3SxmXl9t9S8e7VGShg9/dOLZ7iX3MLY9x fTd/54/zt2NxI8Ppg+FY/1YmkDfo35cE8uu2CKRaAnFmyFT7hnoxERCB1E4g4Ey078szu3/I ZmD/FqamIih2w8f6SVwy0jODu4n4hjGWHgF1Iu46nYgdaG5xBfjfj7T7FkyNoN0Roboprk95 WalmsgmO9sz3g7C9g1nTVQiTfc0NBuHxN9/nwVyT7zBBx6VJ+31C9SIw7iaIdyVBr33NBQuB 6k8EIs/VBneW9cw0F0ZQb4fgOhq/+O9I39980m12H//0D1w78HPvhAD/vHPHMn93jpG4cOVC 0KxNYG5XZm6fRqFpAsOB9k4I9afw+V+AgnTW+v+2QhIs+zGjngWlbSsB7d7MO+mKM+vbgqDh pa7e+M4IjD8SI9ABN6oeWHouRoEYj8XEc6chHmIKQmBL2nscYTc77zQ8vjJ87yWnPIvdwN9+ DW5XD6LI5aYta2j7T1YuLk6ziJMoC8dBCLg5sETN9o1JIOD4V1yCDjK27uX9YxlfOxhz+bCa 5Ec5WF67dm3P+oMge4hxsYw+G8xKXOuoJyflfI7LT7n47rt3QqkqTbk1sGRcxPiaZgqIPSOO oCOK3QgUyz9Z7vZDFLa7ib9paOkYC9NMcbNgYlv1i+DkZfBbTttqMgPfhPE9Cze2hvTboyhH WYnfmMNCAw2d0ufqTuycUN+7fFj+1iU0Dom9KUo72qCsLra/H1aDWgbDfhbHBM8txDAspvwz uAn+gfWpP23dCLM8KBJvuvITO7OQQmGU0Fa26ABK1SgshscTy8PzoH9fgihLSUQgVRH4f3tl qnqtVPcyZk5VX6W6btULJUIg6HHPrOmtlOW5KSVS5lmPLdDVrAV20wJVfR+auwmznrl8XY7s OTP1WbBMFEB4jE1MCDELAdaLE+a77Vt2cq4D1WvLXDIjfwjh/rRv2QhZGVB2Mpkvv91HAM3J rHM+hKht8Sk/vnl9r2022AQ4Y8IsfDQK0sH43ol7HRFiV1scAjPt2f3Z+ZaZ2DWz4flRgMz6 48WmuPQ2Uw7/KP/+cs8TOienPHNrwrUtY3zvapYVuJqbWIKWEMtPrEEBFIdYC+qNr202RpgR z2wB0PYchY1QnhHd/e/bM+IlXqT/nsBikQmF4YjrV3vm/7EgcBSBaITxfaaw+D+P77v9LTCu d5trnblkYQ076WKD4kvvey8pfR/sODR+KPGnXVyOq88Co7F0ZUeJ2mHj0t1P7OzGcWLpfJ5v wa1rvM93XZ4/AkH/3p+/JqjkpBKQYJpUYqFJrz+u0HBXraElEPS4R4nIS1PbcMi6GsI+c4Ik AeE/hLAZEV21UyLiewmnRASrFMRXxvm6lwr73pTXMSgRcXFL54udyvUIBP17L17hQ0D/4YZP X6glIiACySRg/9GjSMwke0MO/a4lk2NKs+HzvogZd89dJ6VlKf8/CWBBmoI7WTAuOP/MfJ7v pLK+NwViphSI8zxoVHzEE5AlIjK6UBp6ZPSTWnluCSR53P9tkTBFIsmuTee26SpNBOInQDxO FLEI+3DD+UcsjeUIZImIv0TdPccELMZECsQ5hhpEcUn+vQ+iTCU5zwQ0Y3eeAat4ERCBC0fg 75nD8SgT+am1MIetHqTJkgvXBaopEQIEOP/A+MxMPMMXBMSPY1fmP3yz4O9vX71/fO/r+rwS MAHWYla28Ruy67zWpMJFQARE4AITsB84fUQgrRHQuE9rPZ423tdWmrKxfYLDAu7Xcti26qb4 2kfj/i8O+jdtEdC4j8D+1gxdZHSa/XGpryKjr9TKc0dA/6mcO5YqKbwJHKR5tuuy/c7r9z68 +0qtOz8ENO7PD1eVKgKamdIYSJMEpESkyW5P9S/tb4mwjeoe4pAlItV3vV4wAAH93geAo0ci kBIC+uNKCT3ljVQCGveR2nNqdyACx3ho/vdvcHi7T/sl1rj3A6KvaYKAxn2a6Ga9ZCgI6I8r FNRVZ6gJaNyHugdU//kgUJxCswQoWOM+ABw9SrUENO5TbdfqxUJNQH9coe4B1R8KAhr3oaCu OkNNQOM+1D2g+kNBQOM+FNRTWGeGFOZXdhEQAREQAREQAREQAREQgTRGQEpEGutwva4IiIAI iIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERABEUhjBKREpLEO1+uKgAiIgAiIgAiIgAiI QEoJSIlIKUHlFwEREAEREAEREAEREIE0RkBKRBrrcL2uCIiACIiACIiACIiACKSUgJSIlBJU fhEQAREQAREQAREQARFIYwSkRKSxDtfrioAIiIAIiIAIiIAIiEBKCUiJSClB5RcBERABERAB ERABERCBNEZASkQa63C9rgiIgAiIgAiIgAiIgAiklICUiJQSVH4REAEREAEREAEREAERSGME pESksQ7X64qACIiACIiACIiACIhASglIiUgpQeUXAREQAREQAREQAREQgTRGQEpEGutwva4I iIAIiIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERABEUhjBKREpLEO1+uKgAiIgAiIgAiI gAiIQEoJSIlIKUHlFwEREAEREAEREAEREIE0RkBKRBrrcL2uCIiACIiACIiACIiACKSUgJSI lBJUfhEQAREQAREQAREQARFIYwSkRKSxDtfrioAIiIAIiIAIiIAIiEBKCUiJSClB5RcBERAB ERABERABERCBNEZASkQa63C9rgiIgAiIgAiIgAiIgAiklICUiJQSVH4REAEREAEREAEREAER SGMEpESksQ7X64qACIiACIiACIiACIhASglIiUgpQeUXAREQAREQAREQAREQgTRGQEpEGutw va4IiIAIiIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERABEUhjBDKlsffV64qACIiACIhA qiRw5syZ/LxYYY4cHOlT5UvqpVIlgauuuird3Llza6bKlwvflzpD0w5zbEufPv2u5DRTSkRy qCmPCIiACIiACIQJAZSHvDSlIUdMmDRJzRCBJBG48sorLb33T5IyKvE5IcBvyBYKmokysS8p BcqdKSm0lFYEREAEREAEwogA//lfRnPacEiBCKN+OddN2b9/f8Yvvvii0Pfff3/RiRMnZGU6 14BVnv1+tPn79yRoGlIigkalhCIgAiIgAiIQPgR8LBBxXgUFCxbs/eCDD9awVhYrVqxnnjx5 nty+fXtm1+q9e/dmYrZxxG+//Zbz+uuvb06aB90zd65cufJdVatW7WjfXXktW7a8LmPGjC/Z Qf6X7XDfb7rppmZ9+/ataOX6H5kyZXrBlZvY+fXXXy+RP3/+vomlC/a5Cdu33357w5IlS3av Vq1ah6FDh5rC5X1+/fXX3FdffXWbEiVK9GjQoMGtv/zySx73zJ1r1arV5uOPP77EfU9ueVZv +fLlu5QpU+a+tm3b1j99+rQrMt0TTzxRsVKlSp057nr66acvj3vw98WYMWNirrjiinuuvfba O+FzZa9evW6Mjo7ucwMf60v/9Nb3Vofv/a+++iq6bt26LS+77LL7WrVq1SghJWTUqFGX0u8d jNedd95Zb+nSpblcOYm109JZuS1atGhcunTp+2F3x4ABAyq4/NZWe0Yb/l2nTp1Wc+bMMetZ gp/43iOh9sGmlY1X38PqT7BwPUiIgI2nhn//riSU5qz7UiLOwqEvIiACIiACIhAxBMyF6R+C pG/rjx07lq1jx47X+95z13fffff8DRs2lFy8eHGcsGgz3itWrCh/yy23/OLS2Xns2LEzTp06 1dOOa6655nvcT+a475MmTZpsaQoUKLAVAaS773Hy5Mle9iyYT5s2bTZOnDhxeDBpg0nTo0eP mrNnz65+//33T23SpMni/v37dxw9erSnFLRu3bp9hgwZzgwcOHB81qxZTzZv3rzbkSNHPJmo X79+FUwIxUf/GhSw7K6u5JS3atWq7I8//nhXhPil//nPf6b89NNPlWDb1Mp88cUXS7/00kt3 oMws79y58w+DBw9u9+qrr5Zw9T333HNlBg0adMOnn3760bRp00aT77fp06eP4fqlyy+/fDt6 xG0u7bhx4wpbuSgaLdevX1/Q3d+8eXOWDh063Etfpee9JqIYlG7WrNm/3HN3Xrt2bbauXbt2 R4nbD5MvaHfMzTff3MmeJ9ZOVwZMr0M5qIIC8i15Fz3zzDMdpkyZUsCew/eWefPmVezevfvU IkWKxNKGngcPHvyHDJrQewRqX6NGjVZcd911S9xh77pv3764Me3ap3NQBDxFIqiUJAr44xNs IUonAiIgAiIgAiJw4QggqFsQdaIuTDfeeOOMr7/++jqOOQidO31byKz0VgT/bS+//HLld955 50d7hlBbFuH61EMPPfS7b9pzfY3C0OCbb76pffz48SxNmzb9HkH5GwTkgk899VRTlJr3EUKb XXTRRQcRuits3br10urVqy9EIB2fPXv207S31AcffFB7wYIFo1y7bLb9jTfeqDphwoSp7h7l 1UCwncm7rLJ71FcBy0JlrBJ7161bV+rbb79955JLLjnODPlmOFxrZWBx2bZkyZIYFItjmTNn PurKsnNyyps6dSoT+yVXvfbaa3OtjJ07d86A8a1cTn333Xfr0iczaPcce/bZZ58tef/992v9 +9//XmsKDcL7v1CCRsAoQ5UqVXohJM9ByK7Ie1einKewolyze/fuTFFRUSdRDqL27NmTE2a7 rSz3gVW5bNmyHfnxxx8/s3u7du365rHHHuuK1eBL3s8Ca70PXEpgddoxY8aML+xGuXLlJtWo UWOwWawCtfOv3H/9++eff17ywAMPTOzdu7c3dt5+++2N9GtZLD276Mdrv/vuu/4ooHt79uy5 mn5sMmLEiDK05axxltB7BGofFo9lrh1m4cBi0QQF8CV3T+ckE4ix3xesiokGW/9DC0xyVcog AiIgAiIgAiJwoQkUDqZChOQ9uC3NYBa9VXzpcQWZj3BXxT3DElAZt5BFuXLl+n+fG/cwkfPR o0ezMdte3fdAKC7inw1BvxAC/dXUNYKZ9pGTJ0+ubwI8Am62TZs2eek3btwYjSvPzVgRplPG cITZK5ipL29l4SJ1GgH4pG+5q1evzr1o0aJyvveYkc6YJUuWU+4e7cuK5aUwQrnFFKQ3hcSe HTp0KCNpM+HS5DEl9mAaTMbx3FauifskpzyE9Qy0Na4NBw4cyIKwH21KAopAAQT1Ta4Cm6HH 8hFt32ESXahQoe2lSpU6wox+dSw/SxGOv7/44ov3Fi9efB2KXrqcOXMeQnDPaemxsiy3NuP6 tNK+uw9cChYtWjSujpo1a8Zincq5fPlyL59L165du7X0y1vuO+xLY5XYhhvWoUDtdOntjPL1 vikQKFv5u3XrVou+LI5VYsUPP/wQBYNjpkC49JS9E4uX967unp0Teo9A7fPNT31tb7vttm9x 0zvqe1/XSSYQ1O+LlIgkc1UGERABERABEQg5AVvGNagPQvjM2NjYgrjVVPbPgJC+AFeRMuZ2 g3CZnpngSszez/dPF8x3hPQc48ePr+N7IFCW9M+7cuXKvAjuuRFwc6HcrGa2fmiFChX2+6dj 2c+5+Mb/adYB2jSNsjwlwmbqmXH+2D+9//d69eotRBhu8N577xU1//w//vijnCkSxHwcRLla T7zETVhoCrZv374ZbleZcOXK6l+G7/fklMes+2Let+wjjzxS1eIbOCwmIoPFCKBMRDH7Hyfs IuzvQcHx2kDMRsHChQt7VoVZs2ZVxVrizbYvW7asGO1YYXEVprShFARcTWfLli1RKBtxdeCm ZYL8GcbDWe9qQjfK4wF7X4tHGD58+B1wmWLfA7XTnvt/UCSavfXWW23MvY2YnBMod1FYdo74 psNispcxkMX3XqDrQO1z+V555ZWSWGbyY8H5xd3TOdkEgvp9kTtTsvkqowiIgAiIgAiEjEDQ K/Tky5fvJAG5Y4cNG9a6U6dOZ81U40++C2F1A4JXRYJedzPLfxLB/s/kvBX17EYheTmxvA8/ /PBKhPe5tKUXSsxB4gXmfv75557A6psXwXGH+162bNlduMY0dt/dmYDkTrg7xSB8Zz58+HAe hPIn7BlC+2cEKs/DF784Ljbd8ubNu5vYg59w0fCy8mwsadrg0lWT2fvlWAHWolzE1efK9z0n pzwTzJlFn4Brz80I1ukbN248G6G8ABaF41hJThCzEGcRIEYgK+3faXXSF3tx36pk1zly5DiM MpALl6B8KF6lUKK+Q6loguLluWlZmoQ+CO/HUY7i6sCqkNnc1WrXrr3HP48pNgQ930VdMYyH 17AmrLU0KtzTbgAAIABJREFUgdrpX4Z9nz9//odYVD5BYelGDMSNd9111xwsL3FtsDQorFmw ssTadbCfhNrn8uMWVh/XuB+xesS5ablnOieZQFC/L1IiksxVGURABERABEQgsgjgJvIbQcVb 7r333qb+La9fv/583IuqMMu9C7eZheYqcz4/FiSLj/tXCLiTmPEug3LTivZtYSb+LGsEM9XZ XDuIA4jBxeqs5/YMRWA6s89ZEVwvQeiu06dPn0/tPoHU23DZyf3ll19+anEPds9WY0Jh2Giu RMQJnMJlapjdt1WFmDEfjEK1zb4n9ElOeVg/chCwvMzFnDz//PNleJftVocpNmvWrIly9eFq FYWrktcGgqS3/Pe//40hSDob5ynEijTH5WsnnEazElZrBPC1uDyNc3kTOsfExOxG+bjUPSc2 Ij8xFDucK5e7b0wQ+jujCO6nfwab4umeBWqnS2NnW30Kq9fHKCh7ccU6gXK4iPoqokjtgXE2 Y4Ey6LmImcUAhWWrb/5A14HaZ/ksdoOjIpzHBipHz84tgfP7S3Fu26rSREAEREAEREAEkkmA INux+Kdf65+dGIaFzHCXRbityko+yXJlsjJxsUlvgqL/4bukqaUjtqEaAd+tcbM5hUBsVoD1 uNf8w33i559/rmzCo60wxP4IVVAAVlt+2yvBlhy1a3zgN1mgLsrPZgTjo3ZtB2kPPfnkk/Xx j29h6VCS8iNklmcVpN+wtpwhX/dnn322rD1jxr02loFNzP6f5XJjz3w/ySmPegsREP0o75fZ DqwRDRo2bLjAykWpWYIrVy1TYsytCoG7JoL1GnuGUnMKd6IZrGLUnnuxxD68asHRWJRWEWsw BCvERmI48lnaQB/edxnKUkmLOcE6kBllpAkKiFeHBSE7FzdWgrqc9hX85JNPvjC3Nktrh/Vd oHbasrzmLmZtsABulJy6ZjGwvPRTVd71V3O5gu96+vpqS0ege1WsRrmwynhWl7+/26MEP4Ha Z5lGjhx5GUvfbmUc/EPRTLBQPUgxAVkiUoxQBYiACIiACIhA+BMgwDoWoW4WgutZ1ghWPjqA IL8ON5t8uJ5sTO6bMLtcmKVHn/PPz0pID/sGuiK4LmR2ugk+8wOxLuxDqD/FsqILsBpc4pvX VkjC1aofAc1ZcPPZirA63Z6Trvibb77Z4n//+99S3/T+1ygTP+L608H2gti2bdvFCNTjXXAv 8RBTsAq0ZKWk4ygq2YnjGO6f3/97csqz+A2WbV2D29WDuCvlpi1raPtPVjYuTrNgX5b4gEEI 7jkIcp+N1eEPV++QIUN+xZJwECXkXt4/FkvNDoTzfLgk5SdeZHl8Lkkurzubu9odd9zxxa23 3vpf3JKOobjtR3l40Z6jWBR94YUX2qDULeZeSQLbL8YS8rzLa2eWk+0fqJ24ENXF3eoIrmkb zM2KeIp7L7300lpkPcN+EStRHBZaOazENArFrQdWjWuJ5chJQP1bzhqC61RHVuOyZAl+ArUP ZcRWf7qM+jz3qwQL0YNzTiAon6dzXqsKTCoB8+9TXyWVmtJHOgGN+0jvQbU/OQSCGvcswViT wq9MTgXhkMf2o0CZiUbwO+gCen3bxb2OxCistjgEZtKzJxZA7JvX/9pWC2KGep+vi46lMSsH KxpFmXLlnyfQ9+SUZ9YZZt8zxveuZllhpv5oIEuI5UdQLoDiEOtcggK10f8ZDLP+/vvvNvuf 6LKd/nnd92DaiSKZaebMmQVwkduFknjC5bWzWTisz80C4RQI95zYCfSMEd3dd51DTuAX4ofm JdYKCaaJEQqP50H9pxIeTVUrROCcEdC4P2coVVAEEQhq3Ee6EpFYfzglAh/7HxJLq+eRT0BK RNj1YVBKhNyZwq7f1CAREAEREAERSNsEWGVnETPu/1hBKG1T0duLQHgRkBIRXv2h1oiACIiA CIhAmifABmuL0zwEARCBMCeg1ZnCvIPUPBEQAREQARGIVAIW+xCpbVe7zw0BVgTLxy7ghSxe 4tyUqFLChYCUiHDpCbVDBERABERABFJIgBV4hrDa0QtsuDXUDlbjGcz6/d0sKDaFRSc5Ozst X8QeDQPiy8iKQFcQuDnctdPOBD73ZyWiWyzgOb48wdyzpUxZEchb/jWY9OcqTe7cuZ9iM7yY c1Xe0KFDLytfvnwX23uhbdu2tsu1V7QtB8vKUg1LlizZvVq1ah0snX+dtuO05fG9n5zy2DU7 t+2tYatbNWjQ4FaWlM3jyjTO7APRkmDw+9iwr5G1yz2zs+1vwWpTrcqVK9eF5Xgbsbzw1Vw/ ZN9Z8amAb1q7ZuWqdPa+vvcD1T9q1KhLiZvpYBxY9akeO63n8s3rrhNrp0sXbHk2bitWrNiZ JYTv6dixY11bftiVkRbPyf5DTYuw9M4iIAIiIAIiEO4EXnnllZcQ6h6yA2GuP0tqZrvnnntu D7d2s7zrXtdOOxNE/fq3335b79FHH62e3LayclKRMWPG/GMvjOSWF2w+hNWhrPLkbSIXbJ6E 0q1atSo7y+B2RUhfyh4eU1iVqRKbz3nL8rKbeM3Zs2dXZ6fvqWyot5h9GTqyiaC3NO64ceMK Wzr2bmhJvxd05Se3vNatW7dn48EzLL87nuV2T7L7dze3bwf7idzL0rvp+/XrNxEBvjT7WfzL 1WeCdb169e5hp+75bND39t133z2PPTlmzp079yX22pjE5nvt2Jcku6W3VaNYVvgaNgpMx8Z7 pVwZdk6oftuskDK658+ffz9t+4L3i2GJ2E6+ee3a2hGonS59sOVNnDgxmn02OqBErGEp3sn0 Q2WW/a3nykmLZykRabHX9c4iIAIiIAJpgoAts4lAt3Dfvn1xs8gIdXW438cOBL04Icg2H2PJ 1fvZNOw5mzFmV2lPOLUZaLNmmJWDDb0eY28Bb/Z7woQJhapUqdLRZoLZB6KnAR0wYEAFlit9 lOMR9kOokhTICMDb2WNgPXs6eG1NqF6UjSLsu9DZlW2bndlqTtYerpsjQJewWXB7jkIRQ9se xFIwiD0Z2tsMuctns+iWx31P6GybxHXp0qU2u2uXZF+JUuT7N0uUPmMz0k4YZifwVvC7yNLA +zabubc6bRYfxShuV+r46rS2miDr6mdjtarMsK967bXX5rIR3lr6awaKRA17jpJUA+F6Jhu0 rbK4EWbEV9BPle0ZwnwUe33kZN+J3fbdfZJT3ooVK3Kyv0cprCvjEcQ3jh079is2kStgM/tY FcrZxnK2+R19v4k2foPL0tUogp41gk3ybsQS8p21nSVpW7OXRO3evXs3xMrUacuWLTnZPG8x nMpZ+7Zu3ZqNd4+GlWuudw5UP+9bgn0zdsyYMeMLqx+leRJtLWO7VvsWklg7Xdpgy2PjwKKM oQUfffTRLNtPhWVsF/K53Mox5Y1yvL8XV25aOEuJSAu9rHcUAREQARFIMwRwDcmMcJbFDhOw EbZqsU/CMgNgOz0jEDZhhvtzNkF7lxnga5nd9gRU3FI6s7nZdtIP5ryTNO0sD7s+d2YTsi0I af0QnqYgEHZhd+vcCJVZmGmuhABZGSF7uu1lgLtHJ4TiBczUjkfousryB/ikd+202XLaVonZ 46ItWrT43fIEqDcr+Qq7cmlHVhSPQgh1seyE/R0KzOZhw4ZNNYWBTdB62I7LKAvm4nUKa0EH l4/vJzJmzGhL6sb7MXcsc69CsRnEu9RgQ75DbHB3O7PgMyZNmjTEduhGmK9rmdlFuqjx2LFj R05cx+ohFB9h5noYm+XtgGNzV0F8deK2U5V4gcwuDcJ4Bmur+37gwIEsKAfRZgVg9j8jylzc M6xMWTds2OCxwCqxnH0vxqFYrHR57Zyc8o4fP24KQXq3n8OhQ4cyUncmFLvCKE4F2fhuk6uD PTxi2QMiJ2PBE+LZj+IyLARLbIyw03YJlI1PcKeaQTtLwm4tiugBOHlag+3/YW1GGXXFeedA 9aP4rqU/33IZUBRLY5XYhjvUIXfPzom106UNtjw2xZuP9WGsKTimSLNBYSPG+iIrxyw2bGbY HS4PYkmrkhKXPNeuSDgryCUSekltFAEREAEREIEgCTz88MM9OeJSExexDyFult1gtrQuy6d+ j7vMCvs+efLkWfioV2OGeQOCcInFixcPj4qKOolg9jVC0TGE5YK4nJREeHrddp1mVnvRJ598 Up/Z5Qrs/rzp5MmTmb7++ut3EFwPmfBEDMR6Zq+/sbJRDGaOHDnSE6AtsBZh2BOU2T15iz1H 2cmHsjLMrt0HP/+57LC8mTITrBcryU6X3vecJ0+eUwio+xGyj6M07Udgrc2sfCzvMtPSvfPO OxOwYAw2xQVF47i52vjmd9cWP8AuzfWZIS+FkDuf93kBd5nttDcDG8blRpkqxO7Mf9LG0Sg9 cRYEl992heZ9pyBYpsPFaBxWhYE2S49icCahOl1eO+MisxjFp/kjjzxSlZnv7bTfYiIyoKRk MqsS3xvAezdKUh4Ut3IoeKt98/tfJ6c8Nvo7aH1J/MVNKEE/IjRfbX1NoHxWrAlRvONRV0+t WrX2cn0Gi01WzgdN0bF3xRJQFd7eOEPgLl6qVKk/TCmZN29eaRTGb13++M6B6rdxaIfls/gP 3Ldux+rxiX85ibXTpQ+2PJeesVEW68ft9ElmFBfPhY1unkb/zMS9qwp/Yw1o020ooLPZmftH f+XGlZMazrJEpIZe1DuIgAiIgAiIwN8E2Pl3GMJuDzvYPbgfAcyn77vvvib2eNeuXQW//PLL pghzT9uBa8bNCPe5lyxZEpU3b95dpkBYOnODYrZ3Ci4yTPLm3+6ENnuGKwnyYqw3k0ye3aZA 2H1mnMtcfvnla+zaPjfccMM674J/EOjvxi3mUTsQpL28xETsce2kXTaD+zbuIVeZuxLKTMB6 Xbl2ZtY6XlkGF5cCzHjHuHetUaNGHzbpS49yc5bbi29ZLVu2bEw77sc9ahVCel+sCmNNgbA0 tPc0AvVHcGkIpyFYSloy4/yP1adoeKwpEPYxZcVmqbFKnOU2hdBbC45P2AGDnMQ3PGjXZvmg 7gPMjk9AWL2ZdPdcddVVS6l7n5VlO3ijKO184IEHur311lvXo2z8ZNYjr7IE/kluedQ1FiWl JBaqXlhC8mCJWYtwv4P4iOMoE3EMd+7cmZl3PIXrkrevB+PNs+6gwB22dKZAwawaFp0dzOaX xmpUEIvRjgSaG3c7ofotgSlUFoj9wQcf3ECZr3EsiMv490Vi7fRNH0x5Lj1K5kL67DHGyiSs P51d0LvtiI7iNB+l+wVc+V6bP39+eXg9Ze/v8qa2c7x/eKntJfU+IiACIiACIpBWCLA602mb 8bUD3/zdHD/gSuKtHIQv+1H89z9F+O1tB7Pyj6NovIaf+nYEo9y4pXgCj826I6heSd6tXOf1 FYQQAqNx41jrz5OZ61iE9nzuPkJUXHAvguZgBPgedpgLi0vj2mnKC8G3i1BeNhOAG5NYvaYM uDIIyL2I7+5r3BmXoqPEIPzu3tXOxC30xYLiCbtxCX0u2rRpsxThdBEz59cjJP7LLCjusS1X i5VkLQL1QCwsQ1FeMvu6Krl0MLQZee+DMpQLrnkoc7+7Z2eUqd/79Okzxg4sJ9YnE+wa17Kf zS0MpWuZ1YNwOwAlYiMKhqcomAKGEvgpffI4VpDnaUMWLB0BlYjklAerDIyVUwjEw3Blevzn n38eTR9GN2rUaBtKy26u4+I8UB7z0387rC/t3YirWY07U3ksKUv4mp7Yka64fX1DPxVBwW2K G90YSxfoE6h+e4b1ozP9exBr0WCLvYivrMTa6fIEWx5WmUYEtNe0fKYk4tb3C32dw8XF2H1T Rth9+0re9w7ikPJidZtkVhl7lho/UiJSY6/qnURABERABETgbwIIoAedYIsr0B+4L1W3Nfvt II6gPe4ujVgJaA8zqbtwc6pq2Xr16lULX/WKCGv7/r7vOa3bmv9YDaIJ9o2zODjQLHm5bOXK lWVtCU8TzBB2k7zKEoLhAQTkrIHqZXZ3NwJalAUsm3JDsHFcPQhsp024tzbhtrUSAe8yt7yt ub5wr6ezEvC9uvm3u/bbGcVhG1aZ93nP/zGTfojA3QdwF+phrkUmjCPQP2ZB0CgbW2666aaF CNg5fPPbNQL2xcSdeHEKxFDUxDKxjd23D9szVyez9nvhvtoOlL5TWDXW2LVZPYi/KIRF4lEL 6LYDi0ODhg0bejPtrG5Un7QtrCzS5ce1qjxuZ7/Z94Q+ySmPNp3h3buj2JW1chHUa2MJ2YRS doT6lpmLmwVZb9++PTMrFjXBVSluPKAkTMbdrRnxNoVxXRpNjMSbWFY2Ex/xiq2mRH8kGoAc qH5c6i6HS0Hc6r4wpdfaYIdZBGxxAMawF2geqJ2+6YItD2UtFqWyLkHu+awu61vu/W5MrC/o s3+huAyaOnXqlSiBU2njwM8++8xz7UuobyL9vmIiIr0H1X4REAEREAERCECA2f1DCFkxFryM r/ZUhJ1uBIA+iSCUnsDfTQh83swwguJEVvzpROxAc4srwA9+pBVrwdS4cHRk9r0prk95EbQn W/yBf5XmosIs9CqW++xr7jcVKlQIKNz657fv5Du8aNGi0lx+n1C9Zl1BaF3ZuHHjvuaCxcpR fyLYe8oALlTr8VcvTExEO4KAR2NR+I70/S02wmbtEXg/cPWy0lInXLGed+5Y7r6diUU4gAvO ZJShqfi5VyYuoh6+/hl4p2XUNxjXnHUoOzkJIP/cN59dw2YXLO/GupCBOILMBJu/79IEqtOl Id5iLYL4GuIJHqSO3KzwtAb3mJ/sOYrGjzzvYKs+YRG6GEF5PJYVi0lI8JPc8ph5n/L888+3 pM3H4ZAdlsOtEqwRu7DIfMEs+38ZJ8csBgSh/EXXAItnINbmdRStOxhDpxlr2+CQwdyYbFUn xtsklzahs83eJ1Q/dZVEkb0Y5e553/wor/1RUGKosw3MFwdqJwpQUZcu2PJQrJeznK4FUw+w 8c3Y20P/T7A2MFY7MPbXERthS/3G+rYrNV/HmQNT80umgnczU5j6KhV0pF4hSQQ07pOES4lT CYGgxj3uO+ZWcWVy3tlmUc1aYHn9BR5z2WHmOJevy5Gls2BkLBMFEKBicVs6bvcS+piFAOvF CfPFTyhNsPcD1WubkTELfAiBznOjcWUieGdA2clkMQR2z5b+xLqQDyVnW3zKj8uX2NlmvfGz P2PvhyUksy1J65/HNrr78MMPG2CRGc7qTlEmyDrLh3/axL6b5QNXqIzxccT6kh9FyaxEXgxL YmXZ8+SUZxYl+j3Kf5xYeVgjstpYQZnbZd/j+5h7DwpFIeI4jqLMJcgCFyA8nUZ09y8jUP3+ aRP6Hkw7E8rrf9/+duj//FjMTvr+jbix4Z8+gr//QmzLvMTaL8E0MULh8Tyo/1TCo6lqhQic MwIa9+cMpQqKIAJBjfuUKBERxCLimuqUCCwjL0dc40PY4ISUiBA2Ka1XHZQSIXemtD5M9P4i IAIiIAIiIALnhACz09txtZl7TgpTISIQ5gSkRIR5B6l5IiACIiACIiACkUGgefPmO+yIjNaq lSKQMgJanSll/JRbBERABERABEQgAQIWY5HAI91OpQSsz21pXFsVy3dp4FT6umn6taREpOnu 18uLgAiIgAikJgKsljOE5TFfYHWboXawcs5gVhPq5pY5vZDvSmDxRQRhD4ivTlbPuYLAzeGu nXYmSLi/bbZmwbTx5Qnmni07anEJwaRNSRpWuSrB0q19U1KGb14TtlmNqCFLhnZn1+4Otmu2 e24B5Gwq18ZWZCI4+VZWncrjnrkzS+K2YafkuKVTk1ue1WubuDFm7mvbtq3tlO2qSMcu0xVZ Maozx11sBHd53IO/L9hJO4aVru4h+P5O+FzJakY3ElDdhxWzbrAAa//0qf0743kAqznF9Ulq fN9k/6GmRhh6JxEQAREQARGIdAIscfoSQuRDdrDrcv+jR49mu+eee24Pt/diVaW9rp12Zqfq 11n5ph47Rsft+5DUNrNqURGE2WuTmi+p6Vm+dCO7UHtLniY1b3zp2WSu5uzZs6uzmdlUdq9e zE7IHZ0A2rp16/as8HSGPRbGszrUSdylujlFi+VnK6BA3MEGfdewjG92V3ZyyrMlgNljoSt7 hixlE70p7IdQiRWomlqZttM0S73egTKznGVlf0AJbMcytCVcfey1UGbQoEE3sBTuR6z8NZp8 v9EXY7h+iV3Mt6NH3ObS6px6CEiJSD19qTcRAREQAREQgbMIsEfEiXr16i1kSdK42Ws2iqvD /T52sAlYPZfBNuBirfv7Wcv/OTal6+Jmtm3m26wZZuVgZvkx1tf3ZsnZR6FQlSpVOrIpWb1i xYr1tHIGDBhQgaVVH+V4hL0NvA3qXPmJnW3JVPZfWM9+Al5bE6oXZaOIzYi78t57772iLIPa 0drDdXMUpxLMhrey5zY7TtseZEnOQez90J5n2Vw+loe9z/K4775ns6LY5mEoN+lRGBqwYd8T 7Asw0HYttnQIyAXvu+++W+yaDeKasdHetVYeitH/4H2bE/JffvnlUtR7p6VzH7OWkMcTzt09 yquBsjCTnY5XsVfHYmb0V8C/sm2Gt27dulII5+PZ5Xojm9h9xax+ASvD8rJ0bQyKxTEsOUdd WXZOTnkoAlWxhKx67bXX5tou0IyTGSgSNay8d999ty6KwAz2eJjDhnl/wn8J/VDLntm7omT8 C5ajbZM4xkQvdrEuArcbWBq2B3tNLGB37cK2uaGlRxkpBat/s8P1M+xm3dnt+JzQfRtbtnu6 jT32++jH3gzxjitbDpjA9rbW17ZB4Ntvv13M6mvVqlUj63u7tg9jpQN7Z1xl1yg+5ax8lv4d ZGPIlgO2+7S9oeWz9plFgb1RrrONAqm/L+3obWPO0gXqe3vuPoHGoUtjZ9vp2yxc9g6M4Za2 2aDdN8uPjUH7GzRLkVmn7H4w7bSx3KJFi8b+Gyta/pR+pESklKDyi4AIiIAIiEAYEWCfhMwm UNlhws6MGTNqsafAMmuiuaQgiDZhpvlzZpLfZVfha5m19gRFhKbO7Li7nfSDOe8kTTvLww7J nRHKtiBg9bMN4Hr37t1lwYIFuRFmsyxfvrwSuztX7tKly3Tbh4AZ6k4IPwsQ9Mazi68nqFkZ CXzSu3baLDhtq4SwWRSB53dLH6DerOTzdoS2dLQjK4pHIXbfjmUviO9QYDYPGzZsqikMnTp1 6sHs+RIEXHPxOoVQ28Hy2IfvJzJmzGhL6sZ9zJ3HFCisAY/DMYcJ67zH1VgdRiBwjmTPg/p2 jxWYsm3atKmIZWQfgmiExJuxIkxHsB4OpyvgUN6eIVSfpp6z9nJAaM7Nhnrl7Ln7sJFdRgTE U+471qOsGzZsKMwGebYUf3oEbs+viB2yM5I2EwqW9/7EHkxjH4dxPPd2xHb5k1MeClMGY+TK YK+NLHv27Ik2JYFduAvUqFFjk3tWpEiRWCwfniIDk+hChQptZwPAIyhA1RlrS0eNGvU9/bCX cbPO9snAre4QO1Z7Ajo7Pd/Ojs4zJk2aNMQ2PERxqmvlJnQfziVgXovNDt9mnE1EYWkbX6wN Ss4dtDkndY9gDP3IsrH325hEsZ1Dn1SwnawZ09XXrFlTEkvPQnPVQsm7lTHyDVagZ60NDz/8 cAM7M77yMWaasgfGYvp13Oeff/4vjrpDhgwZiQK0mv690dIF6nt7bp/ExuFfqdKlM2GfzRA7 U994ewfaWQxlrr7tEs87dIbT5ygPA1B4DqLMekpRMO2kH46xb0lRNgEciJLVzlm4XL0pOac5 H7WUwFJeERABERABEQh3AghCPTnimokAtw/heJbdYHa7btOmTb9HoFph3xEAZ+FyUg0hbYMJ a4sXLx4eFRV1EqH4a9xWjiHoFURQKomQ9ToztkeZrV70ySef1GdGugI7JW9iJ+JMX3/99Tu2 6zNuSFWIgVjPrPk3VjaKwUwEv+Z2bYG2CHjerCo7HW+xewjp+VBWhtm1+xAPMJfdkDdTZoL1 IuTvdOl9z7aRHLPE+xHGjyPI7kdQrW07VfMuMy0dO3FPYAZ9MIJXFgSr4yhAb9t9hOHM8KiJ 0FiP/TcysOP2bHh8SAzCUWbRyyC450bwz4WytRpBeijveBQmnkBs+e1z1VVXzbUZervGJWsa loDyKB1LbbdoO+x+oI9Zi2hnAzjuRujMg/BbDgF8te3+bEwRGm9CAP4RK9DVxhwhOuu5Lo/d sBejcDV/5JFHqjJzv532WExEBotnQJmIYib8qKuTXaj3oLx4bUCwLcjO57vtGYJwVWbTx9n1 smXLivFey01YN5c625zNNgJkA73cCPWF4PIn/TwaxTEbQnPz+O5bOfZBgP7KNryzg36qibWk NIrqH3899cZadsZudRS+AcSN7DarFjts12EDu/LDhw//BUVhPG5+t9mu4yirH6L0nLB+J35m jPWrKSVw3snmecVdmbBfhDK6wL5jJTnAuJ2NErPedt9+7LHH4pTRhPrelYNiUC3QOHTpUI5q Ygn848knn/QUfph/hvUgijFYE95rqdNTrlH+v+Lv5GlnVUusnWXLlj1MX7xjlj3GZB0Uk25M BOzC8vUddS12CqprR1LOskQkhZbSioAIiIAIiECYE0BwGoZA1sOOmTNn9iOA+TSuN02s2cyg F/zyyy+bIjg8bcdHH310M8J9btxionDX2WUKhKUzNyiEtSlLly7FuyL/dlMg7L59ECbxsoj1 3CnIs9sUCLuPC0sZ/N/X2LV9mBle513wDwL93bjjPGoHwruXF9efPa6dtOtBlJC3Fy5ceJW5 KyEQBqzXlWtnZuvjlWVwAyqwY8eOGPeuKAB9UBLSo9ycpQAghPUaN27cdQhpn/FeTyHQfmcK hJWNMraSmIO5CKG9zK2FmfarUXyO2TPfD3zilnVFaNuF0lHK97ldo8B0MpcUBNc7UWSK2LUd Fk9BbTdaAAAgAElEQVSAu8o8FKCduO10e+utt65HmP+JerwdsXk2FqWiJJaiXgiWebACrKXN cfX512Pfk1Oe7YyNe9sE3IBuRs68B+F4KX20zxQuFLMTCPtx3FAGstJ2T5ljZn4v3PJavTly 5Di8ZcuWXLhB5TMGuN7sxCrQpEKFCqvsOeWdRhn6iLHVkLE2BGtTSywdGIQypovvvuWxDwpr 3PvCaTdKbcm/nvz1L2OvgPUtY+4R198oxcVRFLyxZi5aPE+HML8bAdoTxmn/CdpZlIHWF9aD 5s+fX8G3TOrZ675jTTmJYrrNvpt1iU/cJHxifR/sOIRbFH3r1WH1MOY2mNLO/fyMqfV2zz7W T7ThGGMil30Ptp2mWMN9Mn3Vj7H0HcpVa8bZnVZGcj/x/uEltzDlEwEREAEREAERuCAEznLD 8a3RhBwEKe+wWVmOH3CNibE0xDscvffeez9FcOttB8Ls4ygar9WpU2e7zQQfO3bM3GfMSpDB /NDJu5XrvBYbYPftg+tQNC5L/5hdZyY3FqE931+p0qVDKCvornGHGYwQ18MOm5F29107TXl5 9tlnF6G8bCZIOCaxek1gdGXg9nGRCYj+H/zKjyLg/u7e1c7EffRFIN3jmxbBeQZcDuOi0sZW JEL4jQtQZufpbFhvvuK9HmM2/FOE15q4wlTyzW/XWCviYi1w9YpBWN7vn4YZ/ul9+vQZgx/9 TBSSnXZtB4HSm02xQrn7FNaPI6w/j2KUhfiE7bQ5A207heVjGHU8/vPPP4+GZXSjRo3ihE3/ eux7cspDKM2BsrcMRWUg1ocBKBEbEbQ9RcaURThHuboYT1FYSrw2MOu/BYE9xmbGsQ5MIX6i Ae/aGE6jUZhaoyDmQVmdbnltxh9L01qrAyvVUN4zM8pDcywE6eK77+pjnMbxtbGM4HwWXywh RxD0T9PG/q6/YfAEgvJsK4O+q4YybVanGCwSngLCs1K4qTWmf18z7ig0syyN+1gwu7sOdE6s 74Mdh9bfxsrVZdY4i6nBOrHN9+/KYpdwOztOzE6spQ22nZZ23rx5eXnPZsQr3YZyuJnx/rPd j+cT1LtLiYiHnG6JgAiIgAiIQJgTOMsHPlBbEQQPohx4rie4Av2B+1J1C3K1gziC9rixNGJF nj0Itrtw66lqZbE8Zy3cVSoyC7/v7/teMKv5ZyPoRBN0G2dxcHUTXLwM3+uylF/AhF+E4iSv soTAdQCBLmugepmF302geBRuQ1Gm3OA6FFcPwtVpE0ytTbhtrUQhuMwtb4u7UQ3u9UTo8pps gbIWbIqr10KE1CEoMSNxZynK7Ln5jt+BkFsExaIacRatcQk7hUC8nJni9czk5nDv7M4I95Xt nVEAslBfFawzq+2Z1W1xKHZNAPomWK9mRngzytNRu7bDLDm4ldRHuGth6XDJyY+7T3ncyX5D ITxDvu60raw9w0JQG+FvE8rREfue0Cc55VFvIQTTR3m/zHZgEWnQsGHDBVaHxZVMnTq1lvE2 4ZaZ/5oont4YMDey9u3bz8ANrD33Yol9eJXnnzGGVqFcDMEKsRFXGk+5RBnKhnLymClnBAVv uemmmxYihOegz8wl7B/33fuxZGw1u0boj2ZmvhgxK54Si3JQFatVLpTOXShue+kjL77Hxikz 9n0Yi4Us3ob8LWnPpyg8k1FuvJgKrG+FTZCmrFjrOxtH8Smjrg0JnRPqe5c+0Dg0hcBiNSwt /ez9/VhshCnzjI2W8MuN9W4p4/Jyu2/peJeKLHTwuxvHdi+xj7nlMa7v5u/8cf52LG5kOH0w HOvfygTyBvX7EmeOSaAQ3RYBERABERABEQg/AgFnon2by+z+IZuB/VuYmoqg2A0f6ydxyUjP DO4m4hvGWHoE1Im463QidqC5xRXgfz/S7lswNYJ2R4Tqprg+5WWlmskmONoz3w/C9g5mTVch TPY1NxiEx998nwdzTb7DBB2XJu33CdWLwLibIN6VBL32NRcsBKo/EYg8VxvcWdYz01wYQb0d guto/OK/I31/80m32X380z9w7cDPvRMC/PPOHcv83TlG4sKVC0GzNoG5XZm5fRqFpgkMB9o7 IdSfwud/AQrSWev/2wpJsOzHjHoWlLatBLR7M++kK86sbwuChpe6euM7IzD+SIxAB9yoemDp uRgFYjwWE8+dhniIKQiBLWnvcYTd7LzT8PjK8L2XnPIsdgN/+zW4XT2IIpebtqyh7T9Zubg4 zSJOoiwcByHg5sASNds3JoGA419xCTrI2LqX949lfO1gzOXDapIf5WB57dq1PesPguwhxsUy +mwwK3Gto56clPM5Lj/l4rvv3gmlqjTl1sCScRHja5opIPaMOIKOKHYjUCz/ZLnbD1HY7ib+ pqGlYyxMM8XNgolt1S+Ck5fBbzltq8kMfBPG9yzc2BrSb4+iHGUlfmMOCw00dEqfqzuxc0J9 7/Jh+VuX0Dgk9qYo7WiDsrrY/n5YDWoZDPtZHBM8txDDsJjyz+Am+AfWp/60dSPM8qBIvOnK T+zMQgqFUUJb2aIDKFWjsBgeTywPz4P6ffl/u00QJSpJyAiYWUl9FTL8qjhEBDTuQwRe1YaU QNDjnlnTW2mp56aUlBZboKtZCyyPBar65jV3E2Y9c/m6HNlzZuqzYJkogPAYm5gQYhYCrBcn zHfbt+zkXAeq15a5ZEb+EML9ad+yEbIyoOxkMl9+u48AmpNZ53wIUdviU3588/pe22ywCXDG hFn4aBSkg/G9E/c6IsSutjgEZtqz+7PzLTOxa2bD86MAmfXHi01x6W2mHP5R/v3lnid0Tk55 5taEa1vG+N7VLCtwNTexBC0hlp9YgwIoDrEW1Btf22yMMCOe2QKg7TkKG6E8I7r737dnxEu8 SP89gcUiEwrDEdev9sz/Y0HgKALRCOP7TGHxfx7fd/tbYFzvNtc6c8nCGnbSxQbFl973XlL6 PthxaPxQ4k+7uBxXnwVGY+nKjhK1w8alu5/Y2Y3jxNL5PN+CW9d4n+8JXkowTRBNWD0I+j+V sGq1GiMCKSOgcZ8yfsodmQSCHvcoEXl5xTYc8ioIYV87QZKA8B9C2IyIrtopEfG9hFMiglUK 4ivjfN1LhX1vyusYlIi4uKVA7PTDE4iOnomACIiACIhAmBKw/+hRJGbSvIYc+v88RP2Ez/si Ztw9d50QNSFVV4sFaQruZMG44FxwDqms702BmBmsAmGwZYm44EMuWRUGPTOVrNKVSQTCk4DG fXj2i1p1fgkkedz/bZEwRSLJrk3n91VUuggERyCQJSK4EpQqhQQsxiRJCoTVp5mLFFJXdhEQ AREQAREIJYG/Zw7Ho0zkpx2FOWz1IE0ShrJTVHeSCODvb+m9f5KUUYlTQsAmLCxmZRu/IbtS UpDyhjcB62h9RCCtEdC4T2s9rvc1Ahr3GgepkUBxXipLgBfTuA8AR49EICUE9MeVEnrKG6kE NO4jtefU7pQQ0LhPCT3lDVcCtsu3je03Obw9H/waqnHvB0RfReBcEdAf17kiqXIiiYDGfST1 ltp6rgho3J8rkionnAjYnhc2tk9w2NK/azke5jAXPPto3P/FIaL+lc9kZHSX/XGpryKjr9TK c0dA4/7csVRJkUNAwlTk9JVamjICB8mei8PkG/3ep4ylcotAggT0n0qCaPQgFRPQuE/FnatX S5CAxn2CaPQgggn4WyLW8C4PccgSEcGdqqZHBgH9pxIZ/aRWnlsCGvfnlqdKiwwCGveR0U9q ZdIIWEyErQT0BodiIpLGTqlFIEUE9J9KivApc4QS0LiP0I5Ts1NEQOM+RfiUOUwJFKddWp0p TDtHzUrdBPSfSuruX71d/AQ07uPnorupm4DGferuX71d/AQ07uPnEtZ3M4R169Q4ERABERAB ERABERABERCBsCMgJSLsukQNEgEREAEREAEREAEREIHwJiAlIrz7R60TAREQAREQAREQAREQ gbAjICUi7LpEDRIBERABERABERABERCB8CYgJSK8+0etEwEREAEREAEREAEREIGwIyAlIuy6 RA0SAREQAREQAREQAREQgfAmICUivPtHrRMBERABERABERABERCBsCMgJSLsukQNEgEREAER EAEREAEREIHwJiAlIrz7R60TAREQAREQAREQAREQgbAjICUi7LpEDRIBERABERABERABERCB 8CYgJSK8+0etEwEREAEREAEREAEREIGwI5Ap7FqkBomACIiACIiACCSZwJkzZ/KTqTBHDo70 SS5AGUQgRASuuuqqdHPnzq0ZourTarVnePHDHNvSp0+/KzkQpEQkh5ryiIAIiIAIiECYEEB5 yEtTGnLEhEmT1AwRSBKBK6+80tJ7/yQpoxKfEwL8hmyhoJkoE/uSUqDcmZJCS2lFQAREQARE IIwI8J//ZTSnDccFVSBmzZp1kR2nT58OIxpqigiIQDIJ2O9Hm79/T4IuQkpE0KiUUAREQARE QATCh4CPBSLOq2DUqFGXVq1atUPJkiW733nnnfWWLl2ay7X4iSeeqFipUqXOHHc9/fTTl7v7 e/fuzdSiRYvGl1122b/r1KnTas6cOWbZiPfTpUuX2tmzZ3/mlltu6Xnrrbc+kCNHjudatWrV yCkTHTt2rGvl+Ga2MvPmzTvwm2++MXcrfURABMKTgP2ONPz7dyWoFkqJCAqTEomACIiACIhA 2BEwF6Y4BWLt2rXZunbt2j1//vz7Bw4c+MWqVatibr755k7W6hdffLH0Sy+9dMfVV1+9vHPn zj8MHjy43auvvlrCnjVv3vyWefPmVezevfvUIkWKxDZr1qznwYMH/yEfkK/OJ598cgP5XkXx GLBnz54nP/zww2FTp06tj1JxvZXl/7n22mtbLl++/PLJkye/0KhRo2T5XfuXqe8iIALnjYCn SARb+j9+JILNqHQiIAIiIAIiIAKhIcBsoc3qn+XC9PHHH5coWLDgjhkzZnyBFWLTK6+8Mmnd unVlfvvtt5zvvvtu3RtuuGHGG2+8MefBBx/8E2vEkvfff7/WsWPH0v/000/Xjhkz5t2ePXuu 5vzt0aNHs48YMaKM/5uNHTu2adu2bSd16tRpg3vWsmXLbbVq1ZqHItHwxIkTZwVz16tX77bf f/+9DO15sXbt2ntdHp1FQATCmkDM378viTZSSkSiiJRABERABERABMKOgK3CdNanXbt2aydM mPCWu4lCUBqrxLby5csf2rlzZ4EaNWpscs/M4rB9+/boH374ISpz5szHrrnmmjghnzw7V6xY Ee3S2tncog4cOBB1++23r/K9b9e33Xbb0uPHj+dYsGBBHvesfv36Lb7//vv6KC9vV69e/YC7 r7MIiEBEEPjH70t8rZYSER8V3RMBERABERCB8CZgy7ie9SlWrNhR4iE8gR1rQ43hw4ff0b59 +ymWCNejKKwUR12GokWL7kHwz7po0aKorFmzHnH37XzRRRftPXToUBbfe6tXr85p34m1OOR7 366xRMTaeffu3V6eNWvWlEHpKF+4cOGNffv2bWbP9BEBEYgoAv/4fYmv9VIi4qOieyIgAiIg AiIQ3gTOch1yTbUgaSwPXT744IMbiIN4jWOBPcuSJcuJzZs3e4qAfSfmIStKxc5cuXKdOHLk SNx9e4aLU5ZSpUp5ioF9tw/WBM9SMXLkyJJ/3fn/fz/66KPSfDuDMrHH7hJsffCrr756mc8o lIlqKBIV/z+1rkRABCKAQLy/L/7tlhLhT0TfRUAEREAERCACCaAMZECQ75w7d+6DBFkP7tat 21r3GqyOtBsLQZT7vmHDhqjixYtvw3Kxh1iGbH/88UfczCMWhfysqLTVpbUz7k/HoqKits2c OfMK3/t2TUxFaZ6v4flJ+44FYgvt2MeqTVubNm069YUXXmhDkHd2e6aPCIhA6iEgJSL19KXe RAREQAREIA0TeO655y6PjY0tyApKX1jANDEPme2w5VdZlWkJwc+1LPj566+/Lvjjjz/WRFFY U7NmzX0XX3zxeqwFVxu6hx56qOrhw4dzNW7ceKc/yjZt2kxj+ddazzzzTNzysLZULDsN17rv vvsm+6e378RlTM2WLdth8raM77nuiYAIRC4BW8pJHxEQAREQAREQgQgngIBfcteuXRdjYXje 91WmTZvW/+23356FS1JZ4h0GoWDkYOnV2f/973//sHSsxDSK1Zx6YK24lpWZcg4aNOgt9oL4 xy5yrPY0DwUjCwpH1wEDBpzMkCHDaVZxSff444+/37t3799963TXefLkOfXUU099hJLRi2Vn F/bv3/8390xnERCByCYQlM9TZL9iqmj9Gd5CfZUqulIvkQQCGvdJgKWkqYZAUOMe4b0mb3xl Ut+aFZMuwvJwlA3hzgqmNssFlopos0DEp0D41mNpiXkohNvUCdJr7wdfOLpOFgH2KEGXHdE9 WZmV6XwQ+CV9+vTzEitYlojECOm5CIiACIiACKQSAnXr1vWCn/1fhxWazrAx3Xb/+/F9t7Ts cL0tvme6JwIikHYIKCYi7fS13lQEREAEREAEREAEREAEzgkBKRHnBKMKEQEREAEREAEREAER EIG0Q0BKRNrpa72pCIiACIiACFxQAvv37894QStUZWFHgF3R833xxReFWDpYLvRh1zspa5CU iJTxU24REAEREAERCBsCbCo3JFOmTC9kzpx5qB05c+YcXKZMmW4WUH2hGzlr1qyLLrnkkgHx 1Tt48OArCNwc7tpp53z58vW/7rrrbrH9LuLLE8w9Ar6jQ7G5HUHmT3366acxwbQxmDRDhw69 zDYNpO/ua9u2bX1bptc+tkTv7bff3pCdw7tXq1atg6XzL892K7c8vveTU96vv/6am6WB25Qo UaJHgwYNbv3ll1/yuDKNM/E1LQnQv4/9QBpZu9wzO69fvz4bK4C1KleuXJcnnniiERsPXs31 Q/ad1cIK+Ka1azY/TGfv63s/UP2jRo26lD1OOhgHVharx6aGuXzzuuvE2unSBVuejduKFSt2 vuKKK+7p2LFjXTZwPGtnd1deWjkn+w81rQDSe4qACIiACIhAJBFgKdaXEOoesgNhrj/Ltma7 5557bg+3d2C37L2unXZ+//33X//222/rPfroo9WT29bp06cXYW+Ka5ObP7n5EFaHXn/99UEF pidWh23Mx7K5XRHSl/7nP/+ZwmZ+lW655Zamlq9Hjx41Z8+eXf3++++f2qRJk8Usmdtx9OjR l9izcePGFbZ0r7/+ekv6vaDds09yy2vdunV7lvE9w9K84wmmP9m8efNupuCZ4NyhQ4d7T506 lb5fv34TEeBLN2vW7F9/1ZYunT2vV6/ePe3atZu/fPnyt+++++55zz777Ez2E3npySefnNS1 a9d2q1ev9jYf3LhxY9a77rrrmilTpqRjM8RSrgw7J1Q/Gylmo4zu+fPn30/bvuD9YlgUoJNv XrtOrJ0ufbDlTZw4MZrlijugRKxheeTJ9EPlnj171nPlpMWzlIi02Ot6ZxEQAREQgTRBoECB AicQ6Bbu27cvbhYZoa4O9/vYgaAXJwSxz0Te0qVL38/mcM/ZjPHHH3/sCac2A23WDLNyREdH P8YO1N7s94QJEwpVqVKlo80EFytWrKcBZf+ICiwh+yjHI2+++WaVpEBGAN5+6aWXrt+2bZvX 1oTqRdkoUqlSpc6u7Pfee68os9IdrT1cN0eALmGz4PYchSKGtj2IpWAQ+2S0txlyl89m0S2P +57Q+f/YOxM4Hcv9/499XxoMOQdZSots2VL2gxYqUYiIlJSUTnUkipROKdXhl85pOSfFUZIW hUKWSoRj3/esY4ydsf/fn7uu53/P45lnHmMwy/d+vW73dq2f63rGd/+SwC9Ht27d6g4bNqzc W2+9VZ56DxMG9++SSDtiuHv37neB3yUqA96tJblXn5LiwxgFMoWH6lNjFSHr+idpYDUk7GtG jBgxR1nHWa8pMBI19B0mqQbE9TSSAq4h6d8iJOIrWKcq+gYxH71nz5585AKJ17M7UtLeihUr 8m3cuLE82pXxMAy/ffbZZ9/s3bu3qCT7aBWuZo8cIWHhWNZ+C2OcisnS9TCCnjaiY8eOt6IJ maGx161bt+0///nPuuQRaYyWqcu2bdvykeRwEThdrfFt3749N3OPASs3XO8arn/mW7ZYsWKx U6ZM+UL9wzRPYKxXLFu2LJ+/keTG6cpG2t7UqVNLs4fmjx49ejqMz28NGzZcwOElXhTzRjve 78W1mxmuxkRkhlW2ORoChoAhYAhkGgQwDckBcZZTpwhsiK06NWvWXCoAMC25FoKwGRLucW+/ /fYHSIDrId32CFTMUrqWLFlyJ+UHc91FmQ6q07p1664ksNsGkfYcxNMkCMJu8+fPLwBRmRNJ c2UIyCoQ2d+vWrUqL+YeXSCK5yOpHQ/RVVv1wxxZ3DglLWdslZEelyZ8rJe4Lky/uahXwrXL OHLBeBSHqIu79dZbZ8DAbB06dOhkMQxdunTppWzdMAsy8TqJtqCTq8fz8WzZsikvR8hD5lgy r4KxGcRcapQqVerQSy+9dDdS8CkTJkwYgolRFoj5+qq8ZcuW0sIjNjY2H6ZjDSCKjyC5Hlqi RIlYcGzpOgjVJ2Y71fAXyOHKQIxn1Vjd84EDB3LCHMRIC4D0PxvMXOAbWqZcmzdv9rBAK7F8 xowZn8NYrHZ1dU1Je8eOHRNDkMXlDDl06FA2+s4OY1cCxqlY6dKlt7g+yHoeR+6QfOwFj4hf uXLl5WgIFmuPrF27tizMxieYU01hnOXAbgOM6AFw8rgGZUzXmGFGXXPeNVz/ML4bWM93XQUY xQpoJXZgDnXIvdM1uXG6spG29+abb85D+/CZGBwx0uPHj2/CXl+odqSx6dq1a09weRxNWtVz Mclz40oPV3NySQ+rZGM0BAwBQ8AQMAQiRODJJ598jDNQGr+IfRBx0/UCaWn95s2bz8RcZoWe J06cOB0b9epImDdDCJddtGjRsOjo6BMQZt9CFB2FWC6GyUk5iKd3kOgnINVe+MknnzREulzp xhtv3HLixIns33777fsQrodEPOEDsQnp9VS1DWMwbeTIkR4BLcdaiGGPUG7VqtU2fYfZKQyz MlT37sDOf0779u230maS/aIl2eXK+6/Kjg2Buh8i+xhM034I1rpI5eOYyzSVe//9979CgzFY jAuMxjGZ2vjru3v5D5DhuyES8vIQufOYzxvKocF4s5KxuwDMVPGHH354LWMcBdMT0CC4+uC9 n/lOgrCUidHnaBUGSkoPY3A6qT5dXV0xkVkE49Pyqaeeqobkeyfjl09EVpiU7NIq8dwIvONh kgrCuF0Ng7fOXz/4PiXtValS5aDWEv+LFjBBP0E0X6+1xlE+F9qEaOaY4PqpU6fOXu5Po7HJ xfWgGB3NFU1ANfD29hkE92Xly5dfJaZk7ty5FWAYf3D1Q13D9a99qFP15P+B+dbdaD0+CW4n uXG68pG258qzNyqi/bibNckB4+KZsLHM37E+0zDvqspvrBFjag0DOovs7z8FMzeunYxwNU1E RlhFm4MhYAgYAoaAIfAHAmT+HQqx20vntGnTnsOB+VSPHj2a6fPu3buLffnll80h5l7WiWnG bRD3BRYvXhxdqFCh3WIgVE5mUEh7J2Eig5C3yE5HtOkbpiTQi3GeJJk68WIg9B6J8xVXXnnl et3ruOWWWzZ6N/wDQX8/ZjFP64SQ9uriE7HHjZNxSYL7HuYhtWWuBDMTtl/Xrq5IrUPSMpi4 FEXiXdLNtUaNGv3I9J0F5iaR2Yu/rTZt2jRlHI9gHrUGIr0/WoXPXBI+xnsKgno0uDQGpyFo StogcT4j+hQDjxMDoUPMiqTUaCUSmU1B9NYBx2d1gkE+/Bse1700H/R9AOn4VxCrt1Huwdq1 ay+h731q6+WXX54Lo7Tr0Ucffejdd9+9CWbjZ2mP/HMIvk9pe/T1GUxKOTRUvdGEFEQTswHi Phb/iGMwEwEMd+3alYM5nsR0yUtkyH7ztDswcIdVTgwUmFVHoxOLNL8CWqNiaIxig8cZ/JxU /yonhkqO2B9++OEttDmCc35w/eTG6S8fSXuuPEzmAtasD3tlAtqfrs7pncAAJ2Cc5sF0v4Ep 34h58+ZdA14vav6ubka7hvzhZbRJ2nwMAUPAEDAEDIHMggDRmU5J4qsT2/x4zh8xJfEiB2HL noD9/qcQv8/oRCrfF0ZjBHbqOyGMCmCW4hE8krpDqNak7nbuC/kJIYjAGMw4NgTjieQ6DqK9 sHsPERVw7oXQHAwB30unTFhcGTdOMS843y6EedmKA27J5PoVM+DawCH3Ep7dY+CKSVECPggr 3Vx1xW+hPxoUj9gNFPTdtGvXbgnE6UIk5zdBJN4uDYr7rHC1aEk2QFAPRMPyOsxLDr+pkisH hpLIewfMUH5wLUib+907XWGmVvbr12+MTjQnWpOvdI9p2WyZhcF0LVU/ELcDYCJ+g8HwGAUx YDCBn7ImfdGCvMYYcqLpCMtEpKQ9sMrKXjkJQTwUU6a+s2fPHsUaxjRp0mQHTEs89wE/D5jH IqxfrNZSc8OvZh3mTNegSVnMYxZ8Rx7A7Gsq61QKBrc5ZnRjVC7cEa5/fUP70ZX1PYi2aLB8 L0K1ldw4XZ1I20Mr0wSH9lqqJyYRs75fWeu8zi9G78WM9OzZsybzbY8fUiG0bhOkldG3jHgY E5ERV9XmZAgYAoaAIWAI/IEABOhBR9hiCrQK86XrFLNfJ34EHTF3aUIkoD1IUndj5lRN1Xr3 7l0HW/VrIdb2/fHeM1pXzH+0BjE4+wY0Dg5oQl4uXb16dUWF8BRhBrF71lGWIAwPQCDnCtcv 0t14CLRoOSyLucHZONAPBNspEfcaE2ZbqyHwLnfhbWX6wrvHnJaA5+tk3+7GryuMww60Mv9h ni8hST+E4+6jmAv1kmmRiHEI+j5ygobZ2NaiRYsFENh5/fV1D4F9KX4nnp8CPhS10EzsqOUm hnUAACAASURBVFix4mF9c30itd8L7ut0wvSdRKuxXvfSeuB/URyNxNNy6NaJxqFR48aNPUk7 0Y0aUvZOtUW5IphWXYPZ2TI9J3WkpD3GdJq594Sxq6h2IdTrognZAlN2hP6WysRNTtY7d+7M QcSiZpgqBfYDTMJEzN1uxt+mBKZLo/CR+Beala34R/yfoimxHsk6IIfrH5O6K8GlGGZ1X4jp 1Rh0SiOg4ADsYc/RPNw4/eUibQ9mLQ6msj5O7oXVl9aWdyuFidaCNbsdxmXQ5MmTa8IETmaM A8eOHeuZ9iW1Nun9vflEpPcVtPEbAoaAIWAIGAJhEEC6fwgiq6Scl7HVngyx8xAOoC9ACGXB 8XcLBJ8nGYZQ/JqIP13wHWgpvwLs4EeqWTlTY8LRGel7c0yfCkFoT5T/QXCXMlFBCr2GcJ/9 ZX5TqVKlsMRtcH09U+/wwoULK3A7M6l+pV2BaF3dtGnT/jLBInLUWgh7jxnAhGoT9uol8Ino gBPwKDQKMyj/vHwjJLWH4P3Q9UukpS6YYr3mzLHce13xRTiACc5EmKHJ2LlXwS+iAbb+WZnT UvobjGnORpidfDiQj/PX0z3Y7AbL+9EuZMWPIAfO5v9xZcL16crgb7EBQnw9/gSP00cBIjyt xzzmZ32H0fiJ750U9QmN0KUQyuPRrMgnIckjpe0heZ/02muvtWHMx8AhD1gOUydoI3ajkfkC Kfvf2CdH5QMCUf6mG4D8GfC1eQdGqz176BR7bQc4ZJUZk6I6sd8muLJJXSW9T6p/+ioHI3sp zN1r/vowr8/DoJSkz3ZgvijcOGGASrtykbYHY72ccLpyph6g/c3e28P6f6UxsFc7sfc34huh UL9x/nFl5PuAOjAjTzIDzE2qMFurDLCQNoWzQsD2/VnBZYUzCAIR7XvMd2RWUTMlc5YUVdoC 1Q0meGSyg+Q4v9/kSOXkjIxmoigEVBxmS8f0LqlDGgK0F8dli59UmUjfh+tXyciQAh+CoPPM aFybEN5ZYXayy4dA7xT6E+1CYZicHaGYH1cvuauk3tjZn9b80ITkUEja4DpKdPfxxx83QiMz jOhO0SJkneYjuGxyz9J8YAqVLRSOaF+KwChJS+T5sCTXlr6npD1plFj36OB9ovbQRuTSXoGZ 263nUIfMe2AoiuPHkQAzlyQWmABh6TS8Z3Ab4foPLpvUcyTjTKpu8Hv9dlj/ImjMTvh/I25v BJdPx8+/4tsyN7nxG2GaHEJp43tE/6mkjaHaKAyBVEPA9n2qQWkNpSMEItr358JEpCMs0t1Q HROBZuQf6W7wF3HASTERF3FImb3riJgIM2fK7NvE5m8IGAKGgCFgCBgCqYIA0umdmNrMSZXG rBFDII0jYExEGl8gG54hYAgYAoaAIWAIpA8EWrZsGaszfYzWRmkInBsCFp3p3PCz2oaAIWAI GAKGgCGQBALysUjik73OoAhozRUaV1Gx/KGBM+h0M/W0jInI1MtvkzcEDAFDwBDISAgQLWcI 4THfILrN6zqJnDOYaEIPuTCnF3KuOBZfghP2gFB9Ej3nKhw3h7lx6oqT8PNKtiZn2lB1Inmn sKPyS4ik7LmUIcpVWUK39j+XNvx1RWwTjagxIUN7krW7k7Jmu+9yICepXDtFZMI5uRVRpwq6 b+5KSNx2ZEoOhE5NaXvqV0nc2DM97rnnHmXKdl1EkWX6WiJGdeW8j0RwVwY+/HFDJu2SRLp6 EOf7e8GnJtGMbsWhuh8Rs26Rg3Vw+Yz+zH4eQDSnwJpkxPmm+IeaEcGwORkChoAhYAgYAukd AUKcvgUR+VedZF1+PiEhIfeDDz54d1qbF1GV9rpx6kqm6neIfNOAjNGBvA9nO2aiFpWCmK13 tvXOtjzhS38jC7UX8vRs64YqT5K5WrNmzbqOZGaTyV69iEzInR0B2rZt245EeDpNjoXxRIc6 gbnUQ47RIvxsJRiI9iTou5Ewvnlc2ylpTyGAybHwADlDlpBEbxL5ECoTgaq52lSmaUK9toeZ WU5Y2R9hAjsQhras649cC1cMGjToFkLhjiby1yjqLWMtxnD/FlnMd8JHtHZl7ZpxEDAmIuOs pc3EEDAEDAFDwBBIhAA5Io43aNBgASFJA9JrEsXdwPt+OkkC1sBVUAIuYt0/Qiz/V0lK181J tiX5ljZDWg4ky32Ir+9JycmjULxq1aqdSUrWoEyZMo+pnQEDBlQitOrTnE+R28BLUOfaT+6q kKnkX9hEPgFvrEn1C7NRShJx196///3v0oRB7azxcN8Sxqks0vC79F3Sccb2OCE5B5H7oSPf crt6hIftoTru2X+VFkXJw2BussAwNCJh37PkBRiorMUqB4FcrEePHnfongRxN5Nor57agzF6 CbxbOyL/H//4R3n6vVfl3CFtCXU84ty9o70aMAvTyHS8hlwdi5DorwD/KkqGt3HjxvIQ5+PJ cv0bSey+QapfVG2oLqFrS8JYHEWTk+Da0jUl7cEIVEMTsmbEiBFzlAWafTIFRqKG2vvggw/q wwhMIcfDLyTMWwv+i1mHOvqmucJk3A6Wo5Qkjj3RmyzWpcDtFkLD9iLXxHyya5dQckOVhxkp D1YPk+H672Sz7uoyPif1XntL2dO198j38Ry5GULuK4UDxrH9Hq21EgS+9957ZdTfXXfd1URr r3sd7JVO5M6orXsYn6vVPqF/B2kPKRyw3jP2xqqn8UmjQG6UvyhRIP33ZxzPaM+pXLi113d3 hNuHroyuyvQtDZfmwB5uo2SDei/Nj/agfoPSFEk7pfeRjFN7+c4772wanFhR9c/1MCbiXBG0 +oaAIWAIGAKGQBpCgDwJOURQ6RSxM2XKlDrkFFiqIcokBUK0GZLmcUiSPyCrcD2k1h6hCNHU lYy7Oyk/mOsuynRQHTIkd4Uo2waB9ZwSwD3zzDPd5s+fXwBiNufy5csrk925Srdu3b5XHgIk 1F0gfuZD6I0ni69HqKmNJI4sbpySgjO2yhCbpSF4Vqp8mH5zUc/LCK1yjCMXjEdxsm/HkQti BgzM1qFDh04Ww9ClS5deSM8XQ+DKxOskRG0n1dHB8/Fs2bIppG7gkDmPGCi0AX3BMa+IdeZx PVqH4RCcI8l50FDviMCUe8uWLaVUkTwEMRCJt6FF+B7Cehg4XQUO1+gbRPUp+kmUywGiuQAJ 9a7Wd3eQyC4bBOJJ94z2KNfmzZtLkCBPofizQHB7dkVkyM5G2ewwWN788T34jjwOn/Pdy4jt 6qekPRimrMLItUGujZx79uyJEZNAFu6iNWrU2OK+lSpVKg7Nh8fIgElM8eLFd5IA8AgM0HXs tSUfffTRTNZhL/tmo/JkYFZ3iIzVHoFOpue7yeg8ZcKECUOU8BDGqb7aTeo9OJcF8zokO3yP ffY1DMs9oXxtYHLaM+Z89D2cPfQTYWMf0Z6Esf2FNamkTNbs6evWr19fDk3PAplqweS1Yo9M RQv0isbw5JNPNtKV/VWYPdOcHBiLWNfPx40bdztn/SFDhoyEAVrH+t6qcuHWXt91JLcPfy8V FSVin2SIXelvvObAOMvAzDVUlnjm0BWcxsE8DIDhOQgz6zFFkYyTdThK3pLSJAEcCJPVwWm4 XL/ncs10NmrnApbVNQQMAUPAEDAE0joCEEKPcQaGCQG3D+J4ul4g3a7fvHnzmRBUK/QMATgd k5PqEGmbRawtWrRoWHR09AmI4m8xWzkKoVcMQqkcRNY7SGwTkFYv/OSTTxoika5EpuQtZCLO /u23376vrM+YIVXFB2ITUvOpahvGYBqEX0vdy9EWAs+TqpLpeJveQaQXhlkZqnt34A8wh2zI W2kzyX4h8ne58v6rEskhJd4PMX4MQnY/hGpdZapmLtNUjkzcXyFBHwzhlRPC6hgM0Ht6DzGc AzxqQTQ2IP9GVjJuzwKPj/FBSECKfgWEewEI//wwW+sgpF9njglg4hHEqq+jdu3acySh1z0m Wd+hCbgGpmOJskXr1Ptwh7RFjLMROMZDdBaE+L0aAnydsj8LU4jGFhDAP6EFul6YQ0TnSu32 yIa9CIar5VNPPVUNyf1OxiOfiKzyZ4CZiEYSnuD6JAv1HpgXbwwQtsXIfB6vbxDC1ZCmf677 pUuXlmFey0Wsy6ROydmUCJAEegUg6ouDy1rWeRSMY26I5pah3qsdHRDQ3yjhnU7WqRbakgow qqt+/+rttTzs3etg+AbgNxIvrRYZtm8ggd01w4YN+xVGYTxmfq2VdRxm9WOYnuNad/xnxmhd xZSA8y6S513m2gT7hTCj8/WMluQA+3YWTMwmZd/u06dPgBlNau1dOzAG1cPtQ1cO5qgWmsBV L7zwgsfwg/lYtAfR7MFa4L2BPj3mGub/G34nLzutWnLjrFix4mHW4n1p9tiTN8CYPIQgYDea rxn0tcgxqG4cZ3M1TcTZoGVlDQFDwBAwBAyBNI4AhNNQCLJeOqdNm/YcDsynML1ppmEjQS/2 5ZdfNodweFnn6NGjb4O4L4BZTDTmOrvFQKiczKAg1iYtWbIE64oiO8VA6L0OiEmsLOI8cwrq xIuB0HtMWK7A/n297nUgGd7o3fAPBP39mOM8rRPi3auL6c8eN07G9ThMyHsLFiyoLXMlCMKw /bp2dUVaH5KWwQyoaGxsbEk3VxiAfjAJWWBuEjEAEGG9P//8879ApI1lXi9C0M4QA6G2YcZW 43MwByK0t8xakLRfD+NzVN/8B/gEwrpCtO2G6Sjv/657GJguMkmBcL0XRqaU7nXKnwBzlbkw QLsw23no3XffvQli/mf68TJi8+0zmIpyaIp6Q1gWRAuwgTEH+gvuR88paU+ZsTFv+wozoNug Mx+EOF7CGu0TwwVjdhxiP4AbzEAuxu4xc0jm94JbIfWbN2/ew9u2bcuPGVRhYYDpzS60As0q Vaq0Rt9p7xTM0Gj2VmP22hC0TW3QdKAQyhYV6r3q6IBhDcwXnOJhasv9/uX3f9l7RbW27Lmn 3HrDFF8Go+DtNZlo8T0KYj4eAtojxhn/ccZZmo3WH6wHzZs3r5K/TfrZ657RppyAMd2hZ2mX OAJC+OTWPtJ9CG7RrK3Xh/phz20W0877IuypTXqnQ+vEGI6yJ/LrOdJxirEG94ms1XPspRkw V23ZZ/eqjZQeIX94KW3M6hkChoAhYAgYAobAxUVARA6ElHdKKsv5I6YxJTUq/B0Sunfv/imE 2zM6IWb7wmiMuOGGG3ZKEnz06FGZz0hLkFV26NTdzn0h+QbovQ5Mh2IwWTpDuo4kNw6ivfDv paKiIMqKuXvMYQZDxPXSKYm0e+/GKebllVdeWQjzshUn4ZLJ9SuC0bWB2cclIhCDD+zKEyBw V7q56orfR38I0j3+shDOU8DlMCYq7RSRCOI34KBM5uncaG++YV59kIZ/CvFaC1OYyv76ukdb EfC1wNSrJMTy/uAySPi/79ev3xjs6KfBkOzSvU4cpbeKsYK5+xSs+0KsvwZjlBP/hJ2MOStj O4nmYyh99J09e/YosIxp0qRJgNgM7kfPKWkPojQvzN5SGJWBaB8GwET8BqHtMTJiFsE52vXF fopGU+KNAan/Ngj2kpKMox2YhP9EI+baFJxGwTC1hUEsCLP6vepK4o+maYP6QEv1OvPMAfPQ Eg1BVKj3rj/2aQBf7WUI50T4ogk5AqF/ijE+79YbDJ6FUJ6lNli76jDT0jqVRCPhMSB8K4+Z WlPWd4Rwh6GZrjLukDO7uw93TW7tI92HWm9h5fqSNk4+NWgndvh/V/JdwuzsGD47cSob6ThV du7cuYWY5834K7WGOdzKfp+t9yk9jIlIKXJWzxAwBAwBQ8AQSAcIQAgehDnwTE8wBVqF+dJ1 cnLViR9BR8xYmhCRZw+E7W7MeqppSoTnrIO5yrVI4ff98d5zZpV9NoRODE63AY2DgwDn4qXY Xlek/aIifiGKzzrKEgTXAQi6XOH6RQofj6N4NGZD0WJuMB0K9ANxdUqEqcaE2dZqGILLXXhb zI1q8O4xiC5vyHKUlbMppl4LIFKHwMSMxJylNNJz2Y63h8gtBWNRHT+LtpiEnYQgXo6keBOS 3Lxuzu4KcV9Fc4YByEl/VdHOrNM39S0/FN3jgL4FrNchEd4K85Sge53S5GBW0hDi7k6VwySn COY+12BOtgyG8DT1ejK2ivqGhqAuxN8WmKMjek7qSEl79FscwvRp5pdDJxqRRo0bN56vPuRX Mnny5DrCW8Qtkv9aMJ7eHpAZWceOHadgBtaRd3H4PrzN97HsoTUwF0PQQvyGKY3HXMIM5YY5 6SPmDKfgbS1atFgAEZ6XNZNJ2Bnv3fwIGVtd9xD9MUjmy+Cz4jGxMAfV0Frlh+ncDeO2lzXy /Hu0T5HY92MvFpe/DfXbMJ5PYXgmwtx4PhVo30qIkKatOK2d9lEoZtSNIalrUmvvyofbh2II 5Kuhsqyz9/uRb4SYefZGG/ArgPZuCfvySr1XOeZyLYEOVrp9rHfJHTLLY1/fz++8L78d+Y0M Yw2Gof1bnVzdcN8D6phwheybIWAIGAKGgCFgCKRPBJDuH5IE9g9iajKE4kPYWL+ASUYWJLhb 8G8Yo5lBoH6NuU4XfAdayq8A+/uRei9nagjtzhDVzTF9KkSkmokiHPXNf0BsxyI1XQMx2V9m MBCPy/zfI7mn3mGcjitQdmZS/UIwxuPEuxqn1/4ywYKgWgtB5JnaYM6yCUlzCQj1DhCuo7CL n0H552WTLuk+9ukfunFg594FAv41Z44le3fOkZhw5YfQrItj7gNIbl+GoWkGhgM1J4j6k9j8 z4dBShT/XxGSwPI5JOo5Ydq249DuSd4pdxlS3ztxGl7i+g11hWD8CR+BTphR9ULTcykMxHg0 Jp45Df4QkyAC2zDeYxC7eZjTsFBt+N+lpD35bmBvvx6zq8dh5AowlvWM/We1i4nTdPwkKoLj IAjcvGiiZvl9EnA4/h8mQQfZW92Zfxz7K5Y9VxitSRGYg+V169b1tD8QsofYF0tZs8FE4tpI P/loZxwmP1eHeu/mBFNVgXZroMm4hP31nRgQfcOPoDOM3XAYy7WEu/0Yhu1+/G8aqxx74Tsx bnImVtQvnJOXgt9yxlYLCXwz9vd0zNgas25Pwxzlwn/jFwINNHZMn+s7uWtSa+/qofnbmNQ+ xPemNONoB7O6SL8fokEtBcPn5McEntvwYVhE+6cxE1yF9ul5xvobmBWEkfiXaz+5K4EUSsCE 3qWgAzBVH6ExPJZcnUi//3+9TaQ1rNzFQEAqNVuri4G89XkxEbB9fzHRt74vFgIR7XskprUY YM2UDFKOrtIWqK4cVf1tyNwEqWd+v8mRviOpz4lmoijEY1xyRIg0BGgvjst22992Su7D9asw l0jkD0Hcn/K3DZGVFWYnu2z59R4CNB9S58IQUTtCMT/+uv57SYNFwAkTpPAxMEgHQ82Jd50h YtfJDwFJe55g7PxtJnePNLwIDJC0P55viisvSTn4Rwevl/ue1DUl7cmsCdO2bKHmKs0KuMpM LElNiOrja1AUxiFOTr2hxqY9gkQ8hxyg9R2GDVee4T2D3+sb/hJvsn7PorHIDsNwxK2rvgUf cgKHEYiBGN8nhiX4e6hn/RbY1/EyrZNJFtqwE843KFR5/7uzWftI96Hwg4k/5fxyXH9yjEbT lQcmKlb70r1P7ur2cXLlgr7/imnX3KB3ZzwaYXoGJGnyRUT/qaTJkdugDIGUI2D7PuXYWc30 i0BE+/5cmIj0C03aHLkjJHEI/zFtjjDtj8oxEaFG6piISJmCUG2cr3cZeO0jYiLMnOl87Sxr 1xAwBAwBQ8AQMAQyPALYvC9E4p7IWTvDT/oCThAN0iTMyVLNBCc1h57Z1940Eam5m85fWxFJ ps5f99ayIXBRELB9f1Fgt04vMgIR7XvTRFzkVbLuUxWBcJqIVO3IGosUgYg0ERadKVI4rZwh YAgYAoaAIZBOEFB0nbFjx14qO+x0MuRMN0yFkiUxX0nZwGe6yduEMwQCxkRkiGW0SRgChoAh YAgYAlFRCp1JdJ37iEbzInkeOnH/Ik6wD8sJOaX4yBGbKDcN5LCckjbOtX64PolSU1bJwsKV Cf5GSM/bOFvqPU60L4qQDy5zrs8KJ6ucE6HaIQpSba0JeRHuxI+iGuY69xF1529JRQUiOlQ7 chkkigalsqxtV601Dt1XhupH74gMVAdTq+4qS53Kbg3lgEwSuKYaB2FZ71Ko0VBtKK+A+ieH waM49LYgWVlxV47IQjGEDG1DGz1IXtbEn0vElfFfQ83DjQ/H9Sg3PoWQla9B8KkM5P727P7i I5CiPwgXf9g2AkPAEDAEDAFDwBAIRoCwp12VMIv48v0IFfoKMfWfVk4CchB0Di4b6bOIw48/ /vguoumkyI/yXOuHGyehPn8jd0CyIU+TagNC+HUiHnkRgpIqczbvCRlagohDzZWXgEg/gWR7 rg2iAN0FAZ+HRGgjSCQ2gUR3Cwkp+86YMWP+RVShKn6GgJCllSC825N870bCpQYS4BHWtALh XtuTu2E5oWB/JDxoB0KzlnV9uKsSrMF83EKuh4WErp1B3odbe/Xqdb2+k+DuDhiEazEjmkzE ozgYhMccg+Hq60pivO5cspB/4UscnE9C9Hv7SPkwyF/QnZC2WRjn18yhAm3c7q/r7pOah398 RFOKcuMjKtFhwpwu9p8kkStH2NM06Rfh5pkZr8ZEZMZVtzkbAoaAIWAIZDgElByNePuXkx14 LI6oxzXB4sWLHydnwdjq1auvEjGvE6K5BWFRX+J8ESKxuTQFOiSVljSYEJpPk39hINqH+npP +NIHdaWNJyBmc0g6LQm46iOhfuTVV1+9Qt91kEPhGmkGkPAPgmBuI7Oq4PrKwkvOgXt/rxH+ XyXYgpi8XeOGYWhEroBnNTZyJzRRTUKYFuvRo8cdumcuN5Pwrp4k45ofcf9bKzSqviXVJ0Sx pPCXQMSXrFGjRkdyYDSl/QHKHeCX/pNc7wYw7acTwr+B2gx1QExHk405H/kU4oO/S2tC6Nm8 rM908nFcxRy6El60PPkgOkCkN+H7VyQBu9HVI6xpSeUgIIFegnunKxmh65MDYQr5PX5B47GW tViMRqOOv4zuya59JcncfhgxYsQcmId1OAH/TAjV6gr5SQjWesz5AyW74/pDQkJCHkKsBtZR 9aXVomwe2hnTpUuXzeQamMn6/1nmV+B5NZm0jyipnHIxkGNkKgnertc6qa7/SGoe/vGRE0HJ Ab3xKW+H8k64E+YmJ0kSV8A8zROD5l8Xfz92f+ERMCbiwmNuPRoChoAhYAgYAqmOABLrSyFe dwWHwoRgP0DCqe8hRk8jua5Hht+rkHoPgRj7B0RgzUceeaS2BoPmoiQMRzOk3B9DrE1F+9BG TAPJ2z7Td96PhIg/3q9fv/rE0d8PEfgKpjhzIS7vFiMigp9kbl1pbzzE8HCkx2UgLhsG1ydh 2ynGkigPgtr3HyS3uxzCsRtmR30hIvPKdIaMytejdRhOAq6REydObKh3ZM/OjdallOqSoyEG gvg2+v8eonoY/iBXIaW/Rt+S6pO6pdEM5OTMtWDBgpqxsbGFIPLfZn7xJCdroboyHQK/Zk88 8cQ4JP4fgF09iHIvM7K++w+S1C0nn8PnEMKr/e91P2HChKvQACzQPcnbmkK0j/7www9nwmgV gVFaDvNzmFwI+fVdB0nTvlNbaJIS5VoggVtRGJ4tv5eKipImgXWKcc/uSvvfgONP7pkkfuXZ G+sg9qPB/6hLZqfvMH67yN6dqA3lKYAhGnjixIks7IvSaB5akahtrXI/4M9RjPvAGMiNEQfD kQ8Nyxk+OEnNI6nxufHqKjMr9mELkt5N0DNZmrWHe9L342RbruqYRH2z48IjYEzEhcfcejQE DAFDwBAwBFIdAZKi5ZF0OFzD2J7Xvf3222eJgISgjUWiPRNpfoAghjiegIR8m4hbzEf2T5s2 LYaynlRdieYg4qKov2zUqFET0DAcwNxmW3x8fAnMW3IhKa5FQrZVL7zwwlIlEYOhGIumYldw fWVGhjj8b/A4xbBI4g+j0heznrYwP2uQevdX2bVr1xaCwC4A8ZpfUnXm8ToZjvcHt0F25DmS zqNR2NG2bdvvmJvHRCTVp78+Cb6OUH4cjFEsZj5TYSg8+3+YrfpIyWf27dt3hbBB4zEdDUJ1 5p0dZunPOsXQ+NsKdQ9GRTHb2T1//vwCmIYVpp2d0gow7xIwW2vIFF4WP4AVoer630HYR4NR QDsBQb2HbNy5/GV0r6R3SswmXDF9aod51WV9+vT5GWYiGg1Hon0C87kXfHMGt6HnzZs35+7d u3cXmKw6rO8maRswk4tmfwTGwD5Qdu3TMERnjCNUm3rnHx8MaJQbn7882az/gs/GHHA7qPeY i31HAsL+7K8fWZdGaNoG4tvRzAII+FG7cPcpsm+8cMOzngwBQ8AQMAQMAUMgEgQg8OIgrErJ adaf8Vi27hDe17/22mtzIF6LIN3f6NpTHQjngPSbZxGD3iFpNYxJDvfsrhCRWWEoukNI/hki brt7L8ISqfgO9ywTGO43i1B278JdYUp6y3wGTcdo7OXX+Ms++eSTq3G4nUObvdE0HMShd864 ceMm+cvovkyZMrHuHRLz3ThNN3XPyV0xgTrgMgGjiTiKBN6bO9qOYl9++WUZNAJ/URtoXbJh 1rQTwrco0vmn9Y55b4DYfkP3SR0Q/ntXr15dCKI4Dl+C7Fon/AWqkkV7L3XzoLFpBiPmaX2S akPvYXaOw5AEJP6sby7a3hWqDhqUEjBmPRjfZjIe/11aBAjuwkjwA/VVD9xzli9fPi5UG6rD WAcqszN+D/3QSK0Ap2PsjUAbaEdywGCeJEv1WeXLcONj/FFufG4MaJZywUDWRgM12L3TVXsb c6p5OmWGhkaiLXvnZub0hLRt/rJ2f34RME3E+cXXWjcEDAFDwBAwBM4HAmcQS0j8eIqKdQAA IABJREFUd0Cc5sD0JJGTLczD1Zj/1IUwPhETE7Md6X5hNyBMWIpDPG5wz5j9nNGu+6arGAKI /PsgJudg39+HqE/D3Xe0DjshuAu6Z0XZkS+Ce07uiq/BFDQphzFBaqfIRgqB6urIPh8G6Ru0 A31gMD7FlKoWpkOV3Xd3RZqe290j8S8JY3CGtsJ9D77ikB5y7owpAd+JTyFSn9GJJLwvGpoR SMB3kK+jl87kGAj1hdZn+fjx42v86U9/OkY0o0n4mPSAIcsG4f0/tDvd0Uz8Iu1E8LiCn/HZ iMdULNq9p+/oyy67LMC8ufeYXRXFofohxj5+6dKl74sZ0De0HXvoN7c/tCxalSIwNwGGUOUw CSslPxHd64D5jCPq1wYYoSL4MMTDOATGgFlcEfZXLIzW7w42v1cJ+69/fPjpRLnxuUr411yH b8pWac3cO3cVA4a2qCZ7oT2McaFWrVpNMAbCoZMq15C/heCWjYkIRsSeDQFDwBAwBAyBtI+A RxD6h9mkSZPdNWvWnD106NAWOPh62gUcaAtje34Hpks/qizflyKdryVTHPkx4EdRqWHDhiv9 7QTfy4SJ4xSmKjkxK8orKTaajaUi2pAC13LlcbBdCoFZUb4RYjZw2m2Dz0EBf32VnTlz5iXy M3D13BX7/QUQ6EPwsRi5cuXK0tjvD8Tkpb0cxmEsqmNm1BYTmpM4IS9Hsr6J8ZyRX2H27NlV GF9WRQ+in6r4JqwL16frO9wV34xVSOGvE2Y6wasjc/Mcu8PVC/4mMyu0G9nkmI1PxE8wAsPk 9IzPwGSYouH4pAQYsOC6/mdMkxZjzlVHZkVi1CDga8EArFcZOW/Lf0H3MHs3gd98CO1lMmnS qfH/YUa0CRy9SE18r3b48OH8RPbytBl6xm8mPwzNdvZRZUWDUnvqi/UphWnTYvwSlqIpKCcz LrWL6VozmFFvDPJjwPSriuqEO/zjYy5RbnyuDg78V7Jfl7lnXdFKyH/kdpiYQWBQk7Cvk9kH A8mJMtVfzu7PGYEz/r6EatHMmUKhYu8MAUPAEDAEDIG0jcAZkmcNF/v8L5DK3kPEnsFESNqH ZL4gUYp+gLGYo++YBc2FOOyJ2c8AzGKOyqEWojCsHb6YBcycVkCoPrNmzRoR9nMg7vrI4Zf3 67G734RkvRXE4xhs15dC5D0Hsb8PQm8bTtCLgutjGnQZjrJ3vvTSS0s0puAD6fkmzpFihNA2 1EXi/AAE5cvY3TfDjGgg2oV9aExOIqmeT1uJ8icomhHS6+fQyOTERGY7BPX3aj+5PoPH4H+G MJ/MnB7C9+AFGK8stL+FyEhj/GUivZ83b96HhNttDm6PItXfjvR+vxzCWad85PXwxppcWzAg 0/EXqYgfwyCYtbyYls3Cd2CV6jGu+nnz5j0iUzK0N2XRxhRnvM1dm5ifbYZZeRXG8iOYvl5o NeoRmSkf6/Su0yLANHSGSRsupgdfkKnsj8dwMpepUxa0L98qepJO8lxor/1N+0j+M6z/m+oH xqL0G2+80Q7Gb5HrN9Q1eHzsiTfc+FQeTVQFTLFm+Oved999ncBuI74RCs0b0vzKX97uU4xA yL8vwa1FZKcYXMmeLzgCUivZWl1w2K3Di4yA7fuLvADW/UVBIOJ9jxlNK0YYMlGaTFWQJheG +I2VGZN/JtISIMWNgbhMkFTa/y3cvcyLkDZ7DrnYrxfENOoYzEiC2kOqnleEpeqrbwjLU4ru 42/PX9//Prl7tS9fBWzws2ncEJEHMck5EFxPycmwjV+HU/ZcCPM8ZzO34LaCn6W1kU+A3qcG 8ar2CLdaBPOs3JiG7fT7sAT3ndSzNDowcAlEdUrkJJ1U+eD3bh9IA+EYiOAyesbkLR9rml/O 8sHf5beA1khajN3B387mGUYRvmZ4z+TquL2QXDn7fk4IbMO0b3wkLRhhGglKF79MxP+pXPyh 2ggMgVRDwPZ9qkFpDaUjBCLe9zARhZhXO06zKgAEx0Rgy++ZbqWjNc/0Q42Uicj0QJ1/ACRw GAMTEZFwwf7wnP8FsR4MAUPAEDAEDIFUR0D/0cNITKPhxpyZ/v9zTG8W4px7VtGBUn1RrEFD IP0iIAZiWqQMhKaZ6f/opN+1tpEbAoaAIWAIZHYE+A9/DYyEwpqKkQhp2pRZMCILdFgb/MyC g83TEEgBAtuoc1YMhPowJiIFSFsVQ8AQMAQMAUMgrSDwh+RwPMxEEcZUglNRi8xcOa0skI0j WQTwsVEZ759kC1uB1EJAppOKwrSDvyHn5NOSWgOyds4PAlpoOwyBzIaA7fvMtuI2XyFg+972 QWZEwPZ9Olx1yxORDhfNhmwIGAKGgCFgCBgChoAhYAhcTASMibiY6FvfhoAhYAgYAoZA5Ajk pGjZyItbSUPAEDAEDIHMjoCp+TL7Dsic87d9nznXPbPPOtS+rw4o/+KU/fLRzA6QzT9DIhBq 32fIidqkDIELjYD9uC404tZfWkDA9n1aWAUbw4VGwO17OUk/ybmBU4nVjnPq215OOwyBjIaA 2/cZbV4Zej4WvSF9LK9+XLZW6WOtbJSph4Dt+9TD0lpKPwi4fa/rQc786WfoNlJD4JwQMDrn nOCzyoZAaAT0n4kdhkBmQ8D2fWZbcZuvEHD7XpqIv3Ku5zRNBCDYkaERcPs+Q0/SJmcIXAwE 7Md1MVC3Pi82ArbvL/YKWP8XA4FQ+14+Ef/kPMV57GIMyvo0BM4zAqH2/Xnu0po3BDIHAvbj yhzrbLNMjIDt+8R42FPmQCDcvs8BBJdlDhhslpkMgXD7PpNBYdM1BFIXAftxpS6e1lr6QMD2 ffpYJxtl6iJg+z518bTW0gcCtu/TxzolGqXliUgEhz0YAoaAIWAIGAKGgCFgCBgChkByCBgT kRxC9t0QMAQMAUPAEDAEDAFDwBAwBBIhYExEIjjswRAwBAwBQ8AQMAQMAUPAEDAEkkPAmIjk ELLvhoAhYAgYAoaAIWAIGAKGgCGQCAFjIhLBYQ+GgCFgCBgChoAhYAgYAoaAIZAcAsZEJIeQ fTcEDAFDwBAwBAwBQ8AQMAQMgUQIGBORCA57MAQMAUPAEDAEDAFDwBAwBAyB5BAwJiI5hOy7 IWAIGAKGgCFgCBgChoAhYAgkQsCYiERw2IMhYAgYAoaAIWAIGAKGgCFgCCSHgDERySFk3w0B Q8AQMAQMAUPAEDAEDAFDIBECxkQkgsMeDAFDwBAwBAwBQ8AQMAQMAUMgOQSyJ1fAvhsChoAh kN4QOH36dBHGXIIzL2eW9DZ+G2/mRaB27dpRc+bMqZV5EbgoMz9Nr4c5d2TJkmX3RRmBdWoI pEMEjIlIh4tmQzYEDIHQCMA8FOJLY86SoUvYW0MgbSNQs2ZNDdD7J22PNGOOjr8h25jZNJiJ fRlzhjYrQyD1EDBzptTD0loyBAyBi4gA//lfTvftOC8oAzF9+vRLdJ46deoizt66NgQMgVRC QH8/2v3x9ySVmrRmDIGMiYAxERlzXW1WhkCmQsCngQhoVz/66KM/V6tWrVO5cuV63nvvvQ2W LFmS34Hy7LPPXlu5cuWunPe9/PLLV7r3e/fuzX7nnXc2vfzyyx++4YYb7vrll1+k2Qh5dOvW rW6ePHn+fscddzzWqlWrR/PmzfvqXXfd1cQxE507d66vdvyV1WahQoUGTp06VeZWdhgChkDa REB/Rxr/8XclbY7QRmUIpAEEjIlIA4tgQzAEDIFzRkAmTAEGYsOGDbkfeOCBnkWKFNk/cODA L9asWVPytttu66Je3nzzzQpvvfVW++uvv355165dfxw8eHCHt99+u6y+tWzZ8o65c+de27Nn z8mlSpWKu/nmmx87ePDgGX8nqXfDJ598cgv13obxGLBnz54XPv7446GTJ09uCFNxk9oKPurV q9dm+fLlV06cOPGNJk2amN11MED2bAikLQQ8RiJtDclGYwikLQTO+M8xbQ3PRmMIGAKGQHgE kBZKqp/IhOm///1v2WLFisVOmTLlC7QQW/7v//5vwsaNG69YtmxZvg8++KD+LbfcMuWf//zn L48//vhatBGL//Of/9Q5evRolp9//rnemDFjPnjsscfWcf0hISEhz/Dhw68IHsFnn33W/J57 7pnQpUuXze5bmzZtdtSpU2cujETj48ePJ3LmbtCgQeuVK1dewXjerFu37l5Xx66GgCGQphEo +cfflzQ9SBucIXCxEDAm4mIhb/0aAoZAaiGgKEyJjg4dOmz46quv3nUvYQgqoJXYcc011xza tWtX0Ro1amxx36Rx2LlzZ8yPP/4YnSNHjqM33nhjgMinzq4VK1bEuLK6yizqwIED0Xffffca /3vdt27desmxY8fyzp8/v6D71rBhwztnzpzZEOblveuuu+6Ae29XQ8AQSBcInPH3JV2M2gZp CFwABIyJuAAgWxeGgCFwXhFQGNdER5kyZRLwh/AIdrQNNYYNG9a+Y8eOk1QI06NotBQJrkLp 0qX3QPjnWrhwYXSuXLmOuPe6XnLJJXsPHTqU0/9u3bp1+fSMr8Uh/3vdo4mI0zU+Pt6rs379 +itgOq4pUaLEb/37979Z3+wwBAyBdIXAGX9f0tXobbCGwHlEwJiI8wiuNW0IGAIXBIFEpkOu RzlJo3no9uGHH96CH8QIzvn6ljNnzuNbt271GAE94/OQC6ZiV/78+Y8fOXIk8F7fMHHKWb58 eY8x0LMOtAmepmLkyJHlfn/z//8dPXp0BZ5Ow0zs0VucrQ9+8803/+D4CGaiOozEtf+/tN0Z AoZAOkAg5N+XdDBuG6IhcN4RMCbivENsHRgChsCFRgBmICuEfNcCBQocxMl68EMPPbTBjYHo SPFoCKLd8+bNm6Mvu+yyHWgu9uDLkHvVqlUBySMahSJEVNruyuqK+dPR6OjoHdOmTbvK/173 +FRU4Pt6vp/QMxqIbYxjH1Gbtjdv3nzyG2+80Q4n7zz6ZochYAgYAoaAIZCeETAmIj2vno3d EDAEQiLw6quvXhkXF1eMCEpfyGEan4ccOhV+lahMi3F+riPn52+//bbYTz/9VAtGYX2tWrX2 XXrppZvQFlyvRv/6179WO3z4cP6mTZvuCu6kXbt23xH+tc7f//73QHhYhYol03CdHj16TAwu r2f8Mibnzp37MHXbhPpu7wwBQ8AQMAQMgfSEgEKY2WEIGAKGQIZCAAK/3O7duy9Fw/Caf2Lf fffd8++99950TJIq4u8wCAYjL6FXZ/3tb39bpXJEYvqIaE690FbUIzJTvkGDBr1LLogzssgR 7WkuDEZOGI4HBgwYcCJr1qyniOIS1bdv3/8888wzK/19uvuCBQuefPHFF0fDZPQm7OyC559/ fpn7ZldDwBAwBAwBQyC9IWC2fuljxU4zTFur9LFWNsrUQyCifQ/xXosua55tt0RMugTNQwIJ 4RI5U0tzgaYiRhqIUAyEvx+VxeehOGZTxylvuR/84Nh9ihAgRwm87PCeKapslc4HAr9myZJl 7vlo2NpMhEBEf+8T1bCHi46AaSIu+hLYAAwBQ+BiIFC/fn3P+Tm4byI0nSYx3c7g96GeVZYM 1ztCfbN3hoAhYAgYAoZARkbAfCIy8ura3AwBQ8AQMAQMAUPAEDAEDIHzgIAxEecBVGvSEDAE DAFDwBAwBAwBQ8AQyMgIGBORkVfX5mYIGAJpBoH9+/dnSzODsYFcFATIil74iy++KE7oYDMl vigrYJ0aAoZAaiJgTERqomltGQKGQJpBgKRyQ7Jnz/5Gjhw5XteZL1++wVdcccVDcqi+0IOc Pn36JX/6058GhOp38ODBV+G4OcyNU9fChQs//5e//OUO5bsIVSeSdzh8x1yM5HY4mb/46aef loxkjJGUef311y9X0kDWrsc999zTUGF6dShE7913392YzOE9q1ev3knlgttTtnLV8b9PSXv/ +9//ChAauF3ZsmV7NWrUqNWvv/5a0LUpnPGvaYODfg/ygTTRuNw3XTdt2pSbCGB3XX311d2e ffbZJiQevJ77v+qZaGFF/WV1T/LDKM3X/z5c/x999NGfyXHSSTgQWawBSQ3z++u6++TG6cpF 2p727bXXXtv1qquuerBz5871SeCYKLO7a8+uhoAhkHERSPF/UBkXEpuZIWAIZBQECMX6FkTd X3VCzD1P2NbcDz744N1pbX5ky97rxqnrf/7zn3d++OGHBk8//fR1KR3r999/X4rcFPVSWj+l 9SBWX7/pppsickxPrg8l5iNs7gMQ6UueeOKJSSTzq3zHHXc0V71evXrVmjVr1nWPPPLI5GbN mi0iZG7nUaNG/UnfPv/88xIq984777Rh3YvpnY6Utte2bduOhPE9TWje8TjTn2jZsuVDYvBE OHfq1Kn7yZMnszz33HNfQ8BXuPnmm2//vbeoKH1v0KDBgx06dJi3fPny9+6///65r7zyyjTy ibz1wgsvTHjggQc6rFu3zks++Ntvv+W67777bpw0aVIUyRDLuzZ0Tap/Einmpo2eRYoU2c/Y vmB+JQkK0MVfV/fJjdOVj7S9r7/+OoZwxZ1gItYTHnki61Dlsccea+DasashYAhkDgSMicgc 62yzNAQyPQJFixY9DkG3YN++fQEpMkTdDbzvpxNCL0AEkWeiUIUKFR4hOdyrkhj/97//9YhT SaClzZCWIyYmpg8ZqD3p91dffVW8atWqnSUJLlOmzGMCm/wRlQgh+zTnU//617+qns0CQADv /POf/7xpx44d3liT6hdmo1TlypW7urb//e9/l0Yq3Vnj4b4lBHRZScH1HYaiJGN7HE3BIPJk dJSE3NWTFF113HNSVxL45ejWrVvdYcOGlXvrrbfKU+9hwuD+XRJpRwx37979LvC7RGXAu7Uk 9+pTUnwYo0Cm8FB9aqwiZF3/JA2shoR9zYgRI+Yo6zjrNQVGooa+wyTVgLieRlLANST9W4RE fAXrVEXfIOaj9+zZk49cIPF6dkdK2luxYkW+jRs3lke7Mh6G4bfPPvvsm7179xaVZB+twtXs kSMkLBzL2m9hjFMxWboeRtDTRnTs2PFWNCEzNPa6deu2/ec//1mXPCKN0TJ12bZtWz6SHC4C p6s1vu3bt+dm7jFg5YbrXcP1z3zLFitWLHbKlClfqH+Y5gmM9Yply5bl8zeS3Dhd2Ujbmzp1 amn20PzRo0dPh/H5rWHDhgs4vMSLYt5ox/u9uHbtaggYAhkTAWMiMua62qwMAUMABDANyQFx llOnCGyIrTo1a9ZcKnAwLbkWgrAZEu5xb7/99gdIgOsh3fYIVMxSupYsWXIn5Qdz3UWZDqrT unXrriSw2waR9hzE0yQIwm7z588vAFGZE0lzZQjIKhDZ369atSov5h5dIIrnI6kdD9FVW/XD HFncOCUtZ2yVkR6XJnysl7guTL+5qFfCtcs4csF4FIeoi7v11ltnwMBsHTp06GQxDF26dOml bN0wCzLxOom2oJOrx/PxbNmyKU57yEPmWDKvgrEZxFxqlCpV6tBLL710N1LwKRMmTBiCiVEW iPn6qrxly5bSwiM2NjYfpmMNIIqPILkeWqJEiVhwbOk6CNUnZjvV8BfI4cpAjGfVWN3zgQMH csIcxEgLgPQ/G8xc4BtaplybN2/2sEArsXzGjBmfw1isdnV1TUl7x44dE0OQxeUMOXToUDb6 zg5jVwLGqVjp0qW3uD7Ieh5H7pB87AWPiF+5cuXlaAgWa4+sXbu2LMzGJ5hTTWGc5cBuA4zo AXDyuAZlTNeYYUZdc941XP8wvhtYz3ddBRjFCmgldmAOdci90zW5cbqykbb35ptvzkP78JkY HDHS48ePb8JeX6h2pLHp2rVrT3B5HE1a1XMxyXPjsqshYAikTQTMuSttrouNyhAwBFIBgSef fPIxzkBL+EXsg4ibrhdIS+s3b958JuYyK/Q8ceLE6dioV0fCvBlCuOyiRYuGRUdHn4Aw+xai 6CjEcjFMTspBPL2DRD8BqfbCTz75pCHS5Uo33njjlhMnTmT/9ttv34dwPSTiCR+ITUivp6pt GINpI0eO9AhoOdZCDHuEcqtWrbbpO8xOYZiVobp3B3b+c9q3b7+VNpPsFy3JLlfef1V2bAjU /RDZx2Ca9kOw1kUqH8dcpqnc+++//xUajMFiXGA0jsnUxl/f3ct/gAzfDZGQl4fIncd83lAO DcablYzdBWCmij/88MNrGeMomJ6ABsHVB+/9zHcShKVMjD5HqzBQUnoYg9NJ9enq6oqJzCIY n5ZPPfVUNSTfOxm/fCKywqRkl1aJ50bgHQ+TVBDG7WoYvHX++sH3KWmvSpUqB7WW+F+0gAn6 CaL5eq01jvK50CZEM8cE10+dOnX2cn8ajU0urgfF6GiuaAKqgbe3zyC4LytfvvwqMSVz586t AMP4g6sf6hquf+1Dnaon/w/Mt+5G6/FJcDvJjdOVj7Q9V569URHtx92sSQ4YF8+EjWX+jvWZ hnlXVX5jjRhTaxjQWWR//ymYuXHt2NUQMATSJwKmiUif62ajNgQMgQgQIPPvUIjdXjqnTZv2 HA7Mp3r06NFMVXfv3l3syy+/bA4x97JOTDNug7gvsHjx4uhChQrtFgOhcjKDQto7CRMZhLxF djqiTd8wJYFejPMkydSJFwOh90icr7jyyivX617HLbfcstG74R8I+vsxi3laJ4S0VxefiD1u nIxLEtz3MA+pLXMlmJmw/bp2dUVqHfJvOiYuRZF4l3RzrVGjRj8yfWeBuUlk9uJvq02bNk0Z xyOYR62BSO+PVuEzl4SP8Z6CoB4NLo3BaQiakjZInM+IPsXA48RA6BCzIik1WolEZlMQvXXA 8VmdYJAP/4bHdS/NB30fQDr+FcTqbZR7sHbt2kvoe5/aevnll+fCKO169NFHH3r33Xdvgtn4 Wdoj/xyC71PaHn19BpNSDg1VbzQhBdHEbIC4j8U/4hjMRADDXbt25WCOJzFd8hIZst887Q4M 3GGVEwMFZtXR6MQiza+A1qgYGqPY4HEGPyfVv8qJoZIj9ocffngLbY7gnB9cP7lx+stH0p4r D5O5gDXrw16ZgPanq3N6JzDACRineTDdb2DKN2LevHnXgNeLmr+ra1dDwBBI/wiE/A8n/U/L ZmAIGAKGQFQU0ZlOSeKrE9v8eM4fMSXxIgdhy56A/f6nEL/P6EQq3xdGYwR26jshjApgluIR PJK6Q6jWpO527gv5CSGIwBjMODYEY43kOg6ivbB7DxEVcO6F0BwMAd9Lp0xYXBk3TjEvON8u hHnZigNuyeT6FTPg2sAh9xKe3WPgiklRAj4IK91cdcVvoT8aFI/YDRT03bRr124JxOlCJOc3 QSTeLg2K+6xwtWhJNkBQD0TD8jrMSw6/qZIrB4aSyHsHzFB+cC1Im/vdO11hplb269dvjE40 J1qTr3SPadlsmYXBdC1VPxC3A2AifoPB8BgFMWAwgZ+yJn3RgrzGGHKi6QjLRKSkPbDKyl45 CUE8FFOmvrNnzx7FGsY0adJkB0xLPPcBPw+YxyKsX6zWUnPDr2Yd5kzXoElZzGMWfEcewOxr KutUCga3OWZ0Y1Qu3BGuf31D+9GV9T2ItmiwfC9CtZXcOF2dSNtDK9MEh/ZaqicmEbO+X1nr vM4vRu/FjPTs2bMm822PH1IhtG4TpJXRNzsMAUMgYyBgTETGWEebhSFgCESAAAToQUfYYgq0 CvOl6xSzXyd+BB0xd2lCJKA9SFJ3Y+ZUTU327t27Drbq10Ks7fvjvWe0rpj/aA1icPYNaBzc EAh5uXT16tUVFcJThBnE7llHWYIwPACBnCtcv0h34yHQouWwLOYGZ+NAPxBsp0Tca0yYba2G wLvchbeV6QvvHnNaAp6vk327G7+uMA470Mr8h3m+hCT9EI67j2Iu1EumRSLGIej7yAkaZmNb ixYtFkBg5/XX1z0E9qX4nXh+CvhQ1EIzsaNixYqH9c31idR+L7iv0wnTdxKtxnrdS+uB/0Vx NBJPy6FbJxqHRo0bN/Yk7UQ3akjZO9UW5YpgWnUNZmfL9JzUkZL2GNNp5t4Txq6i2oVQr4sm ZAtM2RH6WyoTNzlZ79y5MwcRi5phqhTYDzAJEzF3uxl/mxKYLo3CR+JfaFa24h/xf4qmxHok 64Acrn9M6q4El2KY1X0hpldj0CmNgIIDsIc9R/Nw4/SXi7Q9mLU4mMr6OLkXVl9aW96tFCZa C9bsdhiXQZMnT64JEziZMQ4cO3asZ9qX1NrYe0PAEEh/CJhPRPpbMxuxIWAIpBABpPuHILJK ynkZW+3JEDsP4QD6AoRQFhx/t0DweZJhCMWvifjTBd+BlvIrwA5+pLqUMzUmHJ2RvjfH9KkQ hPZE+R8ED0cmKkih1xDus7/MbypVqhSWuA2ur2fqHV64cGEFbmcm1a+0KxCtq5s2bdpfJlhE jloLYe8xA5hQbcJevQQ+ER1wAh6FRmEG5Z+Xb4Sk9hC8H7p+ibTUBVOs15w5lnuvK74IBzDB mQgzNBk79yr4RTTA1j8rc1pKf4MxzdkIs5MPB/Jx/nq6B5vdYHk/2oWs+BHkwNn8P65MuD5d GfwtNkCIr8ef4HH6KECEp/WYx/ys7zAaP/G9k6I+oRG6FEJ5PJoV+SQkeaS0PSTvk1577bU2 jPkYOOQBy2HqBG3EbjQyXyBl/xv75Kh8QCDK33QDkD8DvjbvwGi1Zw+dYq/tAIesMmNSVCf2 2wRXNqmrpPdJ9U9f5WBkL4W5e81fH+b1eRiUkvTZDswXhRsnDFBpVy7S9mCslxNOV87UA7S/ 2Xt7WP+vNAb2aif2/kZ8IxTqN84/Lrs3BAyBjIVAQA2esaaV4WYjFbCtVYZbVptQMghEtO8x 35FZRc1k2gr5WVJUaQv0MZjgkckOkuP8fpMjlZMzMpqJohBQcZgtHdO7pA5pCNBeHJctflJl In0frl8lI0MKfAiCzjOjcW1CeGeF2ckuHwK9U+hPtAuFYXJ2hGJ+XL3krpKzLhg4AAAgAElE QVR6Y2d/WvNDE5JDIWmD6yjR3ccff9wIjcwwojtFi5B1mo/gssk9S/OBKVS2UDiifSkCoyQt kefDklxb+p6S9qRRYt2jg/eJ2kMbkUt7BWZut55DHTLvgaEojh9HAsxcklhgAoSl0/CewW2E 6z+4bFLPkYwzqbrB7/XbYf2LoDE74f+NuL0RXD4dP/+Kb8vcdDz+9DL0iP7ep5fJZJZxGmGa PlbaflzpY51slKmLQET7/lyYiNQdrrXmR8AxEWhG/uF/b/fhEUiKiQhfy76eRwSMiTiP4Pqa jujvva+83aYBBMycKQ0sgg3BEDAEDIGMhgDS6Z2Y2szJaPOy+RgChoAhYAj8joAxEbYTDAFD wBAwBFIdgZYtW8bqTPWGrUFDwBAwBAyBNIGARWdKE8tggzAEDIGMjoB8LDL6HG1+iRHQmis0 rqJi+UMDJy5lT4aAIWAIpE8EjIlIn+tmozYEDIFkECBazhDCY75BdJvXdRI5ZzDRhB5yYU6T qZ6qn3EsvgQn7AGhGiV6zlU4bg5z49QVJ+HnlWxNzrSh6kTyTmFH5ZcQSdlzKUOUq7KEbu1/ Lm3464rYJhpRY0KG9iRrdydlzXbf5UBOUrl2isiEc3Irok4VdN/clZC47ciUHAidmtL21K+S uLFnetxzzz3KlO26iCLL9LVEjOrKeR+J4K4MfPjjhkzaJYl09SDO9/eCT02iGd2KQ3U/Imbd Igfr4PIZ/Zn9PIBoToE1yejztfkZApkFgRT/B5VZALJ5GgKGQPpFgBCnb0FE/lUnWZefT0hI yP3ggw/endZmRFSlvW6cupKp+h0i3zQgY3Qg78PZjpmoRaUgZuudbb2zLU/40t/IQu2FPD3b uqHKk2Su1qxZs64jmdlkslcvIhNyZ0eAtm3btiMRnk6TY2E80aFOYC71kGO0CD9bCQaiPQn6 biSMbx7XdkraUwhgciw8QM6QJSTRm0Q+hMpEoGquNpVpmlCv7WFmlhNW9keYwA6EoS3r+iPX whWDBg26hVC4o4n8NYp6y1iLMdy/RRbznfARrV1ZuxoChoAhkJ4RMCYiPa+ejd0QMAQiRoAc EccbNGiwgJCkAek1ieJu4H0/nSQBa+AaUwIuYt0/Qiz/V0lK181JtiX5ljZDWg4ky32Ir+9J ycmjULxq1aqdSUrWoEyZMo+pnQEDBlQitOrTnE+R28BLUOfaT+6qkKnkX9hEPgFvrEn1C7NR ShJx196///3v0oRB7azxcN8Sxqks0vC79F3Sccb2OCE5B5H7oSPfcrt6hIftoTru2X+VFkXJ w2BussAwNCJh37PkBRiorMUqB4FcrEePHnfongRxN5Nor57agzF6CbxbOyL/H//4R3n6vVfl 3CFtCXU84ty9o70aMAvTyHS8hlwdi5DorwD/KkqGt3HjxvIQ5+PJcv0bSey+QapfVG2oLqFr S8JYHEWTk+Da0jUl7cEIVEMTsmbEiBFzlAWafTIFRqKG2vvggw/qwwhMIcfDLyTMWwv+i1mH OvqmucJk3A6Wo5Qkjj3RmyzWpcDtFkLD9iLXxHyya5dQckOVhxkpD1YPk+H672Sz7uoyPif1 XntL2dO198j38Ry5GULuK4UDxrH9Hq21EgS+9957ZdTfXXfd1URrr3sd7JVO5M6orXsYn6vV PqF/B2kPKRyw3jP2xqqn8UmjQG6UvyhRIP33ZxzPaM+pXLi113d3hNuHroyuyvQtDZfmwB5u o2SDei/Nj/agfoPSFEk7pfeRjFN7+c4772wanFhR9e0wBAyBs0fAmIizx8xqGAKGQDpBgDwJ OURQ6RSxM2XKlDrkFFiq4cskBUK0GZLmcUiSPyCrcD2k1h6hCNHUlYy7Oyk/mOsuynRQHTIk d4Uo2waB9ZwSwD3zzDPd5s+fXwBiNufy5csrk925Srdu3b5XHgIk1F0gfuZD6I0ni69HqKmN JI4sbpySgjO2yhCbpSF4Vqp8mH5zUc/LCK1yjCMXjEdxsm/HkQtiBgzM1qFDh04Ww9ClS5de SM8XQ+DKxOskRG0n1dHB8/Fs2bIpxGLgkDmPGCi0AX3BMa+IdeZxPVqH4RCcI8l50FDviMCU e8uWLaVUkTwEMRCJt6FF+B7Cehg4XQUO1+gbRPUp+kmUywGiuQAJ9a7Wd3eQyC4bBOJJ94z2 KNfmzZtLkCBPIcmzQHB7dkVkyM5G2ewwWN788T34jjwOn/Pdy4jt6qekPRimrMLItUGujZx7 9uyJEZNAFu6iNWrU2OK+lSpVKg7Nh8fIgElM8eLFd5IA8AgM0HXstSUfffTRTNZhL/tmo/Jk YFZ3iIzVHoFOpue7yeg8ZcKECUOU8BDGqb7aTeo9OJcF8zokO3yPffY1DMs9oXxtYHLaM+Z8 9D2cPfQTYWMf0Z6Esf2FNamkTNbs6evWr19fDk3PAplqweS1Yo9MRQv0isbw5JNPNtKV/VWY PdOcHBiLWNfPx40bdztn/SFDhoyEAVrH+t6qcuHWXt91JLcPfy8VFSVin2SIXelvvObAOMvA zDVUlnjm0BWcxsE8DIDhOQgz6zFFkYyTdThK3pLSJAEcCJPVwWm4XL92NQQMgbNDINPZZp4d PFbaEDAE0jMCEEKPcQamAAG3D+J4ul4g3a7fvHnzmRBUK/QMATgdk5PqEGmbRawtWrRoWHR0 9AmI4m8xWzkKoVcMQqkcRNY7SGwTkFYv/OSTTxoika5EpuQtZCLO/u23376vrM+YIVXFB2IT UvOpahvGYBqEX0vdy9EWAs+TqpLpeJveQaQXhlkZqnt34A8wh2zIW2kzyX4h8ne58v6rEskh Jd4PMX4MQnY/hGpdZapmLtNUjkzcXyFBHwzhlRPC6hgM0Ht6DzGcAzxqQTQ2IP9GVjJuzwKP j/FBSECKfgWEewEI//wwW+sgpF9njglg4hHEqq+jdu3acySh1z0mWd+hCbgGpmOJskXr1Ptw h7RFjLMROMZDdBaE+L0aAnydsj8LU4jGFhDAP6EFul6YQ0TnSu32yIa9CIar5VNPPVUNyf1O xiOfiKzyZ4CZiEYSnuD6JAv1HpgXbwwQtsXIfB6vbxDC1ZCmf677pUuXlmFey0Wsy6ROydmU CJAEegUg6ouDy1rWeRSMY26I5pah3qsdHRDQ3yjhnU7WqRbakgowqqt+/+rttTzs3etg+Abg NxIvrRYZtm8ggd01w4YN+xVGYTxmfq2VdRxm9WOYnuNad/xnxmhdxZSA8y6S513m2gT7hTCj 8/WMluQA+3YWTMwmZd/u06dPgBlNau1dOzAG1cPtQ1cO5qgWmsBVL7zwgsfwg/lYtAfR7MFa 4L2BPj3mGub/G34nLzutWnLjrFix4mHW4n1p9tiTN8CYPIQgYDearxn0tcgxqG4cdjUEDIHw CJgmIjw+9tUQMATSMQIQTkMhyHrpnDZt2nM4MJ/C9KaZpoQEvdiXX37ZHMLhZZ2jR4++DeK+ AGYx0Zjr7BYDoXIyg4JYm7RkyRKsK4rsFAOh9zogJrGyiPPMKagTLwZC7zFhuQL79/W614Fk eKN3wz8Q9PdjjvO0Toh3ry6mP3vcOBnX4zAh7y1YsKC2zJUgCMP269rVFWl9yL/pmAEVjY2N LenmCgPQDyYhC8xNIgYAIqz3559//heItLHM60UI2hliINQ2zNhqfA7mQIT2llkLkvbrYXyO 6pv/AJ9AWFeItt0wHeX933UPA9NFJikQrvfCyJTSvU75E2CuMhcGaBdmOw+9++67N0HM/0w/ XkZsvn0GU1EOTVFvCMuCaAE2MOZAf8H96Dkl7SkzNuZtX2EGdBt05oMQx0tYo31iuGDMjkPs B3CDGcjF2D1mDsn8XnArpH7z5s17eNu2bfkxgyosDDC92YVWoFmlSpXW6DvtnYIZGs3easxe G4K2qQ2aDhRC2aJCvVcdHTCsgfmCUzxMbbnfv/z+L3uvqNaWPfeUW2+Y4stgFLy9JhMtvkdB zMdDQHvEOOM/zjhLs9H6g/WgefPmVfK3ST973TPalBMwpjv0LO0SR0AYmdzaR7oPwS2atfX6 UD/suc1i2nlfhD21Se90aJ0Yw1H2RH49RzpOMdbgPpG1eo69NAPmqi377F61YYchYAhEjkDI /3Air24lDQFDwBBIuwiIyIGQ8k5JZTl/xDSmpEaMv0NC9+7dP4Vwe0YnxGxfGI0RN9xww05J go8ePSrzGWkJssoOnbrbuS8k3wC914HpUAwmS2dI15HkxkG0F/69VFQURFkxd485zGCIuF46 JZF27904xby88sorC2FetuIkXDK5fkUwujYw+7hEBGLwgV15AgTuSjdXXfH76A9BusdfFsJ5 CrgcxkSlnSISQfwGHJTJPJ0b7c03zKsP0vBPIV5rYQpT2V9f92grAr4WmHqVhFjeH1wGCf/3 /fr1G4Md/TQYkl2614mj9FYxVjB3n4J1X4j112CMcuKfsJMxZ2VsJ9F8DKWPvrNnzx4FljFN mjQJEJvB/eg5Je1BlOaF2VsKozIQ7cMAmIjfILQ9RkbMIjhHu77YT9FoSrwxIPXfBsFeUpJx tAOT8J9oxFybgtMoGKa2MIgFYVa/V11J/NE0bVAfaKleZ545YB5aoiGICvXe9cc+DeCrvQzh nAhfNCFHIPRPMcbn3XqDwbMQyrPUBmtXHWZaWqeSaCQ8BoRv5TFTa8r6jhDuMDTTVcYdcmZ3 9+Guya19pPtQ6y2sXF/SxsmnBu3EDv/vSr5LmJ0dw2cnTmUjHafKzp07txDzvBl/pdYwh1vZ 77P13g5DwBCIHAFjIiLHykoaAoZAOkcAQvAgzIFneoIp0CrMl66Tk6tO/Ag6YsbShIg8eyBs d2PWU03TJTxnHcxVrkUKv++P954zq+yzIXRicLoNaBwcPDgXL8X2uiLtFxXxC1F81lGWILgO QNDlCtcvUvh4HMWjMRuKFnOD6VCgH4irUyJMNSbMtlbDEFzuwttiblSDd49BdHlDlqOsnE0x 9VoAkToEJmYk5iylkZ7Ldrw9RG4pGIvq+Fm0xSTsJATxciTFm5Dk5nVzdleI+yqaMwxATvqr inZmnb6pb/mh6B4H9C1gvQ6J8FaYpwTd65QmB7OShhB3d6ocJjlFMPe5BnOyZTCEp6nXk7FV 1Dc0BHUh/rbAHB3Rc1JHStqj3+IQpk8zvxw60Yg0aty48Xz1Ib+SyZMn1xHeIm6R/NeC8fT2 gMzIOnbsOAUzsI68i8P34W2+j2UPrYG5GIIW4jdMaTzmEmYoN8xJHzFnOAVva9GixQKI8Lys mUzCznjv5kfI2Oq6h+iPQTJfBp8Vj4mFOaiG1io/TOduGLe9rJHn36N9isS+H3uxuPxtqN+G 8XwKwzMR5sbzqUD7VkKENG3Fae20j0Ixo24MSV2TWntXPtw+FEMgXw2VZZ293498I8TMszfa gF8BtHdL2JdX6r3KMZdrCXSw0u1jvUvukFke+/p+fud9+e3Ib2QYazAM7d/q5Orad0PAEEiM QEANmfi1PRkChoAhkPEQQLp/SBLYP4ipyRCKD2Fj/QImGVmQ4G7Bv2GMZg2B+jXmOl3wHWgp vwLs70fqvZypIbQ7Q1Q3x/SpEJFqJopw1Df/AbEdi9R0DcRkf5nBQDwu83+P5J56h3E6rkDZ mUn1C8EYjxPvapxe+8sEC4JqLQSRZ2qDOcsmJM0lINQ7QLiOwi5+BuWfl026pPvYp3/oxoGd excI+NecOZbs3TlHYsKVH0KzLo65DyC5fRmGphkYDtScIOpPYvM/HwYpUfx/RUgCy+eQqOeE aduOQ7sneafcZUh978RpeInrN9QVgvEnfAQ6YUbVC03PpTAQ49GYeOY0+ENMgghsw3iPQezm YU7DQrXhf5eS9uS7gb39esyuHoeRK8BY1jP2n9UuJk7T8ZOoCI6DIHDzooma5fdJwOH4f5gE HWRvdWf+ceyvWPZcYbQmRWAOltetW9fT/kDIHmJfLGXNBhOJayP95KOdcZj8XB3qvZsTTFUF 2q2BJuMS9td3YkD0DT+CzjB2w2Es1xLu9mMYtvvxv2mscuyF78S4yZlYUb9wTl4KfssZWy0k 8M3Y39MxY2vMuj0Nc5QL/41fCDTQ2DF9ru/krkmtvauH5m9jUvsQ35vSjKMdzOoi/X6IBrUU DJ+THxN4bsOHYRHtn8ZMcBXap+cZ629gVhBG4l+u/eSuBFIoARN6l4IOwFR9hMbwWHJ17Lsh YAgkjcD/11cmXca+XHwEpEq2tbr462AjuLAIRLTvkZjWYlg1UzI0ObpKW6C6clT1tyFzE6Se +f0mR/qOpD4nmomiEI9xyREh0hCgvTgu221/2ym5D9evwlwikT8EcX/K3zZEVlaYneyy5dd7 CNB8SJ0LQ0TtCMX8+Ov67yUNFgEnTJDCx8AgHQw1J951hohdJz8EJO15grHzt5ncPdLwIjBA 0v54vimuvCTl4B8dvF7ue1LXlLQnsyZM27KFmqs0K+AqM7EkNSGqj69BURiHODn1hhqb9ggS 8RxygNZ3GDZceYb3DH6vb/hLvMn6PYvGIjsMwxG3rvoWfMgJHEYgBmJ8nxiW4O+hnvVbYF/H y7ROJllow04436BQ5f3vzmbtI92Hwg8m/pTzy3H9yTEaTVcemKhY7Uv3Prmr28fJlQv6/ium XXOD3tlj6iMQ0d/71O/WWjwXBIwwPRf0Llxd+3FdOKytp7SDQET7/lyYiLQz1YwxEkdI4hD+ Y8aY0YWfhWMiQvXsmIhImYJQbZyvdxl47Y2JOF+bJnG7Ef29T1zFni42AmbOdLFXwPo3BAwB QyCDIIDN+0Ik7omctTPI1NLENNAgTcKcLE2a4Njap4ktYoMwBC4oAqaJuKBwp7gz49BTDJ1V TMcIRLTvTRORjlfYhn4GAuE0EWcUthcXAgHTRFwIlKOiIvp7f2GGYr1EioBFZ4oUKStnCBgC 6RIBRdcZO3bspbLDTpcTyASDVihZEvOVlA18JpiuTdEQMAQMgQyBgDERGWIZbRKGgCEQjIBC ZxJd5z6i0bxInodO3L+IE+zDckIOLhvpsxyxiXLTQA7LkdbxlzvX+v62gu+JUlNWycKC34d7 JqTnbZwtVQYn2hdFyIcrn5JvCiernBOh6hIFqbbWhLwId+JHUQ1znfuIuvO3pKICER2qHbkM EkWDUlnWtqvWGofuK0P1o3dEBqqDqVV3laVOZbeGckAmCVxTjYOwrHcp1GioNpRXQP2Tw+BR HHpbkKysuCtHZKEYQoa2oY0eJC9r4s8l4sr4r6Hm4caH43qUG59CyMrXIPhUBnJ/e3ZvCBgC hsDFQCBF/xFejIFan4aAIWAInA0ChD3tqoRZxJfvR6jQV4ip/7RyEpCDoPPZtOMvK+Lw448/ votoOinyJzvX+v6xBN8T6vM3cgckG/I0uJ57hhB+nYhHXoQg9+5croQMLUHEoebKS0Ckn0Cy PdcmUYDugoDPQyK0ESQSm0Ciu4WElH1nzJgx/yKqUBU/Q0DI0koQ3u1Jvncj4VIDCfAIa1qB cK/tyd2wnFCwPxIetAOhWcu6PtxVCdZgPm4h18NCQtfOIO/Drb169bpe30lwdwcMwrWYEU0m 4lEcDMJjjsFw9XUlMV53LlnIv/AlDs4nIfq9faR8GOQv6E5I2yyM82vmUIE2bvfXdfdJzcM/ PqIpRbnxEZXoMGFOF/tPksiVI+xpmvSLcPO0qyFgCGQOBIyJyBzrbLM0BDIVAkqORrz9y8kO PBZH1OOafPHixY+Ts2Bs9erVV4mY1wnR3IKwqC9xvgiR2FyaAh2SSksaTAjNp8m/MBDtQ329 J3zpg7rSxhMQszkknZYEXPWRUD/y6quvXqHvOsihcI00A0j4B0Ewt5FZVXB9ZeEl58C9v9cI /68SbEFM3q5xwzA0IlfAsxobuROaqCYhTIv16NHjDt0zl5tJeFdPknHNj7j/rRUaVd+S6hOi WFL4SyDiS9aoUaMjOTCa0v4A5Q7wS/9JrncDmPbTCeHfQG2GOiCmo8nGnI98CvHB36U1IfRs XtZnOvk4rmIOXQkvWp58EB0g0pvw/SuSgN3o6hHWtKRyEJBAL8G905WM0PXJgTCF/B6/oPFY y1osRqNRx19G92TXvpJkbj+MGDFiDszDOpyAfyaEanWF/CQEaz3m/IGS3XH9ISEhIQ8hVgPr qPrSalE2D+2M6dKly2ZyDcxk/f8s8yvwvJpM2keUVE65GMgxMpUEb9drnVTXfyQ1D//4yImg 5IDe+JS3Q3kn3Alzk5MkiStgnuaJQfOvi78fuzcEDAFD4EIgYEzEhUDZ+jAEDIELigAS60sh XncFh8KEYD9AwqnvIUZPI7muR4bfq5B6D4EY+wdEYM1HHnmktgaK5qIkDEczpNwfQ6xNRfvQ RkwDyds+03fej4SIP96vX7/6xNHfDxH4CqY4cyEu7xYjIoKfZG5daW88xPBwpMdlIC4bBtcn YdspxpIoD4La9x8kt7scwrEbZkd9ISLzynSGjMrXo3UYTgKukRMnTmyod2TPzo3WpZTqkqMh BoL4Nvr/HqJ6GP4gVyGlv0bfkuqTuqXRDOTkzLVgwYKasbGxhSDy32Z+8SQna6G6Mh0Cv2ZP PPHEOCT+H4BdPYhyLzOyvvsPktQtJ5/D5xDCq/3vdT9hwoSr0AAs0D3J25pCtI/+8MMPZ8Jo FYFRWg7zc5hcCPn1XQdJ075TW2iSEuVaIIFbURieLb+XioqSJoF1inHP7kr734DjT+6ZJH7l 2RvrIPajwf+oS2an7zB+u8jenagN5SmAIRp44sSJLOyL0mgeWpGoba1yP+DPUYz7wBjIjREH w5EPDcsZPjhJzSOp8bnx6iozK/ZhC5LeTdAzWZq1h3vS9+NkW67qmER9s8MQMAQMgQuBgDER FwJl68MQMAQuKAIkRcsj6XC4TrE9r3v77bfPEgEJQRuLRHsm0vwAQQxxPAEJ+TYRt5iP7J82 bVoMZT2puhLNQcRFUX/ZqFGjJqBhOIC5zbb4+PgSmLfkQlJci4Rsq1544YWlSiIGQzEWTcWu 4PrKjAxx+N/gcYphkcQfRqUvZj1tYX7WIPXur7Jr164tBIFdAOI1v6TqzON1MhzvD26D7Mhz JJ1Ho7Cjbdu23zE3j4lIqk9/fRJ8HaH8OBijWMx8psJQePb/MFv1kZLP7Nu37wphg8ZjOhqE 6sw7O8zSn3WKofG3FeoejIpitrN7/vz5BTANK0w7O6UVYN4lYLbWkCm8LH4AK0LV9b+DsI8G o4B2AoJ6D9m4c/nL6F5J75SYTbhi+tQO86rL+vTp8zPMRDQajkT7BOZzL/jmDG5Dz5s3b87d u3fvLjBZdVjfTdI2YCYXzf4IjIF9oOzap2GIzhhHqDb1zj8+GNAoNz5/ebJZ/wWfjTngdlDv MRf7jgSE/dlfP7IujdC0DcS3o5kFEPCjZveGgCFwPhFIkV3v+RyQtW0IGAKGwLkiAIEXB2FV Sk6z/ozHsnWH8L7+tddemwPxWgTp/kbXl+pAOAek3zyLGPQOSathTHK4Z3eFiMwKQ9EdQvLP EHHb3XsRlkjFd7hnmcBwv1mEsnsX7gpT0lvmM2g6RmMvv8Zf9sknn1yNw+0c2uyNpuEgDr1z xo0bN8lfRvdlypSJde+QmO/Gabqpe07uignUAZcJGE3EUSTw3tzRdhT78ssvy6AR+IvaQOuS DbOmnRC+RZHOP613zHsDxPYbuk/qgPDfu3r16kIQxXH4EmTXOuEvUJUs2nupmweNTTMYMU/r k1Qbeg+zcxyGJCDxZ31z0fauUHXQoJSAMevB+DaT8fjv0iJAcBdGgh+or3rgnrN8+fJxodpQ HcY6UJmd8Xvoh0ZqBTgdY28E2kA7kgMG8yRZqs8qX4YbH+OPcuNzY0CzlAsGsjYaqMHuna7a 25hTzdMpMzQ0Em3ZOzczpyekbfOXtXtDwBAwBFIbAdNEpDai1p4hYAhcaATOIJaQ+O+AOM2B 6UkiJ1uYh6sx/6kLYXwiJiZmO9L9wm6wmLAUh3jc4J4x+zmjXfdNVzEEEPn3QUzOwb6/D1Gf hrvvaB12QnAXdM+KsiNfBPec3BVfgyloUg5jgtROkY0UAtXVkX0+DNI3aAf6wGB8iilVLUyH Krvv7oo0Pbe7R+JfEsbgDG2F+x58xSE95NwZUwK+E59CpD6jE0l4XzQ0I5CA7yBfRy+dyTEQ 6gutz/Lx48fX+NOf/nSMaEaT8DHpAUOWDcL7f2h3uqOZ+EXaieBxBT/jsxGPqVi0e0/f0Zdd dlmAeXPvMbsqikP1Q4x9/NKlS98XM6BvaDv20G9uf2hZtCpFYG4CDKHKYRJWSn4iutcB8xlH 1K8NMEJF8GGIh3EIjAGzuCLsr1gYrd8dbH6vEvZf//jw04ly43OV8K+5Dt+UrdKauXfuKgYM bVFN9kJ7GONCrVq1mmAMhEMnVa4hfwup0rI1YgikcwSMiUjnC2jDNwQMgSiPIPTj0KRJk901 a9acPXTo0BY4+HraBRxoC2N7fgemSz+qLN+XIp2vJVMc+THgR1GpYcOGK/3tBN/LhInjFKYq OTEryispNpqNpSLakALXcuVxsF0KgVlRvhFiNnDabYPPQQF/fZWdOXPmJfIzcPXcFfv9BRDo Q/CxGLly5crS2O8PxOSlvRzGYSyqY2bUFhOakzghL0eyvonxnJFfYfbs2VUYX1ZFD6Kfqvgm rAvXp+s73BXfjFVI4a8TZjrBqyNz8xy7w9UL/iYzK7Qb2eSYjU/ETzACw+T0jM/AZJii4fik BBiw4Lr+Z0yTFmPOVUdmRWLUIOBrwQCsVxk5b8t/QfcwezeB33wI7WUyadKp8f9hRrQJHL1I TXyvdvjw4fxE9vK0GXrGbyY/DM129lFlRYNSe+qL9SmFadNi/BKWoikoJzMutYvpWjOYUW8M 8mPA9KuK6oQ7/ONjLlFufK4ODvxXsl+XuWdd0UrIf+R2mJhBYFCTsEuDpBQAACAASURBVK+T 2QcDyYky1V/O7s8ZgTP+vpxzi9aAIZBBEDBzpgyykDYNQyATI3CG5FlYYJ//BVLZe4jYM5gI SfuQzBckStEPMBZz9B2zoLkQhz0x+xmAWcxROdRCFIa1wxezgJnTCgjVZ9asWSPCfg7EXR85 /PJ+PXb3m5Cst4J4HIPt+lKIvOcg9vdB6G3DCXpRcH1Mgy7DUfbOl156aYnGFHwgPd/EOVKM ENqGukicH4CgfBm7+2aYEQ1Eu7APjclJJNXzaStR/gRFM0J6/RwamZyYyGyHoP5e7SfXZ/AY /M8Q5pOZ00P4HrwA45WF9rcQGWmMv0yk9/PmzfuQcLvNwe1RpPrbkd7vl0M465SPvB7eWJNr CwZkOv4iFfFjGASzlhfTsln4DqxSPcZVP2/evEdkSob2pizamOKMt7lrE/OzzTArr8JYfgTT 1wutRj0iM+Vjnd51WgSYhs4wacPF9OALMpX98RhO5jJ1yoL25VtFT9JJngvttb9pH8l/hvV/ U/3AWJR+44032sH4LXL9hroGj4898YYbn8qjiaqAKdYMf9377ruvE9htxDdCoXlDml/5y9t9 ihEI+fclxa1ZRUMgAyEQkX1uBppvep2K1Km2Vul19WzcKUUg4n2PGU0rOgmZKE2mKkiTC0P8 xsqMyT8YaQmQ4sZAXCZIKu3/Fu5e5kVImz2HXOzXC2IadQxmJEHtIVXPK8JS9dU3hOUpRffx t+ev73+f3L3al68CNvjZNG6IyIOY5BwIrqfkZNjGr8Mpey6EeZ6zmVtwW8HP0trIJ0DvU4N4 VXuEWy2CeVZuTMN2+n1YgvtO6lkaHRi4BKI6JXKSTqp88Hu3D6SBcAxEcBk9Y/KWjzXNL2f5 4O/yW0BrJC3G7uBvZ/MMowhfM7xncnXcXkiunH0/JwS2Ydo3/pxasMqRIhDx3/tIG7Ry5x8B I0zPP8ap0YP9uFIDRWsjvSEQ8b6HiSjE5NpxmnYVEBwTgS2/Z7qV3hY+M483UiYiM2N0geYu gcMYmIiIhQsXaFwZtZuI/95nVADS47zsP9z0uGo2ZkPAEEiEgP6jh5GYxsvGnJn+7xqmNwtx zj2r6ECJALUHQyBzIyAGYpoxEJl7E9jsk0cg0/9nmzxEVsIQMATSAwL8h78GRkJhTcVIhDRt Sg/zSI0xkgU6rA1+avRhbRgCGRSBbczLGIgMurg2rdRFwJiI1MXTWjMEDIH/x96ZwNlYtn/c OvalwZBClhbZ96XsL1qohKwRyVIiLZIkIu1UvOlte0vxKkpJoZBoI2SL7Ev2fd+X//f36J7/ mePMnGMYM2fmej6fx7Pd6+++z7h+93Vd95WICPyzcjgBMpGLZuTj1K5FZraZiGNiVV8YAvjY KIP3z4XltNQXgYBMabQL0zb+hlyUT8tFtMGyGgKGgCGQIAjoD5wdhkBKQ8DmfUobceuvELB5 b/MgJSJg8z4MR93iRIThoFmTDQFDwBAwBAwBQ8AQMAQMgcREwEhEYqJvdRsChkB8EYggY+H4 ZrZ8hoAhYAgYAoaAIWAIpAQETM2XEkbZ+uiPQKB5X55E73DKfvm4fwZ7NgSSAQKB5n0y6JZ1 wRCIEwGb93HCYx8NgfgjYD+u+GNnOcMXATfv5ST9OOc6TgVWO8mpb/s47TAEkhsCbt4nt35Z fwyBuBCweR8XOkn0m+1akkQHxq9Z+nHZWPmBYo/JHgE373U9xJk12ffYOmgInEPA/t7bTEhp CLi/9ymt39ZfQyDBEdCPyw5DIKUh4Oa9NBGPca7lNE1ESpsFKa+/bt6nvJ5bj1MyAjbvU/Lo W98TFAH7cSUovFZ4EkUg0LyXT8R/OM9wnkii7bZmGQIXg0CgeX8x5VleQyAcELB5Hw6jZG0M SwTsxxWWw2aNvkgE4pr36Sn7moss37IbAkkRgbjmfVJsr7XJELgUCNi8vxQoWhmGQAAE7McV ABR7lewRsHmf7IfYOhgAAZv3AUCxV8keAZv3YTjEFiciDAfNmmwIGAKGgCFgCBgChoAhYAgk JgJGIhITfavbEDAEDAFDwBAwBAwBQ8AQCEMEjESE4aBZkw0BQ8AQMAQMAUPAEDAEDIHERMBI RGKib3UbAoaAIWAIGAKGgCFgCBgCYYiAkYgwHDRrsiFgCBgChoAhYAgYAoaAIZCYCBiJSEz0 rW5DwBAwBAwBQ8AQMAQMAUMgDBEwEhGGg2ZNNgQMAUPAEDAEDAFDwBAwBBITASMRiYm+1W0I GAKGgCFgCBgChoAhYAiEIQJGIsJw0KzJhoAhYAgYAoaAIWAIGAKGQGIiYCQiMdG3ug0BQ8AQ MAQMAUPAEDAEDIEwRMBIRBgOmjXZEDAEDAFDwBAwBAwBQ8AQSEwE0iVm5VZ3wiNw9uzZXNSS jzMzZ+qEr9FqMAQuDQJVqlRJNWfOnMqXpjQrJUQEzpLuCOe21KlT7w4xjyUzBAwBQ8AQSIEI GIlIpoMOechB1+py5k+mXbRuJXMEKlWqpB56/yTzribJ7vE3ZAsNmwGZ2J8kG2iNMgQMAUPA EEhUBMycKVHhT5jK+c//WkpuyXlZCcTMmTOv0HnmzJmE6ZiVaggYApcTAf39aPnP35PLWa/V ZQgYAoaAIRAGCBiJCINBupAm+mggorVMH3/88dXlypVrV6RIke733ntvrSVLlmR1ZT799NOl Spcu3ZHzvhdeeOEG937fvn3p7r777vrXXnvtgzfddFPz3377TZqNgEenTp2qZ8qU6cW77rqr Z5MmTR7OnDnzy82bN6/nyET79u1rqhzfzCozR44cA6dPny5zKzsMAUMgaSKgvyN1//m7kjRb aK0yBAwBQ8AQSBQEjEQkCuwJWqlMmKIJxLp16zI+8MAD3XPlynVg4MCBX65atSr/HXfc0UEt eP3114u98cYbrapVq7asY8eOPw0ZMqTNW2+9VVjfGjdufNfcuXNLde/efWqBAgV23XrrrT0P HTp03nwh302ffvrpbeR7C+IxYO/evc998sknQ6dOnVobUnGLyvI/atSo0WzZsmU3TJ48eVi9 evXM7tofIHs2BJIWAh6RSFpNstYYAoaAIWAIJDYC5wmFid0gqz/+CLBaqFX9GCZM//vf/wrn yZNnx7Rp075EC7Hp3//+96T169df9+eff2b54IMPat52223T/vOf//z2yCOPrEYbsfjDDz+s evz48dS//PJLjbFjx37Qs2fPNVx/OHbsWKYRI0Zc59+68ePHN2zduvWkDh06bHTfmjVrtq1q 1apzIRJ1T548GcOZu1atWk3/+uuv62jP69WrV9/n8tjVEDAEkjQC+f/5+5KkG2mNMwQMAUPA ELh8CBiJuHxYX46atAtTjKNNmzbrJk6c+K57CSEohlZiW4kSJQ7v3Lkzd8WKFTe5b9I4bN++ Peqnn36KTJ8+/fGbb745Wsgnz87ly5dHubS6yizq4MGDkffcc88q3/e6b9q06ZITJ05knj9/ fnb3rXbt2nfPmjWrNuTlvQoVKhx07+1qCBgCYYHAeX9fwqLV1khDwBAwBAyBBEHASESCwJpo hWob1xhHoUKFjuEP4QnsaBsqDh8+vFXbtm2nKBGmR5FoKY65DAULFtyL4J9h4cKFkRkyZDjq 3ut6xRVX7Dt8+HCE77s1a9Zk0TO+Fod93+seTcQuXffs2ePlWbt27XWQjhL58uX7+5lnnrlV 3+wwBAyBsELgvL8vYdV6a6whYAgYAobAJUXASMQlhTPRC4thOuRaIydpNA+dPvroo9vwgxjJ OV/fIiIiTm7evNkjAnrG5yEDpGJn1qxZTx49ejT6vb5h4hRRtGhRjxjoWQfaBE9TMWrUqCLn 3vz/v2PGjCnG01nIxF69xdn60DfffPMmx8eQifIQiVL/n9ruDAFDIAwQCPj3JQzabU00BAwB Q8AQSAAEjEQkAKhJqUjIQBoE+Y7ZsmU7hJP1kK5du65z7WN3pD1oCCLd88aNGyOvueaabWgu 9uLLkHHFihXRK49oFHKxo9JWl1ZXzJ+OR0ZGbpsxY0Zx3/e6x6eiGN/X8v2UntFAbKEd+9m1 aWvDhg2nDhs2rCVO3pn0zQ5DwBAwBAwBQ8AQMAQMgfBCwEhEeI3XBbf25ZdfvmHXrl152EHp SzlM4/OQXqe2X2VXpsU4P1eV8/O3336b5+eff64MUVhbuXLl/VdeeeUGtAXVVOFjjz1W7siR I1nr16+/078BLVu2/I7tX6u++OKL0dvDaqtYIg1X7dat22T/9HrGL2NqxowZj5C3WaDv9s4Q MAQMAUPAEDAEDAFDIGkjoK377EjGCCDgF9m9e/eVaBhe9e3md9999+x77703E5Ok6/F3GATB yMzWq7OffPLJFUrHTkwfs5tTD7QVNdiZKcugQYPeJRbEeVHk2O1pLgQjAsLxwIABA06lSZPm DLu4pOrbt++HTz311F++dbr77Nmznx48ePAYSEYvtp1d8Oyzz/7pvtnVEDAEDAFDwBAwBAwB QyDpI2A2rkl/jNTCs5xBxwrhvTLpKinDhRzsmHQFmodjBISL4UwtzQWaiihpIAIRCN86lBaf h7yYTZ0kvcV+8AXH7uOFADFK4LIjuscrs2VKCAR+T5069dyEKNjKjIFASH/vY+SwB0Mg/BGw eR+GY2iaiDActEvd5Jo1a3rOz/7lskPTWQLTbfd/H+hZaYlwvS3QN3tnCBgChoAhYAgYAoaA IZC8EDCfiOQ1ntYbQ8AQMAQMAUPAEDAEDAFDIMERMBKR4BBbBYaAIWAIGAKGgCFgCBgChkDy QsBIRPIaz7DozYEDB9KGRUOtkQmGAFHRc3755Zd52TrYTCoTDGUr2BAwBAwBQ8AQSDgEjEQk HLZJpmSCyr2SLl26YenTp39NZ5YsWYZcd911XeVQfbkbOXPmzCuuuuqqAYHqHTJkSHEcN4e7 duqaM2fOZ//1r3/dpXgXgfKE8g6H76jECG6Hk/ngzz77LH8obQwlzWuvvXatggYydt1at25d W9v06tAWvffcc09dIod3L1++fDul8y9P0cqVx/d9fMr7448/srE1cMvChQv3qFOnTpPff/89 uytTOONf0wwH/W7EA6mndrlvum7YsCEjO4A1v/HGGzs9/fTT9Qg8WI37x/TMbmG5fdPqnuCH qdRf3/dx1f/xxx9fTYyTdsKBncVqEdQwq29edx+snS5dqOVp3pYqVapj8eLFO7dv374mARxj RHZ35dnVEDAEDAFDwBBITgjEWzBLTiCkhL6wFesbCHWP6USYe5ZtWzN27tz5nqTWd6Jl73Pt 1PXDDz98+4cffqjVu3fvCvFt6/fff1+A2BQ14ps/vvkQVl+75ZZbQnJMD1aHAvOxbe4DCOlL Hn300SkE8yt91113NVS+Hj16VJ49e3aFhx56aGqDBg0WsWVu+9GjR1+lb1988UU+pXv77beb Me559E5HfMtr0aJFW7bxPcvWvBNwpj/VuHHjriJ4EpzbtWvX5fTp06n79+//NQJ8sVtvvfXO c7WlSqXvtWrV6tymTZt5y5Yte+/++++f+9JLL80gnsgbzz333KQHHnigzZo1a7zgg3///XeG ++677+YpU6akIhhiUVeGrrHVTyDFjJTRPVeuXAdo25f0Lz+bAnTwzav7YO106UMt7+uvv45i u+J2kIi1bI88mXEo07Nnz1quHLsaAoaAIWAIGALJFQEjEcl1ZOPoV+7cuU8i0C3Yv39/9Coy Qt1NvO+nE0EvWggizkSOYsWKPURwuJe1Yvy///3PE061Ai1thrQcUVFRfYhA7a1+T5w4MW/Z smXbayW4UKFCPdUM4keUZAvZ3pxPvPPOO2XjaNp5nxCAt1999dUbtm3b5rU1tnohGwVKly7d 0RXw3//+tyCr0u3VHu4bI0AX1iq4vkMo8tO2R9AUDCJORlutkLt8WkVXHvcc25UAfuk7depU ffjw4UXeeOONouR7kG1wX9SKtBOGu3Tp0hz8rlAa8G6qlXvVqVV8iFF0pPBAdaqtEmRd/QQN LMcK+6qRI0fOUdRxxmsaRKKivkOSKiJczyAo4CqC/i1iRXw541RG3xDmI/fu3ZuFWCB79OyO +JS3fPnyLOvXry+KdmUChOHv8ePHf7Nv377cWtlHq3Ajc+QoAQvHMfabaON0TJaqQQQ9bUTb tm1vRxPyo9pevXr1Fv/5z3+qE0ekLlqmDlu2bMlCkMNF4HSj2rd169aM9D0KrFxzvWtc9dPf wnny5Nkxbdq0L1U/pHkSbb3uzz//zOJbSLB2urShljd9+vSCzKH5Y8aMmQnx+bt27doLOLzA iyJvlOP9Xly5djUEDAFDwBAwBJILAkYikstIBukHpiHpEc4idErARtiqWqlSpaXKhmlJKQTC Bqxwf/7WW299wApwDVa3PQEVs5SO+fPn3076IVx3kqaN8jRt2rQjAey2IKT1R3iagkDYaf78 +dkQKiNYaS6NAFkGIfv7FStWZMbcowNC8XxWaicgdFVR/jiO1K6dWi2nbaVZPS7I9rFe4Lo4 6s1AvnyuXNqRAeKRF6Fu1+233/4jBGbz0KFDp4owdOjQoYeidUMWZOJ1Gm1BO5eP55Np06bV ftUBD5ljybwKYjOIvlQsUKDA4eeff/4eVsGnTZo06RVMjFIjzNdU5k2bNhUUHjt27MiC6Vgt hOKjrFwPzZcv3w5wbOwqCFQnZjvl8BdI79IgjKdRW93zwYMHIyAHUdICsPqfFjIX/Q0tU4aN Gzd6WKCVWPbjjz9+AbFY6fLqGp/yTpw4IUKQ2sUMOXz4cFrqTgexywdxylOwYMFNrg6inu8i dkgW5oInxP/111/XoiFYrDmyevXqwpCNTzGnmkY7i4DdOojoQXDyWIMipqvNkFFXnHeNq36I 7zrG812XAaJYDK3ENsyhDrt3ugZrp0sbanmvv/76PLQP40VwRKQnTJhQj7m+UOVIY9OxY8fu 4PIImrSyF2OS59plV0PAEDAEDAFDIKkgYE6NSWUkErgdjz/+eE/O6Frwi9iPEDdTL1gtrdmw YcNZmMss1/PkyZNnYqNenhXmjQjChRctWjQ8MjLyFILZtwhFxxGW82ByUgTh6W1W9I+xqr3w 008/rc3qcsmbb75506lTp9J9++237yO4HpbwhA/EBlavp6tsiMGMUaNGeQK0HGsRhj1BuUmT Jlv0HbKTE7IyVPfuwM5/TqtWrTZTZqz1oiXZ6dL7XhUdGwH1AEL2CUjTAQTW6qzK76IvM5Tu /fffn4gGY4iIC0TjhExtfPO7e/kPEOG7NivkRRFy59GfYYqhQXvTELE7G2Qq74MPPriaNo6G 9ERrEFx+8D5Af6cgWMrE6Au0CgO1Sg8xOBtbnS6vrpjILIL4NH7iiSfKsfK9nfbLJyINJCWd tEo81wHvPZCk7BC3GyF4a3zz+9/Hp7wyZcoc0ljif9EIEvQzQnM1jTWO8hnQJkTSx2OunqpV q+7j/iwamwxcD4noqK9oAsqBtzfPELivKVq06AqRkrlz5xaDMP7g8ge6xlW/5qFO5ZP/B+Zb 96D1+NS/nGDtdOlDLc+lZ25cj/bjHsYkPcTFM2FjmL9jfGZg3lWW31gd2tQUAjqb6O8/+5Mb V45dDQFDwBAwBAyBcEHANBHhMlIX2U4i/w5F2O2hc8aMGf1xYD7TrVu3Bip29+7deb766quG CHMv6MQ04w6E+2yLFy+OzJEjx24RCKWTGRSrvVMwkWGRN9d2J7TpG6YkyIu7vJVk8uwRgdB7 Vpyvu+GGG9bqXsdtt9223rvhHwT6+zGL6a0TQdrLi0/EXtdO2qUV3PcwD6kicyXITJz1unJ1 ZdU64NzGxCU3K975XV8rVqzYj0jfqSE3McxefMtq1qxZfdrxEOZRqxDSn0GrMN4F4aO9ZxCo x4BLXXB6BU1JM1acz9t9iobvEoHQIbKiVWq0EjHMphB6q4Lj0zrBIAv+DY/oXpoP6j7I6vhE hNU7SNe5SpUqS6h7v8p64YUX5kKUdj788MNd33333VsgG79Ie+TbB//7+JZHXeMhKUXQUPVC E5IdTcw6hPsd+EecgExEY7hz58709PE0pkteIEPmm6fdgcAdUToRKDArj0ZnB6v5xdAa5UFj tMO/nf7PsdWvdCJUcsT+6KOPbqPMkZzz/fMHa6dv+lDKc+khmQsYsz7MlUlofzo6p3c2BjgF cZoH6R6GKd/IefPmlQCvweq/y2tXQ8AQMAQMAUMgHBEIKGiFY0eszXEjwO5MZ7TiqxPb/D2c P2FK4u0chC37Mez3P0P4fUonq/J9IRojsVPfjmCUDbMUT+DRqjuCaiXybuU+h68ghBAYhRnH Ov9WsHK9C6E9p3uPEBXt3IugOQQBvodOmbC4NK6dIi843y6EvGzGATd/sHpFBlwZOORewbN7 jL5iUnQMH4S/XF91xW/hGTQonrAbndDnpmXLlksQTheycn4LQuKd0qC4z9quFi3JOgTqgWhY XoO8pPc1VXLpwFAr8t4BGcoKrtkp84B7pytk6q9+/fqN1YnmRGMyUfeYlv0qszBI11LVg3A7 ABLxNwTDIwoiYJDAzxiTvmhBXqUNEWg64iQR8SkPrNIwV04jEA/FlKnvr7/+OpoxjKpXr942 SMse7qP9PCCPuRi/HRpL9Q2/mjWYM5VAk7KYx9T4jjyA2dd0xqkABLchZnRjlS6uI6769Q3t R0fG9xDaoiHyvQhUVrB2ujyhlodWph4O7ZWVTyQRs77fGevMzi9G70VGunfvXon+tsIPKQda t0nSyuibHYaAIWAIGAKGQLgiYCQiXEfuItuNAHrICbaYAq3AfKmC9uzXiR9BW8xd6rET0F5W Undj5lRO1fXq1asqtuqlENb2//PeM1rXnv9oDaJw9o3WOLjmseXl0pUrV16vLTwlmCHsXvAu SwiGBxGQM8RVL6u7exDQIuWwLHKDs3F0PQhsZyTcq02Yba1EwLvWbW8r0xfe9XRaAp4ryL7d tV9XiMM2tDIf0s/nWUk/jOPuw5gL9ZBpkYRxBPo+coKGbGxp1KjRAgTszL75dY+AfSV+J56f Aj4UldFMbLv++uuP6Jurk1X7feC+Riek7zRajbW6l9YD/4u8aCR6y6FbJxqHOnXr1vVW2tnd qDZp71ZZpMuFaVUJzM7+1HNsR3zKo01n6Xt3iN31KhdBvTqakE2QsqPUt1QmbnKy3r59e3p2 LGqAqVL0fIAkTMbc7Vb8bfJhujQaH4l30Kxsxj/i39pNifEI6oAcV/2Y1N0ALnkwq/tSpFdt 0CmNgDYHYA57juZxtdM3XajlQdZ2QSpr4uSeU3VpbHn3lzDRWDBmd0JcBk2dOrUSJHAqbRw4 btw4z7QvtrGx94aAIWAIGAKGQDggYD4R4TBKCdBGVvcPI2Tll/MyttpTEXa64gD6HIJQahx/ NyHweSvDCIpfs+NPB3wHGsuvADv4UWqOnKkx4WjP6ntDTJ9yIGhPlv+Bf1NlosIq9Cq2+3xG 5jclS5aMU7j1z69n8h1ZuHBhMW5nxVavtCsIrSvr16//jEyw2DlqNYK9RwYwodqAvXo+fCLa 4AQ8Go3Cj6R/Vr4RWrVH4P3I1ctOSx0wxXrVmWO597rii3AQE5zJkKGp2LmXwS+iFrb+aejT UuobgmnOeshOFhzIP/fNp3uw2Q2W96NdSIMfQXqczT90aeKq06XB32Idgvha/AkeoY5s7PC0 FvOYX/QdovEz39tp1yc0QlciKE9AsyKfhFiP+JbHyvuUV199tRltPgEOmcByuCpBG7EbjcyX rLI/yTw5Lh8QhPLXXQPkz4CvzdsQrVbMoTPMtW3gkEZmTNrVifk2yaWN7arV+9jqp64iENkr IXev+uaHvD4LQclPnS3BfFFc7YQAFXTpQi0PYr2M7XTlTD1A85u5t5fxn6g2MFfbMffX4xuh rX53+bbL7g0BQ8AQMAQMgXBHINr8I9w7kszbL9OHoGOF+Y7MKirFBwutokpboLz+Ao9Mdlg5 zuprcqR0ckZGM5EbAWoXZksn9C62QxoCtBcnZYsfW5pQ38dVr4KRsQp8GIHOM6NxZSJ4p4Hs pJMPgd5p60+0CzkhOdsCkR+XL9hVq97Y2Z9V/9CEpNeWtP55FOjuk08+qYNGZji7O0VKkHWa D/+0wZ6l+cAUKm0gHNG+5IIoSUvk+bAEK0vf41OeNEqMe6T/PFF5aCMyaK5A5nbrOdAh8x4I RV78OI5B5mLFAhMgLJ1GdPcvI676/dPG9hxKO2PL6/9evx3GPxcas1O+vxE3N/zTh/Hz7/i2 zA3j9odL00P6ex8unbF2GgIhImDzPkSgklKyoIJpUmpsCm5LSD+uiyERKRjbBO+6IxFoRt5M 8MqSUQWxkYhk1MVw64qRiMszYiH9vb88TbFaDIHLhoDN+8sG9aWryMyZLh2WVpIhEBABVqe3 Y2ozJ+BHe2kIGAKGgCFgCBgChkAYImAkIgwHzZocXgg0btx4h87warW11hAwBAwBQ8AQMAQM gdgRsN2ZYsfGviQQAvKxSKCirdgkioDGXFvjalcs362Bk2hzrVmGgCFgCBgChoAhEAQBIxFB AEoOn9kt5xW2xxzG7jav6WTnnCHsJtTVbXN6OfuIY/EVOGEPCFQnu+cUx3FzuGunrjgJP6tg a3KmDZQnlHfadlR+CaGkvZg07HJVmK1bn7mYMnzzSthmN6K6bBnanajd7RQ1232XAzlB5Vpq Ryack5uw61R2981d2RK3JZGSo7dOjW95qldB3Jgz3Vq3bq1I2a6KVESZLsWOUR057yMQ3A3R H/65IZJ2fna66ozz/b3gU4ndjG7HobofO2bdJgdr//TJ/Zn5PIDdnKLHJLn31/pnCBgChoAh kHwRiLdglnwhSZ49Y4vTNxAiH9NJ1OVnjx07lrFz5873JLXesqvSPtdOXYlU/TY739QiYnR0 3IcLbTO7FhVAmK1xofkuND3bl/5NFGpvy9MLzRsoPUHmKs+eDs+6rwAAIABJREFUPbsCwcym Er16EZGQ2zsBtEWLFm3Z4eksMRYmsDvUKcylujqixfazJSEQrQjQdzPb+GZyZcenPG0BTIyF B4gZsoQgelOIh1CaHagaqkxFmmar11aQmWVsK/sTJLAN29AWdvURa+G6QYMG3cZWuGPY+Ws0 +f5kLMZy/wZRzLfDI5q6tHY1BAwBQ8AQMAQMgfBCwEhEeI3XJWktMSJO1qpVawFbkkavXhMo 7ibe99NJELBariIF4GKv+4fYy/9lgtJ1civbWvmWNkNaDlaW+7C/vrdKThyFvGXLlm1PULJa hQoV6qlyBgwYUJKtVXtzPkFsAy9AnSs/2FVbphJ/YQPxBLy2xlYvZKOAVsRdef/9738Lsg1q e7WH+8YQp8KshjfXd62O07ZH2JJzELEf2vIto8vH9rDdlMc9+16lRVHwMMhNaghDHQL2PU1c gIGKWqx0CMh5unXrdpfuCRB3K4H2aqg8iNHz4N3UCflvvvlmUeq9V+ncIW0JeTzh3L2jvIqQ hRlEOl5FrI5FrOgvB/8yCoa3fv36ogjnE4hy/TdB7L5hVT+3ylBetq7ND7E4jibnmCtL1/iU BxEohyZk1ciRI+coCjTzZBpEoqLK++CDD2pCBKYR4+E3AuatBv/FjENVfVNfIRl3guVoBYlj TvQiinUBcLuNrWF7EGtiPtG18ym4odJDRoqC1YNEuH6RaNYdXcTn2N5rbil6uuYe8T76E5sh 4LzSdsA4trfWWCtA4HvvvVdI9TVv3ryexl73Opgr7YidUUX3EJ8bVT5b/w7SHNJ2wHpP2+sq n9onjQKxUf6lQIHU/wzteEpzTuniGnt9d0dc89Cl0VWRvqXhUh+Yw80UbFDvpfnRHNRvUJoi aaf0PpR2ai7ffffd9f0DKyq/HYaAIWAIGAKGQCgIGIkIBaVkkIY4CeklUOmUsDNt2rSqxBRY qq7JJAVBtAErzZ+zkvwBUYVrsGrtCYoITR2JuLud9EO47iRNG+UhQnJHhLItCFj9FQDuqaee 6jR//vxsCLMRy5YtK0105zKdOnX6XnEIWKHugPAzH0FvAlF8PUFNZcRypHbt1Co4bSuNsFkQ gecvpY+j3gzk8yJCKx3tyADxyEv07V3EgvgRArN56NChU0UYOnTo0IPV88UIuDLxOo1Q2055 dPB8Mm3atNpqLvqQOY8IFNqAvuCYWcI6/aiG1mEEAucoYh7U1jt2YMq4adOmAspIHIIohMQ7 0CJ8j2A9HJyKg0MJfUOoPkM9MWI5IDRnI6DejfruDgLZpUVAPO2e0R5l2LhxYz4C5Glr5tQI 3J5dERGy05I2HQTL6z++B98Rx+ELvnsRsV3++JQHYUojjFwZxNqI2Lt3b5RIAlG4c1esWHGT +1agQIFdaD48IgMmUXnz5t1OAMCjEKAKzLUlH3/88SzGYR/zZr3iZGBWd5iI1Z6ATqTne4jo PG3SpEmvKOAhxKmmyo3tPTgXBvOqBDt8j3n2NYSldSBfG0hOK9qchbpHMId+ZtvYhzQnIba/ MSYlFcmaOV1h7dq1RdD0LJCpFiSvCXNkOlqgl9SGxx9/vI6uzK+czJmGxMBYxLh+8fnnn9/J WfOVV14ZBQFaw/jernRxjb2+6wg2D8+lSpVKwj7BEDtS3wT1gXYWgszVVpR4+tARnD6HPAyA 8ByCzHqkKJR2Mg7HiVtSkCCAAyFZbZyGy9VrV0PAEDAEDAFDIBgCKc4mORggyfU7glBPzuju IcDtRzieqResbtds2LDhLASq5XpGAJyJyUl5hLSNEtYWLVo0PDIy8hRC8beYrRxH0MuDoFQE IettVmyPsVq98NNPP63NinRJIiVvIhJxum+//fZ9RX3GDKksPhAbWDWfrrIhBjMQ/BrrXo62 CHjeqiqRjrfoHUJ6TsjKUN27A3+AOURD3kyZsdaLkL/Tpfe9KpAcq8QHEMZPIMgeQFCtrkjV 9GWG0hGJeyIr6EMQvCIQrE5AgN7Te4Th9OBRGaGxFvE30hBxezZ4fIIPwjFW0a9DcM+G4J8V srUGQfo1+ngMTDyBWPl1VKlSZY5W6HWPSdZ3aAJKQDqWKFq0Tr2P65C2iHbWAcc9CJ3ZEX5v RABfo+jPwhShsREC8M9ogaoJc4ToDJe6PKJhL4JwNX7iiSfKsXK/nfbIJyKN/BkgE5GshB9z dRKFei/kxWsDgm0eIp/v0TcE4XKspn+h+6VLlxaiX8skrMukTsHZFAiQAHrZEOrzgstqxnk0 xDEjQnPjQO9Vjg4E6G8U8E4n41QZbUkxiOqKc1+9uZaJuVsBwjcAv5E90moRYfsmAtiVGD58 +O8QhQmY+TVV1HHI6ieQnpMad/xnxmpcRUrAeSfB865xZYL9QsjofD2jJTnIvJ0Nidmg6Nt9 +vSJJqOxjb0rB2JQPq556NJBjiqjCVzx3HPPeYQfzMehPYhkDlYG73XU6ZFryP83/E5ecFq1 YO28/vrrjzAW70uzx5y8CWLSlYWA3Wi+fqSuRY6gunbY1RAwBAwBQ8AQ8EfANBH+iCTTZwSn oQhkPXTOmDGjPw7MZzC9aaDusoKe56uvvmqI4PCCzjFjxtyBcJ8Ns5hIzHV2i0AoncygENam LFmyBOuKXNtFIPReB8IkVha7PHMK8uwRgdB7TFiuw/59re51sDK83rvhHwT6+zHH6a0T4d3L i+nPXtdO2vUIJOS9BQsWVJG5EgJhnPW6cnVltT7g3MYMKPeOHTvyu75CAPpBElJDbmIQAISw Xl988cW/ENLG0a/BCLQ/ikCobMjYSnwO5iCE9pJZCyvt1SA+x/XN9wCf6G1dEdp2QzqK+n7X PQSmg0xSEFzvhcgU0L1O+RNgrjIXArQTs52u77777i0I879QjxcRm2/jIRVF0BT1QrDMjhZg HW2Ors+/Hj3HpzxFxsa8bSJmQHcgZ3ZGOF7CGO0X4YKYnUTYj8YNMpCBtntkjpX5feCWQ/Vm zpz5yJYtW7JiBpVTGGB6sxOtQIOSJUuu0nfKOwMZGsPcqstcewVtUzM0HSiE0qYK9F55dEBY o/sLTnsgtUXOfTn3L3Mvt8aWOfeEG29I8TUQBW+uyUSL76kQ5vcgQHvCOO0/STsLMtGeAetB 8+bNK+lbJvXsc89oU05BTLfpWdoljuhFmWBjH+o8BLdIxtarQ/Uw5zaKtPM+F3Nqg97p0DjR huPMiax6DrWdItbgPpmx6s9c+hFy1YJ5dq/KsMMQMAQMAUPAEIgLgYCCVlwZ7Ft4IiAhB0HK O7Uqy/kTpjH51Rv8HY516dLlMwS3p3QizPaFaIy86aabtmsl+Pjx4zKfkZYgjezQybuV+xzy DdB7HZgORWGydN7qOiu5uxDac55LlSoVQlked485zBCEuB46tSLt3rt2iry89NJLCyEvm3ES zh+sXgmMrgzMPq6QgOh/YFd+DAH3L9dXXfH7eAaBdK9vWgTnaeByBBOVltqRCOE32kGZyNMZ 0d58Q7/6sBr+GcJrZUxhSvvm1z3aimhfC0y98iMsH/BPwwr/9/369RuLHf0MCMlO3evEUXqz iBXk7jOw7ouw/irEKAL/hO20OQ1tO43mYyh19P31119Hg2VUvXr1ooVN/3r0HJ/yEEozQ/aW QlQGon0YAIn4G0HbIzIii+Ac6epiPkWiKfHawKr/FgT2/FoZRzswBf+JOvS1PjiNhjC1gCBm h6x+r7xa8UfTtE51oKV6jX6mhzw0RkOQKtB7Vx/zNBpfzWUE5xj4ogk5iqB/hjY+68YbDJ5G UJ6tMhi78pBpaZ3yo5HwCAjfimKmVp/xHSncITQzlcYdcmZ393Fdg419qPNQ4y2sXF3Sxsmn Bu3ENt/flXyXMDs7gc/OLqUNtZ1KO3fu3Bz081b8lZpCDjcz33/VezsMAUPAEDAEDIG4EDAS ERc6yfgbguAhyIFneoIp0ArMlyrIyVUnfgRtMWOpx448exFsd2PWU05QsD1nVcxVSrEKv/+f 954zq+yzEXSicLqN1jg46HAuXort9fWUn1vCL0LxBe+yhMB1EIEuQ1z1sgq/B0fxSMyGIkVu MB2Krgfh6owEU7UJs62VEIJr3fa2mBtV5F1PhC6vyXKUlbMppl4LEFJfgcSMwpylIKvnsh1v hZBbAGJRHj+LFpiEnUYgXsZK8QZWcjO7Prsrwn0Z9RkCEEF9ZdHOrNE31S0/FN3jgL4JrNew IrwZ8nRM9zqlycGspDbC3d1Kh0lOLsx9SmBO9ieE8Cz5utO26/UNDUF1hL9NkKOjeo7tiE95 1JsXwbQ3/UuvE41Inbp1685XHfIrmTp1alXhLeGWlf/KEE9vDsiMrG3bttMwA2vLu134PrzF 93HMoVWQi1fQQvyNKY1HLiFDGSEnfUTOcAre0qhRowUI4ZkZM5mEnffe9Y8tY8vrHqE/ipX5 QviseCQWclAOrVVWSOduiNs+xsjz79E8ZcW+H3Mxr/xtyN+M9nwG4ZkMufF8KtC+5ZMgTVm7 NHaaR4HIqGtDbNfYxt6lj2seihDIV0NpGWfv9yPfCJF55kYz8MuG9m4J8/IGvVc6+lKKjQ7+ cvNY74IdMstjXt/P77wvvx35jQxnDIaj/VsZLK99NwQMAUPAEDAEotXvBkXKQoDV/cNagf1H mJqKoNgVG+vnMMlIzQruJvwbxgoRBNSvMdfpgO9AY/kVYH8/Su/lTI2g3R6huiGmTznYqWay BEd98z0QtnewaroKYfIZmcEgPP7p+z2Ue/Idwem4GGlnxVYvAuMenHhX4vT6jEywEKhWIxB5 pjaYs2xgpTkfgnobBNfR2MX/SPpnZZOu1X3s0z9y7cDOvQMC/KvOHEv27pyjMOHKiqBZHcfc B1i5fQFC0wAMB6pPCPWnsfmfD0GKsf+/dkgCy/6sqEdA2rbi0O6tvJPuGlZ978ZpeImrN9AV gfFnfATaYUbVA03PlRCICWhMPHMa/CGmIAQ2o70nEHYz0afhgcrwfRef8uS7gb39WsyuHoHI ZaMta2n7LyoXE6eZ+ElcD46DEHAzo4ma7euTgMPxH5gEHWJudaH/u5hfO5hzOdGa5IIcLKte vbqn/UGQPcy8WMqYDWEnrvXUk4VyPsfk58ZA712fIFXFKLcimowrmF/fiYDoG34E7SF2IyCW q9nu9hMI2/3439RVOubCdyJucibWrl84Jy8Fv2W0rTIr8A2Y3zMxY6vLuPWGHGXAf+M3Nhqo 60ifqzvYNbaxd/nQ/K2PbR7ie1OQdrSErC7S74fdoJaCYX/5MYHnFnwYFlH+WcwEV6B9epa2 /g1m2SES77jyg13ZSCEfJLS5Nh2AVH2MxvBEsDz23RAwBAwBQ8AQ8EXg//X0vm/tPqkhIBOK oGPFimll0lWKT+Pl6CptgfLKUdW3DJmbsOqZ1dfkSN9ZqY9AM5Eb4XFXMCFEGgK0Fydlu+1b dnzu46pX21yyIn8Y4f6Mb9kIWWkgO+lky6/3CKBZWHXOiRC1LRD58c3re6/VYAlwwoRV+CgI 0qFAfeJde4TYNfJDYKU9kz92vmUGu2c1PBcESNofzzfFpddKOfhH+o+X+x7bNT7lyawJ07a0 gfoqzQq4ykwsVk2I8uNrkBvisEtOvYHapjnCinh6OUDrO4QNV54R3f3f6xv+Eq8zfk+jsUgH YTjqxlXf/A85gUMEohDG94uw+H8P9KzfAvN6j0zrZJKFNuyU8w0KlN733YWMfajzUPhB4s84 vxxXnxyj0XRlgkTt0Lx074Nd3TwOls7v+++Yds31e2ePlx6BkP7eX/pqrURDIFERsHmfqPDH r/Kggmn8irVclxiBkH5cF0MiLnF7U3xxTpDEIfynFA9GPAFwJCJQdkciQiUFgcpIqHfJeOyN RCTUpIlZbkh/72NmsSdDIOwRsHkfhkNo5kxhOGjW5KSPADbvC1lxj+GsnfRbHT4tRIM0BXOy JGmCY2MfPvPIWmoIGAKGgCEQfwRMExF/7C5nzpAYumkiLueQWF0JjUBcmoiErtvKD4iAaSIC wnLJX4b09/6S12oFGgKJi4DN+8TFP1612+5M8YItPDNpd51x48ZdKTvs8OxB8m+1tpIlMF9+ 2cAn/95aDw0BQ8AQMAQMAUMgXBEwEhGuI3cB7dbWmeyucx+70QwmzkM77gfjBPugnJAvoJgY SeWIzS43teSwHONDiA8Xmz+uatilprCChcWVxv8bW3rewdlY73GiHSxB3j/NxT5rO1nFnAhU DrsgVdGYEBfhbvwoymGucx+77jwZ265A7A7VklgGMXaDUlrGtqPGGofuGwLVo3fsDFQVU6su Skue0m4M5YBMELj6agfbsjbXVqOBylBcAdVPDIOHcehtRLCyvC4dOwtFsWVoM8roRvCyer6x RFwa32ugfrj24bieyrVPW8jK18D/VARy3/Ls3hAwBAwBQ8AQMAQuDwLxEgAvT9OslkuFANue dlTALPaX78dWoS+xp35vxSQgBkH7+NYh4fCTTz5pzm468fKrudj8cbWbrT7/JnZA0C1PYysD Qfg1djzydgiKLc2FvGfL0HzsONRQcQnY6Sc62J4rg12AmiPAZyIQ2kgCiU0i0N1CtpR9e+zY se+wq1AZX0LAlqUlEbxbEXzvZrZLjQ6Ax7amxdjutRWxG5axFexPbA/ahq1ZC7s63FUB1iAf txHrYSFb1/5I3Ifbe/ToUU3fCXB3FwShFGZEU9nxaBcEoacjGC6/rgTG68IlNfEXvsLB+TRC vzePFA+D+AVd2NI2Ne38mj4Uo4w7ffO6+9j64ds+dlNK5drHrkRH2OZ0se9JELkibHuaJP0i XD/taggYAoaAIWAIJFcEjEQk15H9p18KjsZ++9cSHXgcjqgn9Tpv3rwniVkwrnz58iskzOtE aG7EtqjPcw5GSGwoTYEOrUprNZgtNHsTf2Eg2oeaes/2pZ11pYxHEWbTa3VaK+DKzwr1Qy+/ /PJ1+q6DGAolpBlghX8QAnMzmVX551cUXmIO3HsuR9z/KsAWwuSdajeEoQ6xAp5W24idUE85 2cI0T7du3e7SPX25lYB3NbQyrv6x739TbY2qb7HViVCsVfgrEOLzV6xYsS0xMOpT/gDFDvBd /Se43k1g2k8ngn8tlRnoQJiOJBpzFuIp7PH/Lq0JW89mZnxmEo+jOH3oyPaiRYkH0QYhvR7f JxIE7GaXj21N8ysGAQH0jrl3uhIRuiYxEKYR3+M3NB6rGYvFaDSq+qbRPdG1byCY2w8jR46c A3lYgxPwL2yhWl5bfrIFaw36/IGC3XH94dixY5nYYjV6HJVfWi3SZqKcsR06dNhIrIFZjP/V Mr8CzxuJpH1UQeUUi4EYI9MJ8FZN46S8vkds/fBtHzERFBzQa5/idijuhDshNxEESVwOeZon guY7Lr712L0hYAgYAoaAIWAIJAwCRiISBtckUyor1lcivO703woTgf0gAae+Rxg9y8p1DSL8 FmfV+xWEsTcRAis99NBDVdQJNBf5IRwNWOX+BGFtOtqHZiINBG8br++8H4UQf7Jfv3412Uf/ AELgS5jizEW4vEdERAI/wdw6Ut4EhOERrB4XQris7Z+fgG1naEuMOAgq3/cguN21CI6dMDvq ixCZWaYzRFSuhtZhBAG4Rk2ePLm23hE9OyNalwLKS4yGKATiO6j/e4Tq4fiDFGeVvoS+xVYn eQuiGYjgzLBgwYJKO3bsyIGQ/xb920NwskbKK9Mh8Gvw6KOPfs6K/wdgVwOh3IuMrO++B0Hq lhHP4QsE4ZW+73U/adKk4mgAFuie4G31EdrHfPTRR7MgWrkgSssgP0eIhZBV33UQNO07lYUm KUasBQK45YbwbDqXKlUqaRIYpyj37K6U/w04/uyeCeJXlLmxBmE/EvyPu2B2+g7x20n07hhl KE4BhGjgqVOnUjMvCqJ5aEKgttWK/YA/Rx7uo9tAbIxdEI4saFjO88GJrR+xtc+1V1eZWTEP GxH0bpKeidKsOdyduh8h2nJZRxL1zQ5DwBAwBAwBQ8AQSBgEjEQkDK5JplSComXS6nBcDcL2 vPqdd945WwIkAu0OVrRnsZofLRAjHE9ihXyLhFvMRw7MmDEjirTeqroCzSHEpSL/n6NHj56E huEg5jZb9uzZkw/zlgysFFcmINuK5557bqmCiEEoxqGp2OmfX5GREQ7/599OERat+ENU+mLW 0wLys4pV72eUdvXq1TkQsLMhvGbVqjr9eI0Ixwf8yyA68hytzqNR2NaiRYvv6JtHImKr0zc/ Ab6Okv5ziNEOzHymQyg8+3/IVk1WyWf17dt3ubBB4zETDUJ5+p0OsnS1ThEa37IC3YNRbsx2 ds+fPz8bpmE5KWe7tAL0Ox9kaxWRwgvjB7A8UF7fdwj2kWAUrZ1AoN5LNO4Mvml0r6B3Cswm XDF9aol51TV9+vT5BTIRiYYjxjyBfO4D3wj/MvS8cePGjL169eoAyarK+G6QtgEzuUjmR3Qb mAeKrn0WQnReOwKVqXe+7YOApnLt801PNOt/4bMxB9wO6T3mYt8RgPAZ5tdPjEsdNG0D8e1o YBsI+KJm94aAIWAIGAKGwKVFIF727Je2CVZaQiKAgLcLwaqAnGZ9Ix7L1h3Bu9qrr746B+E1 F6v76107lAfBOXr1m2cJg96h1WqISXr37K4IkWkgFF0QJK9GiNvq3kuwZFV8m3uWCQz3GyUo u3dxXSElvWQ+g6ZjDPbyq3zTPv744ytxuJ1Dmb3QNBzCoXfO559/PsU3je4LFSq0w71jxXw3 TtP13XOwKyZQB10kYDQRx1mB9/qOtiPPV199VQiNwL9UBlqXtJg1bUfwzc3qfG+9o9/rELaH 6T62A8F/38qVK3MgFO/ClyCdxgl/gbJE0d5H3kxobBpAxDytT2xl6D1k5ySEJHrFn/HNQNk7 A+VBg5IPYtaN9m0k4vGL0iIgcOdkBT86v/KBe0TRokV3BSpDeWjrQEV2xu+hHxqp5eB0grkR XQbakfQQzNNEqb6geBmufbQ/lWufawOapQwQyCpooIa4d7pqbmNONU+nzNDQSLRg7txKnx6V ts03rd0bAoaAIWAIGAKGwMUjYJqIi8cwKZVwnrDEiv82hNP0mJ7EcLKFPNyI+U91BONTUVFR W1ndz+k6gglLXoTHde4Zs5/zynXfdBUhQMi/D2FyDvb9fdj1aYT7jtZhOwJ3dvesXXbki+Ce g13xNZiGJuUIJkgttbORtkB1eWSfD0H6Bu1AHwjGZ5hSVcZ0qLT77q6spmd096z454cYnKet cN/9rzikB+w7bTqG78RnCKlP6WQlvC8ampGsgG8jXkcPncEIhOpC67NswoQJFa+66qoT7GY0 BR+TbhCytAjef6Dd6YJm4jdpJ/zb5f+Mz8YeTMUi3XvqjrzmmmuiyZt7j9lVbhyqu9L2CUuX Ln1fZEDf0Hbspd6MvlvLolXJBbmJJoRKh0lYAfmJ6F4H5HMXu36tgwjlwodhD8Qhug2YxeVi fu2AaJ1zsDmXJc5/fduHn04q1z6XCf+aCvimbJbWzL1zVxEwtEWVmAutIMY5mjRpMskIhEPn klwD/hYuSclWiCFgCBgChkDYIWAkIuyGLM4GewKhb4p69ertrlSp0q9Dhw5thIOvp13AgTYn tud3Ybr0k9LyfSmr85VliiM/BvwoStauXfsv33L872XCxHEGU5UIzIoyaxUbzcZSCW2sAld2 6XGwXYqAeb18I0Q2cNpths9BNt/8Sjtr1qwr5Gfg8rkr9vsLENBfwcdi1F9//VUQ+/2BmLy0 ksM4xKI8ZkYtMKE5jRPyMlbWN9Ce8+Ir/Prrr2VoXxrtHkQ9ZfFNWBNXna7uuK74ZqxgFb6C MNMJXm3pm+fYHVc+/28ys0K7kVaO2fhE/AwRGC6nZ3wGpkKKRuCTEk3A/PP6PmOatBhzrqoy KxJRQ4CvDAFYqzRy3pb/gu4he7eA33wE7T9l0qRT7f/HjGgDOHo7NfG93JEjR7Kys5enzdAz fjNZITRbmUeltRuUylNdjE8BTJsW45ewFE1BEZlxqVxM1xpARr02yI8B068yyhPX4ds++pLK tc/lwYH/Bubrn+5ZV7QS8h+5ExIzCAwqse3rVObBQGKiTPdNZ/cXjcB5f18uukQrwBAwBAwB QyBsETBzprAduoANP2/lWamwz/+SVdnW7NgzhB2S9rMyn51din6AWMzRd8yC5iIcdsfsZwBm McflUItQGKcdvsgCZk7LEVSfWrVqlQT7OQh3feTwy/u12N1vYGW9CcLjWGzXlyLk9UfY34+g twUn6EX++TENugZH2buff/75JWqT/8Hq+QbOUSJCaBuqs+L8AALlC9jdN8CMaCDahf1oTE6z Uj2fsmLET9BuRqxe90cjE4GJzFYE6u9VfrA6/dvg+4xgPpU+dcX34DmIV2rK38TOSGN904R6 P2/evI/YbrchuD3Mqv5WVu8PyCGcccpCXA+vrcHKgoDMxF/kevwYBkHWMmNaNhvfgRXKR7tq Zs6c+ahMydDeFEYbk5f2NnRlYn62EbLyMsTyY0hfD7QaNdiZKQvj9K7TIkAa2kPSRoj04Asy nfnREydzmTqlRvvyrXZP0kmcC821JzWP5D/D+L+ueiAWBYcNG9YS4rfI1Rvo6t8+5sQw1z6l RxNVDFOsH33z3nfffe3Abj2+EdqaN6D5lW96u483AgH/vsS7NMtoCBgChoAhENYIhGSXHtY9 TB6NlxlBSGOFGU0T0gYMlCZTFVaTcyL87pAZky800hKwihuFcHlMq9K+3+K6l3kRq82eQy72 69kxjToBGTmm8lhVzyzBUvlVN4LlGe3u41ueb37f98HuVb58FbDBT6t2I0QewiTnoH8+BSfD Nn4NTtlzEcwzXUjf/Mvyf5bWRj4Ben8phFeVx3aruTDPyohp2HZfHxb/umN7lkYHAneMXZ1i OEnHlt7/vZsH0kA4AuGfRs+YvGVhTLPKWd7/u/wW0BoncmB1AAAgAElEQVRJi7Hb/9uFPEMU 4TUjugfL4+ZCsHT2/aIQ2IJp34SLKsEyh4pAyH/vQy3Q0hkCYYCAzfswGCT/JoYkmPpnsufL jkDIPy5IRA5a15LTtEyA4EgEtvye6dZlHzmrMN4IhEoi4l2BZQwVAS04jIVEhLy4EGrBli4g AiH/vQ+Y214aAuGJgM37MBw3EzTDcNDiarL+o4dIzCBNXc4UP76Y3izEOfeCdgeKC1/7Zgik MAREIGYYgUhho27dNQQMAUMgBARSvJAZAkZhl4T/8FdBJLStqYhEQNOmsOtUPBtMFOg4bfDj WaxlMwRSAgJb6KQRiJQw0tZHQ8AQMATigYCRiHiAFg5Z/lk5nACZyEV783Fq1yIzXwuHwbM2 egjgY6Or949BctkQkEmBdmHaxt+Qi/JpuWwttooMAUPAEDAEDAFDIFYE9B+7HYZASkPA5n1K G3HrrxCweW/zICUiYPM+DEfd4kSE4aBZkw0BQ8AQMAQMAUPAEDAEDIHERMBIRGKif2nqjqCY wpemKCvFEDAEDAFDwBAwBAwBQ8AQMASSCwKB1Hzl6dw7nLJfPp5cOmr9MAR8EAg0730+260h kCwRsHmfLIfVOhUEAZv3QQCyz4ZAfBFwPy45ST/OuY5TgdVOcurbPk47DIHkhoCb98mtX9Yf QyAuBGzex4WOfUuuCNi8D8ORtd16wmPQ9OPSWOl6iDMrpx2GQEpAwP5GpYRRtj76IuD+3vu+ s3tDILkjYPM+uY+w9S/RENCPS4c0EY9xruU0TQQg2JGsEXDzPll30jpnCPghYPPeDxB7TBEI 2LxPEcNsnUwMBAL9uOQT8R/OM5wnEqNRVqchkMAIBJr3CVylFW8IJDoCNu8TfQisAYmAgM37 RADdqkwZCMT140oPBNekDBislykMgbjmfQqDwrqbghCweZ+CBtu6Go2AzftoKOzGELi0CNiP 69LiaaWFBwI278NjnKyVlxYBm/eXFk8rLTwQsHkfHuMUo5UWJyIGHPZgCBgChoAhYAgYAoaA IWAIGALBEDASEQwh+24IGAKGgCFgCBgChoAhYAgYAjEQMBIRAw57MAQMAUPAEDAEDAFDwBAw BAyBYAgYiQiGkH03BAwBQ8AQMAQMAUPAEDAEDIEYCBiJiAGHPRgChoAhYAgYAoaAIWAIGAKG QDAEjEQEQ8i+GwKGgCFgCBgChoAhYAgYAoZADASMRMSAwx4MAUPAEDAEDAFDwBAwBAwBQyAY AkYigiFk3w0BQ8AQMAQMAUPAEDAEDAFDIAYCRiJiwGEPhoAhYAgYAoaAIWAIGAKGgCEQDAEj EcEQsu+GgCFgCBgChoAhYAgYAoaAIRADASMRMeCwB0PAEDAEDAFDwBAwBAwBQ8AQCIaAkYhg CNl3Q8AQMAQMAUPAEDAEDAFDwBCIgYCRiBhw2IMhYAgYAoaAIWAIGAKGgCFgCARDwEhEMITs uyFgCBgChoAhYAgYAoaAIWAIxEDASEQMOOzBEDAEDAFDwBAwBAwBQ8AQMASCIWAkIhhC9t0Q MAQMAUPAEDAEDAFDwBAwBGIgYCQiBhz2YAgYAoaAIWAIGAKGgCFgCBgCwRAwEhEMIftuCBgC hoAhYAgYAoaAIWAIGAIxEDASEQMOezAEDAFDwBAwBAwBQ8AQMAQMgWAIGIkIhpB9NwQMAUPA EDAEDAFDwBAwBAyBGAgYiYgBhz0YAoaAIWAIGAKGgCFgCBgChkAwBIxEBEPIvhsChoAhYAgY AoaAIWAIGAKGQAwEjETEgMMeDAFDwBAwBAwBQ8AQMAQMAUMgGAJGIoIhZN8NAUPAEDAEDAFD wBAwBAwBQyAGAkYiYsBhD4aAIWAIGAKGgCFgCBgChoAhEAwBIxHBELLvhoAhYAgYAoaAIWAI GAKGgCEQAwEjETHgsAdDwBAwBAwBQ8AQMAQMAUPAEAiGQLpgCex7eCNw9uzZXPQgH2dmztTh 3RtrfUpCoEqVKqnmzJlTOZn0+Sz9OMK5LXXq1LuTSZ+sG4aAIWAIGAIpGAEjEcl08CEPOeha Xc78ybSL1q1kjkClSpXUQ++f5NRVfptb6M8MyMT+5NQv64shYAgYAoZAykLAzJmS4XgjpFxL t1pyXhCB2LVrV/px48Zd+eeff2ZJhrDEu0tr1qzJ9Nlnn+VfsWKFtDl2GAIXi4B+ly3/+Z1e bFmW3xAwBAwBQ8AQSBQEjEQkCuwJV6mPBuI8LVPBggV7Zc2adfDJkydjmDWtW7cuY+nSpe+7 +uqrBz/88MPtuB987bXXPvjHH39kU0vbt29fU8++rb7pppua58iRY+D06dNlLhX0ePvttwvn ypXrmaAJfRI0aNDgDs7GepUtW7bBEuR9Pl+S20ceeaRi69atawcq7MEHH6yifrdq1eruDz/8 sNztt99+X758+Z58+umnSwVKX7Vq1Zb/+9//rvL9prTg2VH4vvDCCzf4fvO979KlS9Xrr7++ i9KSp/ShQ4e83+a+ffvS3X333fXVDmH+22+/ScN03jF37twcqr9IkSIP33rrrY0mTpyY1yX6 5ptvomrWrNmMMro1b968nv/4u3TuGqgfgdr37bff5ilXrlx7//OBBx6o7sqya6wI6PdZ95/f a6yJ7IMhYAgYAoaAIZBUETASkVRHJv7tqkvW8wiEhP09e/bkSZs27Zk333yzmG/x9evX74hp RapNmzb127Zt20tbtmzpnSlTpmNNmzZt75vO3deoUaPZsmXLbpg8efKwevXqhWTf3bJly7+/ /vrr4a6MC70iCL92yy23bL/QfLGl/+KLL/LdddddDSE3zTZs2JDHPx19bI4An4l+jgSvSW3a tFm4ZMmSt8eOHfvOlClTyvgSgv79+5dE8G6F/f7N27dvz+TKev3114u98cYbrapVq7asY8eO Pw0ZMqTNW2+9Vdh9d9fHHnusPOTjtrp16y7s1KnTj+++++7tPXr0qKbvjRs3vguCUKp79+5T CxQosAuC0NMRDJdf1zvuuKMLl9TPPPPMV4zxaYR+b+w2b94c0a5duy6nT59OTTu/pg/FKONO 37zuPrZ+xNa+woULH/nXv/612Pdcu3ZtkSxZspxwZdo1TgQ8IhFnCvtoCBgChoAhYAgkUQSM RCTRgYlPs1jVlFYg4Go9wmxFVoz/KF++/B+YLFV05Y8aNarA+vXrrx0zZsy43Llzn9T7vHnz nvzvf/87jrQr/Feta9Wq1fSvv/66btq0aa9Xr159nyvH9wphqJMnT56npam455576unb999/ n6dbt2536R6B91a0GzW0Mo5m5HmVefToUW8uIrAXrVChwr1K53sgFGsV/gqE+PwVK1Zs26xZ s/qUPwDNQG/f1f/777//JvrRTyeCfy3fMnzvEaYj9+7dm+WKK67Y4/te99KaHDx4MDOYzHzx xReL04eO3333XdGbb765DUJ6Pb5P/Pjjj292+RYvXpw/Q4YMx9OnT3/MvdP1gw8+qHnbbbdN +89//vMbGo/VaBkWo9Go6ptG97Nnz76hUaNGP4wcOXIO5GFNw4YNf/nhhx/KHz9+PPUvv/xS gz5/0LNnzzVcfzh27FimESNGXOdbhjRJpM1EOWM7dOiw8aWXXpoFmbla5lfgeWPGjBmP/vzz z+PuvffeTV27dp3+008/VfMfV5UXWz9ia1/x4sUPv/LKK3+4E3ITceONNy6HPM3zbZ/dx4lA /n9+t3Emso+GgCFgCBgChkBSQ8BIRFIbkYtrT77YsiNEVsIsZ16LFi0WcpR1q9msnl+JIL2z RIkSh33zIsgfHD9+/PcIxtpVxjtq165996xZs2ojHL+n7+6971VmNGg9qqF1GDFo0KBRaCtq y5xm9+7dGdF0FFDav//+OwqB+I6HHnroe4Tq4fhgFGeVvoS+pUuX7gx1ntK970HegmgGIjgz LFiwoNKOHTtyIOS/FRkZuWfAgAGNlFamQ7S5waOPPvo5K/4foDGogVAeTZh8y3v22WeX/fjj j18gCK/0fa/7SZMmFUcDsED37733Xn2E9jEfffTRLHxGcrHqvgzyc+Tw4cNZ9V3Hl19++Z3K Qnuj3Xeij507d+aG8GxyL6RJQLiPcs/uSvnfvPbaaz+7Z8anKOOxBmE/EiyOQ16iyRomYTuX L18eoww0AscgRANPnTqVGvJXEM1DE0zXVmMedQR/jjzcR7ehcuXKuyAcWdCwnOf3Els/Ymuf a6+uMrP65JNPGr3zzjuTfN/bfUgIxPq7DSm3JTIEDAFDwBAwBBIBASMRiQB6AlYZ0PFXgiUC ZgSr0Os6d+68DsH0JEJrcbXjwIEDmbRSHaxNmKlcx+p9CVb+/2Y1/tbY0q9cuTIHAnY2hNes WlWfOnXqayVLljzgn57tO+dodR6NwjaIzXdoKjwSgR/COgTS//mn932OiIg4SvrP8VHYgZnP dAiFZ/+PRqImq/iz+vbtuxztwRY0HjPRIJTHjCsdmoOrdYrQ+JYV6B4ToNylSpXaPX/+/Gz7 9+/PSTnbpRWAAOQDw1Xvv/9+YbQ6ywPl9X2HYB+JRiZaO4Ewv/fEiRMZfNPoHsF+/5VXXnmC 8tNj+tQS86pr+vTp8wtkIhINR4yxgfDtA98I/zL0vHHjxoy9evXqAMmqWqxYsQ3SNmCaFol5 UXQbMLsSITkLITqvHYHK1LvY2ueb/sknn/wXPhtzwO2Q73u7DwmBgL/bkHJaIkPAEDAEDAFD IJEQMBKRSMAnULUxHKZdHaz2V8IMJmP+/Pl765Qgy6qzt0KPsLlr69atBeTA69LrKk0Fdvw3 SQDXc+bMmQ8hgGMd8+bHkInyEImAzsWPP/74SgTVOZjV9MqZM+cAzIGqUedxleF7FCpUaId7 ZsV8N6SjqHsOdsUE6iDCtachQRNxHIKUXnnQduT56quvGqIReEEnmoo7MEvKNnPmzNyszvfW iUlVm2DlI/jvExmCMB3HlyCdsHniiScqZM+efR+CeqZ///vfDcBmYbByIDsnISTRK/5gmoGy dwbKhwYl33XXXdeP9mb5/fffX5T2gX6exMwrOr/yQWYiihYtuitQGdI80NaBELcBmEPVwYTt WnA6AVGMLgPtSPo0adKcxhRtb6AyYnsXqH0uLZqlDBC/Kv369fvJvbPrBSEQ8Hd7QSVYYkPA EDAEDAFD4DIjYCTiMgN+uavTCvq8efMqsGPOOAT/8Tq5/wwTotLa0hVhdRuCcnq0FTEcfl99 9dUbMUWqjpDumRYhUG+BHOxnd5+trPZPHTZsWMtVq1ZFOxG7fsk+H43AN2gH+uCQ+xn29JUx HSrtvrsrq+kZ3T0r/vkRmM/TVrjv/lecwKNNrHy/oVE5hu/EZwjeT+mEHPWdMWPGSHY32obd eQ+dkIBhvnkC3ePHsGzChAkVr7rqqhP0dwq+Id1Y1U+L4P3HnXfe2QXNxG/STgTK6/sOn409 aHAi3Tvqjrzmmmu2uWd3xewqNw7VXWn7hKVLl74vMqBvaDv2Um9G361lIXW5WPHf6vLqCkks ID8R944drXax09Y6iFAuCNweiEN0GzBry8WY7oBknXHpg11ja5/LN3DgwArMj82+Zlfum10N AUPAEDAEDAFDIHkiYCQieY5rdK9wer0BP4OT2LX/jg/CWp1oE35nhfoIOwyV1O5KBPX6dejQ oY3QMHh2/jjz5iT9XfgFBFxZxp9hKgL7ERyom0VX9M8Nvg3lMTNqgQnNaQjLMvwANkBWzjPX +PXXX8vImVq7B+FnURbfhDUqgvsrYttC1b8u/2eceldgvlRB2hOd+HC0xSHZc+z2TxvXs8ys 0G6klWM2PhE/QwSGy+kZ7c1USNEIdrDKHld+9w3TpMVoBarKrEjboSLAV4YArNV3OW/LzEz3 rODfgsnQfEjXnzJp0qn2/2NGtAEcvZ2a+F7uyJEjWdlNy9Nm6HnRokVZITRbGbvS2g1K5aku aZcwbVqMxmQpmoIiMuNSuYMHD26AJsNrg/wYMP0qozxxHbG1z+Vh96gbmEN/ume7GgKGgCFg CBgChkDyR8BIRDIf488//7wyAt4fvt3EnCVV2bJlFyNseiZN+Ap8SRyGg+weNASTnUFsbzqQ +6UQizm++dw9aU4jjI6RgzOr0CXce10RShesXr26GLsjDWQl/zH5FJBmvm8a3UNijrN63Z9V 9wF6RqD+XlfMka6B5Nyj+ws9EMynouHIgu/Bc6zED8J8KAs7I3nlXmhZaG8+wrQoE+ZeDyvG AtvBNsCZvC0EqR34bAilPAjITMzAjuLHMAgNxlNoFhbjO7BCeWlXTb5X1T3am8L4eDQEj2Hu hBA9qm+QuY8hAPW0ExX3rXEi/6/TIkAa2mO2lE/aIrRD0yENPTEhe5a4Fw+hfflWuyeJJOJQ /2WTJk2ehDwMhLTlR1P0pcqm3ILSKOk+riOu9ikfpmjFwGRdXGXYN0PAEDAEDAFDwBBIXgiY LW54jKfMd4KOFeY6lUlXKb5dktkMK9s52YFohzNjik9Z2OCnZQU+CgH8EILzebs48a59mTJl 1qAJmcsqeSatuMennkB5zpw5kwptRG59I65EQN+BQPlie6fyENRzYZ6VkfgK2xHSz9s5Kra8 7r20KzhOH2NXpxhO0u57sKtM0oSnNBCOQATKw65NWRjDrBCe80yt5LfA1rzSYoQU1yNQ+Zf7 HU7z8KYR3S93vYlQ3++Y6M1NhHqtyqSJQEh/75Nm061VhkC8EbB5H2/oEi9jUME08ZpmNfsg ENKP62JJhE99CXrrSAS2/AHNpRK0cis8bBAwEhE2Q2UNvbQIhPT3/tJWaaUZAomOgM37RB+C C29AugvPYjkMgYtDANObhZgxXdDuQBdXo+U2BAwBQ8AQMAQMAUPAELiUCBiJuJRoWlkhIcC2 r4tCSmiJDAFDwBAwBAwBQ8AQMASSJALmWJ0kh8UaZQiEhgBRrXOya1Re7eYUWg5LZQgYAoaA IWAIGAKGwMUjYCTi4jFM8iUQ9OwVtnkdRqTq13Sy/eoQApt1lcNvfBsvh+N77723loLSxbeM UPOxc9Tgzz77LH+o6YOlI1r3tSVKlOgEBt3Yyai2+qJDW7ES6bpukSJFuhMbop3S+ZfF9q8V lcf3fXzK++OPP7IpOnXhwoV71KlTpwkB5qK3jdV2rNoRCkfsbsSpqKd2+dZHROuM7IbUnB2c OrEdbj12s6rG/WN6dk7lvumT+z1xMe7gbJzc+2n9MwQMAUPAEDAEkhICCS4AJqXOpuS2EGX5 DYTRx3QihD6rCNadO3eO11aqwlGC7SeffNKcLVwTfAUcofo1dlo6b8eh+IynAuSxDe0DCOlL Hn300SnExCjNbkYNVVaPHj0qEweiArE0piKULiJIXvvRo0dfpW9ffPFFPqVjG9lm4JdH73TE t7wWLVq0Zavds2x/O4Htbk8Rk6Ori5tBZO0uBABM3b9//6+J/1CMXaHuPFdbqlSKq1GrVq3O xLCYt2zZsvfuv//+uS+99NKMOXPmvPHcc89NIpBgG7ZczeTS29UQMAQMAUPAEDAEDIGEQMBI REKgmsTLJIbDSQTRBRAAb/VbhAAhvRFRo5/nHEzwsoZudZ5V+YenT5+ey3VJzwpSxhatnfWO FftHFcSM4GYRbNXaGq3BIKIy9yAGQiGXRzEWiMhc3T37XhU1W9+GDx9e5I033ijK6vuDbGP6 YqlSpTo6YZhIzs2p8wqlod1NtXKverSKz/ar0dGYtXI/ceLEvL7la8VeUbTdu5dffrkcfVil 4HFdu3ZdhxA+DSLhxcsgVkNFhPsZBHFbJb8N4iwsJ6aCF4wNYT5y7969WYj5sMeVpWt8ytNW rOvXry+KdmUChOHv8ePHf7Nv377c0kCgVbiRQH5HCUw3Dk3PJto4HZOlahoj1de2bdvb0YT8 qLYTQbsF8SaqP/XUU3XZlrfDli1bshDMbhE43ai0RCXPQpTxlozpEOJP9H7nnXe8MYntPeN+ a/v27WsIR80FYS1io7L8D3C7iXnUT6eC8uk78UauJkL24wSfy6HnBx98sIo0OrrXO2KP3Kf5 Bf4Pgdt1ek/gwvx6T1yLBopxgYbofjC/qlChQo989NFHqaQZUrpgY680OuKah+dSnPtXc5gt iB8C65elwVGd+iKNkLR00t5FRUX1IY6Gp42Kq53ETXnOtVNE05XlW5/dGwKGgCFgCBgCyQ2B gAJCcuuk9SdVKsyOPEFfQpYiJU+bNq0qQeiWChuiGtcgPkTxKVOmvIIA9CYCbCVW46voG+nz E3QtWtvA81V6RrMxXt8R/EflyZPn5G233daK91kQJEcgEP7M9pwPKe6E0iCQncaM6rTu3TFz 5swrEHzvUlA4SEpFIlsffv755+9hJX3apEmTXoHEpEaYr6n0mzZtKoiQHUGshiyYYNWCQBz9 +uuvhyIY70CbEG3GQh0n06ZNq23iog/MhsrhL5DevUAYT+PbFtocATmIkrDM6n9atdWlRVuT YePGjfn0jFZi2Y8//vgFxGKl+65rfMo7ceKECEFqF/OBAHlpqTsdAmw+iFMeguVtcnVAzHYR JyILWocsekesh2vRXiyeP39+NoL6FWasPsWcahrtLAJ26xB8D4JTNqWFXNyMluME0cGHsCPW b0Sebh3Xe2JJRCEs38HYf8/2u8MhG8WJQB4jmKDyK6I4xKcB2H/+1ltvfcC8qYEWp6JIDyRr L6SwCaQr6wcffHA3JOkX5aHumsQeOYCm5yUC9kl7co+IKuOaYenSpeV3796d7dVXX/2QtueD yDxCgLwfIDGpxo0b10QxLoKNverQEdc8PJfi3L+YiXWE8GzndzCE60760kZfmjZt2hESvIW+ 97/vvvumgGEnYR1XO5mnn7p2SrvE76k7Y/hI7969y8ZGwnzbYveGgCFgCBgChkA4IhAtHIZj 463NoSPw+OOP9+SMzoBfxH6Ez5l6QSCz6gj+M2+++eZ9ekYQm6VVeW4DRqxWGtJ6K/Ks9O+S xgASUgEyMAAtwR5WY7dPmDDhJgKFlWAF+XdW3Kcrjw75D6ClqI12oCgC8jy+DWMFfLt8K44c OZIN4S0vK9iriaY9GtOdaA3CudypUtHuAzgST1HUbUyMvmBVe6BW6SEGZ2Xe49LFdu3Zs+ci fBEaP/HEE+WIQL0doVk+EWkQEtMhtC7guQ5EYQ8mS9khQTciUK6JrSy9j095aHEOEc17A6vX jRBef2a1u9qpU6fSEaQvA9qESPp4zNWJJkFjchaNTQauh0R01Fc0FuVYwV+udGB9DdGoV4iU sOJfDCH/B70nT04IkqdtYlV/FnB5BCi298pTpUqVOfh9rNY9Wp7vmAclBg0atETP7oBo1oSU zMIszKt/8uTJM/HFKM/3eRDU8cyJfmi2chEVfaEri4jdfzIvNhF07wR92sLcyMf4qk+p6M8x hPkv1C/auWLnzp2R0gRBRFOhudhPO6KULrax1zcdMi2Lax6eS+VF6o6CmBYm7XAFVWTMv0Xw Pw55zQNhKQLReRtNyDG0JQs//fTT2mh7SqJR2RZbO1UuBMhrJxh/x1yagSlaWXCqg/lbU8jy bDD8GS3LYdcGuxoChoAhYAgYAuGOgGkiwn0EQ2w/QttQhPQeOmfMmNGfCLlnunXr1kDZMWvK hQ/AelcUZh67EOqzumffKwHtzpszrIbn5n1qyMcTCLIv6ERIuwYzJ29F3OVv1qxZfVZnHyLY 3CqE9GfQKowXgdB3hMUzCNRjMEeqi2D3CivCzVjFTevyumuuXLl2iUDokECqlV+0EjFMmDD1 qYp25Gmd9DcLfXtE99J8KII25jcTITJ3kK4zQvMSCaoqSxG0Wcnf+fDDD3d99913b4Fs/KLV ald3oGt8y6Ou8ZCUIqyI95KgjyZmHeRihzQHkAlP66D6EKjT08fTmC55cTUYN0/Twor/EaUT gQKz8mh0drz++uvFtm3bloeV/h3KO3To0CloMSIodwhCcU+0A55ZWmzvlYd0Xl7dE8tjNwSx qO59D7QGeb766quGbqzHjBlzBxodb6wVfZy2/gIZuob2fOvySWMDueiSOXPmlyAfzd17XdEs HRCB0D3XU6zib9W9Dvp+Bo2QN+DBxj7Uebh48eLIHDly7HZR2WXeB4ZThA/HdhGIc7WnSsW8 gXPt8voWajsV1RySNw9CMgwTspHz5s0rwRgM1li5cu1qCBgChoAhYAiEOwLnCYTh3iFrf2AE 2J3pjFaqdUpbwPkTJjD5lRrBeSsCbU6XE5v9vKxsr3PPMi3SvcxKEEo9EyX3TVfMio5K2Fu7 du2zCP5P6UQr8DRaiNm+6Vq2bLmE1diFrJzfAqG4U1uTuu8IxGkxYVmHQD1w1KhRr2Hykx5S 0dh9d1fq91av9cxKclZIQnbKPOC+64oJzV+Yz4zViXnSMXwqJuoek5tfZWKF2c9S1cOK8QBI xN8Iih5RoM3ZEI4/g0D1ZZX8VdoQgaYjThIRn/Jk4oIt/mnwHIopU1/MjUZDFqLq1au3DdKy Ryvxrj8IxrkQdndo3PQOgrcGc6YSaFIW85ga35EHMKeZDvYFIIoNMS8a6/IikJ+hfW9h0tUX R/KFEJd29CsitvfKR3uitT+Y8eSHYMXAVmlouzD9zI01Jm59IaYj9U1mTPgbVJEw3qdPn3p6 x5ilBv/7cBCfA9noQ3tG6L07RGjdfVzXYGMf6jzEb2Q78yab2qX6pAWDOFbiN7GV+xy+wj6k LAry4/0WQm2nypRmC01KJcamFSQ9R5MmTSY5oqTvdhgChoAhYAgYAuGOgJGIcB/BeLYfwfmQ E8rkG4FZUWXFGpCdOjv9lKxdu/ZfKppV1T0I1p5zKX4BMnHyDkiDrmdYpY1A+NqNsLnvmWee 8b4rdgEr9P0wcfFIAv4TReR0C3HYxirwh3x/npX0w9jQPywnbJkWSRhHoO8jJ2jIxpZGjRot QKA9j7AgYF+JPb7np4APRWWE1W2smB9RYzCdqSYabZUAACAASURBVCCnZVbC92FmtEYn5Ok0 Wo21upfWA5OrvGgketPu9DrRONSpW7fufOVnd6PapL1b93Imx7SqBGYuf+o5tiM+5dGms/S9 O34B16tcNCLV0YRswqH5KPUtlUmNnKzlsD548OAGELq1rn5IwmTMa27FDyEfpkuj8ZF4B83K Zvwj/g25+BLtjucgrPQ4ibcDI62CH8I86FcRPYTb9LG9Vx4ITRmRHJENyiqLaZdnzoVZTmH5 0igNjsgrGNsKmi86mSttwdcjDPSrKd//xCzpHQjQze+//35B2paZMrNA4pZKkEYbVVnlXOgR 19irrGDzEIG+nIgnhGov83o3GpFyyterV6+q+LuUwsxq/z/vy+q95jFalyicyKPx1/u4Ds0b 5tedkMFBmAlWgrBOZZ4NxGci2qQvrvz2zRAwBAwBQ8AQCBcEzCciXEbqErcTE47DCKn5ZUeO r8RcBOzumHEMYOX+OIL5TgSr5aoSW/bZmGS0hkjUw8xkIzvReL4QEgZZFV/Oqu5TlDEQG/BP sMW/H+1CXbQKV2Da9J0cbVUGOyHVgbTscc/4IhzEfGQyguVU8pWBwNTC1j9NyZIll7IzzhBM c9azIpzlySef/Fz5fQ/q343QfT8r4WnwI0iP4++H7jtO3h0Qel/ljNX2HH+LdQjia/EneIQ6 srHD01r65zn/Igj/zPd22vWJFegrEegnOD8RV4f/Nb7l4Q8xBTv6ZrT5BDhkQjszXGWjjdiN RuZLVq6f1FjID4CV/dddvSIE+CC8DdFqhS/FGcZkGzikkRmTdnWCYExyacF7Jrb490OUNqNV yYjPh2eXH9t75cOc6jgr+v0ZjwjGbCvE4Xu9p9yamCId7dChw0YIxVQE5a7U/Zy0VKTfxPex EJ7ikLiStPc5mXnVr19/Go7JrTFdexkzpzmQ1T5oVI4wb9ZCmjZgytUE5+U5Kj+UI66xV37a fjaueYh5VXvMxkaA4Wrm0NcQqw6QnMbgfAIsR6kMOVPjt9MebVhDtCY5IL6Tqfe0voVykL8d /VuPb4S2Jd4VSh5LYwgYAoaAIWAIhCMCZqMbHqMme/GgY4VfglZ4K8WnSzLtYOU0CoHwmOza fcvAXCUCgTutVsp93+teTtWslHvvZcLBCnkUJjb7L9SJVPVLCNSWrZh/pJdztn9daDpKEZui zsqVK4ezu1OkBO5/NCL+SYM+S/OBSUtaCbv+iXEmzoXAq1XpU/7fYnuOT3mQhzSsgEcGEjZl OoaWISuC+O7Y6hTeEIq8mKMd0yp8ICxEEhHqcxGHYptvfwK9B4v2CNhr5BtC/Zn854FvO6Sx coHtArXfN6271/aptPWEfA403phgZY6L8GEOhIXWiO7KfyFjH+o8lAmdMPbvp+Y745Jbmwbg AH/CtT+Uq5vHoaT1SfM7plJzfZ7tNmUjENLf+5QNkfU+GSJg8z4MBzWoYBqGfUqOTQ7px3Ux JCIcQHOCJCZPb4ZDe8OtjY5EsL3rT0mh7YFIRDIdeyMRSWHCJZ02hPT3Puk011piCFwSBGze XxIYL28hZs50efG22i4CAVaMt2OjHrL5y0VUlSKzsm3rQvxLvF2gkhoANvZJbUSsPYaAIWAI GAIpHQHTRITHDAiJoSd3TUR4DJW18lIh4KuJuFRlJtFyTBORRAcmkZoV0t/7RGqbVWsIJBQC Nu8TCtkELNd2Z0pAcK1oQ+ByIiD/FJzU88s/43LWa3UZAoaAIWAIGAKGQMpDwEhEChhzdp95 hW1Fh7Gj0ms62fFnCLsgdWULzyvi23051rLLTy0cri/rHGKHobuJN9Aovu32z0fMgmwElWup HZlwTm4i51+XRtG1cRDvBFbdWrdurcjW7pN3xWE5h777voxPeYpLwG5NdYlJ0Z3IyO1UrytT TsJEE6+PU/uD7ITVXHW6b+7KDlFV9J1dne7Gn6Ecwebuw0H+SXbLKuXS+F7ZyrQl0ZSjt4KN q345GbMFbhNtxcv1rtGjR0fn8y0zlHYqfajlsX1tDpzsU4HJwxpvdvPytgv2rdPuDQFDwBAw BAwBQyDxELisAmDiddNqJlbDGwiLj+lky81niQKcsXPnzvfEFxkJnuyU1JydlC6rXw3bsU4h GvAl23OfmAlt2dXoLDEWJrA71Cl2MeqqXZO0exFxBB4gpsASgt5N+eWXX0qzY1RD4aWdk9jK 82a2/7yfHYaK+mIYn/KIn1B59uzZFR566KGpRNdeRDyO9k5Ypz13IVCXwrRnKtuT7kKg7ulL 3NhBqDkCfCYC5Y0El0nEjFhIwLe3x44d+w47ZZVhp6UbXPvY/rQkBKIVcUBuZnvfTO59XPWz leu969evzw8G30CYNrdv3/5xESWX112DtdOlC7U8thzuojw403+VNm3a02zp296VYVdDwBAw BAwBQ8AQSHwEjEQk/hhc9hYQI+IkK/oLIADeqrsIAdt0NiJg3POcgxHgGrpVd60EK4CWa6Se tRrOVqCd9Y6V80cVFE0rzDi/ts6WLdsgrVq/9957hVwehO8GnTp1qu6e47qyX/+1CKo1CPSW RSvmtGcIq+q9IQ9eeQSEq/Tyyy97QcLYKrSnIg2zbWgfgtf1J66EFyRM5QeqE0G8ErEBooVq BaZDQC6KCdAEolz/TRC7bxDIcyvQm+qgr6uIcTGHmALrCDg2DSLhBdOjrxnZJSiKSNJezAzX n/iWx5ayFSEfMwiGtor2LWLb0+VoCspou1DqrAEh+EDB8rj+APnLxLan16lOBYAjlkHmMWPG zCRfcbQZHdl2tSixLdogfNfj+0SC/N3s2kegv/yKA4E26ph7p2ts9WsOECjuBsr/BKKxhgjk vxNEbQNkpYxv/mDtdGlDLU8BBykzE0HsUikuBUH5ZjHHrpaZloicrxbFlW1XQ8AQMAQMAUPA ELi8CBiJuLx4J1ptrF57gr6EfUUenjZtWlVFqlaDCKpWg0i+xVm5fgUB7U0iDVdiVbyKvpE+ P4JqtLaB56v0jGZjvL4TLG0UQclOElyuFe+zILSOwPzmZwT2h5xtPuZUpxFcYw3YJRIikkE5 Tw0YMKANROQYQcpuRuA9QQTlIewa9Fu/fv1aq75Nmzbl4oz8574wAn9VAoO9R/6vCSbWWnv/ 61ugOuljIchJtFkMAdi0sUBqAqB5dkpEyE5LkLV0mDTlg1il8W0zfYvYu3dvlLQUiitAHIEv EOxnqC53xLc86kyr9rpyIAoZNm7cmI+IyZG04bhvwDsFAoSsRCntpEmTiqMBWKB7SFt9yMUY IkXPIkKyoiYvw8TpCH3Kqu86CAT4ndqtgG/n3pz7N7b6eZ/666+/fkmRnJVSGhiC2l2NudRq 3/zB2unShloepmXHwHogGwWk0lyF4DUhsN1qRSaX1oj52p3nR4h8XVbj4cq3qyFgCBgChoAh YAhcPgSihcPLV6XVlBgIEJW6J2d01fhF7Mf2fqZeEGSuOoL/TCesQghmaXWaT7Fup0pabxVe Abnk0IuAXgGNxQD8CvawWrydCMw3IdSW0Oo1K/0BzY8UWO7555+vCWmpiqnOeojHV5gQLUdw Plu9evUWCJKepkSCMRGAV6qt/ger998o2JlO7OYrozkohkZiRWx1+uZHm3KIYGIbWMFvhLnO z2hBqhH9OR1EJAMEYRG+Eo2feOKJckTY3o4WQD4RaWT7jxAeMABZfMuTVojy66CB2IOpWXbI 141oc9YsXLgwEiLlBfJz7Ubjsg9iEKHnzZs350bAXjh//vxsaJVyokHaLq0ApCwf2pNVRGMu TOyH5S5vbNfY6tc4YF61S/kgE1FoY+6/4YYblmHGtc23rGDtdGlDLc+lh5SlInJ6B/qWh8CC 30tjxjz4jjGYgWlWWQhvHbQtTSFMs4nM7UXjdnntaggYAoaAIWAIGAIJi4Ct4iUsvkmmdAT6 oURo7qFzxowZ/YmQe6Zbt24N1ECEtFwIi+tdY4sVK7YLzUX0CrZ7ryurw+fNGUhAbt6nhnw8 gYD9gk60BdcgzJ5nO+/K+vbbb/PgqDtgx44dV3D/MlGo38YXYJkETaUZOnToFATiCATzITJb ws4/2qTKlaErZGaHe8asaQ++BUXcs64yvULD8bRONAyVIDcNdC8TKH3HZ2A8QnuR5s2b9xJp gcyso84dimSNf8FEVvjvQCDvXKVKlSWYVu2/8sorAxIIlaUjPuUpQjTt2YlpVtd33333FsjL L5gNbae+k6y0ZzlX8rl/hQkRwj3Bnn7sA7ccmHsdZ5U/nQgOpKdC9uzZ96HJyIS2qAGr9gt9 8we6j61+l5YybgKfxxmv3yAMH7j37hqsnS6duwYrz6XLmDFjKvo0EJI7AMJZB62X53CuyNuY VM1DMzIMM7eR8+bNK8GYDRbJcHntaggYAoaAIWAIGAIJi8B5AmHCVmelJzACngAeqA52ZzqD cO+d0hZw/oSgmV9pEWC3IkjndPkwl8mLoLrOPbMC7wlnMmdBiD1v+1CE2KOYmZzByfhZhN6n dOLo+zRaiNmuDP8rQvp+tAffkacYTrMtMGMq6SsEQibO0Ka3cOLti3PzQgTddqy8eyvwvmXJ P8E9qz/05YB71pWdlQ5jCjVWJ31ahQ/HH/88j5MpDILqafo1lNX9vphOjd65c2cUq97bqDvz Aw88sFRmNQiyAyARfyO0b/ct2/8+vuWBVbavvvrqM4hbX/r4KivwEfhjbAejvWCSUW1xde3Z sycXuzRt1TOkbRmkqCLalBMI+VPoWzfSp0WL88edd97ZBc3Eb9JOuLyxXWOrX+kZm6qYTdVE y/OyfDIY5/OKCdZO3wyhlMcOUwUqVqzY1uWTNuTqq69eB2GKJpIiTPJxQRPVChKco0mTJpMc AXX5wuga6+82jPpgTTUEDAFDwBBIYQicLxGkMACSWXdj2LrH1TcE4kMQggxKI98IzH8qI6Cm k/Mru/eUxKn1L31j1XcPAq63AoymwHMs1vt/hMkz2N9HQEh2sxq9D2de7zs28jkRLPvh5Ov5 H7AiXgRfiauVzx1a0Z88efKkLVu29EcY/p0V/wY4fA/QdqZoHbLiaNwOUyetMB/CafhXkRQE x/Quv7tizlJe9zK3oaxCCJwe+XF14vx8Sk7JOrnfh1Zjp+7lKAyxOss2td1x3L1eZaBxqE67 NuFLcBTTrLyYyfSmf+l1oiGow0r8fKWL7YhveTiL127atOndKldO7PhtlGC1/k/5XtCeDeBa Td8QmMuhScpav379nXp+5JFHVmN+lRaNSS3w+xlCNlyO4Pg+TEUjMwL/Bc8cTGnjOmKrX6QO gf7uwYMHj2Ec9st3RafIkspTezBjyxqsnS5dqOVBfLYyB0pDqP6vvTuBs6n+/zhOGDOWaAZp oqxFsu+yRWhRIUop2lFo3yV+tP1atGjT9mv5qwfJksoSSVRCpCJ7JPuanfB/f27OPI47987c mTvjzJn7uo/H6dzlnO/3e57fM/p+zvf7PSdQbOu1UrBYVkObFpqP6uVy9dQMVg9FfQV6k1Q/ g0aNGhVyyFxax52Dfov47zYHlZmiIIAAAgjEuABzInLXCXDcWPW0Dk0N9j1qECbbrUw1V+JH Ndz6qIE9UBN8D9jkXTXYAmPpdUX7Ww0ZuUaBRGtNZl2joTKBuRB21VfDnhbrqvhDSmOQxqh/ qOcS3KQGbCvNKThFgcFkNdDXWhnUsD1fQcs257O7XErvsCZEz7XFAg31XrTQOP8rtO10jXO/ SY33v3RlPl7j9kOOeVeDu5LSrmd56vank7t27bouvTyd/O0YNB9i4rPPPttZQ2UOqnGcoCv7 L9vvevbCqldffXVljRo17lQPQVFN9l0ph++cfUOtM5uegppZyq+7PatCDf/TFECMceanaBja B7LoV6xYsWaacF1YJm9aj5KTv4byvKcApJ3qoq+u1q9XoPS3elZKqWelsIZHTXG2S2sdLn/1 PCTLvpB6D+7TkpKE8hunO1lNUZ310PCvYQowlqdVTmc79XDtjSQ9C440mX6qzqVLFcQ+pozz Krj8QnNG9ihIvFXH+ofmRjxn82BSCuXvNxH/3fr7MCk9AggggEBuEmAMsT9q04Y7RFRXmpvQ UdsGhill5NDUK5FXV3ZLaWjSfruy7N5XV4Hj1JDOZ1fo3d/be5tUrWFCge9tiInu8FSqevXq O/VMgT3B20b62cqiCcVHLcDRnIYk3YFog42DD95fzw94QbctfUQN5vxqzO5Lb75C8P7OZ7uy rrsWJYZqlNpQIl39z6eelV3O9umtM5ueJrMnqVdoZ/CxOnVjPRDuAMJdDutB0ryBJM0xiVcw tTE4Dfe24d6Hyz/c9sHfR1LO4H3S+qw7bg1r3779YJuo72znnBvO51ywXqf5SWNywXFwCFkn EPG/91mXJSkh4LkA573nVZDxAkTUMM14suyRxQIR/3EpiLAnGnfVkut7mZwgIpqAJYvrieSy UEBzHtTBMaxPFiaZ05KywPhjBRHHBe05rZCU54QLRPzv/QkvGRkikH0CnPfZZ5ttKTMnItto vUn4WIPEnl+Q6sq9NyXKvlz1vIKJGpaV5t2Ssi93UkYgKgH7+5xGABGVITsjgAACCHgokOuv Vnto61nWapgsU4+E3fq0lZYMD23yrOAZzFh3DJqYwV3YHIGcIGDzdgggckJNUAYEEEAAgUwL EERkmi5n73jsCucYBRN2W8zSWuw2oQxfy9nVRulcAnquh30K/Mf1tV/fWle93YVpg/42t/r1 ICg3AggggAACCPhLwBogvBDIbQLldEBxaRwU530aOPyUawU473Nt1XJgaQhw3qeBw08IRCPA H1c0euybUwUOqGB2bg/XEnjeR1BBOe+DQPgYEwKc9zFRzRxkkADnfRAIHxHIKgH+uLJKknRy ksAOFcbO7UNa7Ba6q7Tcq8WG4NmL8/5fB/4bWwKc97FV3xztvwKc9z48Exgj749K44/LH/VE KaMX2K0kimixf5vsvOffKCHwiikBzvuYqm4O9pgA5z2nAgLZJEAQkU2wJOupQHBPxEqV5h4t 9ER4Wi1k7rEA/957XAFk74kA570n7GQaCwL8ccVCLcfeMdqcCLtj0RtamBMRe/XPEYcW4N/7 0C58m7sFOO9zd/1ydB4K8MflIT5ZZ5tAOaXM3ZmyjZeEfSrAv/c+rTiKHZUA531UfOyMQHgB /rjC2/BL7hXgvM+9dcuRhRfgvA9vwy+5V4Dz3od1e5IPy0yREUAAAQQQQAABBBBAwEMBgggP 8ckaAQQQQAABBBBAAAE/ChBE+LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCAAAIIIIAAAgj4 UYAgwo+1RpkRQAABBBBAAAEEEPBQgCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqMAAIIIIAA AggggICHAgQRHuKTNQIIIIAAAggggAACfhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCfrBFA AAEEEEAAAQQQ8KMAQYQfa40yI4AAAggggAACCCDgoQBBhIf4ZI0AAggggAACCCCAgB8FCCL8 WGuUGQEEEEAAAQQQQAABDwUIIjzEJ2sEEEAAAQQQQAABBPwoQBDhx1qjzAgggAACCCCAAAII eChAEOEhPlkjgAACCCCAAAIIIOBHAYIIP9YaZUYAAQQQQAABBBBAwEMBgggP8ckaAQQQQAAB BBBAAAE/ChBE+LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCAAAIIIIAAAgj4UYAgwo+1RpkR QAABBBBAAAEEEPBQgCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqMAAIIIIAAAggggICHAgQR HuKTNQIIIIAAAggggAACfhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCfrBFAAAEEEEAAAQQQ 8KMAQYQfa40yI4AAAggggAACCCDgoQBBhIf4ZI0AAggggAACCCCAgB8FCCL8WGuUGQEEEEAA AQQQQAABDwUIIjzEJ2sEEEAAAQQQQAABBPwoQBDhx1qjzAgggAACCCCAAAIIeChAEOEhPlkj gAACCCCAAAIIIOBHAYIIP9YaZUYAAQQQQAABBBBAwEMBgggP8ckaAQQQQAABBBBAAAE/ChBE +LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCAAAIIIIAAAgj4UYAgwo+1RpkRQAABBBBAAAEE EPBQgCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqMAAIIIIAAAggggICHAgQRHuKTNQIIIIAA AggggAACfhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCfrBFAAAEEEEAAAQQQ8KMAQYQfa40y I4AAAggggAACCCDgoUB+D/MmawQQQCBbBI4ePZqkhEtrKaQlb7ZkQqIIZINAw4YN88yePbtB hEkf1XZ7tWzImzfv1gj3YTMEEEAgSwQIIrKEkUQQQCAnCCh4KKZytNKSnBPKQxkQyKhA/fr1 bZfAfzKyr879ddp+moKJnRnZj20RQACBzAownCmzcuyHAAI5SkCNqMoqUFctGQogtmzZUmDU qFGn/fbbb4Vz1AF5XJgVK1YkjBw5MnnJkiXWm8Mr5wvYed/12N9Bzi8tJUQAAd8LEET4vgo5 AAQQcPVApOpdPeOMM+4qUqTIkEOHDh03rGnVqlXxNWrUuL5MmTJD+vbt213vh1SuXPm2+fPn FzXRHj16NLfPbt3zzjuvS7FixQZNnTrVhkul+3r99dfLJyUlPZruhq4N2rZte5mWS+2rokWL DrGGvOvnLHl755131rvmmmtahkrstttua2jHffXVV3f63//+V/uSSy65vnTp0g888sgj1UNt 36hRo64fffTR6e7fbFt53mi+Tz75ZBX3b+73PXv2bHT22Wf3tG21T43du3cH/p+0Y8eO/J06 dWpj5TDzH374wXqYUr1+/PHHYpZ/hQoV+l500UXtx48ff6qz0eeff16qefPmnZVG7y5durQO rn9nO2cd6jhCle+LL74oWbt27R7Byy233NLEScvDtZ3/rY79PXhYDLJGAIFYECCIiIVa5hgR yP0CrXSIqQIIa+xv27atZL58+Y689NJLldwMbdq0uVFDP/KsXbu2/4YNG55et27d/QkJCfuv uOKKHu7tnPfNmjXrvGjRoipffvnl0NatW0c0/rxr165/fvbZZy87aWR0rYbwcxdeeOHGjO4X bvtPP/20dIcOHdopuOm8evXqksHb6Ri7qAGfoON8TV4TunXrtuCXX355/eOPPx4+ceLEmu6A YMCAAeeq4X21xu833bhxY4KT1gsvvFDpxRdfvLpx48aLbrzxxplPPPFEt1dffbW887uzvuee e+oo+Li4VatWC26++eZv3nzzzUv69evX2H6/9NJLOyhAqN6nT59JZcuW3aIA4Q4nwHD2t/Vl l13WU6u8jz766DjV8WE1+gN199dff8V179695+HDh/OqnJ/pGCopjcvd+zrvwx1HuPKVL19+ 7wUXXLDQvaxcubJC4cKFDzpperwOBBIel4HsEUAgBgQIImKgkjlEBHKzgK66Wq9AyKv1aszW 0xXj+XXq1JmvIUv1HIf333+/7B9//FF5xIgRo0qUKHHIvj/11FMPvfvuu6O07ZLgq9YtWrS4 4vfffz/rq6++eqFJkyY7nHTcawUM55csWfIR66m48sorW9tvU6ZMKdm7d+8O9l4N3ovUu9HM royrZ+RxS3Pfvn2Bf4PVYK9Yt27d62w790uNYrsKf4oa8cn16tW7tnPnzm2U/kD1DNzvvvp/ 0003nafj6G+LGv4t3Gm436sxnbh9+/bCp5xyyjb39/beek127dpVSCbTn3rqqao6hhsnT55c sWnTpt3USG+t38d/8MEHTZ39Fi5cmFywYMEDBQoU2O98Z+t33nmn+cUXX/zVG2+88YN6PJar l2GhejQaubex999++22V9u3bf/3aa6/NVvCwol27dt99/fXXdQ4cOJD3u+++a6ZjfueOO+5Y ofXX+/fvTxg2bNhZ7jSsJ0nbJiidj2+44YY1Tz/99AwFM2Vs+JU8z4mPj983a9asUdddd93a Xr16TZ05c2bj4Hq19MIdR7jyVa1adc8zzzwz31kU3MSdc845ixU8zXWXz+P3ycf+LjwuBtkj gEBuFiCIyM21y7EhEBsCpcMdphqR9TUsZ+5VV121QK9aztVsXT0/TQ3pzdWqVdvj3lcN+V2f fPLJFDWM7a43gVfLli07zZgxo6Uax2/Z78737rUNo1GvR2P1OgwbPHjw++qtaGnDabZu3Rqv no6ytu2ff/5ZSg3iy26//fYpalS/rDkYVXWVvpr9lj9//iPK8x97735p3zPUMxCnpeBPP/1U f9OmTcXUyH81MTFx28CBA9vbtjZ0SGVue/fdd4/WFf931GPQTI3ylIDJnd5jjz226JtvvvlU DeGl7u/t/YQJE6qqB+Ane//WW2+1UaN9xHvvvTdDc0aSdNV9kYKfvXv27Cliv9tr7Nixky0t 9d7Y3YFSXps3by6hgGet84X1JKhxX8r57KyV/ufPPffcLOez6qei6mOFGvuJsjig4CUlWNOQ sM2LFy8+Lg31COxXQDTon3/+yavg7wz1PHTU0LXlGh61V/M5Sup9ShkaNGiwRQFHYfWwpJr3 Eu44wpXPKa+tbZjVhx9+2H748OET3N/nkPdh/y5ySPkoBgII+FyAIMLnFUjxEUAgcBvXVAzW sFQDM05XoVfdeuutq9QwPaRGa1Xb8O+//06wK9Wpdgr6QsNUztLV+2q68v+nrsZfFPRzysel S5cWUwO7qBqvReyq+qRJk54799xz/07Z4Ngb3b5ztl2dV4/CBgU2k9VTEQgiNA9hlRqkHwVv 7/4cFxe3T9uP1hyFTRrmM1UBRWD8v3okmusq/oyHH354sXoP1qnHY7p6EOpoGFd+9RyUscUC Gndaod5rCFCJ6tWrb503b17RnTt3Flc6geUCJwAAIABJREFUG61XQAFAaRkue/vtt8urV2dx qH3d36lhn6gemZTeCTXmtx88eLCgext7r4b9ztNOO+2g0i+goU9dNbyq3IMPPvidgolE9XAc VzcK+HbINy44Dfu8Zs2a+LvuuusGBVmNKlWqtNp6GzQ0LVHDi1LKoGFXFpAcVUCUqhyh0rTv wpXPvf0DDzxwgeZszJbbbvf3OeQ9E+JzSEVQDARyqwBBRG6tWY4LgdgROG7CtHPYutpfX8Ng 4pOTk++3xRqyuuocuEKvxuaW9evXl7UJvM72traeCo3jP88a4Pa5UKFCu9UA1+iYlz5QMFFH gUTIycX33nvvUjVUZ2tYzV3FixcfqOFAjZXnAUvD/TrzzDM3OZ91xXyrgo6Kzuf01hoCtUuN 60APiXoiDihAKmD7qLej5Lhx49qpR+BJW9RTcZmGJRWdPn16CV2dv98WDanqll76avjvsGBI AdMBzSXIbzb33Xdf3ZNPPnmHGuoJr7zySlvZLEgvHQU7hxSQpFzxl2lBpb051H7qQSl91lln 9Vd5C8+ZM+cp633QcR7SMK+U/W0/BTNxFStW3BIqDet5UFkHKXAbqOFQ52sIW2U5HVSgmJKG ekcKnHTSSYc1FG17qDTCfReqfM626lkqqMCvYf/+/Wc63+Wwdci/ixxWRoqDAAI+FiCI8HHl UXQEEAgtYFfQ586dW1d3zBmlhv8ntuj9SA0hqmG3dFVjdYMaygXUW3HchN9nn332HA1FaqJG emBokRrU6xQc7NTdfdbrav+koUOHdl22bFnKJGIndxufrx6Bz9U78KAm5I7UePoGGjpUw/nd WetqerzzXlf8k9VgTtVb4fwevNYk8JQhVu7f1KOyX3MnRqrh/ZAtCo4enjZt2mu6u9EGjYvv Z4uCgKHufUK91zyGRWPGjKl3+umnH9TxTtTckN66qp9PDe/5l19+eU/1TPxgvROh9nV/pzkb 29SDk+h8p7wTy5Urt8H57Kw17KqEJlT3UtnH/Prrr29bMGC/qbdju/KNd99aVkFdkq74r3f2 tbWCxLI2T8T5Tne02qI7ba1SIJSkAG6bAoeUMmhYW5LqdJOCrCPO9umtw5XP2W/QoEF1dX78 5R525fzGGgEEEIgFAYKIWKhljhGBGBPQpNcqmmdwSOPa52gOwkpb1JswR1eo9+oOQ+fa3ZX0 UK/vn3/++fbqYQiM89dk3uLavoPmBYS8sqz5DJPUYN+rCdSdgzk1t6GOhhldpSE0hxWwLNI8 gNUKVlINJ/n+++9r2mRqu3uQ5lnU0tyEFZaW3p8S7haqwXkFf9ak3iUavlTXek9s0RyOazUh OTCxO3jbtD7bMCv1buSzidmaEzFLgcDLNulZvTeTFBQN0x2sTk5rf+c3DU1aqF6BRjasyG6H qgZ8AwUAK+13m7xtw8zsva7gX6ghQ/MUdP1mQ5pssfIfG0a0Wo6BOzXp99p79+4tortpBXoz 7PPPP/9cRAHNetVdDbsblKVneVnvkoY2LVSPya/qKahgw7gs3SFDhrRVT0agDDaPQUO/ato+ ab3Clc/ZR3ePqqJz6DfnM2sEEEAg1gQIImKtxjleBGJAYPTo0Q3UwJvvPlQNZ8lTq1athWps BoY0aa7AWD2HYZfuHvSEhuwM1u1NB+n9rwosZrv3c95rm8NqjI6wCc66Cl3N+d7WapT+tHz5 8kq6O9IgXcm/x+YUaJt57m3svYKYA7p6PUBX3QfaZzWop9haw5HKKci50t5n9KWG+ST1cBTW 3IP/6Er8YA0fKqw7IwXSzWha6r15T0OLEjTcq689Y0G3g22ryeTXKkDqLp/VkaSnAGS6hoHt 0zyGwerBeEg9Cws1d2CJ7atyNdfvjey9em/Ka45HO3kMdRYFRHfbbwrmPlAA0NruRKX312gS +btOL4KChh4atlTaeovUOzRVQcMdGkL2mJ57cbt6X76wuydZkKgJ9WM7duz4gIKHQQraktVT NNbSVrpnWI+SvU/rlVb5bD8NRaskk1VppcFvCCCAQG4WYMykP2rXhjFQV/6oK0qZdQIRnfca rtNAWdbPbLY2bEZXtovrDkSbnGFMmUlLY/Dz6Qp8KTXAd6vhnOouTvquR82aNVeoJ+RHXSVP sCvumckn1D5HjhzJo96IEvabnisRcu5AqP3CfWfpqaGepOFZ8Xq+wkY10lPdOSrcvs731rui idP7dVen4yZJO7+nt7YhaeZpPRBOABFqH921qbDqsIgCnlRDrWzegm7Na70YET3XI1T6J/o7 TZpX3DSsTxbkO0dD4H7MgnRIAoETIRDRv/cnoiDkEbkADdPIrbzckj8uL/XJ2yuBiM77aIOI E3VwThChsfwhh0udqHKQT84WIIjI2fVD6bJNIKJ/77MtdxLOlED+TO3FTggggAACGRLQ0JsF GsaUobsDZSgDNkYAAQQQQOAEChBEnEBsskIAgdgV0G1ff47do+fIEUAAAQRymwATq3NbjXI8 CCCAQAwJaIJzwsiRI5Pdt4SNocPnUBFAAAHPBAgiPKMnYwQQyE4BPfTsGd3mdaieVP2cLbr9 6hN6sFkvm/Cb2XxtwvF1113Xwh5Kl9k0MrNfixYtOmmCc/vM7Btqn/nz5xe1p0SXL1++3/nn n99RD3pLuX2rnupduVq1ajfLqrfueNTSjtn9sluk2u/u7zKTnt0CVk/YblWhQoU+eiZFd8vX SdMedKc7LbXRpOzbdHvYLpan85uz1lO+G9rvugtTJ80zqa07SF2vuzw9EO5WuXreR1fdoel0 Z/+08tetYuNatWrVUc+36Kd1h//7v/9L2c/Z39aRlNO2izQ93Ta2mCa055FJX6vv8ePHB55K bmnwQgABBHKawAn9H2FOO3jKgwACuVtAT1l+UY3Fe2xZvXr1Y/YE61tvvTVTt1I1KWt4fvjh h110C9cTOhR0+PDhE3UL2KlZVVtXXXXVtbrl7VHdhnaMbjv7j56N0cueX2EP0tPtam/R7V1/ ufvuuyfq2Rk1dNejdpav3eno+uuvb9q5c+eb9AyJ4560nZn0+vXr10DPn6irZ3hM0oPiftbD +Xo4jXWVp4Ma1NU1yXiSnrmxRQ3qO9yBm26t2kUN+IRFixa9JpcJerbFAj0z4nU9y2O4HhJX U3fAquJYDRgw4FwFEFfPnj27qZ4ZkfKgwLTy1526rvvjjz+SZfC5Aqa/evToca8FSk6azjq9 cjrbRZqenn3R0/bRMzLG5cuX77AexNfDSYM1AgggkNMECCJyWo1QHgQQyBYBPcPhkK7o/6QA IHDV3QIC3Q61vZ4a/biWIWrAtXOuutuV4KlTpyY5BbHPdjVct2i91b7TlfO77SFmdoVZt2q9 Rs+bGGxXrfUMhDOdfewZC3oicxPnc1prPbegshqqzfRE7cJ2xVzleUJX1e9X8BBI7z//+U/9 //73v7UtjTPPPPOOvn371i9VqtSDehbDAD2DoZaTdqg81RCvr/kYKY1quyWqGsgVNQRoTPfu 3f/85JNPPleDvIQ9mM3y0LEus4fM9erVa9VNN930lQKJwHM1dKzxenZCKd0Gd5uTn60zm56e EVFPwcc0PTxumc0X0fMdFqunoKbd2lV5NlNA8I4emrdC668V/CXotqdnWX72wDo9y6LQiBEj pmu/qurNuFG3t62oJ0d3U+O7tX4fr2eANLVt7bVw4cJkez6HeqP2//vNv/8Nl7+dA3rmRxWl /6ECjRUvv/zyHD0Be7WCleMeUJdeOZ28Ik3PnnquNBP0sMA8N9xww5qnn356hs6xMjZMywI5 dy+KkzZrBBBAwEsBgggv9ckbAQSyVUBXrwMNfWvs25OSv/rqq0Z6CN2vlqmeatxMz4eoqivX z6iB9pKerFxfV8Ub2m/aPlkN1ZTeBn0+3T6rZ+MT+/3FF198v2TJkocuvvjiq/V9YTVah2n4 zSw12G93xuZrONVhNVwP2/ahXhaEWJChdB7Sw9S6KRDZ/9BDDzVVg/egnmz9hO7m9IOemnyN 7bt27dokLYnH3pdXg7/R+++//5b2/0wPX7vGnlFhv4XKU8d4poKTlGExBw8etFt753WevaAH 1eU7fPhwfg1pKq3A6iR3mXVscdu3by9lvRT2XItvvvnmUzXsp1leziuz6SnPfFZeJx0FCgXX rFlTeubMmYkqwwEFBTuc35KSkjYrWCllnydMmFBVPQA/2XsFbW0UXIx47733ZugJ4Um64r9I Q5z26piK2O/20hO3J1u5dbx7//3m3/+Gy1/f5/3ss8+eVjAXeI6H9cDoad1lNFxquXv/9Mrp bBtpehpatl/Wg3TLYnsI4RkK8DrqAYLLdUevvdZrpPO1jz7fef/999ey+nDSZ40AAgh4JZDy P0mvCkC+CCCAQHYJ3HvvvXdoSUle8yJ2auz9dPtCDzJroob/dKexqoBghl2d1k8hn1ht+2jb wFV4DafZYhN61UCvqx6LgZpXsE1XizeOGTPmPDVqq9nVa13pDzn8SGPeEx9//PHmCloaaajO Hwo8xmkI0WI1nI82adLkKjUkAz0l1jD+9NNPl1q+wS9dvf/cHipni8bNN1DPQSV7KnS4PN37 qzdlt56qvVpX8NtruM4s9YI0/ueff/IrECmoAOFnzZW49L777qutJ1VvVC+AzYk4ycb+qxF+ 0J2O8z6z6VmvkNI/Xz0Q2zTU7GQFX+eoN2fFggULEhVIHfeAOvW47FBgEGd56unTJdTAXjBv 3ryi9mRw9SBttF4BBWWl1Xuy7O233y6vZ3IsdsoXbh0uf6sHDa/aYvspmCil3pibqlSpskjD uDa400qvnM62kabnbK+gLI+ewn2Djq2knrw9xXrMdB5MVh1M09CsWgp4z1dvyxUKmL4dPHjw LA232uPsyxoBBBA4kQJczTiR2uSFAAInVEAN+uf37t3bz5Zp06YN0BN8j/Tu3butFUKNtCQ1 Fv9wCqQnTW9Rz0XKFWzne1vr6nCqfysVBJTQ93kVfNynBvaTtqi3oJwas6nGzjtpffHFFyU1 UXegngR9it7/d+nSpa9rLsAia2jaNs8///xENYjj1DB/woYtaZx/ypAqJw1bK5jZ5HzWsKZt mltQwflsaxt6pR6OR2xRD0N9BTdt7b0NgbLfNWfgEzXaK3Tp0uUuC1oUzKxSnpvsSduaXzBe V/gvU4P81oYNG/6ioVU79eTpkAGEpWWvzKRnT+5WeTZraFavN99880IFL99p2NBG5XdIV9oL /5vyv/81k4oVKwYa9jqOHXIrpuFeB3SVP78FOAp66p588sk71JORoN6itrpqv8C9f6j34fJ3 tlUa58nnXtXXDwoY3nG+d9bpldPZzlmnl56zXXx8vE3YHqQgd6ACzvPV6xWYcG5PDdeQqrnq GRmqYW6vzZ07t5rqbIgFGc6+rBFAAIETKZDqf4wnMnPyQgABBLJAINAAD5WO7s50RI37wGK9 BVpmqqGZbNuqAbteDenizn4aLnOqGqqrnM+6Ah9onNlwFjViCznfO2s1YvdpmMkRTTJ+TI3e h2zRRN9H1AvxrbNN8FqN9J3qPZisfSpp0uxVGsZ0rrsRqGDiiMr0qibxPqzJzQvU0O2uK++B K/DutGx+gvPZjkfH8rfz2da6s9IeDYX62BYd0zLN4Zh/7PMoGwqjhuphHdfzurr/sIZO/d/m zZtL6ar3BuVd6JZbbvnVhtWoITtQQcSfarRvdKcd/D6z6cmq6Lhx40YqcHtYx/isrsDHaT7G Rhltl0m8lcXJa9u2bUm6S9N6+6ygbZGConrqTTmoRv5EHVtvbZ9PvTjzL7/88p7qmfjBeiec fcOtw+Vv26tuGmnYVHP18vzX5mSonlMlk1453TtEkp7uMFW2Xr161zr7WW9ImTJlVilgSgkk LWCyOS7qibpaQXCxjh07TnACUGc/1zrs34VrG94igAACmRZI/S9jppNiRwQQQMATgePGuqdV AjWIdysgKGjb2NwIDf9poAZqfpv8qrv3nKtJrb/bb7rqu00N3MAVYPUUBCYW2/fHGpNHNP4+ TgHJVl2N3qHJvIHfNUa+uBqW/TXJNzD/QFfEK2iuRBnbz3nZFf0vv/xywrp16waoMTxHV/zb asL3QLudqXodimiicXcNdbIrzLs1afh7C1LUcCzg7O+sNZyljr234TZK60w1OAPBj5OnJj// Y5OSbdH7HerV2GzvbaKwAqujuk1tH03cPdvSUI9DE5VrreYS7NPQrFM1TOZ+HV8BW9RDcL6u xM+z7cK9MpueJou3vOKKKzpZujaJXfM2qulq/W8290LlWS3XxvabGsy11ZNUpE2bNpvt8513 3rlcw6/yqcekhfxmKSB72SaCa+7DJPXIDNP8hcBwMNs2rVe4/C2oU4O+05AhQ0aoHnba3BVb LFiy9Kw8GsZWJL1yOttFmp4Cn/U6B2oooAoU23qtFCyW1dCmheajerlcPTWD1UNRX4HeJNXP oFGjRoUcMnfsuCP+uzi2PSsEEEAAgVwowBWlXFipHFK6AhGd9xpSlKTl9uBFV2j3qrH9jPt7 TUp9U+Pt9+jq7r0ajvSIJuyuVyCwXQ3tDWpE/6Ir8nfa9rpy/IGGPh0uVqzY5urVq8/TUJmt Cg4G2G8a9vSr5lbsUOP9rmefffYFpbfL0lF++3UlfLyTn8aq/6Sg5Cvnc7i1Jkg/qYDmu1q1 av2onolXdWvPA2osrlRwsU69Fl/afuqVmOq8V2BxSGX4Tb//pYnJezXJ+DMn7VB5aujT19de e+1IZxtbq7E+wtJXY/0PBUwbNWymv/O7pWHfa6L31ho1aszRkKHjbNVwf1o9GX8722c2vdGj Rw8+9dRTV2sexBJLT899eM9J034rVKjQTrlvtmNUwPOi85ut1WvRx45bk5F/1/yUr+U+Tj0S 32sS8kINYXvOva3z3upQ8z+GOp/D5a85B4/rzLRz77hFAc9Y29f8nXTSKqezXUbS0zGNt3x1 3m2yc09B5WjLUz0Sy+1cUgD6mFP+CNYpPRjp/qWxAQLeC0T07733xaQEbgHGUro1cu57++Oi rnJu/VCy7BGI+LxXg6qjihAYppSRoqhXIq+u7JbS0KT9dmXZva+uAsdpqE0+u0Lv/t7e26Rq DRMKfG9DTHSHp1IKNnZGM8nVyqKA5Kg9q0FzGpLUoNxg4+CD81aQ8YJuW/qIhiLl11yGfWrw pzlfIXh/57NdWdddixJtcrbznbO2oUS6+p9PPSu7nO/SW2c2PU1mT1IQtTP4WJ26sR4IG5IW Kn/rQVIAlKQ5JvF6lsTG4DRC7RP8Xbj8g7cL9zmScobbN9T3uuPWsPbt2w+2ifrO78654XyO YL1OQfCYCLZjEwRyikDE/97nlAJTDhqmfjkH+OPyS01RzqwUiPi8VxBhTzTuqiXX33HOCSKi CViyspJIK2sFNOdBnSnD+kSRqgWeHyuIOC4ojiI9dkXgRAhE/O/9iSgMeUQmwJyIyJzYCgEE crDAsQaTPb8g1ZX7HFzsTBVNzyuYqKFImep9yFSG7OQnATv/pxFA+KnKKCsC/hXI9Vft/Fs1 lBwBBDIioIbTMvVI2K1PW2nJ8NCmjOTl5ba6Y9BEL/Mn7+gENFwtUQ+N26mhaykP2osuxZS9 1+kdAUQKB28QQCC7BQgisluY9BFA4IQJHLsCO0bBhE0qLa3FbhPKfKITVgNklJ6A7ow1U+dn Ac1lGav5Hp/qKelL3PvouR72MfAf9/dh3tsQELsL0wad+1vDbMPXCCCAAAIxLGD/o+CFQKwJ cN7HWo3HxvHu0GHauX1Ii01cX6XFHqvu3E2J814YvGJOgPPeh1XOFTp/VJr9cVFX/qgrSpl1 AvxPJessSSlnC+xW8exp6fbvPP/e5+y6onTZI8B5nz2upIpA4H8qMCAQawIEEbFW47FxvME9 ESt12PdooSciNuqfowwtwL/3oV34FoGoBfjjipqQBHwowHnvw0qjyOkKHNAWNo/hDS2BJ48H 7cF5HwTCx5gQ4LyPiWrmIL0Q4I/LC3Xy9FqA897rGiD/7BAop0Tj0kiY8z4NHH7KtQKc97m2 ajkwrwX44/K6BsjfCwHOey/UydNrAc57r2uA/L0Q4Lz3Qj3KPHnYXJSA7I4AAggggAACCCCA QKwJEETEWo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCA AAIIIIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKy OwIIIIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJ EETEWo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAII IIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwII IIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETE Wo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAA AlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAA AggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1z vAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEK EERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggg gAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgg gAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERE CcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAAC sSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAAC CCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcju CCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAACsSZA EBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCA AAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcjuCCCA AAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAACsSZAEBFr Nc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCAAAII RClAEBElILsjgAACCCCAAAIIIBBrAvlj7YA5XgQQQAABBHKjwNGjR5N0XKW1FNKSNzceI8eU 4wSOqkR7tWzImzfv1hxXOgqUrQIEEdnKS+IIIIAAAghkr4CCh2LKoZWW5OzNidQRCC+g83Cd fp2mYGJn+K34JTcJMJwpN9Umx4IAAgggEFMCarhV1gF31ZKhAGLLli0FRo0addpvv/1WOKbA 0jnYFStWJIwcOTJ5yZIl1pvDK2MCdg52PXZOZmxPtvalAEGEL6uNQiOAAAIIxLqAqwci1aiC M844464iRYoMOXTo0HHDmlatWhVfo0aN68uUKTOkb9++3fV+SOXKlW+bP39+UfPs0aNHc/vs tj3vvPO6FCtWbNDUqVNtuFS6r9dff718UlLSo+lu6Nqgbdu2l2m51L4qWrToEGvIu37Okrd3 3nlnvWuuuaZlqMRuu+22hnbcV199daf//e9/tS+55JLrS5cu/cAjjzxSPdT2jRo16vrRRx+d 7v7NtpXnjeb75JNPVnH/5n7fs2fPRmeffXZP21b71Ni9e3egLbZjx478nTp1amPlMPMffvjB ephSvX788cdiln+FChX6XnTRRe3Hjx9/qrPR559/Xqp58+adlUbvLl26tA6uf2c7Zx3qOEKV 74svvihZu3btHsHLLbfc0sRJ69jazsVWx87NoJ/4mNsECCJyW41yPAgggAACsSLQSgeaKoCw xv62bdtK5suX78hLL71UyY3Rpk2bGzXcJM/atWv7b9iw4el169bdn5CQsP+KK67o4d7Oed+s WbPOixYtqvLll18Obd26dURj3rt27frnZ5999rKTRkbXagg/d+GFF27M6H7htv/0009Ld+jQ oZ2Cm86rV68uGbydjrGLGvAJOs7X5DWhW7duC3755ZfXP/744+ETJ06s6Q4IBgwYcK4a3lfP nj276caNGxOctF544YVKL7744tWNGzdedOONN8584oknur366qvlnd+d9T333FNHwcfFrVq1 WnDzzTd/8+abb17Sr1+/xvb7pZde2kEBQvU+ffpMKlu27BYFCHc4AYazv60vu+yynlrlffTR R8epjg+r0R+ou7/++iuue/fuPQ8fPpxX5fxMx1BJaVzu3td5H+44wpWvfPnyey+44IKF7mXl ypUVChcufNBJ07UOBBKuz7zNpQIEEbm0YjksBBBAAIHcK6ArvdYrEPJqvRqz9XTFeH6dOnXm a8hSPUfh/fffL/vHH39UHjFixKgSJUocsu9PPfXUQ+++++4obbsk+Kp1ixYtrvj999/P+uqr r15o0qTJDicd91oBw/klS5Z8xHqYqeZRAAAS90lEQVQqrrzyytb225QpU0r27t27g71Xg/ci 9W40syvj6hl53NLct29foO2hBnvFunXrXmfbuV9qFNtV+FPUiE+uV6/etZ07d26j9AeqZ+B+ 99X/m2666TwdR39b1PBv4U7D/V6N6cTt27cXPuWUU7a5v7f31muya9euQjKZ/tRTT1XVMdw4 efLkik2bNu2mRnpr/T7+gw8+aOrst3DhwuSCBQseKFCgwH7nO1u/8847zS+++OKv3njjjR/U 47FcvQwL1aPRyL2Nvf/222+rtG/f/uvXXntttoKHFe3atfvu66+/rnPgwIG83333XTMd8zt3 3HHHCq2/3r9/f8KwYcPOcqdhPUnaNkHpfHzDDTesefrpp2comCljw6/keU58fPy+WbNmjbru uuvW9urVa+rMmTMbB9erpRfuOMKVr2rVqnueeeaZ+c6i4CbunHPOWazgaa67fK73ycfOUddX vM1tAgQRua1GOR4EEEAAgVgQKB3uINWIrK9hOXOvuuqqBXrVcq5m6+r5aWpIb65Wrdoe975q yO/65JNPpqhhbHfaCbxatmzZacaMGS3VOH7Lfne+d69tGI16PRqr12HY4MGD31dvRUsbTrN1 69Z49XSUtW3//PPPUmoQX3b77bdPUaP6Zc3BqKqr9NXst/z58x9Rnv/Ye/dL+56hnoE4LQV/ +umn+ps2bSqmRv6riYmJ2wYOHNjetrWhQypz27vvvnu0rvi/ox6DZmqUpwRM7vQee+yxRd98 882naggvdX9v7ydMmFBVPQA/2fu33nqrjRrtI957770ZmjOSpKvuixT87N2zZ08R+91eY8eO nWxpqffG7kiU8tq8eXMJBTxrnS+sJ0GN+1LOZ2et9D9/7rnnZjmfVT8VVR8r1NhPlMUBBS8p wZqGhG1evHjxcWmoR2C/AqJB//zzT14Ff2eo56Gjhq4t1/CovZrPUVLvU8rQoEGDLQo4CquH JdW8l3DHEa58TnltbcOsPvzww/bDhw+f4P4+xPuw52iIbfnKhwIEET6sNIqMAAIIIBDzAiEn /lrDUg3MOF2FXnXrrbeuUsP0kBqtVU3r77//TrAr1enJaZjKWbp6X01X/v/U1fiLwm2/dOnS YmpgF1XjtYhdVZ80adJz55577t/B2zds2HC2XZ1Xj8IGBTaT1VMRCCI0D2GVGqQfBW/v/hwX F7dP24/WHIVNGuYzVQFFYPy/eiSa6yr+jIcffnixeg/WqcdjunoQ6mgYV371HJSxxQIad1qh 3msIUInq1atvnTdvXtGdO3cWVzobrVdAAUBpGS57++23y6tXZ3Gofd3fqWGfqB6ZlN4JNea3 Hzx4sKB7G3uvhv3O00477aDSL6ChT101vKrcgw8++J2CiUT1cBxXNwr4dsg3LjgN+7xmzZr4 u+666wYFWY0qVaq02nobNDQtUcOLUsqgYVcWkBxVQJSqHKHStO/Clc+9/QMPPHCB5mzMlttu 9/ch3oc8R0Nsx1c+FSCI8GnFUWwEEEAAgZgWOG7CtCOhq/31NQwmPjk5+X5brCGrq86BK/Rq bG5Zv359WZvA62xva+up0Dj+86wBbp8LFSq0Ww1wjY556QMFE3UUSIScXHzvvfcuVUN1tobV 3FW8ePGBGg7UWHkesDTcrzPPPHOT81lXzLcq6KjofE5vrSFQu9S4DvSQqCfigAKkAraPejtK jhs3rp16BJ60RT0Vl2lYUtHp06eX0NX5+23RkKpu6aWvhv8OC4YUMB3QXIL8ZnPffffVPfnk k3eooZ7wyiuvtJXNgvTSUbBzSAFJyhV/mRZU2ptD7acelNJnnXVWf5W38Jw5c56y3gcd5yEN 80rZ3/ZTMBNXsWLFLaHSsJ4HlXWQAreBGg51voawVZbTQQWKKWmod6TASSeddFhD0baHSiPc d6HK52yrnqWCCvwa9u/ff6bzXRrrkOdoGtvzk88ECCJ8VmEUFwEEEEAAAQmkDD1yNOwK+ty5 c+vqjjmj1PD/xBa9H6khRDXslq5qrG5QQ7mAeiuOm/D77LPPnqOhSE3USA8MLVKDep2Cg526 u896Xe2fNHTo0K7Lli1LmUTs5Gfj89Uj8Ll6Bx7UhNyRGk/fQEOHaji/O2tdTY933uuKf7Ia zKl6K5zfg9eaBJ7qOG0b9ajs19yJkWp4P2SLgqOHp02b9prubrRBY/H72aIgYGhwesGfNY9h 0ZgxY+qdfvrpB3W8EzU3pLeu6udTw3v+5Zdf3lM9Ez9Y70TwfsGfNWdjm3pwEp3vlXdiuXLl NjifnbWGXZXQhOpeKvuYX3/99W0LBuw39XZsV77x7lvLKqhL0hX/9c6+tlaQWNbmiTjf6Y5W W3SnrVUKhJIUwG1T4JBSBg1rS1KdblKQdcTZPr11uPI5+w0aNKiuzo+/3MOunN9CrEPWXYjt +MqnAgQRPq04io0AAgggENMCgcanW0CTXqtonsEhjWufozkIK21Rb8IcXaHeqzsMnWt3V6pf v/73zz//fHv1MATG+Wsyb3Ft30HzAkJeWdZ8hklqsO/VBOrO7rzsveY21NEwo6s0hOawApZF mgewWsFKqiEs33//fU2bTG13D9I8i1qam7DC9tf7U8LdQtV+T+ulSb1LNHyprvWe2KI5HNdq QnJgYnda+wX/ZsOs1LuRzyZma07ELAUCL9ukZ/XeTFJQNEx3sDo5eJ9QnzU0aaF6BRrZsCK7 Haoa8A0UAKy0bW3ytg0zs/e6gn+hhgzNU9D1mw1pssXKf2wY0Wo5Bu7UpN9r7927t4juphXo zbDPP//8cxEFNOtVdzXsblCWnuVlvUsa2rRQPSa/qqeggg3jsnSHDBnSVj0ZgTLYPAYN/app +6T1Clc+Zx/dPaqKzqHfnM/prFOdo+lsz88+EyCI8FmFUVwEEEAAAQQkkOoq9+jRoxuogTff raPhLHlq1aq1UI3NwJAmzRUYq+cw7NLdg57QkJ3Bur3pIL3/VYHFbPd+znttc1iN0RE2wVlX oas539tajdKfli9fXkl3RxqkK/n32JwCbTPPvY29VxBzQFevB+iq+0D7rAb1FFtrOFI5BTlX 2vuMvtQwn6QejsKae/AfXYkfrOFDhXVnpEC6GU1LvTfvaWhRgoZ79bVnLOh2sG01mfxaBUjd 5bM6kvQUgEzXMLB9mscwWD0YD6lnYaHmDiyxfVWu5vq9kb1X7015zfFoJ4+hzqKA6G77TcHc BwoAWtudqPT+Gk0if9fpRVDQ0EPDlkpbb5F6h6YqaLhDQ8ge03Mvblfvyxd29yQLEjWhfmzH jh0fUPAwSEFbsnqKxlraSvcM61Gy92m90iqf7aehaJVksiqtNFy/pTpHXb/xNhcIMF7NH5Vo XYLUlT/qilJmnQDnfdZZkpJ/BCI+7zVkp6MOK+RtXtM7XBs2oyvbxXUHok3OMKb09gn1u8bg 59MV+FJqgO9WwznVXZz0XY+aNWuuUE/Ij7pKnmBX3EOlk5nvjhw5kke9ESVsXz1XIuTcgYyk a+mpoZ6k4Vnxer7CRjXSU905Kr30rHdFE6f3665Ox02STm8/53cbkmae1gPhBBDOb+617tpU WHVYRAFPqqFWNm9Bt+a1XoyInuvhTjcL36/TULQxGUgv4vM+A2myaTYL0DDNZuAsSp4/riyC JBlfCXDe+6q6KGwWCUR83iuIKKY87epyYEJ0FuWfpck4QYTG8occLpWlmZFYThGw4OtjBRHu gLGcvlunJdTD6fR1YI4PbVKT8NGL4Uw+qiyKigACCCCAgCNwrJE2TZ8zfMXcSSO71xp6s0AP mFuT3fmQfo4RsHNxWlAAYYWzoV12567hWupo4ZULBIj6/FGJEV+Z8sfhUEoEIhLgvI+IiY1y mUCGz/tjPRKt5JCpoU25zI/D8U7AehpCBRBWIntmhfWcWZBhz7Kw4WevaHlXiw27yvB5r314 eSxAEOFxBUSYPX9cEUKxWa4S4LzPVdXJwUQoYOd9pl56wnEeTda15zzk0ZXgTKXBTghkREAB bB7dRSqP7mJlz+7IyK627W4tdpcwO1n5914IvBDIDoFM/08lOwpDmgicIAHO+xMETTY5SoDz PkdVB4XJIoHA07OV1iEtNgHfbj17j5YkLfbivP/Xgf8ikOUC/HFlOSkJ+kCA894HlUQRs1yA 8z7LSUkwBwjYfAh7bsQbWkLNieC8zwGVRBFypwB/XLmzXjmqtAU479P24dfcKcB5nzvrNdaP qpwA4tJA4LxPA4efEIhGgD+uaPTY168CnPd+rTnKHY0A5300euzrVwHOex/WHLd49WGlUWQE EEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGE l/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEE fChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBA AAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQRHipT94I IIAAAggggAACCPhQgCDCh5VGkRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQR Pqw0iowAAggggAACCCCAgJcCBBFe6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAAB BLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCA AAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPI CCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGC CC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQRHipT94IIIAAAggggAAC CPhQgCDCh5VGkRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQRPqw0iowAAggg gAACCCCAgJcCBBFe6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAABBLwUIIjwUp+8 EUAAAQQQQAABBBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUI InxYaRQZAQQQQAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAA Agh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBA AAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQRHipT94IIIAAAggggAACCPhQgCDCh5VG kRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQRPqw0iowAAggggAACCCCAgJcC BBFe6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAAB BBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQ QAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+ eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8K EET4sNIoMgIIIIAAAggggAACXgoQRHipT94IIIAAAggggAACCPhQgCDCh5VGkRFAAAEEEEAA AQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQRPqw0iowAAggggAACCCCAgJcCBBFe6pM3Aggg gAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8r jSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEv BQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAA Aggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgII IIAAAggggAACXgoQRHipT94IIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAII IIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAAC CCCAAAIIIIAAAggggAACCCCAwAkX+H+rpIIgkpqmDQAAAABJRU5ErkJggg== --------------040308090004080203020701-- --------------010205020301030302040003-- From john.elwell@siemens-enterprise.com Wed Feb 3 09:11: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 0213828C194 for ; Wed, 3 Feb 2010 09:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 6JP6kOzoxqD2 for ; Wed, 3 Feb 2010 09:11:25 -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 4AEAA28C18B for ; Wed, 3 Feb 2010 09:11:21 -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-767389; Wed, 3 Feb 2010 18:12:04 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 0351B23F02CD; Wed, 3 Feb 2010 18:12:04 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 3 Feb 2010 18:12:04 +0100 From: "Elwell, John" To: Adam Roach Date: Wed, 3 Feb 2010 18:12:00 +0100 Thread-Topic: Further details around use case 3 Thread-Index: Acqk7b+Q+/GMzn7BTLWRq8R0YdpA3gABLwTw Message-ID: References: <4B6767A4.8000008@nostrum.com> <4B68A66C.50108@cisco.com> <4B69A3D2.6060309@nostrum.com> In-Reply-To: <4B69A3D2.6060309@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_A444A0F8084434499206E78C106220CAB920FECBMCHP058Aglobala_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Further details around use case 3 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 17:11:32 -0000 --_004_A444A0F8084434499206E78C106220CAB920FECBMCHP058Aglobala_ Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CAB920FECBMCHP058Aglobala_" --_000_A444A0F8084434499206E78C106220CAB920FECBMCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, Thanks for your responses. Just a couple of things to pick up on. Yes, of course you a right about contact/record-route. I meant to ask what = would go in record-route in the non-B2BUA case, but I forgot. Presumably th= e PBX can put anything in the user part, as long as it keeps the same IP ad= dress that it registered in the host part? Concerning From, I know that sometimes there is a practice of inserting the= default value for the PBX if the request comes from off-PBX (i.e., if the = caller is not reachable from the SP via that particular PBX), but that can = often be misleading, so a value that can be reached via some other PBX (per= haps via some other SP) would also make sense. It comes down to policy whet= her the SP will accept that, but in principle it should be possible. This i= s probably a detail MARTINI doesn't need to be concerned with. Also I am happy to keep PAI outside the scope of MARTINI, if others agree. Concerning RFC 4474, what you seem to be saying is that the SP would have t= o sign the request, because the PBX would not have the necessary certificat= e. So it depends on transitive trust, i.e., the SP trusts the PBX to have t= rusted the UA. Of course, if the request has originated in a domain that ha= s a domain name published in DNS and also a certificate, then signing can t= ake place in that domain, and the Identity header field would simply be pas= sed through the PBX to the service provider. But again, this is probably be= yond the scope of our work. John ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: 03 February 2010 16:27 To: Elwell, John Cc: Paul Kyzivat; martini@ietf.org Subject: Re: Further details around use case 3 John: Thanks for taking a deeper dive into these issues. Some comments inline. On 2/3/10 3:04 AM, Elwell, John wrote: To Paul's questions about From, To and PAI, I think we should also add Cont= act. In the following examples I will show only the flows between the SSP and th= e PBX 1. Inbound call to PBX. PBX SSP INVITE sip:123456789@10.1.2.3 To: Q1 (see below) From: Not relevant PAI: Not relevant Contact: Not relevant <------------------------- 180 Contact: Q2 (see below) --------------------------> 2. Outbound call from PBX. PBX SSP INVITE Any off-PBX value To: Q3 (see below) From: Q4 (see below) PAI: Q5 (see below) Contact: Q6 (see below) -------------------------> 180 Contact: Not relevant <-------------------------- Questions raised: Q1: Value of To URI in inbound INVITE request: In principle, it could be any value, since the request may have been retarg= eted to the PBX. However, in the most common case I would expect it to have= a URI of the form sip:+123456789@ssp.net;useer=3Dphone. I would agree that it can have pretty much any value. I'm not sure we need = to make any assumptions about the form it actually takes in practice, since= the value of the "To" header field is generally useless for processing pur= poses. Q2: Value of Contact URI sent by PBX in response to inbound INVITE request: Option 1: It must be one of the registered contact URIs (i.e., correspondin= g to one of the registered E.164 numbers). This is not viable for two reaso= ns: a) because this would fail to identify the particular UA on the PBX that ha= s accepted the call; b) because the call might have been retargeted by the PBX to a destination = that is not one of the registered E.164 numbers. I agree that this approach has shortcomings. We might not see eye-to-eye on= what those shortcomings are, but as long as we all agree that this approac= h is sub-optimal, we can discard it and move on. Option 2: Any value ending in @10.1.2.3. The PBX could then choose a value = that identifies the specific UA that accepted the call. I think you're making some (not universally true) assumptions here about th= e way the PBX behaves. In particular, you're assuming it will act as a B2BU= A for all calls. And I acknowledge that the vast majority of PBXes do exact= ly this. For these PBXes, the approach you're describing would work fine. Now, if someone wanted to deploy a PBX that acted as a proxy for some of it= s calls (which is exactly how the PBX we're using for our office works), th= en the contact URI would be whatever the terminal itself generated. Based o= n the relatively broad range of terminals I've played with, this contact UR= I will end up being some kind of cookie (like a line identifier) in the use= r part, and the phone's own IP address in the hostport part. Since the PBX, in these kinds of environments, is often straddling a NAT bo= undary, it will usually need to Record-Route so that it stays in the call. How all this works becomes much clearer if you look at the whole interactio= n instead of just the interaction between the PBX and the SSP: PBX Terminal Internet SSP 192.0.2.3 10.20.30.127 | | | | | | | | | | | | |INVITE sip:+9919990@ssp.example.com | | |------------------>| | | | | | | | | | | | |INVITE sip:+9919990@192.0.2.3 | | |Record-Route: | |------------------>| | | | | | | | |INVITE sip:+9919990@10.20.30.1= 27 | | |Record-Route: | | |Record-Route: | | |------------------>| | | |200 OK | | | |Record-Route: | | |Record-Route: | | |Contact: | | |<------------------| | |200 OK | | | |Record-Route: | | |Record-Route: | |Contact: | | |<------------------| | |200 OK | | | |Record-Route: | = | |Record-Route: | |Contact: | = | |<------------------| | | | | | | |ACK sip:line-1@10.20.30.127 | | |Route: |= | |Route: | = | |------------------>| | | | | | | | | | | | |ACK sip:line-1@10.20.30.127 | | |Route: | | |------------------>| | | | | | | | | | | | | | | | |ACK sip:line-1@10.20.30.127 | | |------------------>| I'll admit that's a bit hard to look at; here it is in a somewhat less clut= tered form: [cid:686090117@03022010-3484] The thing that's kind of nice here is that this works for both the B2BUA ca= se and for the proxy case. In any case, I don't think we need to be proscriptive about this -- in gene= ral, having the PBX Record-Route will work; and, if B2BUA PBXes want to use= a Contact that indicates their own IP address, they can do that. Option 3: I don't think the PBX would necessarily be able claim gruu proper= ties for a contact URI in accordance with option 2, in which case if it nee= ded a gruu, it would need to obtain one from the SSP using the REGISTER tra= nsaction. I really don't know if and how this would work. I go over GRUUs in the GIN draft. These GRUUs do actually have GRUU propert= ies (which is the point) and can be used accordingly (including use in Cont= act header fields). Q3: Value of To URI in outbound INVITE request: In most cases it would reflect the value of the Request-URI. In some cases = it could differ, if the request has already been retargeted. Yes. Q4: Value of From URI in outbound INVITE request: Option 1: Of the form sip:123456789@10.1.2.3. But this is a contact URI. Option 2: Of the form sip:+123456789@ssp.net;user=3Dphone. Option 3: Of the form sip:+123456789@pbx.com;user=3Dphone. But this brings = back the whole argument about domain names. Option 4: Of the form tel:+123456789 Keep in mind that an unauthenticated "From" URI cannot generally be used f= or anything. Really. It can't. So, it only makes sense to evaluate this question in the context of RFC 447= 4, which actually gives some meaning to this value. In other words, the que= stion about what we want to put in "From" comes down to how we want to trea= t identity. I'm not sure MARTINI has to open that particular can of worms. However, I w= ill make the following observations: 1. Option 1 would be effectively impossible to apply RFC 4474 to, as I se= riously doubt any legitimate CA will issue a cert asserting ownership of an= IP address. 2. Given the types of business relationships we're talking about, the ent= ity that seems in the best position to make an assertion about the value in= the "From" header field, which would mean that Option 2 makes the most sen= se. 3. Option 3 gets us mired back down into the domain conversation. Also, i= t would require the PBX operator to operate as a 4474 authentication servic= e, which seems extremely unlikely for these kinds of deployments. 4. For option 4: we haven't even begun to get any kind of a grip on how t= o apply identity to naked phone numbers. Also, what if the request comes from a source that is not reachable by inbo= und requests, i.e., it is not from a registered E.164 number? Using an analog to deployed ISDN-connected PBXes: if I call out from an int= ernal extension that cannot be direct-dialed, the calling party ID presente= d to the called party will generally be the PBX's lead number. I would assu= me this is treated in the same way: if the request comes from a source that= is not directly reachable by inbound requests, then the "From" header fiel= d will generally be the PBX's lead number. Subject to policy, configuration= , etc. Q5: Value of PAI in outbound INVITE request: Similar considerations to Q4: In addition, option 2 looks suspect, because = it would require the PBX to make an assertion on behalf of the SSP. I would really rather leave this out of scope for MARTINI. If some external= body -- like SIPForum -- wants to define how this is done to be "SIP Conne= ct 1.2 Compliant," then that's great. But I don't think the answer has an i= mpact on the solution we choose, and I don't think we want to tackle those = issues in MARTINI. Q6: Value of Contact URI in outbound INVITE request: Similar considerations to Q2, bearing in mind the source of the request mig= ht not be a UA bound to one of the registered E.164 numbers. The answer here is pretty much identical to the answer I gave for Q2: the c= ontact will come from the phone itself. The PBX can either Record-Route, or= it can act as a B2BUA and mint a new contact with a state cookie that give= s it a handle back to the correct device. I prefer the latter, but acknowle= dge that both can work -- and, as before, I see no reason to be proscriptiv= e about how this works. Really, once we've figured out how to route the first dialog-establishing r= equest, all the Contact/Route/Record-Route shenanigans will Just Work. Maki= ng sure this particular thing works is one of the things we did pretty well= in SIP. /a --_000_A444A0F8084434499206E78C106220CAB920FECBMCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adam,
 
Thanks for your responses. Just a couple of things= to pick=20 up on.
 
Yes, of course you a right about contact/record-ro= ute. I=20 meant to ask what would go in record-route in the non-B2BUA case, but I for= got.=20 Presumably the PBX can put anything in the user part, as long as it keeps t= he=20 same IP address that it registered in the host part?
 
Concerning From, I know that sometimes there is a = practice=20 of inserting the default value for the PBX if the request comes from off-PB= X=20 (i.e., if the caller is not reachable from the SP via that particular PBX),= but=20 that can often be misleading, so a value that can be reached via some other= PBX=20 (perhaps via some other SP) would also make sense. It comes down to policy= =20 whether the SP will accept that, but in principle it should be possible. Th= is is=20 probably a detail MARTINI doesn't need to be concerned with.<= /DIV>
 
Also I am happy to keep PAI outside the scope of M= ARTINI,=20 if others agree.
 
Concerning RFC 4474, what you seem to be saying is= that the=20 SP would have to sign the request, because the PBX would not have the neces= sary=20 certificate. So it depends on transitive trust, i.e., the SP trusts the PBX= to=20 have trusted the UA. Of course, if the request has originated in a domain t= hat=20 has a domain name published in DNS and also a certificate, then signing can= take=20 place in that domain, and the Identity header field would simply be passed= =20 through the PBX to the service provider. But again, this is probably beyond= the=20 scope of our work.
 
John

From: Adam Roach [mailto:adam@nostrum= .com]=20
Sent: 03 February 2010 16:27
To: Elwell,=20 John
Cc: Paul Kyzivat; martini@ietf.org
Subject: Re:= =20 Further details around use case 3

John:

Thanks for taking a deeper dive into these issues= .=20 Some comments inline.

On 2/3/10 3:04 AM, Elwell, John wrote:=20 
To Paul's questions about From, To and PAI, =
I think we should also add Contact.
In the following examples I will show only the flows between the SSP and th=
e PBX

1. Inbound call to PBX.

PBX                     SSP
      INVITE sip:123456789@10.1.2.3
      To: Q1 (see below)
      From: Not relevant
      PAI: Not relevant
      Contact: Not relevant
<-------------------------

      180
      Contact: Q2 (see below)
-------------------------->

2. Outbound call from PBX.      =20
PBX                     SSP
      INVITE Any off-PBX value
      To: Q3 (see below)
      From: Q4 (see below)
      PAI: Q5 (see below)
      Contact: Q6 (see below)
------------------------->

      180
      Contact: Not relevant
<--------------------------

Questions raised:
Q1: Value of To URI in inbound INVITE request:
In principle, it could be any value, since the request may have been retarg=
eted to the PBX. However, in the most common case I would expect it to have=
 a URI of the form sip:+123456789@ssp.net;useer=3Dphone.

I would agree that it can have pretty much any val= ue.=20 I'm not sure we need to make any assumptions about the form it actually t= akes=20 in practice, since the value of the "To" header field is generally useles= s for=20 processing purposes.

Q2: Value of Contact URI sent by PBX in resp=
onse to inbound INVITE request:

Option 1: It must be one of the registered contact URIs (i.e., correspondin=
g to one of the registered E.164 numbers). This is not viable for two reaso=
ns:
a) because this would fail to identify the particular UA on the PBX that ha=
s accepted the call;
b) because the call might have been retargeted by the PBX to a destination =
that is not one of the registered E.164 numbers.

I agree that this approach has shortcomings. We mi= ght=20 not see eye-to-eye on what those shortcomings are, but as long as we all = agree=20 that this approach is sub-optimal, we can discard it and move on.

Option 2: Any value ending in @10.1.2.3. The=
 PBX could then choose a value that identifies the specific UA that accepte=
d the call.=20

I think you're making some (not universally true)= =20 assumptions here about the way the PBX behaves. In particular, you're ass= uming=20 it will act as a B2BUA for all calls. And I acknowledge that the vast maj= ority=20 of PBXes do exactly this. For these PBXes, the approach you're describing= =20 would work fine.

Now, if someone wanted to deploy a PBX that acted= as a=20 proxy for some of its calls (which is exactly how the PBX we're using for= our=20 office works), then the contact URI would be whatever the terminal itself= =20 generated. Based on the relatively broad range of terminals I've played w= ith,=20 this contact URI will end up being some kind of cookie (like a line=20 identifier) in the user part, and the phone's own IP address in the hostp= ort=20 part.

Since the PBX, in these kinds of environments, is often=20 straddling a NAT boundary, it will usually need to Record-Route so that i= t=20 stays in the call.

How all this works becomes much clearer if you = look=20 at the whole interaction instead of just the interaction between the PBX = and=20 the SSP:

        =20             &= nbsp;=20    =20             &= nbsp;  =20 PBX           &nbs= p; =20 Terminal
Internet       &n= bsp;      =20 SSP           &nbs= p; =20 192.0.2.3        =20 10.20.30.127
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
    |INVITE sip:+9919990@ssp.example.com&nb= sp;  =20 |            =       =20 |
   =20 |------------------>|        &= nbsp;         =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |INVITE sip:+9919990@192.0.2.3  &nb= sp;      =20 |
   =20 |            =       =20 |Record-Route:<sip:+9919990@ssp.example.com>= ;
   =20 |            =       =20 |------------------>|        &= nbsp;         =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |INVITE sip:+9919990@10.20.30.127
 = ;  =20 |            =       =20 |            =       =20 |Record-Route: <sip:+9919990@192.0.2.3>
&nb= sp;  =20 |            =       =20 |            =       =20 |Record-Route:<sip:+9919990@ssp.example.com>= ;
   =20 |            =       =20 |            =       =20 |------------------>|
   =20 |            =       =20 |            =       =20 |200=20 OK            = ;=20 |
   =20 |            =       =20 |            =       =20 |Record-Route: <sip:+9919990@192.0.2.3>
&nb= sp;  =20 |            =       =20 |            =       =20 |Record-Route:<sip:+9919990@ssp.example.com>= ;
   =20 |            =       =20 |            =       =20 |Contact: <sip:line-1@10.20.30.127>
&= nbsp;  =20 |            =       =20 |            =       =20 |<------------------|
   =20 |            =       =20 |200=20 OK            = ;=20 |            =       =20 |
   =20 |            =       =20 |Record-Route: <sip:+9919990@192.0.2.3>=20 |
   =20 |            =       =20 |Record-Route:<sip:+9919990@ssp.example.com>= ;
   =20 |            =       =20 |Contact: <sip:line-1@10.20.30.127> = ;   =20 |
   =20 |            =       =20 |<------------------|        &= nbsp;         =20 |
    |200=20 OK            = ;=20 |            =       =20 |            =       =20 |
    |Record-Route: <sip:+9919990@192.0.2.3>=20 |            =       =20 |
    |Record-Route:<sip:+9919990@ssp.example.com>= ;           &nbs= p;   =20 |
    |Contact: <sip:line-1@10.20.30.127> = ;   =20 |            =       =20 |
   =20 |<------------------|        &= nbsp;         =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
    |ACK sip:line-1@10.20.30.127  &= nbsp;        =20 |            =       =20 |
    |Route:<sip:+9919990@ssp.example.com>= ;  =20 |            =       =20 |
    |Route: <sip:+9919990@192.0.2.3> &= nbsp;     =20 |            =       =20 |
   =20 |------------------>|        &= nbsp;         =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |ACK sip:line-1@10.20.30.127  &= nbsp;        =20 |
   =20 |            =       =20 |Route: <sip:+9919990@192.0.2.3> &= nbsp;     =20 |
   =20 |            =       =20 |------------------>|        &= nbsp;         =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |            =       =20 |
   =20 |            =       =20 |            =       =20 |ACK sip:line-1@10.20.30.127
 &nb= sp; =20 |            =       =20 |            =       =20 |------------------>|



I'll admit that's a bit hard= to=20 look at; here it is in a somewhat less cluttered form:

3D=


The thing that's kind of = nice=20 here is that this works for both the B2BUA case and for the proxy=20 case.

In any case, I don't think we need to be proscriptive about = this=20 -- in general, having the PBX Record-Route will work; and, if B2BUA PBXes= want=20 to use a Contact that indicates their own IP address, they can do=20 that.


Option 3: I don't think the PBX would necess=
arily be able claim gruu properties for a contact URI in accordance with op=
tion 2, in which case if it needed a gruu, it would need to obtain one from=
 the SSP using the REGISTER transaction. I really don't know if and how thi=
s would work.

I go over GRUUs in the GIN draft. These GRUUs do=20 actually have GRUU properties (which is the point) and can be used accord= ingly=20 (including use in Contact header fields).

Q3: Value of To URI in outbound INVITE reque=
st:
In most cases it would reflect the value of the Request-URI. In some cases =
it could differ, if the request has already been retargeted.

Yes.

Q4: Value of From URI in outbound INVITE req=
uest:
Option 1: Of the form sip:123456789@10.1.2.3. But this is a contact URI.
Option 2: Of the form sip:+123456789@ssp.net;user=3Dphone.
Option 3: Of the form sip:+123456789@pbx.com;user=3Dphone. But this =
brings back the whole argument about domain names.
Option 4: Of the form tel:+123456789

Keep in mind that an unauthenticated "From" URI&nb= sp;=20 cannot generally be used for anything. Really. It can't.

So, it on= ly=20 makes sense to evaluate this question in the context of RFC 4474, which=20 actually gives some meaning to this value. In other words, the question a= bout=20 what we want to put in "From" comes down to how we want to treat=20 identity.

I'm not sure MARTINI has to open that particular can of= =20 worms. However, I will make the following observations:
  1. Option 1 would be effectively impossible to apply RFC 4474 to, as I= =20 seriously doubt any legitimate CA will issue a cert asserting ownership= of=20 an IP address.

  2. Given the types of business relationships we're talking about, the= =20 entity that seems in the best position to make an assertion about the v= alue=20 in the "From" header field, which would mean that Option 2 makes the mo= st=20 sense.

  3. Option 3 gets us mired back down into the domain conversation. Also= , it=20 would require the PBX operator to operate as a 4474 authentication serv= ice,=20 which seems extremely unlikely for these kinds of deployments.

  4. For option 4: we haven't even begun to get any kind of a grip on ho= w to=20 apply identity to naked phone numbers. 


Also, what if the request comes from a sourc=
e that is not reachable by inbound requests, i.e., it is not from a registe=
red E.164 number?

Using an analog to deployed ISDN-connected PBXes: = if=20 I call out from an internal extension that cannot be direct-dialed, the=20 calling party ID presented to the called party will generally be the PBX'= s=20 lead number. I would assume this is treated in the same way: if the reque= st=20 comes from a source that is not directly reachable by inbound requests, t= hen=20 the "From" header field will generally be the PBX's lead number. Subject = to=20 policy, configuration, etc.

Q5: Value of PAI in outbound INVITE request:
Similar considerations to Q4: In addition, option 2 looks suspect, because =
it would require the PBX to make an assertion on behalf of the SSP.

I would really rather leave this out of scope for= =20 MARTINI. If some external body -- like SIPForum -- wants to define how th= is is=20 done to be "SIP Connect 1.2 Compliant," then that's great. But I don't th= ink=20 the answer has an impact on the solution we choose, and I don't think we = want=20 to tackle those issues in MARTINI.

Q6: Value of Contact URI in outbound INVITE =
request:
Similar considerations to Q2, bearing in mind the source of the request mig=
ht not be a UA bound to one of the registered E.164 numbers.

The answer here is pretty much identical to the=20 answer I gave for Q2: the contact will come from the phone itself. The PB= X can=20 either Record-Route, or it can act as a B2BUA and mint a new contact with= a=20 state cookie that gives it a handle back to the correct device. I prefer = the=20 latter, but acknowledge that both can work -- and, as before, I see no re= ason=20 to be proscriptive about how this works.

Really, once we've figure= d out=20 how to route the first dialog-establishing request, all the=20 Contact/Route/Record-Route shenanigans will Just Work. Making sure this=20 particular thing works is one of the things we did pretty well in=20 SIP.

/a
--_000_A444A0F8084434499206E78C106220CAB920FECBMCHP058Aglobala_-- --_004_A444A0F8084434499206E78C106220CAB920FECBMCHP058Aglobala_ Content-Type: image/png; name="contact-2.png" Content-Description: contact-2.png Content-Disposition: inline; filename="contact-2.png"; size=128563; creation-date="Wed, 03 Feb 2010 18:12:00 GMT"; modification-date="Wed, 03 Feb 2010 18:12:00 GMT" Content-ID: <686090117@03022010-3484> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAxEAAAM+CAYAAABlnYyFAAACLmlDQ1BJQ0MgUHJvZmlsZQAAeAGt 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 AElEQVR4AeydB7glRbW2T5ocGIKAmAYBEyoqiGBAxCzqNYuRoF5zzjnniDnrVVF/r4o5omLWq6go ohJERJEcJocT/u9dXV+f2j1777NPGmbOqXqe3mvVSlW9anV3VVd17b6+kooHigeKB4oHigeKB4oH igeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oH igeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oH igeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oH2nugvz25UIsH igeKB4oHigcm5YHyPGnvruKX9n6ZDepYG6PtaG3Epkwq7dvedcUv7f0yG9R2Md6ONuNll0aecZcW g8UDxQPFA/PCA+2eH6YBje+IztiR67a9/DVZH0xWvt15TKVjM1mdXH40VcI0w3Z165XWzg+mAY33 am97yu3IddtefpisDyYr3+48phJ3k9XJ5Wcj7tud1w4d7G0rXIjFA8UDxQPFA9eoB/KHKrgPKtXE e6lobq+TfC8ynXR7pU+3jOnq5/WcSVu5XfDZtN0saybyeeeomz3kLOtOFNC4+YbdbLXj5X4D94Fs E2+n36Tl9po853uRsexU4XTLmK5+Xu+ZtJXbBZ9N282yZiLvWJ7IVh7PjvWZjPuu5Q915RZm8UDx QPFA8UDxwLgH/CAG5sdAyg+OiwZmmQa55rWjT4fm+tlGM2/6ZGE7O+1oTbu9yDR1es3btmGver3K zZbdZvm9dpaaes7nnShwd6RGhDsPDt15ofWAA3yiZF8A82Mux73PuembTvRcrheZXH4yuG0bTka3 F9nZstssm1icTkLfNvK4nsm4n7B+ZRAxoYuKQPFA8UDxQPGAPOCHK5CDDhTHgqc97WkH3exmNzti 2bJl116wYMHy0dHRgX4l8foEkOkbGxvrHxwc7Eu8yCeZAegphd2kCgmR/oGBgbBFPsmFgui1DDzK UKrLND/To1592HM9UFCK+qRyKIMyw3b8VDaxH3WlHGSy8iKPHaUoAz5HZifyCESBNajOMemGTdcj p6GjVKvnmVQPk6h4CLoo9JCRn8O++dQNP7iOyX5UCHnoPkcKVvK5RSbTjbx/RMfH7sxjI1iyP5rw MWRSqjtD4oVggnUWOWWsEHT0Zc+60Gj8gMPDw1euWbPmrNNPP/1zz3ve834g9S060KeDRaptVdmu v7UvJQWOfznmRdync41rFxcrX+J+/JqRO8bTHIv78RPrgvni6CJSWMUDxQPFA8UD89wDfla4EwWk I7/wZS972UMPO+ywg69znetsVieODmn/1q1bB4eGhvrUmVO/dXyAkDqlyPSNjIxEZ1cdk7pjbj46 5kPDLv4XTKDKQ/IhXo1Lp+7omI8dcHhA7Ke6RT7Xh4856oZeZboeFNQdcfgNXihaF6ijrhd288N8 ZOigpSSRSo18Lp/oIet6uY7WyeuEPnbhIW9eZXa8LjkPPCV04/xyG/DIZ3KWbwslGwMDd/qrKtVj hUAqk2PYjYFAGmDQ0a91MSPd0aQfgxDVoR6UZLo2PnrJJZf0/+IXv/j8cccdd6JsrdUxrAO7HlB4 MCFS24TvSMCIV8ES91OI+2bMKR+pavJAw8/C2l4zSCBL3CEjXKhvC1UeuhKiJe6nF/f4sadU3917 ki5CxQPFA8UDxQPz0QPREdWJ89Tm4Nmx6GEPe9jhxxxzzB1333133vAOavAwpA7goDrog4Z62IMP OC84lPPh6Zk/wIDDdDoI5ClLNGbM0Q8b2ElHnacMdKwvPvUIHXSTndATHuUgn+yGruWhc1CGccuZ lsnWMkk26mw5aNTJdgxlLzro2IVG3rhlgC4n5yOXOkmhazlBt1HYsj2g9RN02SGvjljMypiHbXSw axqwIo8PwsyD0ZRNPIFKj7qhD8xw+EFDTvTI84Owzj1kkYeWQ3DnEQdHHn8h67R8+fKx613vejfT gPaCn//85+eL3m7QMF6wFcdh+EhZ7HLMq7iXX32t1ddIu3hGDv/I/3Ws53Li0UZ1vCJLHrrxnE87 pras+cgRF0055d1GIWt7QB2mhUxWZrxMyMrAdMjmMuhX5HkX9zr13hJOK6l4oHigeKB4oHigkwf8 nMg7UnTs9/jEJz7x0Fvd6lb7bNmyZUgP2wEGEXRKPQMBZEZCD2sexvEgh09BPKyVQOOHzgAJOjME 1nEeQaUWG+RJpgOT/SgDnssBV4qlTJQFnXyy4d5C01bwcxmMoI8uNvLZDOSSbPCzvNBWXhKoy0u+ sH4uH3VGnzJtJ8+bwbnnMsZTfYOXBOpykDEt4XFe4C7L9CQHnRQ2KjQqh56zgZNXnaLjDq6DRHkB 4yfNNkiRbCSMqP0BGIzZCXVKI29d88mDUw4yyqOIXsxaKD/yl7/85XeHH374y0W7WMfWdHhWwkuc RG5J4QBR5mXcqyHi+pD/Ij4EI+7lj7h2HPfwoXGklOcDb8S2ZUPBukk/5G2TeM7pljWf8lBAzrS8 3sKhk1rKSvma5rx183IyXYoiRZ0qNE56rsW9T60nONvfREQD91ST+SVU/LL92nv8qTZeZjvaOHf6 WGnf9j4sfmnvl9mgtovxdrRey6btOPIO1SotYdqdgQKDBz1sWwYRovtNegwI3JFAjod7nk+ViDLg 0xlMHQAe9NiJfCcdOhG2gTx1Vao7CbIXttHnwDYdBnBkm/Km5XzT6Dy5bqJxLgLjNjI87H7zm99c 9sxnPnOfxYsX1/7X8q8N+o7k6tve9rZb3vOe9+zyzne+c1d9T8LSHJZZ9d3ylrfc8q53vevK6173 uqO//vWvF2rGZ4/Pfe5zlx9xxBF0gPsvuOCCwSOPPHJ36a15wAMesIWTVQo/Z+Vz/sqO1w37Wd1r vHGe1vF5hhGIuT62M/uwnQdKdCwGAoI4OQYCiCQ67R/nix40eGpnoVUmgZCxPUQ9eAhBnQ+8RIvy OBd4ogfEsPx4Q4FddVypg8I80ACnfjFiEWymaEMRkeHgjfu8jfv/+q//OuCcc85ZLB/EckP52u3a 98UvfvEfN7/5zSMWxaZdEAvI9ZeloMPjyGMPHeRovpe85CW76JoYe+UrX8kytJCFn+PIKm0T9wid dtppQyeccMKyP/7xj2uxV4VEpW88LxsdpRBI/MAh5vqUx2HZQKo8dInOibjntHpKMz2IqJ2elW4a 0HjG3qHQHb1+s+msXs69F5np1LF+yPZopFf5XA7cB8XkvB6L3UasnV9MAxrfRnEHIezo9ZtNN/Vy 7r3ITKeOk43BXuVzOXAf1DXn9VJ3fJB3pHh2LNFykWWahRhkIKF8PZggrwd0LC+hA8FDWPzoMOhB ix2SaeFf0ZGT2viAABnLY0Mp3jpCJ++3oepEhi3o0JTPZxlqnvXz+rge8MBJOa2ZRyjVJeTowDZl xOc8EKWegxpsDf/oRz/6F+cmfw289rWvXfXqV796969+9auXIHuHO9xh06c+9anLkd+0aVP/gx70 oD3e8pa37KKBxJpDDz105Pjjj1//7Gc/e5VsXCGf92lQsstd73rXLfe73/2G0dcRVXA9BKOO2AOn LmqH+s1yLp/LUuGUwhnC3XaQ7aAaB0nJ8pRrGoV7IEE9osMJn4M2kiADAHTHlaoyJRJyISOcWAo9 2aHDT71I0FoGERQOTXEAIDugzuhugst0LNDBzANH2BHslqgbdeAgxudl3Ou88XcMFGhI8ne84x33 VxxfpDjcQB6yrntmIpWtru1KdHx2kLxp1pHdsGe6IKlPH8SvB1HcDpJv2oSnFPYCaZQpu1ER6yNL WUknyuSckl0gKQoCpnrVNPQyPjjJ8hGbFUlEyaZ4pbydMe59KhPCmRpE1I5MTiVvWhOfsFJJwPrd 5HuR6abfC286ZUxHt1m3mbSV254tu3kZs4HnD51O9pGxnN80AY2bb9jJTid67jtwH8g38U42mvTc ZpPnfC8ylp0qnE4Z09F1fWfChm11gtujjE5lT5XueO6mn8ezY32qcW8fATnyDhXfFsQ6aGYixKsH ETy46TDTUQSmBzIP1EhUHgQAn7xkYk1Cotd85aMzkFSiM4M96dFpCRvoKIUN8bYZRMBDn8MzCeDI mg5MqYVGOZZBlzJzeznfcvCpI3l8gAF8Ak02+vUdyYYHPvCBK9auXYvfQg4++MKFC/v0RlfFDIcu tl7wghdsOvXUUxe/4hWvWHHggQeO6G3w4Ec/+tF1shezNOhRD+znZUNT+XHyqRyBSFEmGHx0lOIn t4F+zrNMg1brBqJOE3KyQ5YBTN3JT7aD4XKQsSzQR6Jjp6UTpixx4sEHYsxWRJsjq4TffM6cnGc8 Fkp2kQ6WMXkgQdv4GhFaJ+sDOZDjiMHyfIh7+Y2kU66u0Wbcw5Cv45sfZM4888yFr3/963e/8MIL FxxyyCGbXvWqV125yy67jJ599tkL3vve9+6iZY9bvv/97y+5y13usok20gzBQi0zW6BZtg0aZI+8 +93vXsFsnQbPa25961uP/L//9/+WKPU99rGP3fzIRz5y5aMf/ehNmrVbcuWVVw488YlP3PTf//3f m7Hzn//8Z0CzFUs0Yzd0oxvdaOTpT3/6Fg1sRuClOtbQ5wNdKeiGyMMHzuO4D8dM5mcmBhF5Q4D7 4IID56KLm4qgE7xOyfY68adCb9ps5mfCJjZ6sduLzFTq4/Jnw/5s2OzlHKunUC+SrTLWA3L4IcGD w3m/iXIeC+C9JvsEmB8l7rf1oH21LWfqlKbNZn7qlsc1Z8PmuPXO2GTiMLdiPSDHTMW9/QAkvnlu xEEHmSN1kOODZT2II28eHW9w6fjhHPbiiS1a4oldd+LpOIZsovl5gUp0TuFLL5mo9JJsdGzcIchs Cq3k4JFRarFBPqXgkaczoXND3kfwJFfLyF5NE+63/ZanvlF/QfzTrx2DBj7+8Y+vVEdpy6JFi2IW 4aKLLhr87Gc/uwxb//rXvwbV2Vr8sY997Gp8Q50YWGjp0noNPFZ+5Stf6fvgBz+4buXKlXX9qQ+6 lAWejuBTOXhKUWnhcV5AiErVyWQdKNPaycDDHr6B7/IwRLKO6EJby63YrQMFaDrCpmDUNdmwvgdC dR6+M4JeUiZ3VR9jywx4DDaoIPKiMYggbpmNYCARMSlIgh+VjVz1k/sH2XkV98ln+MD+Czy1d/gG 33PtazA88IQnPOHaxx577Jp73vOeV374wx9eqZmE3RWnV6xfv37opz/96ZLLLrts6PGPf/y6n/3s Z4u//vWvL9GAeM3973//TZpVW3XQQQdtffvb377mS1/60hLB5ZqVW/vPf/5ziOVM1OOss84aet/7 3rf0bW972wYGCxqgLH3Uox61denSpf0f+chHFu25555jp5xyynrN1A29+MUvXvzLX/5yo+sP5Ej1 ruOT86KZocMnnk1LunUeGXiiz4e451x7TlwU00nhWRkActAKHAue8Yxn3FKjwjtrJLqX8iv9IImW FEEwWgw03Ywinxo7bKGTUuTd2JV6v6eyEXGQhA30UlDUwe/ys0DBZjw1AKJHXnpCx2+OSQReHNRf qb5JI+/ykEn1d6DFDd024IGn86ptilbXA9tkqY/lE61+OMCHh4zlx03UbRE8/eCTMGoZdNBXPZpl RJ1QVJK4q1Wfe4tfLYS/krA7C/YP8nEkfv1GSTf40NEPN26JVdv3JfnIJ4F4y2QZwcirbMvUfGyi r/rUNIQkO6olBFfpRve32d43vMR9XDsl7ude3Me9QdefIRd9zETQidBBR65lEMH9CR6XoGRJdGpF ru8XYQu5JBPPAl2vISDdtnxkOZIdy4R9ymjas214JPSgpRR6woOZ6KZRf8Qij751wa2T7mVRD8vm ZYL/+9//XqD/0bgOhkjq9IzwxlU8zrX/iiuuGFBHayH6vGkVvU9vdheocxUdW2zc+MY3Hr32ta89 evXVV/frWwoVWy/ZwiS+DciPUlVp2UNXvKgveDqHkEn1DRkIPj/oyBpCB+dwMt908vCUFxr3fZDI WyfxK4FERC/JB1t4PBOUCTrEijQO29HwRyUaLnNFHXM4h8EDB/2emPURDP8LdkrYyQ/k50Xcc96p vYG0Rfgh0cJv+JzjG9/4xnLF5vDjHve49ehp6d3au93tbntrABG7Nen526+Zhqt22223MQYRminY pAEE30/0iTaqmbnNGlTL1OhmDT5WZD6v+xSib9Is3KiOrRpQLNZs3NAtbnGLUZUzAmSZ301vetOx v//974Pr1q1zmzm2OQXHUeAqw7wS9zhjimk6gwgaiQT0hciFuVAjwYdqvdxtdKPkTcuYpsHW6SbE DVmg6qyrFdEhxU3NeWSgKWDrzjk3MOdzPrt+hAEFB3aRSXmCxEEUMPGbtBDXD3Vw/XyjDNmmHWQ5 8oFAbps6VEWHHE/MsGc69ki2A6yy1TmDQyA1ZHgKWLht3SqVqn7UibzKjfJtyzIJihwV4K6LzbiY gEro8xSpLzTj6ZziTp3kQl5loRPlcb4QSaLF0w0+WR0xvQ1dR+DU07yEByHDPSUOPXi64UTdMjsS rwYR8FRPbkoBFTcrxTv4Bje4wSF77LFHvm+4y6VenqmA1imFn8QERqwKlrjvEPfJT2qiKjnfhOJG wCGV85QtcV91DneEuCfeOYh3juhA6LqKjppg5NVmpjsfHYGqaetrJu4TstFy39Z1GvdibMJLOtGB IcP1LBD3FvAkU3f2k0zURzj8eHaAwyMvvdpeIgUr8RMI8ZY6cN/LdDFlO4Fji3rbDnxowL333ntY yzOuANef8fWtWLEi7rXIc2iAMXziiSeyBjyUfvvb3w7phcRyLfXY6nu5lnIs1vO0b7/99hvVspEl b3zjGzdhPKXqZFOZyX/BSnVy3QLCoCzLuZ7KBysU9QOf8yblsqZbD37Cc7kwZl6yTZbEeQeSYC0L EftKQQOHpKPWgZfoyKISEJx6mIdO4gHpMHgA4TiOD9WR6ZDQQ9by8yru8SPJcS8/RDyIXgWF8uIN 6EP/Beedd96CO9/5zte2H2mLyy+/fAgbiv8RvVCu7TBzAJ2D6+GAAw6I5Ucqis0Z6oGDZbApnfo+ ohmIvo0bN4Y+94zjjjtuyZ///OcBDbTrmEEXPaBSHRNNXCKOq5C3zjyPe9zQU5rOIIIC8guMoGLf 8MPufve731Kjy80aPLBGNvb7ptNNnhtiKGaDCOwo1UFJJtmOj8ESnwCMfGpc7NYBwlt1ghnVTD+h 1f7C5if9ePCkcuoHF2W4vKoacY7YcZ0MKZs6+6IyPR9E1A83ymzayPOV+fGyXEfXz9By+DNdJFEu 9DwPbhs5PZ2bH2BRV/i225CVeH0RxoWWlQMr9Jo65FPZyNQ3BKFc4BSGYtQ36QYdHDpJeAskA482 FM83CqNxMyGjhEwc6OgGA8BeGN9rr73GFJ8P1RrjM/Um8DtibdTB1DapKlRVrrIdf6kkbe9jXsW9 zht/q4mrN7rk8UVqu4hHbuzkkQmkkgke+X/84x8LtGPKCA+QpA85Evnzzz9/SPu7j3Bdk1cKuWbc 5zxwmjnFXuDQfGAj1bnE/eTiPu5z8iPJ/oTGHvJx303XJddmxIbav/4mAr8nOu3odgka9tQmQQum ZLFFQUpRFmW4XRO0fMjk7Z1s1Hx0k52QtT4ZcKBSOxnzaxlsKdXn4nIrE1XshUBFCJuUkcrsW7Vq FYHMPca8pFrp5vXRLP6oOmADF1988SCzD3/9618HP/ShDy36zGc+s0EdqDHtyLRMH18Pa0aCC811 jXskdnIahZiWys7zUYeMH3l+cloTt1BOT2WaVUNkMAchyfs+2yIjXuQTFAjfJbU4p9pGIuby2I4j 8ep2U73Cluj14Fe4YzraIgxt+2MZOJabN3GP/1Ob5vfLGAgkf0R7Sm6A/+NgpzHNNrD7FXr9it0B Ylcza/g9ZJNe3KO5zrFvHvnISJ+yk6zbzvfuSkFMZNQH7NcuZ4tf+MIXbv3CF76wWf3N/n333Xdp 0g9z4Hk5xmHmvBBu0HJ+J5vYE8/qNUzydcxKbhshZKyboEBNC9x60DEuGGXkMMPtH6lNOe7rc+gF meogoq6oCgGn8bG1633ve9+b6y3LaBpAQItBBA8KggSIM1KeE0U/8oI4CBnQ+IGPPHk6hOlGHnnk UEfHnYukGzalg3ptH134dHDQgZXzRRe7LjZsm48tH5SFrPWxm+oYdt/61rfuqVHx0k9/+tPnpzpQ x9BHx3a+9a1vLV+9evUw03M5nTpY3rI5vxPussR3feqysPf+979/8ZOe9KTNmsEJfrITMvBJOpfa JzBS2sYedOTNT/kWcrKJYc4niVYXLvnEZ+kR9msZcFI7Gr6GVbErHcnRFv7QTtn6Y8N6MAExVXeM dZZaW3x/DSJ+IzvsG07CJoMHnxO0ZjIPyFHivoob2qq+dpJv5O66cxM4dK1p3UPrYXeRPMs2hg4+ +OANb37zmy/lYYOQ+Ku0Yw3T2bzFGtTONJvVTlckft8+++xzPV1/FMZLiT69eRp+zGMes+Fxj3vc RvRpZnSV3EaQI1Z9nZJPyddBifvucW9/AWu/gsunHjiEU8njcNohO2JgkPze0kaWxXCj7SDlZdU2 bDcEZIB2tW3rJJltbMDvUk4tn9tE3vdk4VHPVG/LB3Qlkv2oe1avlvODntUj7lO8WYWuAfTgBz7w gcU3uclNhnnpwfNK210u0T1rq64X3or0sx5cHadF3/nOdzYyO5HKyW2GLZcB3zj6TXnnOZFek+zR seO+GW1PvlPqxst1VI8wQl1zXDIitXauoOW6xpNc6Gc4bDqz0ScR5N4d9RbsJeWxOC/iXk6pz1l+ dPzgV+P4La4nxeVWDXCXa9nekO7Ro1retFjfRSwTvJI2QBCIbp5yXqLXss43ZBxvIo/1X3XVVf16 jvTrxWBcF5rtq/u01sOOcEBdvnnN+iA0UcLWPIr7idwRF9SEQh0EHGBcjBxcoKv0sN+DAQR5rYOL vcPJq7FialvO900cnRhdCtC48TDiZu08iFKUA7/KVm/+hcegAkVkaNj0AEMMsvWcD/uQzUOOgzKh WR9cyXrbyDsgM32fk+tCXRklE9AtZZC37c9//vO7aqeCDXpYtOyDzAMMOfsi18noQscvctvM+OGT VFiM2F/2spct104Hw6wdxHa6kELEeWguN8dTWVGmy0r6QeNHqdatslG/hFYg6XBFx1VNXikGAMJx jkB90wkl6Mkn8bCVjAceyCKDEXAygUg+dA3hpXMM2ZneN3w+x718TyzVg2raABoQn6dMvz58W6aP R3dTx+ef+ofjUX1gOvTSl750Dx176uO4S3/wgx8s0YNoF31UepGWnMEf1NLIXcXfTfwrbVQfll6u 9bPMHvX/+Mc/XqidO3Y96qijhlevXh2DQMLAZbou5EWP+gBNL3EfA2dfj9y3us3Chd8kE/c3wUhc m/apoXnkdThruZZ7T9KhzYJuKCWaDd34AUn26jw0EnRSgjVNCOQ6bzwI+rEeeXCBtvK2m2QQr5N5 EJo2RGqpq2UNraN/U16ojhgf/vbpJceodmca0fImts7s++QnP7lIH1vzMXZ8LMo5aH34Fr2EWqq1 4Que85znsCSna8rL6yRIO6br1ecRotApk6OZZLdJQheaQMuLIZTNoJ1q3HSUuqWk0k0k6q161rZd Z+lSvuMWSDLNeOgFp/UHOcsCI82HuPe5Jv/FuSfcrIC6H2/VzNgGtibWs3Bk8+bN/dr+dU2LkDK5 LrjbJ8nVvm3qdcprxUvfQx7ykGF9zL2YmT5dQ6P6j5VR7da0QH2dahlCQ7lZbon79oPxhts6ZutR W0eJzgxfVFyQHuEv0SzEUg8evO2f3qTE1DaDCd2k4kZvSBARSUr5hc3NLAIKhhpd2SqvsqC3yIvn 2QXoJGptJOSZPVCwREenySOP/Sy44maa5ATGbWFUckGDzpHrUlcO6AwitDvBrnwX8pvf/GbJn/70 pyXa5myj9v6+VLMUK7XudYmmqRcR/JrB2fg///M/K0SPt7APf/jD1z/5yU9ehx11oNjfuv/3v//9 wv3333/4d7/73QJtd7ZRU4fLNRIf0FZnG3Rs4rz1QdGAOl3L1LlasHr16hHtgLCJfcb15gobfbrY Vnzve99bpweV/Vhf2OhTjh8a4D5XeMJDByElkUI+MvBoB6DpwKSzzc0Zuo7Q9Q/5nG4+9dFBgSKF DP7NBx71oAJbCCFPMoSW6+v8Z3Tf8PkY9579k5vrWAInJRiDvyCIpCVMi7QUgw/gWOY3qIFCnwYJ V+tj94Vqp0HxFzJLxHpx+Bpo9CuW1/7hD39YmO4hMhvtGzuCUMyd7nSnEX3nMqKP9RZp+VN8qAed MqkDR5aP+phGSAhHIIDqELKQxEusOoZDqBI3Wj0U50nchz/4SQknxIsZE3qF9jvy1WVZ+TPHbasd TY0kcjXTkdrO4m1hbgO8rVArsZbJdRHhfkJ7TybpI9It+vgzvodop6cdazbp2My5pPPJv7nrO/74 47eccMIJEdvSj7pxneiZEvvoN236HDv5RnyX01SlPVp4eR6cJLsgcU/GFynvtgwhy4ZC+jHN9+Sc Z7wbz/qWNRQdnwhU0PQ2MJ7LiY5O3c5tZHNSLgde4l5O0Mugi9O1EP7RLkvrNCu8kd3H+G6HGTLa jC2J9YeLV0kl5HRP3+A4x8k//OEP15Dn/qv+0chPfvITXqr2vfzlL49rAvwXv+2J0O8AACAASURB VPhFfC+EDM8dybAMOexppnqLlk71852EvrsIO9pEheWD/drJaQv6KTYith2/0J2oZ6pTkPI8OMl6 xOg8ifs474l+pjKIiIbDp+ngwuSI2QcGChzk6UTL8fW/mHowQYOqEWo7kgGPO3PCa75kY3o80WnI KFcg5KUHqe7AZkEddP0QQFz0BFfLIAIe+hzUiQMaP8ibR16pzqe61zTrWl556hYdJe1hvEBvjFao M3+ZOv7rNBuwx8knn7xSa1o3qqO/jOUa+gh9i6b9lmmwsFJbl13F0g1dkLsqjT30oQ/drO3/hrTe b6l2M9iof4zcrH8uXap9lwff8Y53rP3Vr361QH9atFxvY7fowdL33Oc+dznT4prWW3/GGWcMPuIR j1iuC2mdPsTbrDfBC7Wkienv8Ad19DlzvsbTeQiMd6bImJ9D6ErhHGwkP9UXbcWuftHTEQ8gUaor E2ScbjwUKtHgQ2/SwhZ0HbSrlzMhF7sz0d7ikTwwqjKpEyK5Gds3fL7EfX4d4Gh8KxAHPB3b5KEp 0eHfrAH00IMf/OB9NP288fa3v/1mtva7/vWvH99Pic82f4O6NvbUYHeT/oBrq/jD4m9JbRlxBq5j jD/l+u53v7tQg49Bzejxp1sRz9wDXC/KBTctuz9ErFoHuXQeAUWv88jYjiFMpVBCNum73IqbflMZ O2vct5zLdDPyE85s66fp2u5Fn/IlF+3Wi3wu4zjIaZPB8ziZTj1cZm7PtBx24lO2Uj0IyHXA0SPR Tgl29JllgclurW+ertWaZnvmkQfP89DyBM91yek5nuu7HvBF52Sb+lNq/7y8yeLUiXOgPpPVnQl5 ypedWS+bnZb08ifONSvPZRtO+ZQ4D8WTB9m1HS37q9uYe7z6Ti0x5fMnFojH9Byo9UHgkWinBDvW 17JAbANzGvrzJe6nMogI//KTEh1m7MQhx8WyJcHYBk302PYvo0fnn3zSVxtUiTwYIOercZJE1bpk RIvvIJJK3CiQkx5smwpb5JFPdmpeLgfPfAwohZzt53kYSmEbmOsKjwEENAZN4g8cddRRG44++mh2 0ug/8sgjN5577rkL1ZHaxB+rMFDQCHrgpJNOWqHZhw3i831EPzMNGnwskdxWbGk0P/ya17wm/hlS dhgsbGA7Mx1sdzYmm0P6w5YxDUYWamp8rd7OjrFeXMtDRtXRWqDBSHw8LDrqtZ84L+zLb/Z98PlR Cro7YBCQRQc/+0JUXuTq5iiImC8sZOH5AquYyY5lq2x1s0dXCR0UQy/J1bQkkPPAo6AkSwxyoxCo /nQIZbUHgw0veaH9prpvOFWY93Gf2qG+DuTbiCGg3B0D9ny2QoOBMQ2gL9aAeJneTC3Tco1dVuub IL1xWqMBxVZiVt9LXC7+kq997WvsF75i3333HdEgeZ0GFPzDF0Uya7drIPrhGtIuNpuYtaCtSbS9 EmjEBdBxkGRCXXUMmfgJSv2QLXFf+WOH+NV125fiKO4ryntQGA9q2pdjeyXiRofrFOHjWOqhDm07 JjLSQsc+qXle7eSaMnkdsAO/qWeZicqBbxnrAG3PfMpoJ8e1mOhxQunaNA1YnWhuPOGwOFJZ20iY vw0jEdCbSKaT7o5An8m4lx9m4gLBn3JrZSq1S692I74n0qG9SC7D7dDUQ64pY1lg4keZOd34ROXA t4x1gK6H+dShndx8ivupDiLCn/qJDjO+TXgMHNJMRCw5EJ0dPJALqI4dV7Z8X80k0Ahkkr7xkMlk xe6rP54WjnwcyRY3dOsgG7zUyTUefHjQ0bMc5UOjnsCqOlVV4LkM5Ek6v4D6CYL0atswbBd76F7r WteKD82xrU5PP29Qk09CFlxbpA3qz4WWa0lTLF1SGX2rtRzJ9WQQgVxlvq9PW6ZFfcmzW8eGDRsG tMVadH7uc5/7LFcdIjEr0fz3RtmMc0y2kaMe4RMe1sZdlsqNepI3Lcm0yPrhHsTqR0W0DASwE3cJ 6MaT/eruAVE+Ew2+L9D8ZlDPONh2COoHHWjUEag8cSe0HqDEeYjm9vK+4THYg67DMS20bcpljM+b uCeGleTiqrOOb8lzwHM+tUH42TrI6KO7Me0hvl7ruNfzZ0L6A63lWt+9SsuRLkdHA+E+8Tbq2KRr YkAfWi971rOetfL//u//YtcP2ejTkr+1TJFTB01Zs9YxyqH9wZFRasKguV4hMS4TJwSN+iNDkr04 L/KmQZcMoJadJ3Ef5zzNn/w67miKzlOKpRYZtUFHfdqEg3YiDvL26qbXUsAEmaYd4iMvZwJ16hT1 d/w4300PWfmi43mjm9nraMo+6VTf5DuB8c5mLuu6uiwKgoY8cjndlYCW6NQ/UtJxtgXCo562Bd5M 1m/Ha8pm51yX35TJ8r5fZKQZQ7u2n0uZzbjHbypnm3OUr8Xahuwq1YyGfltbVhIMfkOnbtdMriNK DEw17vNyiQHuJZ3OkXKQxw+uTC5rW8g5WR65nG4+tESvlZKORVogPOppW+1i2/rteC3GlEGGuqHT 5LXJ1+fdhtcTaTqDCAqgAvQq6kMnEB1nIAc8XRzxYTVQeZxFhyMe/MpG5wM5cB0keORDVs6AHge6 ZPmR/bBBkMg2JN7+By/hgFqW+pBPdgMPARFsC5hkAqZMTot6UKZSlA+TepHPcGyGEHRwyaBD8vkF RFfrwMee+tSnrtOHSZvh82GSBxvJdvgCHgagme681gOO8d8ZrB/0x9P8cVFam5jroU9l7d8acv6+ 6DL7nBbFhJ5Anq/xjF/bb0dTGZBbUiorBgiJXzsLHvXV4QFE8KDLCOQaCg+7DWj9iDsJ2HfEow/a qm6vMNL5h/IsHzC1b7QzOPy5GPe4hAZPPsf5bv+Y/UnsnM41iUy/BgO7aj/8rdohbAN6+oZhVAOK DRr0LlmzZs2AlvqtYLCsb4Hi+x59/M4HpBu1nnyR/mBrkPimfP1Tb0xXg2PXdSEv3/t+UgWsRKCn FHEglbp+1iXmuCeZZ3nyJMkBgp/yNZ7ygJBr6NQ0ymimVP7OEPf2YxM2T6ltXj7BgdZtkcG3+Cz5 uIVHppvuNsIZIbeH/ana6VYHl4H9TqlZLnnHKXrt+LJVG0z+6eg/l+u6KI47yloGnXZl21aCYSdd G3U9cxuSQ4a2q+ub8pYnG21rvQwKrTtc0fkJ4Q4/1uvArsmpD1DnOyB5fblft/0IV3TLNWEHs63k ZtvmXM6HNuh0Xt10cztNPLfXro3FF9mn09TuLe8ybEewbcw16SmWQrbJa+Ypo0mjdqYZNuuSn0FT JunXNnLZDC9xnzljInQ6gwii0JHIRQg+oA9ahrT3ez2QgKbA0X2tekMILlp0sB3MooUtNbg7BKAt gwTJRqcfnaQXMskWOIERtkVzHlinZnnImeb6kcemUtSpQis5yfhmGR2jNMXOuQWdgpJ+6GZ48Mmn c43zR88DBe2xvFXLjhbd6173iu1e9cHpcjpZz3/+8/mAyKm2j61kP3jg6nSN8ScuX/7ylxfoA6dh vcntv9/97rdEsxub2bGA6ukfJPvZ05mOHeVTZwwAsJFgjSe2y887aTXNiGRlourw2455QPg6f2zH AQkFpcjnZYkW9Uq8eFAl3yEv0WqUneSCph/bpbicFrZSeXnbxBI80fOZiOBjoEPK+fMu7mk/xU34 wLFMG5DwF4A8KEfiBe02t7kNe3kv1TcPm9m6Ep52YlokfISPqcXnD7kWaSC9BT62tAnAQv6oCH6y GzDhUWYqSyAS11i8fUImVSt0wOFBzK7Zmif5GreejXKu6LRLkpXqnI/7dqceNM69ExPfiNeWn/wd MdP0d2avo34m0wmtdR0TCOZ4B8Vaz3zOMa8j/9+gDzp31XdpfDBN3PRB09asK3TfHWIp6fHHH79e cczIsV9bfg996lOfWsp/P+gPubbovrxZGwtIjaIkoNjUMcY/+2oXpsX82Rz3/6c85Smb9Y1cJSQ5 5BWHzDz3a7nfIv5gi3/r1TUzzD0eW7YJrjr1aTZvgbaN7T/kkEPGtJPNCH/IRVlKca3k52U6uk7w bRO+6CibbbgtQTKWS1BgGzHrt0DaCFkOyic/UUIG2QnShAIT6Nds1a2jLfupFs6Q/Ly61Df8nKlN Bq1181jP8aYxvrvUrPAeiulLXCfFYh+75Wlji8WaIebfqNekeK7Vsak+TJ++tVzxt7/9bSHLq/VS aJN2F4vd8/j3aH3DuUS7iw0q/rbKxqZ07w0blIWv9KH0gi996UuLKJOlq4rTrbwIJcnGgPowCzVz PXDYYYeN6CXUFq+YQFciAlU8I68XTwtPOOGEYdWhDjYtFx/U8vCBJUuW9GmJ+Ki+uRvVddqn7cV5 wY0aCTt8uzd23HHHxfOHtkqMKMf5IFY/dRmmuX3JJ3mBbcQs3gLxp/WpC/mJEjLZOXQSr0+yk8BU 6e2fihNbyysEzoGtjbpZhbZOLAYScgity82qzue4OrO8sY3OtWUxAB6GEm6e6YZih33nLWe6ymqx bb4hZTR1mzzn83pDo+6CoW8ZIDZTqvGMHvWBrwtiq3ZvWvbtb3970ROf+MSNets6oODeVW9edwVn x6VcL8PDvPIEWV0GF5ZuAuyrv/DII49cctRRRy1lS9c0gOjXw2uEt7oMJDCAPWyko7YTxtMPvEp0 vCzrULZxQ2QV0C1XDHkOybusZH1bkNlBlhT1tKTydd2z8qMeyLhs5NAlJbzl/DRDww4Q8YAXhNfC V75dymWsM6/iXj7npUAdw6k98HXLIefVvjLvmGOO2ahY3KpvGvbQjXw3xfpuDJzf9KY3rUNG3wFt En/kHve4xyptILBS8buLbvwL1VmKrS5TWdEu1AEkp+VlOjZyGdcDmvkNfViRRAcKlLivPDK1X1+P ubZ8n2drPJfN8VqgB6Sp18znJmjb1L45ucbRbepz79TW3Mtf9KIX7aGNKxbVwkL07c4qyfdpdm3t woUL+VZnVz0j+jTL1q/BwCqWtbKMT9+vDeqbttiFz/qui66FJT/60Y+GuPfrG6JRXRPL+AdfEjKG KmOxOm0DsrNFHbdR/YfEEu2Ko+Jb7716mbQIf2tHnGE9H8ZUj/h3xzCUfpo6TZ7rZii+0Pq5ER2d PN/EkbeObWNAKT+nlrzlcpjXM9d1POX8XA8c+e2Z2tXF9WzWI5fN8aZct3xTr5nPde076qPdHNmE ZRd9l7a3BqSLczkNKnbT95VL1Ie4WstQhxU7ezoWcznNIK8655xzFqgPs1Z/kshAYbdLL710QAPd Pm0Qs4vK6X/605++QbtLLtC9fGmuS12kO6CXpsvYtlurMTZpA5gFGnDHdsfU7wlPeMIS6qpY36wd yQa1SQzX3TYNqmcJ19VCDVqG+P8It7m+w2NZ7JCeO6PaBW2EgYMGR4Psinnve997jEMDH45RbVTT z0AD/9lPhpRpHEid8nwTT3UUebyqZJTqeKyy4/ncN8bztsx1KZ+U861jiPxsp+nMROR1c03XqvEu E2Ov5omlRqk7FnxXQKc3yUUHxAZ14iLXbzRNriF83saI0DIIgm4h28jygeL4Tm8ULWuY7EVdTGtC ZHTUZM5HF9M66q/Urz8EWmscAtugYRAdfUi9iTdS+k6ij2VICuw1jLaRX716NU7AP32ajYjRO/aw wYfT0CkbqC3S1punnZ6GdaGN6EHFv0WO6YNTVCJoNRrfopmi2AotiK0/Mle9mfIov5VdB2vUnXJ1 cOIt55/p1E7hXDlIDahsK8/8zI7LqfUp2xdQLmccG9QNGWTJp3ixSN9ZZ531H2W8TVxd11qgN8R6 8y7ucU/WVhGrItXXX+LL/eMkYvx1r3vdWr0pWq8/JRq84Q1vOMLbJgsRd+pErdc1syHxR1m6lNv4 y1/+wt7jYdTlZ3zaI3iiBd5GhqrlSSIl7nOHzBbutsB+1mYdi3MbdhTowkCXdm0nktfD/JzWrW5s oa179JDeyA5feOGF8fykHLba1hbeC/UC52J2yWMmQv9nslQdpCH+70SzCsO6j8eW3fqH3Q3anWw3 zUr0+/5MPRhw/O///u8idYbW6M3v6OGHHz6iHfsW/fKXvxzSC6DYGAM56iraoOQ28I3R7W53u1EN bNgFcEhvUOsNCDR4oZPITMRWri02NmB3NL1AqZcDYs/3SXBS03fNfCXVfhkTPPsSPedNsy5503wv z/PCSSEO37jtJTvbgFTXkBcOrOuQhCuj22jOHiGvO3WaKCW/TSzYxlA6/7a6eT2sSjzrjfxCDXC3 aifJOp6RVTytUFz9WzE2wr9Rq3POt2mL1MdgyXUk5LTl/CLJxR+GitivTvtSZpi1UxPbdY9pZ8r4 H6xjjz12ozr5K3X/35D3MTQYH9ILpS2K3djSldUY2j52gQYtW7SD5ZCeAWP6z4lY4qpBwBbRF2tQ vNk27FNtl9/P1sccqkfdzqeeeuqA+mTD2qky/pBOA/MRXZuDmikc0eCbFRpxP1L/a0AvrkYf9rCH xe6OHXzpeNrGx/YvejiHvGnklZQdp82VuJ+pQUQ4SD+b1KH9i0aj10mdg2hMdeAYMjFtRMcu/vQL XAdeFQinuyOCLVLQ4acMtoKGPIjy0Vig6Yi85ZMM2UiVinPVzVI5Ou217cRFNepjHnThcSSZGodO IkCEk+pzEQ4raIamocLexmlQEwOjfbUbTZITqDro2Et+iPMmn2RcTm2fOvC/FFpbXl8clgVyQQpG 3bN6QIIWdrGRJ+RMQyblfWK1vVTHXLXGrQ8BG+R9JKF6psJ587Pyo2zXATlkyPtBg6xTkkMnDtvT x+Z9H/3oR/9PcnRI8Tfn0P71qBgTJHTnVdzjj+RngSo2s0Fa0Joy5Eno6eEywlaACCoFzRAZ8frU uYrOkNrMcYYsvg6IfAOv89DJOKGHHWAbvaBLFiGrBETWNOtiByb5BJFpKS+U04/1k6yycybu89Pc Bk/+Cb/QOfYDfxvBaRDyMqZhpkUVm0ot7SlaLaPBw8gLXvCCq/74xz8u1JvVxcjC9/3H58kbWw4t xRhiq2K91V1D2yOrpUoL+G8TxXhLPGpQMsgmGeq0xb0IeWYjWM6hQYRjLuJUu5dt8DInBgpnnnnm gN7QshFH1FXl0IHr1/dxm3hhp/ryZ3WDDDh4A9tMyIsWJ5rqKTDuB/h5PtOPAsXLSBUKLacnXGCc Dp5s5/q1sTa8FpsoIYP/BWMgBkx27bMa5oXMBk5dqBK2d8S4l1/cxqpqfx/xrNmxyzQAXqwYWYLf SFp+tEAvN0cVY/W3IsxGaKXJAsVz/PdCCOrZqaVGl2rJacSsYrGfgbNmFrZqidKiAw44gN0lo20U yyN6iTnAP0xr0BJ+wl+add6iJa5b+H5Ts2uDn/jEJxZp9mMzeipvQH/GWz+bdd2M8v3cFVdcgY2o guusF7RM2fVrADIIzeXqpdSwY57yNNswoAF62CSPjq69vje84Q2DGrSwVXg6tSq2lB+/AdScehA9 TkmYyzYj2ROYm3Hf8ibfJ90DtJeBHDRIHGqEM7U85yzW+jN48AGfBuMwLYfmZbDWRS7Xs0xTv5m3 nHWzfNh23UV3/ev6ZbJB65Cv7cCn/OSHXCdkzAdSbptzQjfXq2WaZTflzDc9BWuLLfG2uZFGVFft F7LopfoFNG46eXAOyjIOTDfx2k7OA3cdhdcd/ga9lnE51qEw7JOgAdEFpHzzXE2vbVIushpAcNP7 hR7Cv5U+b/fqNsOeDpJhlRv/NR3IYd3ReRb3js36usS/+MRx7bZr5k0HpuuFdqnvDaYDcTvQB/aN A20bOrJK7ky0yOU6IURlVV0OeIbwLJvk6rzlRQ955+dJ3Ic7+JlMohM1lUQbbE89l9Wp3KytowNv eaB1NCAY1ezDVv1/zwrtkjekbyOW830Dy594G8s/sCP/1a9+dZE6+8v1RnWD72nQSfwrdXqLWhH0 yxp0Xnq4DjBUZh+dKXCWguh7iCXMVLCsCRpJ8nXHh0GG1pEv+OIXvzikP/Pie7iwV4lV14HrQjlZ UrbiJzrMoCGT8zrhuS3rJlvb1KFpkzz1SvJRsbwc84FTSPmJ5njTVDdeUzbyO1vctzsJzQQPMaDF 32qDiHvF8Ai7PSLvuNc9mFiMC50BM0uZNFDdohfJw5rZGOD7S6XQTwON+J6nWSYy2qFvSJtvLLvs ssv6991334hlrglsIE9dZAM8vu0EQnddwPMEHR0G2yxRYnmVBkxDp5122gCzEfAc95qhG9Ry21G+ KZWN0IPPQd60yCS6+e0gcinVuslWbdN6yBm3zA4Q967/hHA6MxE0cjgog9A2aD3bKWefffblWmt2 gEafu2kUGG9sFHDxcBeMQCQA5TRwBhzVFi66QSoxuIEWfAUDic44URHyiR/C4CnFoEi4xKo/IIOe 8SMwIZmeeMwGhBz2KRc6R47n+cpsJYMtEroAlNFL+aDxg74S/Mjyo4Q45YQyGeE1XYjlA4odEHlk M0Gy5Guo8iMPLcNtr5bLdSxL/Uk5L8tzrvCiDqZD00EFOJfQTTSXH3Tkkz5oXMjY8gUNG33ypnO+ zme6Ub7ytV3k0bUNeGS0dGC9YvIiveX4jf6jgFkIloDxRiUfSBAfjmuhbZP52PUBbd7FPW0iX+dx H0vx8At0QUA0hgC+Mq1iiBUClUzoWM4w2RDYNu4rtdYYRa8Kh36uoxrHgOWNOw/kIFRK3OOdySX5 jrbD1/gx4GQsoCN5YsNwMupRZlKIWJuMcioblZ51OU+nDO9XB2WN1lvvomVGS/S922bNBm/dt5pZ jg009B3FSr6HeM973nO11n9HxyvT79N3FPH9hG0D6bQxG2Ea8qpzZLXVMWvMF2od+VatG6/f+OY2 keW/iPT2dbP+lJHv4hYdddRRI0cccYTExs8Dg7q/MjCnAcN+Kge5Ft/gM2SgI5PkQqf5E4IiIk8y zO/lpgGpQwjqx+U4D7QsvJye48jApwxmhgxzmQaOrY72GrJ1ljJcR8Oa2QOCjsTwrWEPWuMiSR9C S/uMS0wek+9ktj9WMzBrYAvQ2TFSm7e0vKmnbOT1XcWSD33oQyu1JGmdZhFiMxh2heTbTvHj/Ihl lrQymHA72j42tLR7q46rP/nJTy7Ssqel+pPcter8j/n7BmT4iBsbzNblNuDleds11DLYftVrgf68 dEyrZbbkf0anOlL/AQ1i6mtIejJX4t7+6wanOojwBQfkBscNkc6Yj41as3m6jn+KtlIHH+zkW2k6 6A3FjgvBeaBx84Ckdrxctg78SrzFTs7L7eT6zTLMawdtwzzs5zi2XKah7QNJttHEg5l+niz4wZyQ 8FwXUp7Py2ujWpNc35owgZ1O8ujnvBy3beLFsZPTjAPNz2GOW9a0PA8tP4hNpjgZLPBnf1fp4Jsd ljGxrhOeYxZZjqZdkepkHnA+x70dQhu7nXPYxMn72sh52MnjFJ758DrFPbxmauqan9NzPOfnuMvP 6wXfdMvmtJyX45Z1TDoPdCyZ5nwOc7wpl+eRy4+ZjnuXBWxXp+D7DWzqIOY6HXF3MDoKzCJjsmVb vtlZobPBuatzM6aXFJeryhED2iBgT333o9VEw3zXtpLZCu2ct4bOlWXy09N3ECP83w/LPej4U47e CA9oSQjt2ZL4BkJruBdoZmPD6tWrq55fJUH7qKr9Y6effjpLQ4be/e53byEvub6DDz54lJ2aMC5a dLaRR5Xy6MSjTN4JXcSdRy6JRCyQb5dyeo6n+BCpftMbZQdBhqBTJnLgkOInySc+vDgH5Mw3pH7Y IG8IPo3kkzSsTe1McW9f4Lr6BBoIPL29H1aHnWVDg2np6Zh2cBrcf//9q6/8k45k+Y5nqeJ6GbGv GONlMFz+E2hEM/T15gPMKrCkiUFAnvTdz2Jm6vhjXej3v//9t+o7niV07hksqNNfbwYgG/0qY7Rp Q2q0i4qu2px6cZDn+1B9j7FA32YMyzaz3tApKn60K9SAth4f4z+K0HFCV6n2U7IHO4RyWesEM7OR y+ykcZ+fWlu8tTXbimxDjMZKVK5eH/lAgk4bD2FoV+sgCJqDiPwh7YYy7MazTDtomoqLAGnmm3T4 nWSQJeUyE+GudxO6DOvneZeRwyZO/gJ+UrIdsrZlPM+bBiTlvBzvxMtlwJv5ph55Ui47flVWPOcN K2r1mz8szTdEArxb3vrIgDsmiUcGDbwhYQYCyKACugcSyFovL0PkSNB8/o75vAwGI/Mh7nGG4xvc KacZdxx0gujmPNuyn8k34x5aziefJ/MM4Rk3NI18k2YekNSLTCXZKtuMIecNrQN03IKbb2hat7z1 kcljcibinvI7Jr25Hm23Y0tHhYzBQ1rZ3P8ZtzOa9BDgKR9vmlOnwB2HujPQfIjrzbT9ONlyu9aV 8rUb0+764PNq1oxr6dCS/fbbbyvfoLE2XB+vsqvMWr5PSJ0J/ng0TlIzows1czGspUtj6swMq1O2 ULszbRZ9AW9h1WmKPx3Vv7kv0D+7D2swwgYEi/TnpBtZW84yDRIzGRySG2TNt5ZXjWqL5EG9YR3Q x7Cj6kz1a+0730ZskV/q88ef5DMf1ucKDR8iQxm5Xsq7Q0a2Tug4GW/YaWkj8Uh1WR5AQMvqFSZd F9sHQss7aTkPHDszmeZ63POthAYMmxVLy9QBX6vvDJbqW4RBBgH4UUvWlxx66KG80R/T9q4r2epY scggOOKKgbJmvTa/733vW843EgwG9B3i0rT1ax9LnRSLfFC9VZsOjGgAspjYZrmSPnpeoCVRfMcw pj/K3Srbi4lddfIpaxGzeLSnbPRr+9nBo48+OupEnOTtbJzNBDR4GJGtUa4V5JhxZpZDqV/XZ782 OmBmo8T9FC6SqQwiXIyvyvyhReeBwYJvUObRyNDh+7AM0LjQGjfNEJ47J+Ckpm47WlOmme+kY7ph Xg9oeV1sswmbcu3y1oGX4+TzxGCMlJdbUVpp7fjIYdspx00DNsu3nKFlPzo/gQAAIABJREFUrNOJ bv5EkBhyHFnWeUPoTTnzDC1jSNzBI+7cuWcQwcET1wMJ05BB1npCt6kXNJLLdGyji8/nS9x3ixHH QzvouMz1cxzfWgbcqd6NyYQusGkP0XY2J6I1648d07rh8HpJxJDjyPLOG0JvyplnaBlDx+9sxD1l 5CnqpjX/g7wVdMfOMBecCl49z+WA1Pmjg8iD33kg+U4JPp0FUlanGHRAa2ePpS+2L5G6V5308/bH REuiLlrKsfbEE09coW27x9j1Rh0oZj77NCOwgB2djjzyyD1yJXXQrmCpkrbIXC6dtXobO6yBxnrt cb+C/0tha1h1gDbof5dCTR+ILtEAYIN2expjqYl2kVmW29OuN5u1leZWbf+6SEudNmkwM8oyJ+0C uEjl6NTG2H52mKUcSuTrc1L9W/K53RzPfWk6drsl+NYDz+WdN8ROzrdem0GFxMZtWScfSEi3XsoE HdPZQX4qaaePe/xifwGb1xV80kte8pLLFS976fvB5cTza17zmss9A6CPkHfTUrrL9Qego7oHsPtR S2yzQ6Vib4N2IlunbYZX0WFnJk6DhaspkwGE7C3XIOJKDTa2agn8YuG7aCAyykBCSwN5yRc7imlp 0ybtorScbzR0jYxpFi5GzfoQfFDXziINIqpRdNW+dUyjT+IbCH2nxPVYz2hoMDP6gx/8YAtxr80H BvhfCfuk0mr9dRyKWtvvJo82fOuB5/LOG1oeSLLeDhT3VcXa/NYOacPrRrIeHScGIobs7UtD5dA8 5Ljrc6Df7gnQCw1dly+0JeX6uYzxJkTZtBxvR2vHR64p63zOy3HskJo061Xc6te0zyj7mIzR1DWr Gz2XMQ50Gd3wiXjm57agtUt+4hhaplO+SUceWk5vl887+XT0PWDg5sTBjQfIrITf2DIrQQeMI7ev bCSfn2PaMI93x795czHucUanWMuvwVwul89xywBJ9jF4HvemG8LvlJr2LWfdThA585o67XimNXWs m0PHk6F5nfJNOvLQcnq7/EzHPedGLHM4tnmFvkTH9bXr0LF6485uKEOakYA/qLftQ3o4s8RnEKgH 4YB3LRJfz8d+vgGjQ4/tgOSVlK3jqpaBDhMZBJRCL8/DNx1cKXSggZsnnRpPg4ZaDx6yqld825Pb R5+864zRlFp0dM79fJS6WrMH6CjFDzDLh47zrpNl6DhoydEgH08zgMAIKRkIkHQSqXqzSt2gI5rL s5MNhz52JV6ClWRCFj3y6Bq3YcuRJ5HPYWQyOnnZMDmg84Zmkte5hnDGE1p3uGqeO1MqH1otgyw0 +InOySDjzRpGdF6jmtG5St+ovEn0v+ngxQTb7fIM8P2fZ0QYESRxonMy7uWPuCZTWwpEo3K+gTsO yONfDYAXeBkSvBCqYiy/ViReXZeVOYv197G5gOJvgHjOeH4JgLmIO5buMYPBjBy2XBaG2fUJG/um D67ho4cMiYxSRazyQTY/icAPeoKRR0bnGfpmJltkI+XypgFNB8dXeXLe0DzyO3Dcu5o9Qzo4U0nR yFKMizUzUN1hxuncSCnDHSkuygjWho71IDf5meiEPMt2suFyDC0PbOr0ImP9XDfHc77LaNJyersy LX+lkE5805vQujm0DLQct0xOy/Gc345u/lShr0BD2+mU70aHx0H88WBgcOClS0APJMBNt2zTrkTq BI9zBzYfOAiZPl/innMmdRo4VNzqt50MHPzZLp5Mi7e5lYkJf9vZsh0rO2/YpJNv8kxrR7f+VKHj zdB2OuW70eFxOJZnKu7b1YlyrtK65Uv1IN2LcgWj/AQFIk9ngGulbv/0EI0HMHiSo4zwL3kl6we9 nYzlESBZRjBsA5P9SqD6rctABRJ6STfqmPC6EpWaTrC1rlEGPOoK0MF/H42ps8RbTc4bWui5M0Od OJB1OSkT+tBko18DM9owBOErUUeg9WocOuUphQ0YSjWuN8DxBle0qGeqbwjxgx40OuJZnUMWfrId 9RYOKc6Jcp1Mdz6HTR55HSSLxbmR9yFGMFPe5x519YACXqo7dpStDCZ6EFIdx7SpBv8LxAw0sYht H0InTHVFJQm+08S9fCEXtMRF+Axa8k20qz0ALdMhHvr1XQ/3EbEqHjGCTNLBH/USPclEXjRkopPP dv/aoaz+ViKTibqgj03+oZ0yyGcyUU/p92lpYCzrQwY+kHoAs+TybTvs6Yf62Dgy8EPfcW8+svBt O8lBghZ6kUl5402IbJ7I6yCZ7HMIu4nuskPW5yZYfyOEHHnLZ4jPKeyqkOnGvevZFU51EGGjnDA3 Oye3JnQuVkb3+QDCDxJDy6Of4+TzZPmc1g5vJ2e7hk29Jn0y+U6yOT3HXXa7eppnaD3DTp0p89Ez bmhbhpOlT8emy+wE6yupg0DeSe8gUl3sYjZtWRdIfBKHQHeqPHAwhIesj6Y9sVoS/Pkc9zijXSyZ Zmin5fmJYh/ZXJ7Bc7eUy+Y4OpPN5+VY1zDntbPd5HfKTxRbjt1O+tBtw9Cy1gXOZNxTjssCYh+4 mf8F0tr7fbwNIw83H+oYRKdADzl8WD8whUfKOiPwpVY9GAXJUEbs7AJdR8iIFnbIQg9DlbJlMlLN Rz1k0UspaInu8qlvCEBX8s4yoQLNfBsRhJTXA4LrVovLVv3WFH+ggxx0Duzgj8xu2CGf+FEQ2USr 5W1P9LpnAZ7bswxl5gk6eeoDnjpUrj9lw3eZcQ5NG+jbDji2gE6Wl0wsLwKmNI4knnWBmVz4IKOF XrIbchZO+rQjMviYpWV9Wgbm/wUirnyETLMuKQ9o8ne6uOca1HnIDePtDm46J5nznM9p4DrwRW0k 0RCPZBlBx1PQaUOVZRx227iXXPAQTCbaxn2Db508WOq4x2aSjzLBnXIeuAcSDT7nHPXgHFwvyyRe 7pOQN9/ysr+zxb1PoSc4nUGEHYYTCVQSnTXo5D0VCI0o4kDWnYja+aI1k3mGOX86tNwOuG0ZNvnO 5/wcNx+Y03PcMu1o7Xid5PxNRCd+sw7t8u3KM82wm/1cphc5y/cCiRvHVDv5bjzkzTf0DR/IQRzm gwkGFM4DLS+0a7J9zh8dEvrQyc+3uNcpTxj7TRnypDyGcrziVr/EfSdeLtdOplcadtrJ5vYt04tc U69bnrhxTLWT68ZD3nxDxzGQg9h0nBPzU417qUZZlGPbo/oo8c+rV6++nrZmvLHWS8egIe+g6AHK tqHxFo0HMQ9s6XPEkiFBJ7bwDj5QiQ6CeYHrh3LNoLMQeUgmS4b6IR9JOJmqh6KHOTh1kK6NIxf0 NjZiUIEOvMQPWwnHGPoklytWXb5p1rcwMORUjxaZRMdAXadkEGB98Dol2VreNugYeRkZtFRX9Ory wW1IMmFfckGiHYzbJnnZjcrDJ8FDNzKNnyRf85G1zaSrbKWayoi6JVqN4ydolJNglKS6+Fxcfg2R 1Ye0YyeddNLPta7/NCnw0ojBdf7SCDvWAW+X4HPs7HEvN9Zbw/si47zkKjVMinHn8V/CQ0B4+J92 VxuETi6TyVovoOgWdlu5o4+NkEn1Ik8xlJND6wfNP8ikw+UFK4v70Et1hef6GA952bBc5NP5mReQ mJuHcR/nPtFP1VITSXXnY4OANDTupUuG5udl5rhLaUczDzgRP5fN5XvRa8o0803bzk9Wrld51/88 Ifu6sAxOZKcTvxM9M12jk5GtlYTkely800kT6Tf55E3jxp8/NPJOlemGud5E9eX8HOtA4453w1zO NnPfdKOZB2ynk/ObuOUNm/w835Rp5nPZHJ+s3GTlz1Nh++YFJnyydnIT09HN7XTCc/uOwU6yE9En 0m/yyZs2U3HP+XAQz3zzwMG2jRx8G8GxUrsB3fpe97rXjbSUZ1f+F4jvIvRwHtCDN76HMOSBLnmx qpR1RnhjmXfK6zzyHPAFowMDrkSW6y4MYsvfOSTzoZf4AA9cQtcyTb0kH3ZThyLKdl3DUFWXsJOf WxAkALTdZC8qC13JDqhZ0JJa8IznEAHXJztP5K1TQ8vBM55DbCmJHeWGDfIQkXOyjvOpLGcDcp4t BGUk5zisWfJTjcNXqgcU8KwDXSl+rJPRQg+BxEMuaMjIBoWM6X+B1mkJ08X6z4HffOtb3/qNaJfq 4IXEWh3N7yEYWPMMyOvMOXHMtbiXi6pmlr9arhfO18wEm/m4JpNcXIdZHIZR6ytuWvJhKMWpcJmI svgxbtVtIAKOw6y80G0KWw67xnOILSWrteDIOVnHeexx5An/5XlwyeQxFGzHsPnEKQdpB4z7qNdk frZxwmSUM1ns5AetQR7oljF0mYYS6TnZRs8KPQhOph69yvYq5+oh303nYvFZdzyZ1M1eJzu96vQq 16mcJn2bC68p0CbfSSeng8dDJUFwDj8wnLdMriuxCRN+yA/ikzzQsWponxlKpOdkGz0r9CA4mXr0 KturHNWzrGG7Kk8l7nPb7Wy2o3WrQy7fq1yu0w2fbLxhq5NOTgd3TOcxPpW49znTmWLmOh9IeBDB R9bsFMS2P73+L1Ae05ThcoRugzd5eT63gy7JfGCON3nknSxreehNWjNP2bm862Jo28286bmuacg+ Vcf7EiHXbSfvOlnfsEnP7VimCdvZt0wn/W466OZx2cx347lc61gWaLzJI755ScSggI+mGTT4f4EY OPBBNYMIeN5Yw7Nzvl7EiuTzmktx73PiBN2eTYiMD+Ry3Hmgk/XJN2VznuUtl+fBkXXc53rY7Jaa ZSKb03JbtjORTdvIoXUNJ7KRxyg6eT7HmzzbN92yQONN3kzGfV5+T/h0ljPlBfjkgDQaJ4WTuTDz Rswdn+MSC3ngTKWm/Zmy26ud/Lx71ekmxy4SU0lNPzTzU7GZ68yEPcdPbneyeG7DeA79kIDG4c4V 5YBPJeX2S9xXHixx33skOX5619hWMrdhPIfTjXts+Rr3NQP0g4tOG8tEHP903GKXJkE6YNDRz+OC vG0K3YYHzXxD05wHGm/ynG9Cyxuan+ehdaqr6cjnR1Mnl4NHsnyVq36b5eb5f2WCphvCMt6EOa8b Do/UTj+nh1Am1ylvehM6FrvRmzLkJ0NDNo9JBgbeeY/nJgd5duhrDhrQa5ewad/Mhbj3uXCu4M47 VpsQOdPALZ9D4+Y7b2h6DsFJTRnnHffOG1Za43q90C3TCTbr4TIMref8RPK5XDN+zcvpOQ6f/GRo yM503FOPSaWZGkRQqE/eFyUNwOE8MiTTq9z0f9s19PSt7jgWfH48qJ1Mc77AbT3QjDvn8wvVtG21 e6eUuO/dV5ORdIyXuJ+M17a93zrGpxv3eZx7AEEng4GC24qy4HHwbIFHQg4ZyxnCM96E8EjNjozl Km6rXdNynaaNdjK2aYgMeKe8eeY7bz1gsw45z3rQ8pTrMBjL85bLyzLNsCnfzFsO6DoY5jzjOS/H c33LTgQdP4a5fJOW53McHedzCM5B3HmQwIDBu/B5K1doze8irGt7EmlJpju2GTTj150x7mlDt+NU cDsm121Hcxk5D7xJNz+PU2aKmqldeU2Z3Aa8Zh7aRHba1a9Ja+ax2y05fgxz2SYtz+c4Os7nEJxj NuKeMntKMzmIcIH5SU7W4bYBnI5ubqcXfHuW1Ut92slw8ypp8h7whZZrOkZz2nRx2wROJ56mozvZ c9ieZU22bpYvcW9PTA7OdNzTiSJeeDi7Q8XDy4M8l0d70ZHj2YIsh/WEtqR2D/peaRjKZZux7HwT omdajrejmZ/z8jLhN/PIWr4JkXcyj3yOm88ggpTzjDdhJTn+C98y49RxLOflOBJ5PsfHtWcey++d uXXHVE4znvPAiUnHJTHJwaCBw0uXwD3IIE6J39yOstukuRj3blegcU48z+e4ndKOZl5+HXSTg+eU 46Z5Nz7zDOEbN7RODuG145tmiE6ON23k+dnCiT2SYZXrHpN5vILPVty7LhPC2RhE5IU2nZPzJsKn ozuR7Z2Rzw2vpJ3DA9OJ3eno7hzemVwtS9xPzl+zIU1M8sAF8tBy8kPYdNqKZ4oHEH5bazn08s4G eXg5H1qemvLm5TrGDS0DNM2wycvpOW45aL3Q29XTeoa2adikkzct39LbNEPr59A8Q/OaedMNc36O mw/sRM9lpoI373XNPDabtHZ5aBzEpgcH+UCCGQkPKoCWQb5pT6Q6wePcbdsM+8P0nSnuqbvrz/nk OPlOcdyU6yQL3bKG0PLUpJM3bbJxj13rGuY08Dz1ImP5XNa0mYDNmGvmKaNJa5eHxjHTcU/5PafZ HkT0XJEiWDxQPFA8UDywQ3uAB1Y+qPNDNn+Q5QMId0gMLc9J5njzpOF141vedp03nEi/aXsy+W6y OS/HXS/DTvU2H+g/F+1mx/JNGecNLZfDqfJyG7OBE0t5auZzXj6gBffBIMEHgwbPPhiHZ1lgtzLE Dv5cj/s8HnKc88/znXDkSDm/ooz/bq+471SPTnXrRB+v+exjzRhs5vMaELNOeRw75oGOdWLf+GTj 3mV0hWUQ0dU9hVk8UDxQPFA8IA/4ocYD1w8xHkrQyTPrwAGNzgIHsu44dHtQm2cotTr1SkOhnWxt KCGWMWzync/5OW4+sElv5i3biW5+O1vt1oa3k+tmw7xu5XfjWd9wMrLWyaFjKKf1gud6OW5daD7c qSIOOehEGQcyGPDRzpbYLckynPvOHvcTtV+T38zjmCatmc+d141nuabMVOK+Xb060brRXacmbNax yZ8o7xiaSK7Jz/Vy3HLQfMx03LuMCWEZREzooiJQPFA8UDxQPCAP8MDiYcXAwB0qoYGTp5OWL2Hy QAIZUruHcTtaJV39TsTPZY1bx9D0drAp08y304HWq5z1c/kcN78J3ZnqJtuNl9vrJteNl9vY3ni7 TlNeh5xv3B0px6ljMh88QGMQAUTOukI7Jtub73E/lVjJdXK8k7NL3HfyTEXP49X4bMV995okbhlE 9OSmIlQ8UDxQPFA8IA/kHSp3xty5MsRR4CR3HAwram+/6ExFbyLrk7XZq3yvcq6f5Q1NB051S+/c Rju7Ob8XfCZsdCvHHaFuMu147fQcm4buXBGnTRp5jl6T9YnrEvetXptsjFjeMLdW4j73xrZ4u5h1 bBrOZNxvW4MGpQwiGg4p2eKB4oHigeKBrh7wwwohd6roEPDw8uABXt5JyPEmj/x0U9P+dO1NRZ86 zFQ9ZqIz5XNo1qmZt9yOCtt1nKhrk06+0+GOFXrgU0nYtm6J+3EPlrgf98VMYs34tu0mvVPMO14d s4a2MyOwDCJmxI3FSPFA8UDxwLzygB9kfjC5I+G8nWG689OFO1sHeKrny3ak7c61HW2qZcwVPXei 8vNxHOY803K5yeIl7ifrscnJl7jv3V95bFvLMZ7zTLPMjMIyiJhRdxZjxQPFA8UD88oD7lQBp9PB nY7uVBy+vcubbB1ZMlPS5D2Qd57QdnxO3lJ3Ddstcd/dT5PllrifrMcq+e0V91OrXdG6xj3gG9Y1 XpFSgeKB7eiBEvfb0dmlqB3GAyXud5imKBXZjh4ocb8dnT1TReXrV2fKZrFTPFA8UDxQPFA8UDxQ PFA8UDxQPDCHPVAGEXO4ccupFQ8UDxQPFA8UDxQPFA8UDxQPzIYHyiBiNrxabBYPFA8UDxQPFA8U DxQPFA8UD8xhD5RBxBxu3HJqxQPFA8UDxQPFA8UDxQPFA8UDs+GBMoiYDa8Wm8UDxQPFA8UDxQPF A8UDxQPFA3PYA2UQMYcbt5xa8UDxQPFA8UDxQPFA8UDxQPHAbHigDCJmw6vFZvFA8UDxQPFA8UDx QPFA8UDxwBz2QBlEzOHGLadWPFA8UDxQPFA8UDxQPFA8UDwwGx4og4jZ8GqxWTxQPFA8UDxQPFA8 UDxQPFA8MIc9UAYRc7hxy6kVDxQPFA8UDxQPFA8UDxQPFA/MhgfKIGI2vFpsFg8UDxQPFA8UDxQP FA8UDxQPzGEPlEHEHG7ccmrFA8UDxQPFA8UDxQPFA8UDxQOz4YEyiJgNrxabxQPFA8UDxQPFA8UD xQPFA8UDc9gDZRAxhxu3nFrxQPFA8UDxQPFA8UDxQPFA8cBseKAMImbDq8Vm8UDxQPFA8UDxQPFA 8UDxQPHAHPZAGUTM4cYtp1Y8UDxQPFA8UDxQPFA8UDxQPDAbHiiDiNnwarFZPFA8UDxQPFA8UDxQ PFA8UDwwhz1QBhFzuHHLqRUPFA8UDxQPFA8UDxQPFA8UD8yGB8ogYja8WmwWDxQPFA8UDxQPFA8U DxQPFA/MYQ+UQcQcbtxyasUDxQPFA8UDxQPFA8UDxQPFA7PhgTKImA2vFpvFA8UDxQPFA8UDxQPF A8UDxQNz2ANlEDGHG7ecWvFA8UDxQPFA8UDxQPFA8UDxwGx4YGg2jBabO44HxsbGdldt9taxVEf/ jlOzUpPige4euN3tbtf361//+tDuUjsMd0w12aDjov7+/st3mFqVihQPFA8UDxQPFA/MkgfKIGKW HHtNm9XgYRfV4Sgd+1zTdSnlFw9MxQO3ve1tUYufqehfUzq69i5U2T/UYOLqa6oOpdzigeKB4oHi geKB2fZAWc402x6+BuyrE3OAij1GRxlAXAP+315FrlmzZvArX/nKXj/5yU923bp1a5ll2l6On7gc rrtj0nU4sXSRKB4oHigeKB4oHtgJPVAGETtho3WrcjYDUc8yXeta13rxs571rEPQu8ENbvDMlStX vubiiy9eYDtXXXXVkN6avvfPf/7zsnvd6173k8yzzDM86KCDjrv1rW99LHnbe8hDHnK3wcHBEzmk /24O5+973/ve++Uvf/ktsNs8hoaG3mm7E8EPfvCD++6+++4vn0iuVz6d7Yc97GFH3fCGN3zabW5z m8e+/e1vZ8AV6fe///2Kww8//Jh99933GXe5y10e+Jvf/GaleYaHHXbYMZ/73Oeu4/xU7VHugQce +Pgb3ehGT37kIx955OjoqE32vfSlL73FLW95yxN0HPfGN77xJjUjIZ///Of3uelNb/rfd7rTnR4j /9z22c9+9tF77rnny+6jRFs25ed6ftWqVa866aST6jbZQc6XdjgqXY87SJVKNYoHigeKB4oHigdm zgNlEDFzvtxRLLGEqWtHcvPmzYuPPfbYe7Wr8OMe97jf/vOf/7zh6aefvtx83nj/5S9/OfABD3jA b0wDfvGLXzxlZGTkmRx3vOMdf6LlJ79y/hvf+Ma3kdljjz3+o47U0/JjeHj42fB6Scccc8wFX//6 19/Ti2wvMs94xjMO/elPf3rwU5/61O/e4x73OP2Vr3zlse6APvzhD3/0wMDA2Ktf/eqTFy1aNHy/ +93vSRs3boxr5BWveMXNNYB4hNbo31EDsCUuayr2zj777CUveclLnnDEEUf86TnPec53fvGLX9xS vr0nNt/1rnftf+KJJz5Cg5kzTzjhhJ+94Q1veNT73//+fV3eW97ylhu99rWvvc8XvvCFz37ve987 SXp//v73v/954Sfe5CY3uVjjiAdbtsBr3AMxkLjGa1EqUDxQPFA8UDxQPDALHiiDiFlw6jVlUh11 PqKecAnT0Ucffcqpp556p29961vXatb1oQ996H/U8b/o3e9+90HmqVN7Y3WuR5773Of+1bTZgBow 3EWzHC/dZZddXq3ZgrtShjrI13ryk5/8APD73//+99bg504HHHDAk5cvX/76O9/5zg92J1/13e/g gw9+DHJO3/zmN/eUTnTOTZO9QzRY+KHO5ew3velNp+uN/l80s3CQBknL/vGPf+ynzvnJj33sYy/Q AOmbequ/BzbQ/eMf/7iPBhabFyxYsMm2gFOxp4HArTUTcvYHPvCBXz/pSU86TwO3UzSQiJmij3/8 40doIHDKhz70oV9p9ugczUb88ZOf/ORhlMW5apDxX1/72tdO0mzO2K1udatn//znP7+e/HYfzSA9 421ve9tp//73v/e+4oorYhCpdttPvnrKkiVL3nSLW9zihHPPPTcGP53ozFI9/elPv61mNV606667 vuKFL3zhrSi3mf7zn/8sPPTQQx+5YsWK165evfoZH/3oR2+AjGLnrmqDR1teM1ePfcpTnnI78hr4 3CzNgr2WGS1mvaCr7kehR/2YUWB2S+d9sMp/uWZc+j7xiU9cH7lubQ/fiVkaZtKoG3U5//zzF5uX Qw0UD2SGCznN6Dzksssui5k5Zn6IwYULF76VmSJmp9DrVk/568WuZ15GwvdJ12UbViEVDxQPFA8U DxQP7LweKIOInbft2tV873bEJu0617nOlep0nqK36A9t8sirU/XbH//4x3UHUjMBB6nj9wd13MfX 3LRTbEPbtGnTYr1tPzg/1Cm+XlNUHeO9fvCDHxyust6rDuenvv3tbx9JB/7yyy9f/K9//SvkL7jg gj3VSby/ZhG+LxvvUUf0pnpTfyC21KkeVQd/OLerTvOKP/zhDzfLaZopGVQHccQ01W+RZl723rJl C98U9KvDHee4fv36QckOaUlT+FTfHnxPPvmy+OzAU6ep2NMSqAHVta7D2rVrF1555ZV7Mki49NJL 9zjkkEP+5QKud73rXaaZjxjIyCd77rXXXhfvt99+GzUAOlgzP3/69Kc//ZNrX/vaV6kz/w8N9PqW LVu2/pxzzokO+utf//qHPeEJTzhFs0Jv1XKpfg2cjsBuJ7r8vK98ftinPvWpjz7+8Y//ugYsj2QW ynUx1CDnEarzMpX93gc96EE/f9rTnvbUv/3tb0tf9apX/UptcnPNshxEe//973+/oWZ6fsdSLQ3y Hnj88cf/QLNAb8bO8573vLsANSBZpba/593vfvfT1a5f/tKXvvRfOo5461vf+imdV5/a92jkurU9 fBIDBpXxDM3i/FE234mPFeePrbjjvxpA7/q6173uBJV3Mueget5Ag7kjf/azn63SOZwgP31Jg4dX adnfOg1mY1DUrZ4aqJ3reo6X0oL1dF22aJRM8UDxQPFA8UDxwA549L0DAAAgAElEQVTuga7LXnbw upfqbesBtnHtKakT/kN1PA+nw/eCF7zgz7mSOlenaanP0Sy7uf71r7/pT3/60y31hvZjuUyvuDrp S08++eQ75PLqFJ9+3HHHXZDTzjrrrF3UcV+hjv9yDW7OVUf67RrsbFLnMTrEltW2n7/mDT35H/3o R9/TTMCBGnT8SW+8z+OwXCeo2YvfaSByF81AXKFO50p1fm8mP5yrbz7Wqbzz1Wm8rzrAP3/nO995 uJZdDakTvaiTLehTsffMZz7zdHV07/f85z//1npbfrHqwzcRA3zPoMHEbnoTvsllyv9XavASdVDH 9lp77733FfDUEb613qZ/GfyMM864gepxJp11Bm2aJbh63bp1Axs2bFihTv1e8ss5mnU6SbMUizvR sUNSB/qb6nhfxqGO+KGaLdlfMxJ/q7h9fcSElrodrAHfq/TdyBVaTnUx7fve9773wPe85z2/USf+ 5Pe9730P1uBqQN92fEaDnq1q7wX6PubztCuDEvn50r/+9a+rbVO+/8M73vGO08hrlmTtAx/4wJ9q EHP+d77znb5TTjklBlDwOrU9PJIGBrfRDMZl8ucPyX/sYx/7mmZy3sDMiQYkW6CRNDg6dP/99//b a17zmjPIy+f/q5mo3TSTc6j8fd6LXvSiv0LXMrJv6ruZN3o2o1M9FScD0tlmsIKNlHq+Lq1QYPFA 8UDxQPFA8cCO7oEyE7Gjt9Dk6tfzDj1aOjKsD3K/SIdPb7/rj6wp7q53vevl6qz+U52tW6gTuZ/e 8g+rAxgd98lVp69P5Vxx3nnnvTs/9A3Cj5t29Gb6LH1z8Gt1Qp/Nsha9aT98n3322dyU01KVS0y7 8Y1vfLkGHfs5b6iO4/EsSVHH9THqQF4PnIPvCTQY+j8tP7lUy3ae9JGPfORe6sz/QuVcjK54X9Sg 4oZaXvNsdSxXahbgPHUc6/JsP4dTsadZnbWPetSjvqZlQPfXG/D/Vuf4T5rluZqOrmZJtqqzXw+c 1OlfpLpfSpl6432Vlt2wdW/f0qVLN1x44YXLtQxqFT7Q0ptLNStwj5vf/OZnw2fWSIOhz2ogcNRu u+321gc/+MEP0UzHYCc6OiR921Kfr/x0hWYOblhxql8tn9pDy3P6NRvxfM3KvJFDMxirNVCIZT8s 0RK/T535K1784hdHZ1z136p6Xp/lQ/L1a3/729/ePLepcq5yXrMpw5phuYi8Psjv08CoftExUdtr Odoel1xyyT6ulwaiL6OuGvjU/sSu/Lab2jbKIK+Y+6di4w+i766YOh8aiXZS7G9WTMT3QZ3qySxY Xs9Ku+W35+uyRatkigeKB4oHigeKB3ZgD5RBxA7cOFOoGn941XPSUpM/603xhU984hNbvhvAwJFH HvlbvW2+ld4yH6RO3e9YKjObSYOMxfo24ZvqBL5Ib8O/oM7roarfLZtlaraiXuN+2mmn7aNO8Zqm jN7wf/9lL3vZ57WO/ocakFwKzqEPpf995plnrvjqV7/6BXXOX6LO+tu0jGmhvk+4mKVEixcvHtHM xztUxkt++ctfnqTB1Z4aUNWdzWY55KdiT53SpVpmdIYGKq/W7MOrNIi4QB3tGMjoe5ArtLxmN5el pVa7aaYk6qC3/heqw74Pb8Y1O/AdfT9xF53r3eWnkzRgeriWfq387Gc/+310eeP/iEc84jzK0PKk t+s8F2hQcb9OdJenQVftX5W9jzrOLf7V4HKjYmFUdXylfPZiDvngpZqF+Ck21Ha3ofOvQcU+GqDG AES8/bRM7e5q3w/gdw1oTkXGSfZ6ituJ2l7fN2zSQOuvrhfwV7/61cs1MLrSZQFpb3xlGt8G8U2N ZicuUvytMl26u2hJ1Ja73e1ul0HrtZ7Wz2BP55fJF7R4oHigeKB4oHhgh/fA7PYMd/jTn3MVbFmv 38vZqfP0Ra0Fv1NTVh3O3+kN943VUb+1PjT+bZPfa15vaPvpNDcP0VtMaE35bfTB98O1pn9EHeIz 9ab4fL1132YZiDr3B6lzOKABwEL9P8KttCzpXAzxXwlsjQr+mMc85l9aMnSuBj//1lvpTeAckl2v JSxHqhP7IOQ0SNpdy30O1C5If9bb5DHpPe3Nb37zjeFphuD2mhn4lzqlG8l3SlOxp3L3Usf0BXzM y6EZkbscddRRsZyH9fzf/e53D2PrWDq3evN/6B3ucIe/U77W6I88+tGPPuXe9773o0W7TN8+vF/8 /9WM0tkaXLxVsxAX6BuO6ARrMLRYg5MXMTjTR8EXasvd36kTvrQT3eenLWNvA65O/556M38DLWuL JWIaHNyaHbu0hOlyDdyuUhvFh+B8R6A39i/T7lB7sdRJ+g9Rfb6gAc+3NbiJbyr0Ufre8uW/Zesy 2k5L0A5mtmKyqVPb284973nPsxSzBxAL0NjWWLRnMgBmQMDSPehq5zO0fO7GfBuhncr6FRsPkf9W KM7/pGVWN4GOnM7lFtqC96/oTzNN+rqcZnlFvXigeKB4oHigeGDWPVAvFZj1kkoB28MDXd+at6sA a9/VgT1VHdeW2Qit1V+rjvw/9CZ7VfP7hXZ2OtG0U9De2nr0LU2+lp48T8tT6rX/6uD9Tp3Re2hn qFerk3q1OvUjWvN/mmYNWvb/Z4ckvQ1/hdbcL9Tb+/9oV5x48y651R/+8IcfpI+G/9QsK8+rw/hz fSPwWP4L4qKLLrq2BhAn6011LKfR9xDf0br4h2hd/hZ1dpdoFmbCrWWnYo9vN7Te/u9advUsvZlf obr8XXX/BfXUEqdT5fsbaznQa9XBXaqP3H+af5OgD45/ryVB6zQIeaLO/zKt4b9Eb/1XadZkdw0a zrz97W8fb921vGm9BhVnqBP8hute97r/UDnLZOdLnej2kQZV+8vuIZqx2FWDle8xAIGnpW3HKh7e q+Vd52i7289owPY4fWx+FHJa2vQ9Bm76FuNRKut8fZx8hvx3pup2qP4D4x76vuTUL3/5y0ep3V6g wdEifb/xK33vcJQHfS57Itip7a2nGbV/qM1+rIHOK/k2glkmfSfxP/D1wfj1VY9jNFg9XYPVS7Qb 1Bny4Ss0aL1a/rxQ39WcLvtjitW/afbplarrBfLZSg0kPmz704CTvi6nUVZRLR4oHigeKB4oHtgu HhhfU7BdiiuFTNEDvLbtqa30hveBkp1wm9cp1mNW1Vhqo8HMnlpWso716M3CRDtWndhz+Q5Bb9SX 8AFxU6bXvN6G766Ziqv5NiTX4U25PmTejcFVTp8In4o9Zmf08fNgu3Plbbre3rM8p+NMCPr61mAP DRwu01r+tm+79fH5bldfffUCPoDOz6EdXX8U+C7NGrxUMxZDGjBs5BuNXCfH+QhcA4E91Rm/moFJ zuuEa7ZiDw2KrtDs0ChLsrT8aFjfa7T4P9fVrk/6Xvu9T4M2mbbXQGiZzmOVBgsXMXuT28xx/Kdv UEY1iKsHs/D5k0HNdC3RIOoSBha5zhTwC7V06+Qp6BWV+euBnu/389dF5cznoAdK3O+EjdpTx3Qn PK+5VuWeLy4NInbRyR+jY87NMrkjqZ2lfjbXGnhHOB8PInodFEy3zlr+tJtmK65WR71tR7/dIGIn a3sGSJ/XIGLKg93p+rjo75Qe6Pl+v1OeXal08UB7D5S4b++XHZo65zqaO7S3t0Pl6LBoIMEWl0fp mFPtq/Xtf9Ab91iusx1cOe+K0Jv772g5WcfZh5l2iD64fgW7GunD8Z/r37t/ppmllm1/8/J2wrZn APHDMoDIW7HgxQPFA8UDxQNzyQNlJmLnaM1Jj9DTjAQDiZ1yadPO0SylltPxgD58fqv+Y2GJOtoj +nh5WEuL1unj95/oG4tf6ZuE9flMxHTKuQZ0+Y6kDCCuAcfPkSInfb+fI+ddTmN+e6DE/U7Y/mUQ sXM0GhfXlJL25u9Th4z/FYh996dkpCgVD2wnD2gwsUGzE0v/P3tnAm9T1f5x8zx1cemWWZR5SqKM IZXeEhEiovQm8ja8KWN6NYgGmmdSKlEoY1IaEDJFkXnmmuf5/312rfs/Tveee+69OOfc+zufz7b3 2XtN+7vWPZ5nPc+z1ty5c4kTv4rT3KsuUNUprcb+Ri0uZRtK0a6UFqb8aZqAhKk03f1p9uU17tNs 1+vFzzeBZCsR57thKl8EUkDAVsWysX2CwwLpbSnbhzjyc9hH4/4vDvo3bRHQuE9b/a23/YuAxr1G ggicJwL64zpPYFVsSAnYjuQ2e/8Gh7c/hV9rNO79gOhrmiCgcZ8mulkv6UdA494PiL6KwLkioD+u c0VS5YQTgeI0JkuABmncB4CjR6mWgMZ9qu1avVgAAhr3AeDokQikhID+uFJCT3kjlYDGfaT2nNqd EgIa9ymhp7yRSkDjPgJ7LkMEtllNFgEREAEREAEREAEREAERCCEBKREhhK+qRUAEREAEREAEREAE RCASCUiJiMReU5tFQAREQAREQAREQAREIIQEpESEEL6qFgEREAEREAEREAEREIFIJCAlIhJ7TW0W AREQAREQAREQAREQgRASkBIRQviqWgREQAREQAREQAREQAQikYCUiEjsNbVZBERABERABERABERA BEJIQEpECOGrahEQAREQAREQAREQARGIRAJSIiKx19RmERABERABERABERABEQghASkRIYSvqkVA BERABERABERABEQgEglIiYjEXlObRUAEREAEREAEREAERCCEBKREhBC+qhYBERABERABERABERCB SCQgJSISe01tFgEREAEREAEREAEREIEQEpASEUL4qloEREAEREAEREAEREAEIpGAlIhI7DW1WQRE QAREQAREQAREQARCSEBKRAjhq2oREAEREAEREAEREAERiEQCUiIisdfUZhEQAREQAREQAREQAREI IQEpESGEr6pFQAREQAREQAREQAREIBIJSImIxF5Tm0VABERABERABERABEQghASkRIQQvqoWAREQ AREQAREQAREQgUgkICUiEntNbRYBERABERABERABERCBEBKQEhFC+KpaBERABERABERABERABCKR gJSISOw1tVkEREAEREAEREAEREAEQkhASkQI4atqERABERABERABERABEYhEAlIiIrHX1GYREAER EAEREAEREAERCCEBKREhhK+qRUAEREAEREAEREAERCASCUiJiMReU5tFQAREQAREQAREQAREIIQE pESEEL6qFgEREAEREAEREAEREIFIJCAlIhJ7TW0WAREQAREQAREQAREQgRASkBIRQviqWgREQARE QAREQAREQAQikYCUiEjsNbVZBERABERABERABERABEJIQEpECOGrahEQAREQAREQAREQARGIRAJS IiKx19RmERABERABERABERABEQghASkRIYSvqkVABERABERABERABEQgEglIiYjEXlObRUAEREAE REAEREAERCCEBKREhBC+qhYBERABERABERABERCBSCQgJSISe01tFgEREAEREAEREAEREIEQEpAS EUL4qloEREAEREAEREAEREAEIpGAlIhI7DW1WQREQAREQAREQAREQARCSEBKRAjhq2oREAEREAER EAEREAERiEQCUiIisdfUZhEQAREQAREQAREQAREIIQEpESGEr6pFQAREQAREQAREQAREIBIJSImI xF5Tm0VABERABERABERABEQghAQyhbBuVS0CIiAC54XAmTNn8lNwYY4cHOnPSyUqVATOA4Grrroq 3dy5c2ueh6JVZMIEzvDoMMe29OnT70o4mZ6IgAj4EpAS4UtD1yIgAhFNAOUhLy/QkCMmol9EjU+z BK688kp7d++fNAshhC/Ob8gWqp+JMrEvhM1Q1SIQEQTkzhQR3aRGioAIJEaA//wvI00bDikQicGK 4Of79+/P+MUXXxT6/vvvLzpx4oSsTBHcl2HadPv9aPP370mYNlHNEoHwICAlIjz6Qa0QARFIAQEf C0ScdbVgwYK9H3zwwRpWbLFixXrmyZPnye3bt2d21ezduzcTs40jfvvtt5zXX399c9I86J65c+XK le+qWrVqR/vuymvZsuV1GTNmfMkO8r9sh/t+0003Nevbt29FK9f/yJQp0wuu3MTOr7/+eon8+fP3 TSxdsM9N2L799tsblixZsnu1atU6DB061BQu7/Prr7/mvvrqq9uUKFGiR4MGDW795Zdf8rhn7lyr Vq02H3/88SXue3LLs3rLly/fpUyZMve1bdu2/unTp12R6Z544omKlSpV6sxx19NPP3153IO/L8aM GRNzxRVX3HPttdfeCZ8re/XqdWN0dHSfG/hYX/qnt763OnzvB6r/3nvvrVW2bNl7rQ20pdLBgwfj /f8xsXa6+oIpzzi2aNGicenSpe+H8R0DBgyo4PLrHFICNp4a/v27EtKGqHIRCGcC8f5IhnOD1TYR EAERiIdAQ+79Q5D0TXfs2LFsHTt2vN73nru+++6752/YsKHk4sWLc7l7NuO9YsWK8rfccssv7p6d x44dO+PUqVM97bjmmmu+x/1kjvs+adKkyZamQIECWxFAuvseJ0+e7GXPgvm0adNm48SJE4cHkzaY ND169Kg5e/bs6vfff//UJk2aLO7fv3/H0aNHe0pB69at22fIkOHMwIEDx2fNmvVk8+bNux05csT7 v6Ffv34VTLjFR/8aFLDsrq7klLdq1arsjz/+eNe6desu/c9//jPlp59+qgTbplbmiy++WPqll166 A2VmeefOnX8YPHhwu1dffbWEq++5554rM2jQoBs+/fTTj6ZNmzaafL9Nnz59DNcvXX755dvRI25z aceNG1fYykXRaLl+/fqC7n6g+h966KFqKEk3NGzYcFGXLl2+e+utt27kHa92ed05sXa6dMGWB/vr 5syZU+XOO+/89uabb170zDPPdEAhcsXoHFoCniIR2iaodhEIbwIB/9MN76ardSIgAiKQLh2CugVR J+rCdOONN874+uuvr+OYg9C505ddq1attiL4b3v55Zcrv/POOz/aM4TasgjXpxAIf/dNe66vURga fPPNN7WPHz+epWnTpt8jKH+DgFzwqaeeaopS8z7CZbOLLrroIEJ3ha1bt15avXr1hVOmTBmfPXv2 07S31AcffFB7wYIFo1y7vvrqq+g33nij6oQJE6a6e5RXA4F1Ju+yyu5RXwWE5spYJfauW7eu1Lff fvvOJZdccpxZ8c1wuNbKwOKybcmSJTEoFscyZ8581JVl5+SUN3XqVAwhJVe99tprc62MnTt3zoDx rVxOfffdd+vSJzNo9xx79tlnny15//33a/373/9eawoNwvu/UIJGwChDlSpVel133XVzUBYq8t6V KOcprCjX7N69O1NUVNTJpUuXRu3ZsycnzHZbWe6DIlI1ofop+3KsSN+6tmGN+Qkm1cjrjQVXRqB2 ujR2Dra8P//885IHHnhgYu/evb0x9vbbb2/ctGlTWd+ydB1SAjH2+4JVUcHWIe0GVR6uBGSJCNee UbtEQASCJVA4mIQIyXtwW5rBDHOr+NLjJjP/u+++q+KeYQmojCvToly5cv2/z417mMj56NGj2Zht r+57IBQX8c+GoF8Igf5q6hrBTPvIyZMn1zcBfteuXdkQJr30GzdujMaV52asCNMpYzjuV1cwU1/e ysJF6jQC/knfclevXp170aJF5XzvYSnJmCVLllPuHu3LiuWlMEK5xRSkN4XEnh06dCgjaTMhRHtM iT2YBpNxPLeVa+I+ySkP150MtDWuDQcOHMiCsB9tSgKKQIEaNWpschUUKVIkFstHtH2HSXShQoW2 lypV6ggz9dWx/CwdNWrU9xdffPHe4sWLr0PRS5czZ85DCOQ5LT1WluXWZlyfVtp39wlU/4gRI77C 1SlOYYBfKdyuVru87hyonS6NnYMtDyXtfVMgUMryd+vWrRZ9Xrxo0aK+Rek69ASC+n0JfTPVAhG4 8ASkRFx45qpRBETg3BKwZVyD+iCEz4yNjS2IW01l/wwI6QvWrl1bxtxecH1Kz4x2JWbv5/unC+Y7 QnqO8ePH1/E9EBRL+udduXJlXgT33Aj+uVBuVjNbP7RChQr7/dOx7OdcfPz/NOsAbZpGWZ4SYTP1 uMN87J/e/3u9evUWoog0eO+994qa3/0ff/xRzhQJYj4OolytJ17iJiw0Bdu3b98Mt6tMuHJl9S/D 93tyyuvZs+di3rfsI488UtXiGzgsJiKDxTOgTEQRc3LU1YEgvQcFx2sDMRsFCxcu7FkVZs2aVRVr yTJLt2zZsmK0Y4XFVZjSVrNmzYCr6QSq3/KilBy3mBmLD8ENqvhjjz32k2uPOwdqp0tj52DLc3lQ JJrhQtXG3OCIr3G3dQ4PAkH/voRHc9UKEbhwBOTOdOFYqyYREIHzQyDoFXry5ct3koDcscOGDWvd qVOns2aqGzVqtAthdQOuMxUvu+yy3czyn0Sw/zM5Taae3SgkLyeW9+GHH16J8D6XtvRCiTlIvMDc zz//fIp/PoK+d7h7BP/uwuWpsfvuzgQEd8LdKQbhO/Phw4fzIJQ/Yc8Q2j8jUHkesQ7FcZ3pljdv 3t0Iyj/houFl5dlY0rTBpasms/fLsQKsRbmIq8+V73tOTnlYdQ60a9duAi47NyMwp2/cuPFshPIC JrxjJTmxefNmz5Jg9RDUnJX277Rr+mIv7luV7DpHjhyHt2zZkgvXrnwoXqVQor5DqWiC4uW5aVma hD6B6rc8xLoUJjbmPt5/A5aYZ+B8lvXF0gRqpz33/QRTnks/f/78D1FgPiH+pBt1u9s6hweBoH9f wqO5aoUIXDgCskRcONaqSQREIAwI4O7yG+4xW1g9p6l/c+rXrz8f96IqWBAq4zaz0FxlzucHRSMb sQlf7dix4zHiFT7Fl74m7fMEZt96sVZkc9+JA4jBxeof1goUgel9+vQZQwzFTJSYnXZtB8rD5uXL l+f+8ssvP0U4fxxh/XkUjSzEB2w3V6Js2bKdwmVqGHU8/vPPP4/GZScahWqbqy++c3LKw/qRo2vX rstQHAZifRiAdWUjisJ2K98UmzVr1kS5unC1isJVyWsDQdJbcPOJwTqQ7b///e8U4hIa8K6N4TSa lbBa4/qV56OPPpru8iZ0DlQ/SkoBAqq7MSbGY+F4Jz4FwsoN1E7feoMtz1apMoXI8jImT6BELsIK 5FuUrkVABEQgbAmc3/8hw/a11TAREIG0TICA5LE//PDDtf4MiGFYyAx3WQT1qh06dEiWK5OViYtN ehNa/Q/fJU0tHbEN1Qj4bo1P/ykEYrMCrMfd6h/uEwj3lU3gRwHIwv4IVbAYeP76tleCLTlqZbHC zyZcdlaj/GwmhuGoXdtB2kNPPvlk/dtuu62FpUNJyk9cRXlWQfoNa8sZ8nV/9tlny9oz/PJrYxnY xOz/Efue0Cc55VFvIQKiH+X9MtuBNaIBqyEtsDqwjCzBlauWLXlqblU//vhjzTp16qyxZyzNewo3 qxnNmjVrz71YYh9e5flnWJRWoVwMwQqxkdl7TxC39Al9AtWPsnU9LkgLUOR+M5cmOyxQ28qy5XbN DcyuA7XTN12w5aHAHUEZqmsuXVYn/VmV5V6tKn1EQAREIOwJyJ0p7LtIDRQBETjXBAiwjkWAnYXg epY1gpWPDiDIr2O2PN9dd921Mbn1IoAWZunR5/zzsxLSw7gmxfn+E5uxEDebJvjCD8S6sA+h/hRL rS7AanCJb15bIQlXq34ENGdh9n4rQq0380664m+++WaL//3vf0t90/tfo0z8iOtPB9sLYtu2bRej QIxneVpvLVHiIaY8//zzLVkp6TiKSnasMIkuLZuc8ix+g2Vb1+B29SAWkdy0ZQ1t9+IOcHGaBfuy rKg0iHiUHAS5z8bq8Id7jyFDhvwaExNzECXkXt4/lpiJHQjd+bCa5Meisbx27dp7XNqEzoHqxyJU AsWxEIzjxgOWgQ2weo4Vo+riRnUEl7MNgdrpmy7Y8swdi1iXey+99NJatPsMCsRKKREJ9aDui4AI hBsB+fqFW4/E354z3FZfxc9Gd1MvgaDGPUsw1gTBlZGKwfajQJmJRng8aH77/u/BvY7EKKy2OATc jrInFkDsn9/3u60ChKVin8WG+N43KwcrGkWZcuV7P7Hr5JRn1hliNjLG965mWcEScjSQJcTy4wJU AMUhNiG3o0DtDlR/oHy+z4Jpp2/6QNdm8Zg5c2YBXOl2oUye6N69O4s7jegeKI+eXVACvxA/NO+C 1pg2Kwvq9z5tognft5ZgGr5949sy/XH50tB1WiEQ1LiPdCUisc50SgQrS/2QWFo9j3wCUiLCrg+l RFyYLgnq9/7CNEW1BEtA7kzBklI6ERABEQgBATagW8SMe6LuOiFomqoUAREQARFIwwSkRKThzter i4AIhD8BNlhbHP6tVAtFQAREQATSGgGtzpTWelzvKwIiEBICFvsQkopVacgIWJ+z63chi6GwladC 1hBVLAIiIALngYCUiPMAVUWKgAiEngAbgw1htaMXMmfOPNQOllEdzLr83Uygu9CtY6fli9gZekB8 9bLM6xUEbg537bQzgc/9WYnoFgt4ji9PMPe++uqraJaN9ZZ/DSZ9ctPY0qb58+fvm9z8/vlM2GbF qIbsY9G9WrVqHYYOHXqZS8Pu1bltR2lbZapBgwa3srRrHvfMndmwrQ17b8StbpXc8qze8uXLd7G9 HNq2bWu7a7sq0tmyuqwy1ZnjLgLeL4978PeF7cjN0rr3sMrUnfC5kuVob4yOju5zAx9bztU/fWr/ zngeMHr06Lg+Se3vq/cTgbRCINn/QaUVQHpPERCByCXwyiuvvIQQ+ZAdbFbW/+jRo9nuueee28Pt jVjeda9rp50Jon7922+/rffoo49WT25bWTmpCMLsP/bCSG55CeVr06bNxokTJya6LGxC+f3vs0t4 TTbdq84O3lObNGmymH0UOjoBtHXr1u3ZAPAMy+COZ9nbk9f/n7YAACAASURBVGyk180pWv369auA AnHH3Llzr2H51+yu3OSUt2rVquwsv9uVzd+WsnfIFFaDqsSmd97yr+xoXprlcO9AmVnOUrk/oAS2 Y+naEq6+5557rsygQYNuYFfxj6ZNmzaafL/RF2O4follf7ejR9zm0uosAiIgApFMQEpEJPee2i4C IhA0AVs+s169egv37dsXN3t999131+F+HzvatWtXzxU2Z86cvCy5ej+bgT1Xrly5Lm5m22a+zZph Vg5mlh974YUXvFnyCRMmFKpSpUpHNm6rxz4QPa2cAQMGVGC50kc5HmE/hCqu7GDOCJ7b2TtgPfsU eG1NqF6UjSI2I+7KtE3RbDUnaw/XzVGcSjAb3sqe2+w4bXswd+7cg9iTob3tAO3ysaTqfZbHffc9 mxUFq8i/UG7SozA0YJ+GJ9i5eSDWgkaWDgG54H333XeLXbNbdrOOHTtea+WhGP0P3rc5IZ8N/kpR 752Wzn3MWkKeuL0Z7D7l1UBZmMnGb6ssHoQZ/RXwr7xixYqc7LNRCuF8PBsBbhw7duxXzOoXsDIs 35IlS2JsPw0sOXH7cCS3PBSBqlhCVr322mtz2YBvLeNkBopEDSuPHbProgjMYF+IOezx8Cf8l9AP ts9DOntXlIx/wXK0beTHmOjFxnhF4HYDy+f2YD+OBWwYWNhtZIcyUgpW/2ZzwGcqVqzYmY0OPeUn ofs2th544IErbeyxp0Y/9tKId1xt3bo1C0sBt7W+ZufvHuxvUcza16pVq0bW93ZtH8ZKB/aquMqu UXzKWfls7jfIxhAbEua0+7S9oeWz9plFoWXLltfx3tWpvy/t6O024gvU91aO+wQahy6NnVEUy5uF y96BMdzSNii0+2b5sTFof4NmKTLrlN0Ppp02llu0aNHYxpLl0UcERCBlBKREpIyfcouACIQxATY1 y2wClR0m7MyYMaMW+yQssyabSwqCaBNmmj9nJvndKVOmXMustScoIjR1ZnOz7aQfzHknadpZHnZ9 7oxQtgUBqx+b0U3p3bt3FzYpy40wm2X58uWV2AW7cpcuXabbXgTMUHdC+FmAoDee3ZI9Qc3KSOCT 3rXTZsFpWyWEzaIIPL9b+gD1ZiVfYVcm7ciK4lGIPQdi2Qn7OxSYzcOGDZtqCgObpfWwHZcRcM3F 6xRCbQeXj+8nMmbMaEssxn3MnccUKKwBj8MxhwnrvMfVWB1GIHCOnDx5cn27t2vXrmzsHF3EMrKP RTRC4s1YEaYjWA+H0xVwKG/PEKpPU89Z+1MgNOdetGhROXvuPmyolxEB8ZT7jvUo64YNGwofP37c YgrSI3B7fkWHDh3KSNpMKFje+xN7MI29Lsbx/LDLa+fklIfClMEYuXIOHDiQhQ0Io01JYIO7AjVq 1NjknrE5YSyWD0+RgUk0m9RtL1Wq1BEUoOqMtaWjRo36nn7Yy7hZhxUlHW51h9h12xNi2STw9q5d u86YNGnSENvlHMWprpWb0H04l4B5rZEjR77NOJuIwtI2vlgblJw7aHNO6h7BGPqRZWPvtzGJYjuH PqmAlaUyY7r6mjVrSmLpWWiuWih5tzJGvsEK9Ky14eGHH25gZ8ZXPsZM08aNGy+mX8d9/vnn/+Ko ywaAI1GAVtO/N1q6QH1vz+2T2Dj8K1W6dCbsP/XUU52pb7y9A+0shjJXn7+vfLxDZzh9jvIwAIXn IMqspxQF00764djKlSuLsu/KQJSsds7C5erVWQREIGkE0pxvZtLwKLUIiEAkE0AQ6skR9woIcPsQ jmfZDWa367J86vcIVCvsOwLgLFxOqiGkbTBhbfHixcOjoqJOIhR/jdvKMQS9gghKJRGyXmfG9iiz 1Ys++eST+sxIV2D3500nT57M9PXXX7/DzPkh3JCqEAOxnlnzb6xsFIOZCH7N7doCbRHwvFnVW2+9 dYvdQ0jPh7IyzK7dh3iAuXfcccdmykywXoT8nS697xnh6hSzxPsRxo8jyO5HUK3NzHEs7zLT0r3z zjsTmEEfjOCVBcHqOArQ23YfYTgzPGoiNNZj/40MzZo1mw2PD4lBOMosehkE99wI/rlQtlYjSA/l HY/CxBOILb992EF6rs3Q2zUuWdOwLJRH6VhqO0bbYfcDfcxaRDsbwHE3QmcehN9yCOCrEfwOGlOE xpsQgH/ECnS1MUeIznquy2NH7sUoXM0feeSRqszcb6c9FhORweIZUCaimAk/6upk9+w9KC9eGxBs C7Lr9W57hiBcldn0cXa9bNmyYrzXchPWzaXONgykzzOw6V5uhPpCcPmTfh6N4pgNobl5fPetHPsg QH9lmwLaQT/VxFpS2nd3b1NCGbvVUfgGEDey26xa7EJehw3syg8fPvwXFIXxuPndhnKVAWX1Q5Se E9bvxM+MsX41pQTOO3///ffiXoX8A/tFKKML7DtWkgOM29koMevhn+Gxxx6LU0YT6ntXDopBtUDj 0KVDOaqJJfCPJ5980lP4Yf4Z1oMoxmBNeK+lTk+5Rvn/ir+Tp51VLbF22uaE9MU7ZtljTNZBMenG RMAuLF/fUddip6C6dugsAiIQmIAsEYH56KkIiEAEE0BwGoZA1sMOdgXuRwDzaVxvmtgrMYNe8Msv v2yK4PC0HR999NHNCPe5cYuJwl1nlykQls7coBDWpixduhTvivzbTYGw+/ZBmMTLItZzpyDPblMg 7D4uLGXwf19j1/ZhZnidd8E/CPR3447zqB0I715eXH/2uHbSrgdRQt5euHDhVeauhEAYsF5Xrp2Z rY/3Nx03oAI7duyIce+KAtAHJSE9AudZCgBCWK9x48Zdh5D2Ge/1FALtd6ZAWNkoYyuJOZiLENrL 3FqYab8axeeYPfP9wGeH+47Qtgulo5T77s4oMJ3MJQXB9U4UmSJ2bYfFE9jO3ChAO3Hb6fbWW29d jzD/E/Vst7w8G4tSURJLUS8EyzxYAdbS5rj6XPm+5+SUhzvPAdzbJuAGdDNy5j0Ix0vpo32mcKGY nUDYj+OGMpCVtnvKHDPze+GW1+rPkSPH4S1btuTCDSqfMcD1ZidWgSYVKlRYZc8p7zTK0EeMrYaM tSFYm1pi6cAglDFdfPctj31QWOPeF067UWpL/vXkr38ZewWsbxlzj7j+RikujqLgjTVz0eJ5OoT5 3QjQnjBO+0/QzqIMtL6wHjR//vwKvmVSz173HWvKSRTTbfbdrEt84iYjE+v7YMch3KLoW68Oq4cx t8GUdu7nZ0ytt3v2sX6iDccYE7nse7DtNMUa7pPpq36Mpe9Qrlozzu60MvQRAREInkC8/+EEn10p RUAERCDkBM5yw/FtjQk5CFLeYbOyHD/gGhNjaYh3OHrvvfd+iuDW2w6E2cdRNF6rU6fOdpsJPnbs mLnPmJUgg/mhk3cr13ktNsDu2wfXoWhclv4xu85MbixCe76/UqVLh1BW0F3jDjMYIa6HHTYj7e67 dpry8uyzzy5CedlMkHBMYvWawOjKwO3jIhMQ/T/4lR9FwP3dvaudifvoi0B61iZ2CM4z4HIYF5U2 tiIRwm9cgPLatWuzYb35ivd6jNnwTxFea+IKU8m/LqwVcbEWuHrFICzv90/DDP/0Pn36jMGPfiYK yU67toNA6c2mWKHcfQrrxxHWn0cxykJ8wnbanIG2ncLyMYw6Hv/5559HwzK6UaNGccKmfz32PTnl IZTmQNlbhqIyEOvDAJSIjQjaniJjyiKco1xdjKcoLCVeG5j134LAHmMz41gHphA/0YB3bQyn0ShM rVEQ86CsTre8NuOPpWmt1YGVaijvmRnloTkWgnTx3Xf1MU7j+NpYRnA+iy+WkCMI+qdpY3/X3zB4 AkF5tpVB31VDmTarUwwWCU8B4Vkp3NQa07+vGXcUmlmWxn0smN1dBzon1vfBjkPrb2Pl6jJrnMXU YJ3Y5vt3ZbFLuJ0dJ2Yn1tIG205LO2/evLy8ZzPilW5DOdzMeP/Z7sfzCerd48mnWyKQ6glIiUj1 XawXFIFUT+AsH/hAb4sgeBDlwHM9wRXoD9yXqluQqx3EEbTHjaURK/LsQbDdhVtPVSuL5Tlr4a5S kVn4fX/f94JZzT8bQSeaoNs4i4Orm+DiZfhel6X8Aib8IhQneZUlBK4DCHRZA9XLLPxuAsWjcBuK MuUG16G4ehCuTptgam3CbWslCsFlbnlb3I1qcK8nQpfXZAuUtWBTXL0WIqQOQYkZiTtLUWbPzXf8 DoTcIigW1YizaI1L2CkE4uXMFK9nJjeHe2d3RrivbO+MApCF+qpgnVltz6xui0OxawLQN8F6NTPC m1Gejtq1HWbJwa2kPsJdC0uHS05+3H3K4072GwrhGfJ1p21l7RkWgtoIf5tQjo7Y94Q+ySmPegsh mD7K+2W2A4tIg4YNGy6wOiyuZOrUqbWMtwm3zPzXRPH0xoC5kbVv334GbmDtuRdL7MOrPP+MMbQK 5WIIVoiNuNJ4yiXKUDaUk8dMOSMoeMtNN920ECE8B31mLmH/uO/ejyVjq9k1Qn80M/PFiFnxlFiU g6pYrXKhdO5CcdtLH3nxPTZOmbHvw1gsZK5O5G9Jez5F4ZmMcuPFVGB9K2yCNGXFWt/ZOIpPGXVt SOicUN+79IHGoSkEFqthaeln7+/HYiNMmWdstIRfbqx3SxmXl9t9S8e7VGShg9/dOLZ7iX3MLY9x fTd/54/zt2NxI8Ppg+FY/1YmkDfo35cE8uu2CKRaAnFmyFT7hnoxERCB1E4g4Ey078szu3/IZmD/ FqamIih2w8f6SVwy0jODu4n4hjGWHgF1Iu46nYgdaG5xBfjfj7T7FkyNoN0Roboprk95WalmsgmO 9sz3g7C9g1nTVQiTfc0NBuHxN9/nwVyT7zBBx6VJ+31C9SIw7iaIdyVBr33NBQuB6k8EIs/VBneW 9cw0F0ZQb4fgOhq/+O9I39980m12H//0D1w78HPvhAD/vHPHMn93jpG4cOVC0KxNYG5XZm6fRqFp AsOB9k4I9afw+V+AgnTW+v+2QhIs+zGjngWlbSsB7d7MO+mKM+vbgqDhpa7e+M4IjD8SI9ABN6oe WHouRoEYj8XEc6chHmIKQmBL2nscYTc77zQ8vjJ87yWnPIvdwN9+DW5XD6LI5aYta2j7T1YuLk6z iJMoC8dBCLg5sETN9o1JIOD4V1yCDjK27uX9YxlfOxhz+bCa5Ec5WF67dm3P+oMge4hxsYw+G8xK XOuoJyflfI7LT7n47rt3QqkqTbk1sGRcxPiaZgqIPSOOoCOK3QgUyz9Z7vZDFLa7ib9paOkYC9NM cbNgYlv1i+DkZfBbTttqMgPfhPE9Cze2hvTboyhHWYnfmMNCAw2d0ufqTuycUN+7fFj+1iU0Dom9 KUo72qCsLra/H1aDWgbDfhbHBM8txDAspvwzuAn+gfWpP23dCLM8KBJvuvITO7OQQmGU0Fa26ABK 1SgshscTy8PzoH9fgihLSUQgVRH4f3tlqnqtVPcyZk5VX6W6btULJUIg6HHPrOmtlOW5KSVS5lmP LdDVrAV20wJVfR+auwmznrl8XY7sOTP1WbBMFEB4jE1MCDELAdaLE+a77Vt2cq4D1WvLXDIjfwjh /rRv2QhZGVB2Mpkvv91HAM3JrHM+hKht8Sk/vnl9r2022AQ4Y8IsfDQK0sH43ol7HRFiV1scAjPt 2f3Z+ZaZ2DWz4flRgMz648WmuPQ2Uw7/KP/+cs8TOienPHNrwrUtY3zvapYVuJqbWIKWEMtPrEEB FIdYC+qNr202RpgRz2wB0PYchY1QnhHd/e/bM+IlXqT/nsBikQmF4YjrV3vm/7EgcBSBaITxfaaw +D+P77v9LTCud5trnblkYQ076WKD4kvvey8pfR/sODR+KPGnXVyOq88Co7F0ZUeJ2mHj0t1P7OzG cWLpfJ5vwa1rvM93XZ4/AkH/3p+/JqjkpBKQYJpUYqFJrz+u0HBXraElEPS4R4nIS1PbcMi6GsI+ c4IkAeE/hLAZEV21UyLiewmnRASrFMRXxvm6lwr73pTXMSgRcXFL54udyvUIBP17L17hQ0D/4YZP X6glIiACySRg/9GjSMwke0MO/a4lk2NKs+HzvogZd89dJ6VlKf8/CWBBmoI7WTAuOP/MfJ7vpLK+ NwViphSI8zxoVHzEE5AlIjK6UBp6ZPSTWnluCSR53P9tkTBFIsmuTee26SpNBOInQDxOFLEI+3DD +UcsjeUIZImIv0TdPccELMZECsQ5hhpEcUn+vQ+iTCU5zwQ0Y3eeAat4ERCBC0fg75nD8SgT+am1 MIetHqTJkgvXBaopEQIEOP/A+MxMPMMXBMSPY1fmP3yz4O9vX71/fO/r+rwSMAHWYla28Ruy67zW pMJFQARE4AITsB84fUQgrRHQuE9rPZ423tdWmrKxfYLDAu7Xcti26qb42kfj/i8O+jdtEdC4j8D+ 1gxdZHSa/XGpryKjr9TKc0dA/6mcO5YqKbwJHKR5tuuy/c7r9z68+0qtOz8ENO7PD1eVKgKamdIY SJMEpESkyW5P9S/tb4mwjeoe4pAlItV3vV4wAAH93geAo0cikBIC+uNKCT3ljVQCGveR2nNqdyAC x3ho/vdvcHi7T/sl1rj3A6KvaYKAxn2a6Ga9ZCgI6I8rFNRVZ6gJaNyHugdU//kgUJxCswQoWOM+ ABw9SrUENO5TbdfqxUJNQH9coe4B1R8KAhr3oaCuOkNNQOM+1D2g+kNBQOM+FNRTWGeGFOZXdhEQ AREQAREQAREQAREQgTRGQEpEGutwva4IiIAIiIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERAB EUhjBKREpLEO1+uKgAiIgAiIgAiIgAiIQEoJSIlIKUHlFwEREAEREAEREAEREIE0RkBKRBrrcL2u CIiACIiACIiACIiACKSUgJSIlBJUfhEQAREQAREQAREQARFIYwSkRKSxDtfrioAIiIAIiIAIiIAI iEBKCUiJSClB5RcBERABERABERABERCBNEZASkQa63C9rgiIgAiIgAiIgAiIgAiklICUiJQSVH4R EAEREAEREAEREAERSGMEpESksQ7X64qACIiACIiACIiACIhASglIiUgpQeUXAREQAREQAREQAREQ gTRGQEpEGutwva4IiIAIiIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERABEUhjBKREpLEO1+uK gAiIgAiIgAiIgAiIQEoJSIlIKUHlFwEREAEREAEREAEREIE0RkBKRBrrcL2uCIiACIiACIiACIiA CKSUgJSIlBJUfhEQAREQAREQAREQARFIYwSkRKSxDtfrioAIiIAIiIAIiIAIiEBKCUiJSClB5RcB ERABERABERABERCBNEZASkQa63C9rgiIgAiIgAiIgAiIgAiklICUiJQSVH4REAEREAEREAEREAER SGMEpESksQ7X64qACIiACIiACIiACIhASglIiUgpQeUXAREQAREQAREQAREQgTRGQEpEGutwva4I iIAIiIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERABEUhjBDKlsffV64qACIiACIhAqiRw5syZ /LxYYY4cHOlT5UvqpVIlgauuuird3Llza6bKlwvflzpD0w5zbEufPv2u5DRTSkRyqCmPCIiACIiA CIQJAZSHvDSlIUdMmDRJzRCBJBG48sorLb33T5IyKvE5IcBvyBYKmokysS8pBcqdKSm0lFYEREAE REAEwogA//lfRnPacEiBCKN+OddN2b9/f8Yvvvii0Pfff3/RiRMnZGU614BVnv1+tPn79yRoGlIi gkalhCIgAiIgAiIQPgR8LBBxXgUFCxbs/eCDD9awVhYrVqxnnjx5nty+fXtm1+q9e/dmYrZxxG+/ /Zbz+uuvb06aB90zd65cufJdVatW7WjfXXktW7a8LmPGjC/ZQf6X7XDfb7rppmZ9+/ataOX6H5ky ZXrBlZvY+fXXXy+RP3/+vomlC/a5Cdu33357w5IlS3avVq1ah6FDh5rC5X1+/fXX3FdffXWbEiVK 9GjQoMGtv/zySx73zJ1r1arV5uOPP77EfU9ueVZv+fLlu5QpU+a+tm3b1j99+rQrMt0TTzxRsVKl Sp057nr66acvj3vw98WYMWNirrjiinuuvfbaO+FzZa9evW6Mjo7ucwMf60v/9Nb3Vofv/a+++iq6 bt26LS+77LL7WrVq1SghJWTUqFGX0u8djNedd95Zb+nSpblcOYm109JZuS1atGhcunTp+2F3x4AB Ayq4/NZWe0Yb/l2nTp1Wc+bMMetZgp/43iOh9sGmlY1X38PqT7BwPUiIgI2nhn//riSU5qz7UiLO wqEvIiACIiACIhAxBMyF6R+CpG/rjx07lq1jx47X+95z13fffff8DRs2lFy8eHGcsGgz3itWrCh/ yy23/OLS2Xns2LEzTp061dOOa6655nvcT+a475MmTZpsaQoUKLAVAaS773Hy5Mle9iyYT5s2bTZO nDhxeDBpg0nTo0ePmrNnz65+//33T23SpMni/v37dxw9erSnFLRu3bp9hgwZzgwcOHB81qxZTzZv 3rzbkSNHPJmoX79+FUwIxUf/GhSw7K6u5JS3atWq7I8//nhXhPil//nPf6b89NNPlWDb1Mp88cUX S7/00kt3oMws79y58w+DBw9u9+qrr5Zw9T333HNlBg0adMOnn3760bRp00aT77fp06eP4fqlyy+/ fDt6xG0u7bhx4wpbuSgaLdevX1/Q3d+8eXOWDh063Etfpee9JqIYlG7WrNm/3HN3Xrt2bbauXbt2 R4nbD5MvaHfMzTff3MmeJ9ZOVwZMr0M5qIIC8i15Fz3zzDMdpkyZUsCew/eWefPmVezevfvUIkWK xNKGngcPHvyHDJrQewRqX6NGjVZcd911S9xh77pv3764Me3ap3NQBDxFIqiUJAr44xNsIUonAiIg AiIgAiJw4QggqFsQdaIuTDfeeOOMr7/++jqOOQidO31byKz0VgT/bS+//HLld95550d7hlBbFuH6 1EMPPfS7b9pzfY3C0OCbb76pffz48SxNmzb9HkH5GwTkgk899VRTlJr3EUKbXXTRRQcRuits3br1 0urVqy9EIB2fPXv207S31AcffFB7wYIFo1y7bLb9jTfeqDphwoSp7h7l1UCwncm7rLJ71FcBy0Jl rBJ7161bV+rbb79955JLLjnODPlmOFxrZWBx2bZkyZIYFItjmTNnPurKsnNyyps6dSoT+yVXvfba a3OtjJ07d86A8a1cTn333Xfr0iczaPcce/bZZ58tef/992v9+9//XmsKDcL7v1CCRsAoQ5UqVXoh JM9ByK7Ie1einKewolyze/fuTFFRUSdRDqL27NmTE2a7rSz3gVW5bNmyHfnxxx8/s3u7du365rHH HuuK1eBL3s8Ca70PXEpgddoxY8aML+xGuXLlJtWoUWOwWawCtfOv3H/9++eff17ywAMPTOzdu7c3 dt5+++2N9GtZLD276Mdrv/vuu/4ooHt79uy5mn5sMmLEiDK05axxltB7BGofFo9lrh1m4cBi0QQF 8CV3T+ckE4ix3xesiokGW/9DC0xyVcogAiIgAiIgAiJwoQkUDqZChOQ9uC3NYBa9VXzpcQWZj3BX xT3DElAZt5BFuXLl+n+fG/cwkfPRo0ezMdte3fdAKC7inw1BvxAC/dXUNYKZ9pGTJ0+ubwI8Am62 TZs2eek3btwYjSvPzVgRplPGcITZK5ipL29l4SJ1GgH4pG+5q1evzr1o0aJyvveYkc6YJUuWU+4e 7cuK5aUwQrnFFKQ3hcSeHTp0KCNpM+HS5DEl9mAaTMbx3FauifskpzyE9Qy0Na4NBw4cyIKwH21K AopAAQT1Ta4Cm6HH8hFt32ESXahQoe2lSpU6wox+dSw/SxGOv7/44ov3Fi9efB2KXrqcOXMeQnDP aemxsiy3NuP6tNK+uw9cChYtWjSujpo1a8Zincq5fPlyL59L165du7X0y1vuO+xLY5XYhhvWoUDt dOntjPL1vikQKFv5u3XrVou+LI5VYsUPP/wQBYNjpkC49JS9E4uX967unp0Teo9A7fPNT31tb7vt tm9x0zvqe1/XSSYQ1O+LlIgkc1UGERABERABEQg5AVvGNagPQvjM2NjYgrjVVPbPgJC+AFeRMuZ2 g3CZnpngSszez/dPF8x3hPQc48ePr+N7IFCW9M+7cuXKvAjuuRFwc6HcrGa2fmiFChX2+6dj2c+5 +Mb/adYB2jSNsjwlwmbqmXH+2D+9//d69eotRBhu8N577xU1//w//vijnCkSxHwcRLlaT7zETVho CrZv374ZbleZcOXK6l+G7/fklMes+2Let+wjjzxS1eIbOCwmIoPFCKBMRDH7HyfsIuzvQcHx2kDM RsHChQt7VoVZs2ZVxVrizbYvW7asGO1YYXEVprShFARcTWfLli1RKBtxdeCmZYL8GcbDWe9qQjfK 4wF7X4tHGD58+B1wmWLfA7XTnvt/UCSavfXWW23MvY2YnBMod1FYdo74psNispcxkMX3XqDrQO1z +V555ZWSWGbyY8H5xd3TOdkEgvp9kTtTsvkqowiIgAiIgAiEjEDQK/Tky5fvJAG5Y4cNG9a6U6dO Z81U40++C2F1A4JXRYJedzPLfxLB/s/kvBX17EYheTmxvA8//PBKhPe5tKUXSsxB4gXmfv75557A 6psXwXGH+162bNlduMY0dt/dmYDkTrg7xSB8Zz58+HAehPIn7BlC+2cEKs/DF784Ljbd8ubNu5vY g59w0fCy8mwsadrg0lWT2fvlWAHWolzE1efK9z0npzwTzJlFn4Brz80I1ukbN248G6G8ABaF41hJ ThCzEGcRIEYgK+3faXXSF3tx36pk1zly5DiMMpALl6B8KF6lUKK+Q6loguLluWlZmoQ+CO/HUY7i 6sCqkNnc1WrXrr3HP48pNgQ930VdMYyH17AmrLU0KtzTbgAAIABJREFUgdrpX4Z9nz9//odYVD5B YelGDMSNd9111xwsL3FtsDQorFmwssTadbCfhNrn8uMWVh/XuB+xesS5ablnOieZQFC/L1IiksxV GURABERABEQgsgjgJvIbQcVb7r333qb+La9fv/583IuqMMu9C7eZheYqcz4/FiSLj/tXCLiTmPEu g3LTivZtYSb+LGsEM9XZXDuIA4jBxeqs5/YMRWA6s89ZEVwvQeiu06dPn0/tPoHU23DZyf3ll19+ anEPds9WY0Jh2GiuRMQJnMJlapjdt1WFmDEfjEK1zb4n9ElOeVg/chCwvMzFnDz//PNleJftVocp NmvWrIly9eFqFYWrktcGgqS3/Pe//40hSDob5ynEijTH5WsnnEazElZrBPC1uDyNc3kTOsfExOxG +bjUPSc2Ij8xFDucK5e7b0wQ+jujCO6nfwab4umeBWqnS2NnW30Kq9fHKCh7ccU6gXK4iPoqokjt gXE2Y4Ey6LmImcUAhWWrb/5A14HaZ/ksdoOjIpzHBipHz84tgfP7S3Fu26rSREAEREAEREAEkkmA INux+Kdf65+dGIaFzHCXRbityko+yXJlsjJxsUlvgqL/4bukqaUjtqEaAd+tcbM5hUBsVoD1uNf8 w33i559/rmzCo60wxP4IVVAAVlt+2yvBlhy1a3zgN1mgLsrPZgTjo3ZtB2kPPfnkk/Xxj29h6VCS 8iNklmcVpN+wtpwhX/dnn322rD1jxr02loFNzP6f5XJjz3w/ySmPegsREP0o75fZDqwRDRo2bLjA ykWpWYIrVy1TYsytCoG7JoL1GnuGUnMKd6IZrGLUnnuxxD68asHRWJRWEWswBCvERmI48lnaQB/e dxnKUkmLOcE6kBllpAkKiFeHBSE7FzdWgrqc9hX85JNPvjC3Nktrh/VdoHbasrzmLmZtsABulJy6 ZjGwvPRTVd71V3O5gu96+vpqS0ege1WsRrmwynhWl7+/26MEP4HaZ5lGjhx5GUvfbmUc/EPRTLBQ PUgxAVkiUoxQBYiACIiACIhA+BMgwDoWoW4WgutZ1ghWPjqAIL8ON5t8uJ5sTO6bMLtcmKVHn/PP z0pID/sGuiK4LmR2ugk+8wOxLuxDqD/FsqILsBpc4pvXVkjC1aofAc1ZcPPZirA63Z6Trvibb77Z 4n//+99S3/T+1ygTP+L608H2gti2bdvFCNTjXXAv8RBTsAq0ZKWk4ygq2YnjGO6f3/97csqz+A2W bV2D29WDuCvlpi1raPtPVjYuTrNgX5b4gEEI7jkIcp+N1eEPV++QIUN+xZJwECXkXt4/FkvNDoTz fLgk5SdeZHl8Lkkurzubu9odd9zxxa233vpf3JKOobjtR3l40Z6jWBR94YUX2qDULeZeSQLbL8YS 8rzLa2eWk+0fqJ24ENXF3eoIrmkbzM2KeIp7L7300lpkPcN+EStRHBZaOazENArFrQdWjWuJ5chJ QP1bzhqC61RHVuOyZAl+ArUPZcRWf7qM+jz3qwQL0YNzTiAon6dzXqsKTCoB8+9TXyWVmtJHOgGN +0jvQbU/OQSCGvcswViTwq9MTgXhkMf2o0CZiUbwO+gCen3bxb2OxCistjgEZtKzJxZA7JvX/9pW C2KGep+vi46lMSsHKxpFmXLlnyfQ9+SUZ9YZZt8zxveuZllhpv5oIEuI5UdQLoDiEOtcggK10f8Z DLP+/vvvNvuf6LKd/nnd92DaiSKZaebMmQVwkduFknjC5bWzWTisz80C4RQI95zYCfSMEd3dd51D TuAX4ofmJdYKCaaJEQqP50H9pxIeTVUrROCcEdC4P2coVVAEEQhq3Ee6EpFYfzglAh/7HxJLq+eR T0BKRNj1YVBKhNyZwq7f1CAREAEREAERSNsEWGVnETPu/1hBKG1T0duLQHgRkBIRXv2h1oiACIiA CIhAmifABmuL0zwEARCBMCeg1ZnCvIPUPBEQAREQARGIVAIW+xCpbVe7zw0BVgTLxy7ghSxe4tyU qFLChYCUiHDpCbVDBERABERABFJIgBV4hrDa0QtsuDXUDlbjGcz6/d0sKDaFRSc5OzstX8QeDQPi y8iKQFcQuDnctdPOBD73ZyWiWyzgOb48wdyzpUxZEchb/jWY9OcqTe7cuZ9iM7yYc1Xe0KFDLytf vnwX23uhbdu2tsu1V7QtB8vKUg1LlizZvVq1ah0snX+dtuO05fG9n5zy2DU7t+2tYatbNWjQ4FaW lM3jyjTO7APRkmDw+9iwr5G1yz2zs+1vwWpTrcqVK9eF5Xgbsbzw1Vw/ZN9Z8amAb1q7ZuWqdPa+ vvcD1T9q1KhLiZvpYBxY9akeO63n8s3rrhNrp0sXbHk2bitWrNiZJYTv6dixY11bftiVkRbPyf5D TYuw9M4iIAIiIAIiEO4EXnnllZcQ6h6yA2GuP0tqZrvnnntuD7d2s7zrXtdOOxNE/fq3335b79FH H62e3LayclKRMWPG/GMvjOSWF2w+hNWhrPLkbSIXbJ6E0q1atSo7y+B2RUhfyh4eU1iVqRKbz3nL 8rKbeM3Zs2dXZ6fvqWyot5h9GTqyiaC3NO64ceMKWzr2bmhJvxd05Se3vNatW7dn48EzLL87nuV2 T7L7dze3bwf7idzL0rvp+/XrNxEBvjT7WfzL1WeCdb169e5hp+75bND39t133z2PPTlmzp079yX2 2pjE5nvt2Jcku6W3VaNYVvgaNgpMx8Z7pVwZdk6oftuskDK658+ffz9t+4L3i2GJ2E6+ee3a2hGo nS59sOVNnDgxmn02OqBErGEp3sn0Q2WW/a3nykmLZykRabHX9c4iIAIiIAJpgoAts4lAt3Dfvn1x s8gIdXW438cOBL04Icg2H2PJ1fvZNOw5mzFmV2lPOLUZaLNmmJWDDb0eY28Bb/Z7woQJhapUqdLR ZoLZB6KnAR0wYEAFlit9lOMR9kOokhTICMDb2WNgPXs6eG1NqF6UjSLsu9DZlW2bndlqTtYerpsj QJewWXB7jkIRQ9sexFIwiD0Z2tsMuctns+iWx31P6GybxHXp0qU2u2uXZF+JUuT7N0uUPmMz0k4Y ZifwVvC7yNLA+zabubc6bRYfxShuV+r46rS2miDr6mdjtarMsK967bXX5rIR3lr6awaKRA17jpJU A+F6Jhu0rbK4EWbEV9BPle0ZwnwUe33kZN+J3fbdfZJT3ooVK3Kyv0cprCvjEcQ3jh079is2kStg M/tYFcrZxnK2+R19v4k2foPL0tUogp41gk3ybsQS8p21nSVpW7OXRO3evXs3xMrUacuWLTnZPG8x nMpZ+7Zu3ZqNd4+GlWuudw5UP+9bgn0zdsyYMeMLqx+leRJtLWO7VvsWklg7Xdpgy2PjwKKMoQUf ffTRLNtPhWVsF/K53Mox5Y1yvL8XV25aOEuJSAu9rHcUAREQARFIMwRwDcmMcJbFDhOwEbZqsU/C MgNgOz0jEDZhhvtzNkF7lxnga5nd9gRU3FI6s7nZdtIP5ryTNO0sD7s+d2YTsi0Iaf0QnqYgEHZh d+vcCJVZmGmuhABZGSF7uu1lgLtHJ4TiBczUjkfousryB/ikd+202XLaVonZ46ItWrT43fIEqDcr +Qq7cmlHVhSPQgh1seyE/R0KzOZhw4ZNNYWBTdB62I7LKAvm4nUKa0EHl4/vJzJmzGhL6sb7MXcs c69CsRnEu9RgQ75DbHB3O7PgMyZNmjTEduhGmK9rmdlFuqjx2LFjR05cx+ohFB9h5noYm+XtgGNz V0F8deK2U5V4gcwuDcJ4Bmur+37gwIEsKAfRZgVg9j8jylzcM6xMWTds2OCxwCqxnH0vxqFYrHR5 7Zyc8o4fP24KQXq3n8OhQ4cyUncmFLvCKE4F2fhuk6uDPTxi2QMiJ2PBE+LZj+IyLARLbIyw03YJ lI1PcKeaQTtLwm4tiugBOHlag+3/YW1GGXXFeedA9aP4rqU/33IZUBRLY5XYhjvUIXfPzom106UN tjw2xZuP9WGsKTimSLNBYSPG+iIrxyw2bGbYHS4PYkmrkhKXPNeuSDgryCUSekltFAEREAEREIEg CTz88MM9OeJSExexDyFult1gtrQuy6d+j7vMCvs+efLkWfioV2OGeQOCcInFixcPj4qKOolg9jVC 0TGE5YK4nJREeHrddp1mVnvRJ598Up/Z5Qrs/rzp5MmTmb7++ut3EFwPmfBEDMR6Zq+/sbJRDGaO HDnSE6AtsBZh2BOU2T15iz1H2cmHsjLMrt0HP/+57LC8mTITrBcryU6X3vecJ0+eUwio+xGyj6M0 7Udgrc2sfCzvMtPSvfPOOxOwYAw2xQVF47i52vjmd9cWP8AuzfWZIS+FkDuf93kBd5nttDcDG8bl RpkqxO7Mf9LG0Sg9cRYEl992heZ9pyBYpsPFaBxWhYE2S49icCahOl1eO+MisxjFp/kjjzxSlZnv 7bTfYiIyoKRkMqsS3xvAezdKUh4Ut3IoeKt98/tfJ6c8Nvo7aH1J/MVNKEE/IjRfbX1NoHxWrAlR vONRV0+tWrX2cn0Gi01WzgdN0bF3xRJQFd7eOEPgLl6qVKk/TCmZN29eaRTGb13++M6B6rdxaIfl s/gP3Ldux+rxiX85ibXTpQ+2PJeesVEW68ft9ElmFBfPhY1unkb/zMS9qwp/Yw1o020ooLPZmftH f+XGlZMazrJEpIZe1DuIgAiIgAiIwN8E2Pl3GMJuDzvYPbgfAcyn77vvvib2eNeuXQW//PLLpghz T9uBa8bNCPe5lyxZEpU3b95dpkBYOnODYrZ3Ci4yTPLm3+6ENnuGKwnyYqw3k0ye3aZA2H1mnMtc fvnla+zaPjfccMM674J/EOjvxi3mUTsQpL28xETsce2kXTaD+zbuIVeZuxLKTMB6Xbl2ZtY6XlkG F5cCzHjHuHetUaNGHzbpS49yc5bbi29ZLVu2bEw77sc9ahVCel+sCmNNgbA0tPc0AvVHcGkIpyFY Sloy4/yP1adoeKwpEPYxZcVmqbFKnOU2hdBbC45P2AGDnMQ3PGjXZvmg7gPMjk9AWL2ZdPdcddVV S6l7n5VlO3ijKO184IEHur311lvXo2z8ZNYjr7IE/kluedQ1FiWlJBaqXlhC8mCJWYtwv4P4iOMo E3EMd+7cmZl3PIXrkrevB+PNs+6gwB22dKZAwawaFp0dzOaXxmpUEIvRjgSaG3c7ofotgSlUFoj9 wQcf3ECZr3EsiMv490Vi7fRNH0x5Lj1K5kL67DHGyiSsP51d0LvtiI7iNB+l+wVc+V6bP39+eXg9 Ze/v8qa2c7x/eKntJfU+IiACIiACIpBWCLA602mb8bUD3/zdHD/gSuKtHIQv+1H89z9F+O1tB7Py j6NovIaf+nYEo9y4pXgCj826I6heSd6tXOf1FYQQAqNx41jrz5OZ61iE9nzuPkJUXHAvguZgBPge dpgLi0vj2mnKC8G3i1BeNhOAG5NYvaYMuDIIyL2I7+5r3BmXoqPEIPzu3tXOxC30xYLiCbtxCX0u 2rRpsxThdBEz59cjJP7LLCjusS1Xi5VkLQL1QCwsQ1FeMvu6Krl0MLQZee+DMpQLrnkoc7+7Z2eU qd/79Okzxg4sJ9YnE+wa17KfzS0MpWuZ1YNwOwAlYiMKhqcomAKGEvgpffI4VpDnaUMWLB0BlYjk lAerDIyVUwjEw3Blevznn38eTR9GN2rUaBtKy26u4+I8UB7z0387rC/t3YirWY07U3ksKUv4mp7Y ka64fX1DPxVBwW2KG90YSxfoE6h+e4b1ozP9exBr0WCLvYivrMTa6fIEWx5WmUYEtNe0fKYk4tb3 C32dw8XF2H1TRth9+0re9w7ikPJidZtkVhl7lho/UiJSY6/qnURABERABETgbwIIoAedYIsr0B+4 L1W3NfvtII6gPe4ujVgJaA8zqbtwc6pq2Xr16lULX/WKCGv7/r7vOa3bmv9YDaIJ9o2zODjQLHm5 bOXKlWVtCU8TzBB2k7zKEoLhAQTkrIHqZXZ3NwJalAUsm3JDsHFcPQhsp024tzbhtrUSAe8yt7yt ub5wr6ezEvC9uvm3u/bbGcVhG1aZ93nP/zGTfojA3QdwF+phrkUmjCPQP2ZB0CgbW2666aaFCNg5 fPPbNQL2xcSdeHEKxFDUxDKxjd23D9szVyez9nvhvtoOlL5TWDXW2LVZPYi/KIRF4lEL6LYDi0OD hg0bejPtrG5Un7QtrCzS5ce1qjxuZ7/Z94Q+ySmPNp3h3buj2JW1chHUa2MJ2YRSdoT6lpmLmwVZ b9++PTMrFjXBVSluPKAkTMbdrRnxNoVxXRpNjMSbWFY2Ex/xiq2mRH8kGoAcqH5c6i6HS0Hc6r4w pdfaYIdZBGxxAMawF2geqJ2+6YItD2UtFqWyLkHu+awu61vu/W5MrC/os3+huAyaOnXqlSiBU2nj wM8++8xz7UuobyL9vmIiIr0H1X4REAEREAERCECA2f1DCFkxFryMr/ZUhJ1uBIA+iSCUnsDfTQh8 3swwguJEVvzpROxAc4srwA9+pBVrwdS4cHRk9r0prk95EbQnW/yBf5XmosIs9CqW++xr7jcVKlQI KNz657fv5Du8aNGi0lx+n1C9Zl1BaF3ZuHHjvuaCxcpRfyLYe8oALlTr8VcvTExEO4KAR2NR+I70 /S02wmbtEXg/cPWy0lInXLGed+5Y7r6diUU4gAvOZJShqfi5VyYuoh6+/hl4p2XUNxjXnHUoOzkJ IP/cN59dw2YXLO/GupCBOILMBJu/79IEqtOlId5iLYL4GuIJHqSO3KzwtAb3mJ/sOYrGjzzvYKs+ YRG6GEF5PJYVi0lI8JPc8ph5n/L888+3pM3H4ZAdlsOtEqwRu7DIfMEs+38ZJ8csBgSh/EXXAItn INbmdRStOxhDpxlr2+CQwdyYbFUnxtsklzahs83eJ1Q/dZVEkb0Y5e553/wor/1RUGKosw3MFwdq JwpQUZcu2PJQrJeznK4FUw+w8c3Y20P/T7A2MFY7MPbXERthS/3G+rYrNV/HmQNT80umgnczU5j6 KhV0pF4hSQQ07pOES4lTCYGgxj3uO+ZWcWVy3tlmUc1aYHn9BR5z2WHmOJevy5Gls2BkLBMFEKBi cVs6bvcS+piFAOvFCfPFTyhNsPcD1WubkTELfAiBznOjcWUieGdA2clkMQR2z5b+xLqQDyVnW3zK j8uX2NlmvfGzP2PvhyUksy1J65/HNrr78MMPG2CRGc7qTlEmyDrLh3/axL6b5QNXqIzxccT6kh9F yaxEXgxLYmXZ8+SUZxYl+j3Kf5xYeVgjstpYQZnbZd/j+5h7DwpFIeI4jqLMJcgCFyA8nUZ09y8j UP3+aRP6Hkw7E8rrf9/+duj//FjMTvr+jbix4Z8+gr//QmzLvMTaL8E0MULh8Tyo/1TCo6lqhQic MwIa9+cMpQqKIAJBjfuUKBERxCLimuqUCCwjL0dc40PY4ISUiBA2Ka1XHZQSIXemtD5M9P4iIAIi IAIiIALnhACz09txtZl7TgpTISIQ5gSkRIR5B6l5IiACIiACIiACkUGgefPmO+yIjNaqlSKQMgJa nSll/JRbBERABERABEQgAQIWY5HAI91OpQSsz21pXFsVy3dp4FT6umn6taREpOnu18uLgAiIgAik JgKsljOE5TFfYHWboXawcs5gVhPq5pY5vZDvSmDxRQRhD4ivTlbPuYLAzeGunXYmSLi/bbZmwbTx 5Qnmni07anEJwaRNSRpWuSrB0q19U1KGb14TtlmNqCFLhnZn1+4Otmu2e24B5Gwq18ZWZCI4+VZW ncrjnrkzS+K2YafkuKVTk1ue1WubuDFm7mvbtq3tlO2qSMcu0xVZMaozx11sBHd53IO/L9hJO4aV ru4h+P5O+FzJakY3ElDdhxWzbrAAa//0qf0743kAqznF9UlqfN9k/6GmRhh6JxEQAREQARGIdAIs cfoSQuRDdrDrcv+jR49mu+eee24Pt/diVaW9rp12Zqfq11n5ph47Rsft+5DUNrNqURGE2WuTmi+p 6Vm+dCO7UHtLniY1b3zp2WSu5uzZs6uzmdlUdq9ezE7IHZ0A2rp16/as8HSGPRbGszrUSdylujlF i+VnK6BA3MEGfdewjG92V3ZyyrMlgNljoSt7hixlE70p7IdQiRWomlqZttM0S73egTKznGVlf0AJ bMcytCVcfey1UGbQoEE3sBTuR6z8NZp8v9EXY7h+iV3Mt6NH3ObS6px6CEiJSD19qTcRAREQAREQ gbMIsEfEiXr16i1kSdK42Ws2iqvD/T52sAlYPZfBNuBirfv7Wcv/OTal6+Jmtm3m26wZZuVgZvkx 1tf3ZsnZR6FQlSpVOrIpWb1ixYr1tHIGDBhQgaVVH+V4hL0NvA3qXPmJnW3JVPZfWM9+Al5bE6oX ZaOIzYi78t57772iLIPa0drDdXMUpxLMhrey5zY7TtseZEnOQez90J5n2Vw+loe9z/K4775ns6LY 5mEoN+lRGBqwYd8T7Asw0HYttnQIyAXvu+++W+yaDeKasdHetVYeitH/4H2bE/JffvnlUtR7p6Vz H7OWkMcTzt09yquBsjCTnY5XsVfHYmb0V8C/sm2Gt27dulII5+PZ5Xojm9h9xax+ASvD8rJ0bQyK xTEsOUddWXZOTnkoAlWxhKx67bXX5tou0IyTGSgSNay8d999ty6KwAz2eJjDhnl/wn8J/VDLntm7 omT8C5ajbZM4xkQvdrEuArcbWBq2B3tNLGB37cK2uaGlRxkpBat/s8P1M+xm3dnt+JzQfRtbtnu6 jT32++jH3gzxjitbDpjA9rbW17ZB4Ntvv13M6mvVqlUj63u7tg9jpQN7Z1xl1yg+5ax8lv4dZGPI lgO2+7S9oeWz9plFgb1RrrONAqm/L+3obWPO0gXqe3vuPoHGoUtjZ9vp2yxc9g6M4Za22aDdN8uP jUH7GzRLkVmn7H4w7bSx3KJFi8b+Gyta/pR+pESklKDyi4AIiIAIiEAYEWCfhMwmUNlhws6MGTNq safAMmuiuaQgiDZhpvlzZpLfZVfha5m19gRFhKbO7Li7nfSDOe8kTTvLww7JnRHKtiBg9bMN4Hr3 7t1lwYIFuRFmsyxfvrwSuztX7tKly3Tbh4AZ6k4IPwsQ9Mazi68nqFkZCXzSu3baLDhtq4SwWRSB 53dLH6DerOTzdoS2dLQjK4pHIXbfjmUviO9QYDYPGzZsqikMnTp16sHs+RIEXHPxOoVQ28Hy2Ifv JzJmzGhL6sZ9zJ3HFCisAY/DMYcJ67zH1VgdRiBwjmTPg/p2jxWYsm3atKmIZWQfgmiExJuxIkxH sB4OpyvgUN6eIVSfpp6z9nJAaM7Nhnrl7Ln7sJFdRgTEU+471qOsGzZsKMwGebYUf3oEbs+viB2y M5I2EwqW9/7EHkxjH4dxPPd2xHb5k1MeClMGY+TKYK+NLHv27Ik2JYFduAvUqFFjk3tWpEiRWCwf niIDk+hChQptZwPAIyhA1RlrS0eNGvU9/bCXcbPO9snAre4QO1Z7Ajo7Pd/Ojs4zJk2aNMQ2PERx qmvlJnQfziVgXovNDt9mnE1EYWkbX6wNSs4dtDkndY9gDP3IsrH325hEsZ1Dn1SwnawZ09XXrFlT EkvPQnPVQsm7lTHyDVagZ60NDz/8cAM7M77yMWaasgfGYvp13Oeff/4vjrpDhgwZiQK0mv690dIF 6nt7bp/ExuFfqdKlM2GfzRA7U994ewfaWQxlrr7tEs87dIbT5ygPA1B4DqLMekpRMO2kH46xb0lR NgEciJLVzlm4XL0pOac5H7WUwFJeERABERABEQh3AghCPTnimokAtw/heJbdYHa7btOmTb9HoFph 3xEAZ+FyUg0hbYMJa4sXLx4eFRV1EqH4a9xWjiHoFURQKomQ9ToztkeZrV70ySef1GdGugI7JW9i J+JMX3/99Tu26zNuSFWIgVjPrPk3VjaKwUwEv+Z2bYG2CHjerCo7HW+xewjp+VBWhtm1+xAPMJfd kDdTZoL1IuTvdOl9z7aRHLPE+xHGjyPI7kdQrW07VfMuMy0dO3FPYAZ9MIJXFgSr4yhAb9t9hOHM 8KiJ0FiP/TcysOP2bHh8SAzCUWbRyyC450bwz4WytRpBeijveBQmnkBs+e1z1VVXzbUZervGJWsa loDyKB1LbbdoO+x+oI9Zi2hnAzjuRujMg/BbDgF8te3+bEwRGm9CAP4RK9DVxhwhOuu5Lo/dsBej cDV/5JFHqjJzv532WExEBotnQJmIYib8qKuTXaj3oLx4bUCwLcjO57vtGYJwVWbTx9n1smXLivFe y01YN5c625zNNgJkA73cCPWF4PIn/TwaxTEbQnPz+O5bOfZBgP7KNryzg36qibWkNIrqH3899cZa dsZudRS+AcSN7DarFjts12EDu/LDhw//BUVhPG5+t9mu4yirH6L0nLB+J35mjPWrKSVw3snmecVd mbBfhDK6wL5jJTnAuJ2NErPedt9+7LHH4pTRhPrelYNiUC3QOHTpUI5qYgn848knn/QUfph/hvUg ijFYE95rqdNTrlH+v+Lv5GlnVUusnWXLlj1MX7xjlj3GZB0Uk25MBOzC8vUddS12CqprR1LOskQk hZbSioAIiIAIiECYE0BwGoZA1sOOmTNn9iOA+TSuN02s2cygF/zyyy+bIjg8bcdHH310M8J9btxi onDX2WUKhKUzNyiEtSlLly7FuyL/dlMg7L59ECbxsoj13CnIs9sUCLuPC0sZ/N/X2LV9mBle513w DwL93bjjPGoHwruXF9efPa6dtOtBlJC3Fy5ceJW5KyEQBqzXlWtnZuvjlWVwAyqwY8eOGPeuKAB9 UBLSo9ycpQAghPUaN27cdQhpn/FeTyHQfmcKhJWNMraSmIO5CKG9zK2FmfarUXyO2TPfD3zilnVF aNuF0lHK97ldo8B0MpcUBNc7UWSK2LUdFk9BbTdaAAAgAElEQVSAu8o8FKCduO10e+utt65HmP+J erwdsXk2FqWiJJaiXgiWebACrKXNcfX512Pfk1Oe7YyNe9sE3IBuRs68B+F4KX20zxQuFLMTCPtx 3FAGstJ2T5ljZn4v3PJavTly5Di8ZcuWXLhB5TMGuN7sxCrQpEKFCqvsOeWdRhn6iLHVkLE2BGtT SywdGIQypovvvuWxDwpr3PvCaTdKbcm/nvz1L2OvgPUtY+4R198oxcVRFLyxZi5aPE+HML8bAdoT xmn/CdpZlIHWF9aD5s+fX8G3TOrZ675jTTmJYrrNvpt1iU/cJHxifR/sOIRbFH3r1WH1MOY2mNLO /fyMqfV2zz7WT7ThGGMil30Ptp2mWMN9Mn3Vj7H0HcpVa8bZnVZGcj/x/uEltzDlEwEREAEREAER uCAEznLD8a3RhBwEKe+wWVmOH3CNibE0xDscvffeez9FcOttB8Ls4ygar9WpU2e7zQQfO3bM3GfM SpDB/NDJu5XrvBYbYPftg+tQNC5L/5hdZyY3FqE931+p0qVDKCvornGHGYwQ18MOm5F29107TXl5 9tlnF6G8bCZIOCaxek1gdGXg9nGRCYj+H/zKjyLg/u7e1c7EffRFIN3jmxbBeQZcDuOi0sZWJEL4 jQtQZufpbFhvvuK9HmM2/FOE15q4wlTyzW/XWCviYi1w9YpBWN7vn4YZ/ul9+vQZgx/9TBSSnXZt B4HSm02xQrn7FNaPI6w/j2KUhfiE7bQ5A207heVjGHU8/vPPP4+GZXSjRo3ihE3/eux7cspDKM2B srcMRWUg1ocBKBEbEbQ9RcaURThHuboYT1FYSrw2MOu/BYE9xmbGsQ5MIX6iAe/aGE6jUZhaoyDm QVmdbnltxh9L01qrAyvVUN4zM8pDcywE6eK77+pjnMbxtbGM4HwWXywhRxD0T9PG/q6/YfAEgvJs K4O+q4YybVanGCwSngLCs1K4qTWmf18z7ig0syyN+1gwu7sOdE6s74Mdh9bfxsrVZdY4i6nBOrHN 9+/KYpdwOztOzE6spQ22nZZ23rx5eXnPZsQr3YZyuJnx/rPdj+cT1LtLiYiHnG6JgAiIgAiIQJgT OMsHPlBbEQQPohx4rie4Av2B+1J1C3K1gziC9rixNGJFnj0Itrtw66lqZbE8Zy3cVSoyC7/v7/te MKv5ZyPoRBN0G2dxcHUTXLwM3+uylF/AhF+E4iSvsoTAdQCBLmugepmF302geBRuQ1Gm3OA6FFcP wtVpE0ytTbhtrUQhuMwtb4u7UQ3u9UTo8ppsgbIWbIqr10KE1CEoMSNxZynK7Ln5jt+BkFsExaIa cRatcQk7hUC8nJni9czk5nDv7M4I95XtnVEAslBfFawzq+2Z1W1xKHZNAPomWK9mRngzytNRu7bD LDm4ldRHuGth6XDJyY+7T3ncyX5DITxDvu60raw9w0JQG+FvE8rREfue0Cc55VFvIQTTR3m/zHZg EWnQsGHDBVaHxZVMnTq1lvE24ZaZ/5oont4YMDey9u3bz8ANrD33Yol9eJXnnzGGVqFcDMEKsRFX Gk+5RBnKhnLymClnBAVvuemmmxYihOegz8wl7B/33fuxZGw1u0boj2ZmvhgxK54Si3JQFatVLpTO XShue+kjL77Hxikz9n0Yi4Us3ob8LWnPpyg8k1FuvJgKrG+FTZCmrFjrOxtH8Smjrg0JnRPqe5c+ 0Dg0hcBiNSwt/ez9/VhshCnzjI2W8MuN9W4p4/Jyu2/peJeKLHTwuxvHdi+xj7nlMa7v5u/8cf52 LG5kOH0wHOvfygTyBvX7EmeOSaAQ3RYBERABERABEQg/AgFnon2by+z+IZuB/VuYmoqg2A0f6ydx yUjPDO4m4hvGWHoE1Im463QidqC5xRXgfz/S7lswNYJ2R4Tqprg+5WWlmskmONoz3w/C9g5mTVch TPY1NxiEx998nwdzTb7DBB2XJu33CdWLwLibIN6VBL32NRcsBKo/EYg8VxvcWdYz01wYQb0dguto /OK/I31/80m32X380z9w7cDPvRMC/PPOHcv83TlG4sKVC0GzNoG5XZm5fRqFpgkMB9o7IdSfwud/ AQrSWev/2wpJsOzHjHoWlLatBLR7M++kK86sbwuChpe6euM7IzD+SIxAB9yoemDpuRgFYjwWE8+d hniIKQiBLWnvcYTd7LzT8PjK8L2XnPIsdgN/+zW4XT2IIpebtqyh7T9Zubg4zSJOoiwcByHg5sAS Nds3JoGA419xCTrI2LqX949lfO1gzOXDapIf5WB57dq1PesPguwhxsUy+mwwK3Gto56clPM5Lj/l 4rvv3gmlqjTl1sCScRHja5opIPaMOIKOKHYjUCz/ZLnbD1HY7ib+pqGlYyxMM8XNgolt1S+Ck5fB bzltq8kMfBPG9yzc2BrSb4+iHGUlfmMOCw00dEqfqzuxc0J97/Jh+VuX0Dgk9qYo7WiDsrrY/n5Y DWoZDPtZHBM8txDDsJjyz+Am+AfWp/60dSPM8qBIvOnKT+zMQgqFUUJb2aIDKFWjsBgeTywPz4P6 ffl/u00QJSpJyAiYWUl9FTL8qjhEBDTuQwRe1YaUQNDjnlnTW2mp56aUlBZboKtZCyyPBar65jV3 E2Y9c/m6HNlzZuqzYJkogPAYm5gQYhYCrBcnzHfbt+zkXAeq15a5ZEb+EML9ad+yEbIyoOxkMl9+ u48AmpNZ53wIUdviU3588/pe22ywCXDGhFn4aBSkg/G9E/c6IsSutjgEZtqz+7PzLTOxa2bD86MA mfXHi01x6W2mHP5R/v3lnid0Tk555taEa1vG+N7VLCtwNTexBC0hlp9YgwIoDrEW1Btf22yMMCOe 2QKg7TkKG6E8I7r737dnxEu8SP89gcUiEwrDEdev9sz/Y0HgKALRCOP7TGHxfx7fd/tbYFzvNtc6 c8nCGnbSxQbFl973XlL6PthxaPxQ4k+7uBxXnwVGY+nKjhK1w8alu5/Y2Y3jxNL5PN+CW9d4n+8J XkowTRBNWD0I+j+VsGq1GiMCKSOgcZ8yfsodmQSCHvcoEXl5xTYc8ioIYV87QZKA8B9C2IyIrtop EfG9hFMiglUK4ivjfN1LhX1vyusYlIi4uKVA7PTDE4iOnomACIiACIhAmBKw/+hRJGbSvIYc+v88 RP2Ez/siZtw9d50QNSFVV4sFaQruZMG44FxwDqms702BmBmsAmGwZYm44EMuWRUGPTOVrNKVSQTC k4DGfXj2i1p1fgkkedz/bZEwRSLJrk3n91VUuggERyCQJSK4EpQqhQQsxiRJCoTVp5mLFFJXdhEQ AREQAREIJYG/Zw7Ho0zkpx2FOWz1IE0ShrJTVHeSCODvb+m9f5KUUYlTQsAmLCxmZRu/IbtSUpDy hjcB62h9RCCtEdC4T2s9rvc1Ahr3GgepkUBxXipLgBfTuA8AR49EICUE9MeVEnrKG6kENO4jtefU 7pQQ0LhPCT3lDVcCtsu3je03Obw9H/waqnHvB0RfReBcEdAf17kiqXIiiYDGfST1ltp6rgho3J8r kionnAjYnhc2tk9w2NK/azke5jAXPPto3P/FIaL+lc9kZHSX/XGpryKjr9TKc0dA4/7csVRJkUNA wlTk9JVamjICB8mei8PkG/3ep4ylcotAggT0n0qCaPQgFRPQuE/FnatXS5CAxn2CaPQgggn4WyLW 8C4PccgSEcGdqqZHBgH9pxIZ/aRWnlsCGvfnlqdKiwwCGveR0U9qZdIIWEyErQT0BodiIpLGTqlF IEUE9J9KivApc4QS0LiP0I5Ts1NEQOM+RfiUOUwJFKddWp0pTDtHzUrdBPSfSuruX71d/AQ07uPn orupm4DGferuX71d/AQ07uPnEtZ3M4R169Q4ERABERABERABERABERCBsCMgJSLsukQNEgEREAER EAEREAEREIHwJiAlIrz7R60TAREQAREQAREQAREQgbAjICUi7LpEDRIBERABERABERABERCB8CYg JSK8+0etEwEREAEREAEREAEREIGwIyAlIuy6RA0SAREQAREQAREQAREQgfAmICUivPtHrRMBERAB ERABERABERCBsCMgJSLsukQNEgEREAEREAEREAEREIHwJiAlIrz7R60TAREQAREQAREQAREQgbAj ICUi7LpEDRIBERABERABERABERCB8CYgJSK8+0etEwEREAEREAEREAEREIGwI5Ap7FqkBomACIiA CIiACCSZwJkzZ/KTqTBHDo70SS5AGUQgRASuuuqqdHPnzq0ZourTarVnePHDHNvSp0+/KzkQpEQk h5ryiIAIiIAIiECYEEB5yEtTGnLEhEmT1AwRSBKBK6+80tJ7/yQpoxKfEwL8hmyhoJkoE/uSUqDc mZJCS2lFQAREQAREIIwI8J//ZTSnDccFVSBmzZp1kR2nT58OIxpqigiIQDIJ2O9Hm79/T4IuQkpE 0KiUUAREQAREQATCh4CPBSLOq2DUqFGXVq1atUPJkiW733nnnfWWLl2ay7X4iSeeqFipUqXOHHc9 /fTTl7v7e/fuzdSiRYvGl1122b/r1KnTas6cOWbZiPfTpUuX2tmzZ3/mlltu6Xnrrbc+kCNHjuda tWrVyCkTHTt2rGvl+Ga2MvPmzTvwm2++MXcrfURABMKTgP2ONPz7dyWoFkqJCAqTEomACIiACIhA 2BEwF6Y4BWLt2rXZunbt2j1//vz7Bw4c+MWqVatibr755k7W6hdffLH0Sy+9dMfVV1+9vHPnzj8M Hjy43auvvlrCnjVv3vyWefPmVezevfvUIkWKxDZr1qznwYMH/yEfkK/OJ598cgP5XkXxGLBnz54n P/zww2FTp06tj1JxvZXl/7n22mtbLl++/PLJkye/0KhRo2T5XfuXqe8iIALnjYCnSARb+j9+JILN qHQiIAIiIAIiIAKhIcBsoc3qn+XC9PHHH5coWLDgjhkzZnyBFWLTK6+8MmndunVlfvvtt5zvvvtu 3RtuuGHGG2+8MefBBx/8E2vEkvfff7/WsWPH0v/000/Xjhkz5t2ePXuu5vzt0aNHs48YMaKM/5uN HTu2adu2bSd16tRpg3vWsmXLbbVq1ZqHItHwxIkTZwVz16tX77bff/+9DO15sXbt2ntdHp1FQATC mkDM378viTZSSkSiiJRABERABERABMKOgK3CdNanXbt2aydMmPCWu4lCUBqrxLby5csf2rlzZ4Ea NWpscs/M4rB9+/boH374ISpz5szHrrnmmjghnzw7V6xYEe3S2tncog4cOBB1++23r/K9b9e33Xbb 0uPHj+dYsGBBHvesfv36Lb7//vv6KC9vV69e/YC7r7MIiEBEEPjH70t8rZYSER8V3RMBERABERCB 8CZgy7ie9SlWrNhR4iE8gR1rQ43hw4ff0b59+ymWCNejKKwUR12GokWL7kHwz7po0aKorFmzHnH3 7XzRRRftPXToUBbfe6tXr85p34m1OOR7366xRMTaeffu3V6eNWvWlEHpKF+4cOGNffv2bWbP9BEB EYgoAv/4fYmv9VIi4qOieyIgAiIgAiIQ3gTOch1yTbUgaSwPXT744IMbiIN4jWOBPcuSJcuJzZs3 e4qAfSfmIStKxc5cuXKdOHLkSNx9e4aLU5ZSpUp5ioF9tw/WBM9SMXLkyJJ/3fn/fz/66KPSfDuD MrHH7hJsffCrr756mc8olIlqKBIV/z+1rkRABCKAQLy/L/7tlhLhT0TfRUAEREAERCACCaAMZECQ 75w7d+6DBFkP7tat21r3GqyOtBsLQZT7vmHDhqjixYtvw3Kxh1iGbH/88UfczCMWhfysqLTVpbUz 7k/HoqKits2cOfMK3/t2TUxFaZ6v4flJ+44FYgvt2MeqTVubNm069YUXXmhDkHd2e6aPCIhA6iEg JSL19KXeRAREQAREIA0TeO655y6PjY0tyApKX1jANDEPme2w5VdZlWkJwc+1LPj566+/Lvjjjz/W RFFYU7NmzX0XX3zxeqwFVxu6hx56qOrhw4dzNW7ceKc/yjZt2kxj+ddazzzzTNzysLZULDsN17rv vvsm+6e378RlTM2WLdth8raM77nuiYAIRC4BW8pJHxEQAREQAREQgQgngIBfcteuXRdjYXje91Wm TZvW/+23356FS1JZ4h0GoWDkYOnV2f/973//sHSsxDSK1Zx6YK24lpWZcg4aNOgt9oL4xy5yrPY0 DwUjCwpH1wEDBpzMkCHDaVZxSff444+/37t3799963TXefLkOfXUU099hJLRi2VnF/bv3/8390xn ERCByCYQlM9TZL9iqmj9Gd5CfZUqulIvkQQCGvdJgKWkqYZAUOMe4b0mb3xlUt+aFZMuwvJwlA3h zgqmNssFlopos0DEp0D41mNpiXkohNvUCdJr7wdfOLpOFgH2KEGXHdE9WZmV6XwQ+CV9+vTzEitY lojECOm5CIiACIiACKQSAnXr1vWCn/1fhxWazrAx3Xb/+/F9t7TscL0tvme6JwIikHYIKCYi7fS1 3lQEREAEREAEREAEREAEzgkBKRHnBKMKEQEREAEREAEREAEREIG0Q0BKRNrpa72pCIiACIiACFxQ Avv37894QStUZWFHgF3R833xxReFWDpYLvRh1zspa5CUiJTxU24REAEREAERCBsCbCo3JFOmTC9k zpx5qB05c+YcXKZMmW4WUH2hGzlr1qyLLrnkkgHx1Tt48OArCNwc7tpp53z58vW/7rrrbrH9LuLL E8w9Ar6jQ7G5HUHmT3366acxwbQxmDRDhw69zDYNpO/ua9u2bX1bptc+tkTv7bff3pCdw7tXq1at g6XzL892K7c8vveTU96vv/6am6WB25QoUaJHgwYNbv3ll1/yuDKNM/E1LQnQv4/9QBpZu9wzO69f vz4bK4C1KleuXJcnnniiERsPXs31Q/ad1cIK+Ka1azY/TGfv63s/UP2jRo26lD1OOhgHVharx6aG uXzzuuvE2unSBVuejduKFSt2vuKKK+7p2LFjXTZwPGtnd1deWjkn+w81rQDSe4qACIiACIhAJBFg KdaXEOoesgNhrj/Ltma75557bg+3d2C37L2unXZ+//33X//222/rPfroo9WT29bp06cXYW+Ka5Ob P7n5EFaHXn/99UEFpidWh23Mx7K5XRHSl/7nP/+ZwmZ+lW655Zamlq9Hjx41Z8+eXf3++++f2qRJ k8Usmdtx9OjRl9izcePGFbZ0r7/+ekv6vaDds09yy2vdunV7lvE9w9K84wmmP9m8efNupuCZ4Nyh Q4d7T506lb5fv34TEeBLN2vW7F9/1ZYunT2vV6/ePe3atZu/fPnyt+++++55zz777Ez2E3npySef nNS1a9d2q1ev9jYf3LhxY9a77rrrmilTpqRjM8RSrgw7J1Q/Gylmo4zu+fPn30/bvuD9YlgUoJNv XrtOrJ0ufbDlTZw4MZrlijugRKxheeTJ9EPlnj171nPlpMWzlIi02Ot6ZxEQAREQgTRBoECBAicQ 6Bbu27cvbhYZoa4O9/vYgaAXJwSxz0Te0qVL38/mcM/ZjPHHH3/sCac2A23WDLNyREdHP8YO1N7s 94QJEwpVqVKlo80EFytWrKcBZf+ICiwh+yjHI2+++WaVpEBGAN5+6aWXrt+2bZvX1oTqRdkoUqlS pc6u7Pfee68os9IdrT1cN0eALmGz4PYchSKGtj2IpWAQ+2S0txlyl89m0S2P+57Q+f/YOxM4Hcv9 /499XxoMOQdZSots2VL2gxYqUYiIlJSUTnUkipROKdXhl85pOSfFUZIWhUKWSoRj3/esY4ydsf/f n7uu53/P45lnHmMwy/d+vW73dq2f63rGd/+SwC9Ht27d6g4bNqzcW2+9VZ56DxMG9++SSDtiuHv3 7neB3yUqA96tJblXn5LiwxgFMoWH6lNjFSHr+idpYDUk7GtGjBgxR1nHWa8pMBI19B0mqQbE9TSS Aq4h6d8iJOIrWKcq+gYxH71nz5585AKJ17M7UtLeihUr8m3cuLE82pXxMAy/ffbZZ9/s3bu3qCT7 aBWuZo8cIWHhWNZ+C2OcisnS9TCCnjaiY8eOt6IJmaGx161bt+0///nPuuQRaYyWqcu2bdvykeRw EThdrfFt3749N3OPASs3XO8arn/mW7ZYsWKxU6ZM+UL9wzRPYKxXLFu2LJ+/keTG6cpG2t7UqVNL s4fmjx49ejqMz28NGzZcwOElXhTzRjve78W1mxmuxkRkhlW2ORoChoAhYAhkGgQwDckBcZZTpwhs iK06NWvWXCoAMC25FoKwGRLucW+//fYHSIDrId32CFTMUrqWLFlyJ+UHc91FmQ6q07p1664ksNsG kfYcxNMkCMJu8+fPLwBRmRNJc2UIyCoQ2d+vWrUqL+YeXSCK5yOpHQ/RVVv1wxxZ3DglLWdslZEe lyZ8rJe4Lky/uahXwrXLOHLBeBSHqIu79dZbZ8DAbB06dOhkMQxdunTppWzdMAsy8TqJtqCTq8fz 8WzZsikvR8hD5lgyr4KxGcRcapQqVerQSy+9dDdS8CkTJkwYgolRFoj5+qq8ZcuW0sIjNjY2H6Zj DSCKjyC5HlqiRIlYcGzpOgjVJ2Y71fAXyOHKQIxn1Vjd84EDB3LCHMRIC4D0PxvMXOAbWqZcmzdv 9rBAK7F8xowZn8NYrHZ1dU1Je8eOHRNDkMXlDDl06FA2+s4OY1cCxqlY6dKlt7g+yHoeR+6QfOwF j4hfuXLl5WgIFmuPrF27tizMxieYU01hnOXAbgOM6AFw8rgGZUzXmGFGXXPeNVz/ML4bWM93XQUY xQpoJXZgDnXIvdM1uXG6spG29+abb85D+/CZGBwx0uPHj2/CXl+odqSx6dq1a09weRxNWtVzMclz 40oPV3NySQ+rZGM0BAwBQ8AQMAQiRODJJ598jDNQGr+IfRBx0/UCaWn95s2bz8RcZoWeJ06cOB0b 9epImDdDCJddtGjRsOjo6BMQZt9CFB2FWC6GyUk5iKd3kOgnINVe+MknnzREulzpxhtv3HLixIns 33777fsQrodEPOEDsQnp9VS1DWMwbeTIkR4BLcdaiGGPUG7VqtU2fYfZKQyzMlT37sDOf0779u23 0maS/aIl2eXK+6/Kjg2Buh8i+xhM034I1rpI5eOYyzSVe//9979CgzFYjAuMxjGZ2vjru3v5D5Dh uyES8vIQufOYzxvKocF4s5KxuwDMVPGHH354LWMcBdMT0CC4+uC9n/lOgrCUidHnaBUGSkoPY3A6 qT5dXV0xkVkE49Pyqaeeqobkeyfjl09EVpiU7NIq8dwIvONhkgrCuF0Ng7fOXz/4PiXtValS5aDW Ev+LFjBBP0E0X6+1xlE+F9qEaOaY4PqpU6fOXu5Po7HJxfWgGB3NFU1ANfD29hkE92Xly5dfJaZk 7ty5FWAYf3D1Q13D9a99qFP15P+B+dbdaD0+CW4nuXG68pG258qzNyqi/bibNckB4+KZsLHM37E+ 0zDvqspvrBFjag0DOovs7z8FMzeunYxwNU1ERlhFm4MhYAgYAoaAIfAHAmT+HQqx20vntGnTnsOB +VSPHj2a6fPu3buLffnll80h5l7WiWnGbRD3BRYvXhxdqFCh3WIgVE5mUEh7J2Eig5C3yE5HtOkb piTQi3GeJJk68WIg9B6J8xVXXnnlet3ruOWWWzZ6N/wDQX8/ZjFP64SQ9uriE7HHjZNxSYL7HuYh tWWuBDMTtl/Xrq5IrUPSMpi4FEXiXdLNtUaNGv3I9J0F5iaR2Yu/rTZt2jRlHI9gHrUGIr0/WoXP XBI+xnsKgno0uDQGpyFoStogcT4j+hQDjxMDoUPMiqTUaCUSmU1B9NYBx2d1gkE+/Bse1700H/R9 AOn4VxCrt1Huwdq1ay+h731q6+WXX54Lo7Tr0Ucffejdd9+9CWbjZ2mP/HMIvk9pe/T1GUxKOTRU vdGEFEQTswHiPhb/iGMwEwEMd+3alYM5nsR0yUtkyH7ztDswcIdVTgwUmFVHoxOLNL8CWqNiaIxi g8cZ/JxU/yonhkqO2B9++OEttDmCc35w/eTG6S8fSXuuPEzmAtasD3tlAtqfrs7pncAAJ2Cc5sF0 v4Ep34h58+ZdA14vav6ubka7hvzhZbRJ2nwMAUPAEDAEDIHMggDRmU5J4qsT2/x4zh8xJfEiB2HL noD9/qcQv8/oRCrfF0ZjBHbqOyGMCmCW4hE8krpDqNak7nbuC/kJIYjAGMw4NgTjieQ6DqK9sHsP ERVw7oXQHAwB30unTFhcGTdOMS843y6EedmKA27J5PoVM+DawCH3Ep7dY+CKSVECPggr3Vx1xW+h PxoUj9gNFPTdtGvXbgnE6UIk5zdBJN4uDYr7rHC1aEk2QFAPRMPyOsxLDr+pkisHhpLIewfMUH5w LUib+907XWGmVvbr12+MTjQnWpOvdI9p2WyZhcF0LVU/ELcDYCJ+g8HwGAUxYDCBn7ImfdGCvMYY cqLpCMtEpKQ9sMrKXjkJQTwUU6a+s2fPHsUaxjRp0mQHTEs89wE/D5jHIqxfrNZSc8OvZh3mTNeg SVnMYxZ8Rx7A7Gsq61QKBrc5ZnRjVC7cEa5/fUP70ZX1PYi2aLB8L0K1ldw4XZ1I20Mr0wSH9lqq JyYRs75fWeu8zi9G78WM9OzZsybzbY8fUiG0bhOkldG3jHgYE5ERV9XmZAgYAoaAIWAI/IEABOhB R9hiCrQK86XrFLNfJ34EHTF3aUIkoD1IUndj5lRN1Xr37l0HW/VrIdb2/fHeM1pXzH+0BjE4+wY0 Dg5oQl4uXb16dUWF8BRhBrF71lGWIAwPQCDnCtcv0t14CLRoOSyLucHZONAPBNspEfcaE2ZbqyHw LnfhbWX6wrvHnJaA5+tk3+7GryuMww60Mv9hni8hST+E4+6jmAv1kmmRiHEI+j5ygobZ2NaiRYsF ENh5/fV1D4F9KX4nnp8CPhS10EzsqOUmhnUAACAASURBVFix4mF9c30itd8L7ut0wvSdRKuxXvfS euB/URyNxNNy6NaJxqFR48aNPUk70Y0aUvZOtUW5IphWXYPZ2TI9J3WkpD3GdJq594Sxq6h2IdTr ognZAlN2hP6WysRNTtY7d+7MQcSiZpgqBfYDTMJEzN1uxt+mBKZLo/CR+Beala34R/yfoimxHsk6 IIfrH5O6K8GlGGZ1X4jp1Rh0SiOg4ADsYc/RPNw4/eUibQ9mLQ6msj5O7oXVl9aWdyuFidaCNbsd xmXQ5MmTa8IETmaMA8eOHeuZ9iW1Nun9vflEpPcVtPEbAoaAIWAIGAJhEEC6fwgiq6Scl7HVngyx 8xAOoC9ACGXB8XcLBJ8nGYZQ/JqIP13wHWgpvwLs4EeqWTlTY8LRGel7c0yfCkFoT5T/QXCXMlFB Cr2GcJ/9ZX5TqVKlsMRtcH09U+/wwoULK3A7M6l+pV2BaF3dtGnT/jLBInLUWgh7jxnAhGoT9uol 8InogBPwKDQKMyj/vHwjJLWH4P3Q9UukpS6YYr3mzLHce13xRTiACc5EmKHJ2LlXwS+iAbb+WZnT UvobjGnORpidfDiQj/PX0z3Y7AbL+9EuZMWPIAfO5v9xZcL16crgb7EBQnw9/gSP00cBIjytxzzm Z32H0fiJ750U9QmN0KUQyuPRrMgnIckjpe0heZ/02muvtWHMx8AhD1gOUydoI3ajkfkCKfvf2CdH 5QMCUf6mG4D8GfC1eQdGqz176BR7bQc4ZJUZk6I6sd8muLJJXSW9T6p/+ioHI3spzN1r/vowr8/D oJSkz3ZgvijcOGGASrtykbYHY72ccLpyph6g/c3e28P6f6UxsFc7sfc34huhUL9x/nFl5PuAOjAj TzIDzE2qMFurDLCQNoWzQsD2/VnBZYUzCAIR7XvMd2RWUTMlc5YUVdoC1Q0meGSyg+Q4v9/kSOXk jIxmoigEVBxmS8f0LqlDGgK0F8dli59UmUjfh+tXyciQAh+CoPPMaFybEN5ZYXayy4dA7xT6E+1C YZicHaGYH1cvuauk3tjZn9b80ITkUEja4DpKdPfxxx83QiMzjOhO0SJkneYjuGxyz9J8YAqVLRSO aF+KwChJS+T5sCTXlr6npD1plFj36OB9ovbQRuTSXoGZ263nUIfMe2AoiuPHkQAzlyQWmABh6TS8 Z3Ab4foPLpvUcyTjTKpu8Hv9dlj/ImjMTvh/I25vBJdPx8+/4tsyN7nxG2GaHEJp43tE/6mkjaHa KAyBVEPA9n2qQWkNpSMEItr358JEpCMs0t1QHROBZuQf6W7wF3HASTERF3FImb3riJgIM2fK7NvE 5m8IGAKGgCFgCBgCqYIA0umdmNrMSZXGrBFDII0jYExEGl8gG54hYAgYAoaAIWAIpA8EWrZsGasz fYzWRmkInBsCFp3p3PCz2oaAIWAIGAKGgCGQBALysUjik73OoAhozRUaV1Gx/KGBM+h0M/W0jInI 1MtvkzcEDAFDwBDISAgQLWcI4THfILrN6zqJnDOYaEIPuTCnF3KuOBZfghP2gFB9Ej3nKhw3h7lx 6oqT8PNKtiZn2lB1InmnsKPyS4ik7LmUIcpVWUK39j+XNvx1RWwTjagxIUN7krW7k7Jmu+9yICep XDtFZMI5uRVRpwq6b+5KSNx2ZEoOhE5NaXvqV0nc2DM97rnnHmXKdl1EkWX6WiJGdeW8j0RwVwY+ /HFDJu2SRLp6EOf7e8GnJtGMbsWhuh8Rs26Rg3Vw+Yz+zH4eQDSnwJpkxPmm+IeaEcGwORkChoAh YAgYAukdAUKcvgUR+VedZF1+PiEhIfeDDz54d1qbF1GV9rpx6kqm6neIfNOAjNGBvA9nO2aiFpWC mK13tvXOtjzhS38jC7UX8vRs64YqT5K5WrNmzbqOZGaTyV69iEzInR0B2rZt245EeDpNjoXxRIc6 gbnUQ47RIvxsJRiI9iTou5Ewvnlc2ylpTyGAybHwADlDlpBEbxL5ECoTgaq52lSmaUK9toeZWU5Y 2R9hAjsQhras649cC1cMGjToFkLhjiby1yjqLWMtxnD/FlnMd8JHtHZl7ZpxEDAmIuOspc3EEDAE DAFDwBBIhAA5Io43aNBgASFJA9JrEsXdwPt+OkkC1sBVUAIuYt0/Qiz/V0lK181JtiX5ljZDWg4k y32Ir+9JycmjULxq1aqdSUrWoEyZMo+pnQEDBlQitOrTnE+R28BLUOfaT+6qkKnkX9hEPgFvrEn1 C7NRShJx196///3v0oRB7azxcN8Sxqks0vC79F3Sccb2OCE5B5H7oSPfcrt6hIftoTru2X+VFkXJ w2BussAwNCJh37PkBRiorMUqB4FcrEePHnfongRxN5Nor57agzF6CbxbOyL/H//4R3n6vVfl3CFt CXU84ty9o70aMAvTyHS8hlwdi5DorwD/KkqGt3HjxvIQ5+PJcv0bSey+QapfVG2oLqFrS8JYHEWT k+Da0jUl7cEIVEMTsmbEiBFzlAWafTIFRqKG2vvggw/qwwhMIcfDLyTMWwv+i1mHOvqmucJk3A6W o5Qkjj3RmyzWpcDtFkLD9iLXxHyya5dQckOVhxkpD1YPk+H672Sz7uoyPif1XntL2dO198j38Ry5 GULuK4UDxrH9Hq21EgS+9957ZdTfXXfd1URrr3sd7JVO5M6orXsYn6vVPqF/B2kPKRyw3jP2xqqn 8UmjQG6UvyhRIP33ZxzPaM+pXLi113d3hNuHroyuyvQtDZfmwB5uo2SDei/Nj/agfoPSFEk7pfeR jFN7+c4772wanFhR9c/1MCbiXBG0+oaAIWAIGAKGQBpCgDwJOURQ6RSxM2XKlDrkFFiqIcokBUK0 GZLmcUiSPyCrcD2k1h6hCNHUlYy7Oyk/mOsuynRQHTIkd4Uo2waB9ZwSwD3zzDPd5s+fXwBiNufy 5csrk925Srdu3b5XHgIk1F0gfuZD6I0ni69HqKmNJI4sbpySgjO2yhCbpSF4Vqp8mH5zUc/LCK1y jCMXjEdxsm/HkQtiBgzM1qFDh04Ww9ClS5deSM8XQ+DKxOskRG0n1dHB8/Fs2bIppG7gkDmPGCi0 AX3BMa+IdeZxPVqH4RCcI8l50FDviMCUe8uWLaVUkTwEMRCJt6FF+B7Cehg4XQUO1+gbRPUp+kmU ywGiuQAJ9a7Wd3eQyC4bBOJJ94z2KNfmzZtLkCBPofizQHB7dkVkyM5G2ewwWN788T34jjwOn/Pd y4jt6qekPRimrMLItUGujZx79uyJEZNAFu6iNWrU2OK+lSpVKg7Nh8fIgElM8eLFd5IA8AgM0HXs tSUfffTRTNZhL/tmo/JkYFZ3iIzVHoFOpue7yeg8ZcKECUOU8BDGqb7aTeo9OJcF8zokO3yPffY1 DMs9oXxtYHLaM+Z89D2cPfQTYWMf0Z6Esf2FNamkTNbs6evWr19fDk3PAplqweS1Yo9MRQv0isbw 5JNPNtKV/VWYPdOcHBiLWNfPx40bdztn/SFDhoyEAVrH+t6qcuHWXt91JLcPfy8VFSVin2SIXelv vObAOMvAzDVUlnjm0BWcxsE8DIDhOQgz6zFFkYyTdThK3pLSJAEcCJPVwWm4XL/ncs10NmrnApbV NQQMAUPAEDAE0joCEEKPcQaGCQG3D+J4ul4g3a7fvHnzmRBUK/QMATgdk5PqEGmbRawtWrRoWHR0 9AmI4m8xWzkKoVcMQqkcRNY7SGwTkFYv/OSTTxoika5EpuQtZCLO/u23376vrM+YIVXFB2ITUvOp ahvGYBqEX0vdy9EWAs+TqpLpeJveQaQXhlkZqnt34A8wh2zIW2kzyX4h8ne58v6rEskhJd4PMX4M QnY/hGpdZapmLtNUjkzcXyFBHwzhlRPC6hgM0Ht6DzGcAzxqQTQ2IP9GVjJuzwKPj/FBSECKfgWE ewEI//wwW+sgpF9njglg4hHEqq+jdu3acySh1z0mWd+hCbgGpmOJskXr1Ptwh7RFjLMROMZDdBaE +L0aAnydsj8LU4jGFhDAP6EFul6YQ0TnSu32yIa9CIar5VNPPVUNyf1OxiOfiKzyZ4CZiEYSnuD6 JAv1HpgXbwwQtsXIfB6vbxDC1ZCmf677pUuXlmFey0Wsy6ROydmUCJAEegUg6ouDy1rWeRSMY26I 5pah3qsdHRDQ3yjhnU7WqRbakgowqqt+/+rttTzs3etg+AbgNxIvrRYZtm8ggd01w4YN+xVGYTxm fq2VdRxm9WOYnuNad/xnxmhdxZSA8y6S513m2gT7hTCj8/WMluQA+3YWTMwmZd/u06dPgBlNau1d OzAG1cPtQ1cO5qgWmsBVL7zwgsfwg/lYtAfR7MFa4L2BPj3mGub/G34nLzutWnLjrFix4mHW4n1p 9tiTN8CYPIQgYDearxn0tcgxqG4cZ3M1TcTZoGVlDQFDwBAwBAyBNI4AhNNQCLJeOqdNm/YcDsyn ML1ppmEjQS/25ZdfNodweFnn6NGjb4O4L4BZTDTmOrvFQKiczKAg1iYtWbIE64oiO8VA6L0OiEms LOI8cwrqxIuB0HtMWK7A/n297nUgGd7o3fAPBP39mOM8rRPi3auL6c8eN07G9ThMyHsLFiyoLXMl CMKw/bp2dUVaH5KWwQyoaGxsbEk3VxiAfjAJWWBuEjEAEGG9P//8879ApI1lXi9C0M4QA6G2YcZW 43MwByK0t8xakLRfD+NzVN/8B/gEwrpCtO2G6Sjv/657GJguMkmBcL0XRqaU7nXKnwBzlbkwQLsw 23no3XffvQli/mf68TJi8+0zmIpyaIp6Q1gWRAuwgTEH+gvuR88paU+ZsTFv+wozoNugMx+EOF7C Gu0TwwVjdhxiP4AbzEAuxu4xc0jm94JbIfWbN2/ew9u2bcuPGVRhYYDpzS60As0qVaq0Rt9p7xTM 0Gj2VmP22hC0TW3QdKAQyhYV6r3q6IBhDcwXnOJhasv9/uX3f9l7RbW27Lmn3HrDFF8Go+DtNZlo 8T0KYj4eAtojxhn/ccZZmo3WH6wHzZs3r5K/TfrZ657RppyAMd2hZ2mXOAJC+OTWPtJ9CG7RrK3X h/phz20W0877IuypTXqnQ+vEGI6yJ/LrOdJxirEG94ms1XPspRkwV23ZZ/eqjZQeIX94KW3M6hkC hoAhYAgYAobAxUVARA6ElHdKKsv5I6YxJTUq/B0Sunfv/imE2zM6IWb7wmiMuOGGG3ZKEnz06FGZ z0hLkFV26NTdzn0h+QbovQ5Mh2IwWTpDuo4kNw6ivfDvpaKiIMqKuXvMYQZDxPXSKYm0e+/GKebl lVdeWQjzshUn4ZLJ9SuC0bWB2cclIhCDD+zKEyBwV7q56orfR38I0j3+shDOU8DlMCYq7RSRCOI3 4KBM5uncaG++YV59kIZ/CvFaC1OYyv76ukdbEfC1wNSrJMTy/uAySPi/79ev3xjs6KfBkOzSvU4c pbeKsYK5+xSs+0KsvwZjlBP/hJ2MOStjO4nmYyh99J09e/YosIxp0qRJgNgM7kfPKWkPojQvzN5S GJWBaB8GwET8BqHtMTJiFsE52vXFfopGU+KNAan/Ngj2kpKMox2YhP9EI+baFJxGwTC1hUEsCLP6 vepK4o+maYP6QEv1OvPMAfPQEg1BVKj3rj/2aQBf7WUI50T4ogk5AqF/ijE+79YbDJ6FUJ6lNli7 6jDT0jqVRCPhMSB8K4+ZWlPWd4Rwh6GZrjLukDO7uw93TW7tI92HWm9h5fqSNk4+NWgndvh/V/Jd wuzsGD47cSob6ThVdu7cuYWY5834K7WGOdzKfp+t9yk9jIlIKXJWzxAwBAwBQ8AQSAcIQAgehDnw TE8wBVqF+dJ1cnLViR9BR8xYmhCRZw+E7W7MeqppSoTnrIO5yrVI4ff98d5zZpV9NoRODE63AY2D gwDn4qXYXlek/aIifiGKzzrKEgTXAQi6XOH6RQofj6N4NGZD0WJuMB0K9ANxdUqEqcaE2dZqGILL XXhbzI1q8O4xiC5vyHKUlbMppl4LIFKHwMSMxJylNNJz2Y63h8gtBWNRHT+LtpiEnYQgXo6keBOS 3Lxuzu4KcV9Fc4YByEl/VdHOrNM39S0/FN3jgL4FrNchEd4K85Sge53S5GBW0hDi7k6VwySnCOY+ 12BOtgyG8DT1ejK2ivqGhqAuxN8WmKMjek7qSEl79FscwvRp5pdDJxqRRo0bN56vPuRXMnny5DrC W8Qtkv9aMJ7eHpAZWceOHadgBtaRd3H4PrzN97HsoTUwF0PQQvyGKY3HXMIM5YY56SPmDKfgbS1a tFgAEZ6XNZNJ2Bnv3fwIGVtd9xD9MUjmy+Cz4jGxMAfV0Frlh+ncDeO2lzXy/Hu0T5HY92MvFpe/ DfXbMJ5PYXgmwtx4PhVo30qIkKatOK2d9lEoZtSNIalrUmvvyofbh2II5Kuhsqyz9/uRb4SYefZG G/ArgPZuCfvySr1XOeZyLYEOVrp9rHfJHTLLY1/fz++8L78d+Y0MYw2Gof1bnVzdcN8D6phwheyb IWAIGAKGgCFgCKRPBJDuH5IE9g9iajKE4kPYWL+ASUYWJLhb8G8Yo5lBoH6NuU4XfAdayq8A+/uR ei9nagjtzhDVzTF9KkSkmokiHPXNf0BsxyI1XQMx2V9mMBCPy/zfI7mn3mGcjitQdmZS/UIwxuPE uxqn1/4ywYKgWgtB5JnaYM6yCUlzCQj1DhCuo7CLn0H552WTLuk+9ukfunFg594FAv41Z44le3fO kZhw5YfQrItj7gNIbl+GoWkGhgM1J4j6k9j8z4dBShT/XxGSwPI5JOo5Ydq249DuSd4pdxlS3ztx Gl7i+g11hWD8CR+BTphR9ULTcykMxHg0Jp45Df4QkyAC2zDeYxC7eZjTsFBt+N+lpD35bmBvvx6z q8dh5AowlvWM/We1i4nTdPwkKoLjIAjcvGiiZvl9EnA4/h8mQQfZW92Zfxz7K5Y9VxitSRGYg+V1 69b1tD8QsofYF0tZs8FE4tpIP/loZxwmP1eHeu/mBFNVgXZroMm4hP31nRgQfcOPoDOM3XAYy7WE u/0Yhu1+/G8aqxx74TsxbnImVtQvnJOXgt9yxlYLCXwz9vd0zNgas25Pwxzlwn/jFwINNHZMn+s7 uWtSa+/qofnbmNQ+xPemNONoB7O6SL8fokEtBcPn5McEntvwYVhE+6cxE1yF9ul5xvobmBWEkfiX az+5K4EUSsCE3qWgAzBVH6ExPJZcnUi//3+9TaQ1rNzFQEAqNVuri4G89XkxEbB9fzHRt74vFgIR 7XskprUYYM2UDFKOrtIWqK4cVf1tyNwEqWd+v8mRviOpz4lmoijEY1xyRIg0BGgvjst22992Su7D 9aswl0jkD0Hcn/K3DZGVFWYnu2z59R4CNB9S58IQUTtCMT/+uv57SYNFwAkTpPAxMEgHQ82Jd50h YtfJDwFJe55g7PxtJnePNLwIDJC0P55viisvSTn4Rwevl/ue1DUl7cmsCdO2bKHmKs0KuMpMLElN iOrja1AUxiFOTr2hxqY9gkQ8hxyg9R2GDVee4T2D3+sb/hJvsn7PorHIDsNwxK2rvgUfcgKHEYiB GN8nhiX4e6hn/RbY1/EyrZNJFtqwE843KFR5/7uzWftI96Hwg4k/5fxyXH9yjEbTlQcmKlb70r1P 7ur2cXLlgr7/imnX3KB3ZzwaYXoGJGnyRUT/qaTJkdugDIGUI2D7PuXYWc30i0BE+/5cmIj0C03a HLkjJHEI/zFtjjDtj8oxEaFG6piISJmCUG2cr3cZeO0jYiLMnOl87Sxr1xAwBAwBQ8AQMAQyPALY vC9E4p7IWTvDT/oCThAN0iTMyVLNBCc1h57Z1940Eam5m85fWxFJps5f99ayIXBRELB9f1Fgt04v MgIR7XvTRFzkVbLuUxWBcJqIVO3IGosUgYg0ERadKVI4rZwhYAgYAoaAIZBOEFB0nbFjx14qO+x0 MuRMN0yFkiUxX0nZwGe6yduEMwQCxkRkiGW0SRgChoAhYAgYAlFRCp1JdJ37iEbzInkeOnH/Ik6w D8sJOaX4yBGbKDcN5LCckjbOtX64PolSU1bJwsKVCf5GSM/bOFvqPU60L4qQDy5zrs8KJ6ucE6Ha IQpSba0JeRHuxI+iGuY69xF1529JRQUiOlQ7chkkigalsqxtV601Dt1XhupH74gMVAdTq+4qS53K bg3lgEwSuKYaB2FZ71Ko0VBtKK+A+ieHwaM49LYgWVlxV47IQjGEDG1DGz1IXtbEn0vElfFfQ83D jQ/H9Sg3PoWQla9B8KkM5P727P7iI5CiPwgXf9g2AkPAEDAEDAFDwBAIRoCwp12VMIv48v0IFfoK MfWfVk4CchB0Di4b6bOIw48//vguoumkyI/yXOuHGyehPn8jd0CyIU+TagNC+HUiHnkRgpIqczbv CRlagohDzZWXgEg/gWR7rg2iAN0FAZ+HRGgjSCQ2gUR3Cwkp+86YMWP+RVShKn6GgJCllSC825N8 70bCpQYS4BHWtALhXtuTu2E5oWB/JDxoB0KzlnV9uKsSrMF83EKuh4WErp1B3odbe/Xqdb2+k+Du DhiEazEjmkzEozgYhMccg+Hq60pivO5cspB/4UscnE9C9Hv7SPkwyF/QnZC2WRjn18yhAm3c7q/r 7pOah398RFOKcuMjKtFhwpwu9p8kkStH2NM06Rfh5pkZr8ZEZMZVtzkbAoaAIWAIZDgElByNePuX kx14LI6oxzXB4sWLHydnwdjq1auvEjGvE6K5BWFRX+J8ESKxuTQFOiSVljSYEJpPk39hINqH+npP +NIHdaWNJyBmc0g6LQm46iOhfuTVV1+9Qt91kEPhGmkGkPAPgmBuI7Oq4PrKwkvOgXt/rxH+XyXY gpi8XeOGYWhEroBnNTZyJzRRTUKYFuvRo8cdumcuN5Pwrp4k45ofcf9bKzSqviXVJ0SxpPCXQMSX rFGjRkdyYDSl/QHKHeCX/pNc7wYw7acTwr+B2gx1QExHk405H/kU4oO/S2tC6Nm8rM908nFcxRy6 El60PPkgOkCkN+H7VyQBu9HVI6xpSeUgIIFegnunKxmh65MDYQr5PX5B47GWtViMRqOOv4zuya59 JcncfhgxYsQcmId1OAH/TAjV6gr5SQjWesz5AyW74/pDQkJCHkKsBtZR9aXVomwe2hnTpUuXzeQa mMn6/1nmV+B5NZm0jyipnHIxkGNkKgnertc6qa7/SGoe/vGRE0HJAb3xKW+H8k64E+YmJ0kSV8A8 zROD5l8Xfz92f+ERMCbiwmNuPRoChoAhYAgYAqmOABLrSyFedwWHwoRgP0DCqe8hRk8jua5Hht+r kHoPgRj7B0RgzUceeaS2BoPmoiQMRzOk3B9DrE1F+9BGTAPJ2z7Td96PhIg/3q9fv/rE0d8PEfgK pjhzIS7vFiMigp9kbl1pbzzE8HCkx2UgLhsG1ydh2ynGkigPgtr3HyS3uxzCsRtmR30hIvPKdIaM ytejdRhOAq6REydObKh3ZM/OjdallOqSoyEGgvg2+v8eonoY/iBXIaW/Rt+S6pO6pdEM5OTMtWDB gpqxsbGFIPLfZn7xJCdroboyHQK/Zk888cQ4JP4fgF09iHIvM7K++w+S1C0nn8PnEMKr/e91P2HC hKvQACzQPcnbmkK0j/7www9nwmgVgVFaDvNzmFwI+fVdB0nTvlNbaJIS5VoggVtRGJ4tv5eKipIm gXWKcc/uSvvfgONP7pkkfuXZG+sg9qPB/6hLZqfvMH67yN6dqA3lKYAhGnjixIks7IvSaB5akaht rXI/4M9RjPvAGMiNEQfDkQ8Nyxk+OEnNI6nxufHqKjMr9mELkt5N0DNZmrWHe9L342RbruqYRH2z 48IjYEzEhcfcejQEDAFDwBAwBFIdAZKi5ZF0OFzD2J7Xvf3222eJgISgjUWiPRNpfoAghjiegIR8 m4hbzEf2T5s2LYaynlRdieYg4qKov2zUqFET0DAcwNxmW3x8fAnMW3IhKa5FQrZVL7zwwlIlEYOh GIumYldwfWVGhjj8b/A4xbBI4g+j0heznrYwP2uQevdX2bVr1xaCwC4A8ZpfUnXm8ToZjvcHt0F2 5DmSzqNR2NG2bdvvmJvHRCTVp78+Cb6OUH4cjFEsZj5TYSg8+3+YrfpIyWf27dt3hbBB4zEdDUJ1 5p0dZunPOsXQ+NsKdQ9GRTHb2T1//vwCmIYVpp2d0gow7xIwW2vIFF4WP4AVoer630HYR4NRQDsB Qb2HbNy5/GV0r6R3SswmXDF9aod51WV9+vT5GWYiGg1Hon0C87kXfHMGt6HnzZs35+7du3cXmKw6 rO8maRswk4tmfwTGwD5Qdu3TMERnjCNUm3rnHx8MaJQbn7882az/gs/GHHA7qPeYi31HAsL+7K8f WZdGaNoG4tvRzAII+FG7cPcpsm+8cMOzngwBQ8AQMAQMAUMgEgQg8OIgrErJadaf8Vi27hDe17/2 2mtzIF6LIN3f6NpTHQjngPSbZxGD3iFpNYxJDvfsrhCRWWEoukNI/hkibrt7L8ISqfgO9ywTGO43 i1B278JdYUp6y3wGTcdo7OXX+Ms++eSTq3G4nUObvdE0HMShd864ceMm+cvovkyZMrHuHRLz3ThN N3XPyV0xgTrgMgGjiTiKBN6bO9qOYl9++WUZNAJ/URtoXbJh1rQTwrco0vmn9Y55b4DYfkP3SR0Q /ntXr15dCKI4Dl+C7Fon/AWqkkV7L3XzoLFpBiPmaX2SakPvYXaOw5AEJP6sby7a3hWqDhqUEjBm PRjfZjIe/11aBAjuwkjwA/VVD9xzli9fPi5UG6rDWAcqszN+D/3QSK0Ap2PsjUAbaEdywGCeJEv1 WeXLcONj/FFufG4MaJZywUDWRgM12L3TVXsbc6p5OmWGhkaiLXvnZub0hLRt/rJ2f34RME3E+cXX WjcEDAFDwBAwBM4HAmcQS0j8eIqKdQAAIABJREFUd0Cc5sD0JJGTLczD1Zj/1IUwPhETE7Md6X5h NyBMWIpDPG5wz5j9nNGu+6arGAKI/PsgJudg39+HqE/D3Xe0DjshuAu6Z0XZkS+Ce07uiq/BFDQp hzFBaqfIRgqB6urIPh8G6Ru0A31gMD7FlKoWpkOV3Xd3RZqe290j8S8JY3CGtsJ9D77ikB5y7owp Ad+JTyFSn9GJJLwvGpoRSMB3kK+jl87kGAj1hdZn+fjx42v86U9/OkY0o0n4mPSAIcsG4f0/tDvd 0Uz8Iu1E8LiCn/HZiMdULNq9p+/oyy67LMC8ufeYXRXFofohxj5+6dKl74sZ0De0HXvoN7c/tCxa lSIwNwGGUOUwCSslPxHd64D5jCPq1wYYoSL4MMTDOATGgFlcEfZXLIzW7w42v1cJ+69/fPjpRLnx uUr411yHb8pWac3cO3cVA4a2qCZ7oT2McaFWrVpNMAbCoZMq15C/heCWjYkIRsSeDQFDwBAwBAyB tI+ARxD6h9mkSZPdNWvWnD106NAWOPh62gUcaAtje34Hpks/qizflyKdryVTHPkx4EdRqWHDhiv9 7QTfy4SJ4xSmKjkxK8orKTaajaUi2pAC13LlcbBdCoFZUb4RYjZw2m2Dz0EBf32VnTlz5iXyM3D1 3BX7/QUQ6EPwsRi5cuXK0tjvD8Tkpb0cxmEsqmNm1BYTmpM4IS9Hsr6J8ZyRX2H27NlVGF9WRQ+i n6r4JqwL16frO9wV34xVSOGvE2Y6wasjc/Mcu8PVC/4mMyu0G9nkmI1PxE8wAsPk9IzPwGSYouH4 pAQYsOC6/mdMkxZjzlVHZkVi1CDga8EArFcZOW/Lf0H3MHs3gd98CO1lMmnSqfH/YUa0CRy9SE18 r3b48OH8RPbytBl6xm8mPwzNdvZRZUWDUnvqi/UphWnTYvwSlqIpKCczLrWL6VozmFFvDPJjwPSr iuqEO/zjYy5RbnyuDg78V7Jfl7lnXdFKyH/kdpiYQWBQk7Cvk9kHA8mJMtVfzu7PGYEz/r6EatHM mUKhYu8MAUPAEDAEDIG0jcAZkmcNF/v8L5DK3kPEnsFESNqHZL4gUYp+gLGYo++YBc2FOOyJ2c8A zGKOyqEWojCsHb6YBcycVkCoPrNmzRoR9nMg7vrI4Zf367G734RkvRXE4xhs15dC5D0Hsb8PQm8b TtCLgutjGnQZjrJ3vvTSS0s0puAD6fkmzpFihNA21EXi/AAE5cvY3TfDjGgg2oV9aExOIqmeT1uJ 8icomhHS6+fQyOTERGY7BPX3aj+5PoPH4H+GMJ/MnB7C9+AFGK8stL+FyEhj/GUivZ83b96HhNtt Dm6PItXfjvR+vxzCWad85PXwxppcWzAg0/EXqYgfwyCYtbyYls3Cd2CV6jGu+nnz5j0iUzK0N2XR xhRnvM1dm5ifbYZZeRXG8iOYvl5oNeoRmSkf6/Su0yLANHSGSRsupgdfkKnsj8dwMpepUxa0L98q epJO8lxor/1N+0j+M6z/m+oHxqL0G2+80Q7Gb5HrN9Q1eHzsiTfc+FQeTVQFTLFm+Oved999ncBu I74RCs0b0vzKX97uU4xAyL8vwa1FZKcYXMmeLzgCUivZWl1w2K3Di4yA7fuLvADW/UVBIOJ9jxlN K0YYMlGaTFWQJheG+I2VGZN/JtISIMWNgbhMkFTa/y3cvcyLkDZ7DrnYrxfENOoYzEiC2kOqnleE peqrbwjLU4ru42/PX9//Prl7tS9fBWzws2ncEJEHMck5EFxPycmwjV+HU/ZcCPM8ZzO34LaCn6W1 kU+A3qcG8ar2CLdaBPOs3JiG7fT7sAT3ndSzNDowcAlEdUrkJJ1U+eD3bh9IA+EYiOAyesbkLR9r ml/O8sHf5beA1khajN3B387mGUYRvmZ4z+TquL2QXDn7fk4IbMO0b3wkLRhhGglKF79MxP+pXPyh 2ggMgVRDwPZ9qkFpDaUjBCLe9zARhZhXO06zKgAEx0Rgy++ZbqWjNc/0Q42Uicj0QJ1/ACRwGAMT EZFwwf7wnP8FsR4MAUPAEDAEDIFUR0D/0cNITKPhxpyZ/v9zTG8W4px7VtGBUn1RrEFDIP0iIAZi WqQMhKaZ6f/opN+1tpEbAoaAIWAIZHYE+A9/DYyEwpqKkQhp2pRZMCILdFgb/MyCg83TEEgBAtuo c1YMhPowJiIFSFsVQ8AQMAQMAUMgrSDwh+RwPMxEEcZUglNRi8xcOa0skI0jWQTwsVEZ759kC1uB 1EJAppOKwrSDvyHn5NOSWgOyds4PAlpoOwyBzIaA7fvMtuI2XyFg+972QWZEwPZ9Olx1yxORDhfN hmwIGAKGgCFgCBgChoAhYAhcTASMibiY6FvfhoAhYAgYAoZA5AjkpGjZyItbSUPAEDAEDIHMjoCp +TL7Dsic87d9nznXPbPPOtS+rw4o/+KU/fLRzA6QzT9DIhBq32fIidqkDIELjYD9uC404tZfWkDA 9n1aWAUbw4VGwO17OUk/ybmBU4nVjnPq215OOwyBjIaA2/cZbV4Zej4WvSF9LK9+XLZW6WOtbJSp h4Dt+9TD0lpKPwi4fa/rQc786WfoNlJD4JwQMDrnnOCzyoZAaAT0n4kdhkBmQ8D2fWZbcZuvEHD7 XpqIv3Ku5zRNBCDYkaERcPs+Q0/SJmcIXAwE7Md1MVC3Pi82ArbvL/YKWP8XA4FQ+14+Ef/kPMV5 7GIMyvo0BM4zAqH2/Xnu0po3BDIHAvbjyhzrbLNMjIDt+8R42FPmQCDcvs8BBJdlDhhslpkMgXD7 PpNBYdM1BFIXAftxpS6e1lr6QMD2ffpYJxtl6iJg+z518bTW0gcCtu/TxzolGqXliUgEhz0YAoaA IWAIGAKGgCFgCBgChkByCBgTkRxC9t0QMAQMAUPAEDAEDAFDwBAwBBIhYExEIjjswRAwBAwBQ8AQ MAQMAUPAEDAEkkPAmIjkELLvhoAhYAgYAoaAIWAIGAKGgCGQCAFjIhLBYQ+GgCFgCBgChoAhYAgY AoaAIZAcAsZEJIeQfTcEDAFDwBAwBAwBQ8AQMAQMgUQIGBORCA57MAQMAUPAEDAEDAFDwBAwBAyB 5BAwJiI5hOy7IWAIGAKGgCFgCBgChoAhYAgkQsCYiERw2IMhYAgYAoaAIWAIGAKGgCFgCCSHgDER ySFk3w0BQ8AQMAQMAUPAEDAEDAFDIBECxkQkgsMeDAFDwBAwBAwBQ8AQMAQMAUMgOQSyJ1fAvhsC hoAhkN4QOH36dBHGXIIzL2eW9DZ+G2/mRaB27dpRc+bMqZV5EbgoMz9Nr4c5d2TJkmX3RRmBdWoI pEMEjIlIh4tmQzYEDIHQCMA8FOJLY86SoUvYW0MgbSNQs2ZNDdD7J22PNGOOjr8h25jZNJiJfRlz hjYrQyD1EDBzptTD0loyBAyBi4gA//lfTvftOC8oAzF9+vRLdJ46deoizt66NgQMgVRCQH8/2v3x 9ySVmrRmDIGMiYAxERlzXW1WhkCmQsCngQhoVz/66KM/V6tWrVO5cuV63nvvvQ2WLFmS34Hy7LPP Xlu5cuWunPe9/PLLV7r3e/fuzX7nnXc2vfzyyx++4YYb7vrll1+k2Qh5dOvWrW6ePHn+fscddzzW qlWrR/PmzfvqXXfd1cQxE507d66vdvyV1WahQoUGTp06VeZWdhgChkDaREB/Rxr/8XclbY7QRmUI pAEEjIlIA4tgQzAEDIFzRkAmTAEGYsOGDbkfeOCBnkWKFNk/cODAL9asWVPytttu66Je3nzzzQpv vfVW++uvv355165dfxw8eHCHt99+u6y+tWzZ8o65c+de27Nnz8mlSpWKu/nmmx87ePDgGX8nqXfD J598cgv13obxGLBnz54XPv7446GTJ09uCFNxk9oKPurVq9dm+fLlV06cOPGNJk2amN11MED2bAik LQQ8RiJtDclGYwikLQTO+M8xbQ3PRmMIGAKGQHgEkBZKqp/IhOm///1v2WLFisVOmTLlC7QQW/7v //5vwsaNG69YtmxZvg8++KD+LbfcMuWf//znL48//vhatBGL//Of/9Q5evRolp9//rnemDFjPnjs scfWcf0hISEhz/Dhw68IHsFnn33W/J577pnQpUuXze5bmzZtdtSpU2cujETj48ePJ3LmbtCgQeuV K1dewXjerFu37l5Xx66GgCGQphEo+cfflzQ9SBucIXCxEDAm4mIhb/0aAoZAaiGgKEyJjg4dOmz4 6quv3nUvYQgqoJXYcc011xzatWtX0Ro1amxx36Rx2LlzZ8yPP/4YnSNHjqM33nhjgMinzq4VK1bE uLK6yizqwIED0Xffffca/3vdt27desmxY8fyzp8/v6D71rBhwztnzpzZEOblveuuu+6Ae29XQ8AQ SBcInPH3JV2M2gZpCFwABIyJuAAgWxeGgCFwXhFQGNdER5kyZRLwh/AIdrQNNYYNG9a+Y8eOk1QI 06NotBQJrkLp0qX3QPjnWrhwYXSuXLmOuPe6XnLJJXsPHTqU0/9u3bp1+fSMr8Uh/3vdo4mI0zU+ Pt6rs379+itgOq4pUaLEb/37979Z3+wwBAyBdIXAGX9f0tXobbCGwHlEwJiI8wiuNW0IGAIXBIFE pkOuRzlJo3no9uGHH96CH8QIzvn6ljNnzuNbt271GAE94/OQC6ZiV/78+Y8fOXIk8F7fMHHKWb58 eY8x0LMOtAmepmLkyJHlfn/z//8dPXp0BZ5Ow0zs0VucrQ9+8803/+D4CGaiOozEtf+/tN0ZAoZA OkAg5N+XdDBuG6IhcN4RMCbivENsHRgChsCFRgBmICuEfNcCBQocxMl68EMPPbTBjYHoSPFoCKLd 8+bNm6Mvu+yyHWgu9uDLkHvVqlUBySMahSJEVNruyuqK+dPR6OjoHdOmTbvK/173+FRU4Pt6vp/Q MxqIbYxjH1Gbtjdv3nzyG2+80Q4n7zz6ZochYAgYAoaAIZCeETAmIj2vno3dEDAEQiLw6quvXhkX F1eMCEpfyGEan4ccOhV+lahMi3F+riPn52+//bbYTz/9VAtGYX2tWrX2XXrppZvQFlyvRv/6179W O3z4cP6mTZvuCu6kXbt23xH+tc7f//73QHhYhYol03CdHj16TAwur2f8Mibnzp37MHXbhPpu7wwB Q8AQMAQMgfSEgEKY2WEIGAKGQIZCAAK/3O7duy9Fw/Caf2Lffffd8++99950TJIq4u8wCAYjL6FX Z/3tb39bpXJEYvqIaE690FbUIzJTvkGDBr1LLogzssgR7WkuDEZOGI4HBgwYcCJr1qyniOIS1bdv 3/8888wzK/19uvuCBQuefPHFF0fDZPQm7OyC559/fpn7ZldDwBAwBAwBQyC9IWC2fuljxU4zTFur 9LFWNsrUQyCifQ/xXosua55tt0RMugTNQwIJ4RI5U0tzgaYiRhqIUAyEvx+VxeehOGZTxylvuR/8 4Nh9ihAgRwm87PCeKapslc4HAr9myZJl7vlo2NpMhEBEf+8T1bCHi46AaSIu+hLYAAwBQ+BiIFC/ fn3P+Tm4byI0nSYx3c7g96GeVZYM1ztCfbN3hoAhYAgYAoZARkbAfCIy8ura3AwBQ8AQMAQMAUPA EDAEDIHzgIAxEecBVGvSEDAEDAFDwBAwBAwBQ8AQyMgIGBORkVfX5mYIGAJpBoH9+/dnSzODsYFc FATIil74iy++KE7oYDMlvigrYJ0aAoZAaiJgTERqomltGQKGQJpBgKRyQ7Jnz/5Gjhw5XteZL1++ wVdcccVDcqi+0IOcPn36JX/6058GhOp38ODBV+G4OcyNU9fChQs//5e//OUO5bsIVSeSdzh8x1yM 5HY4mb/46aefloxkjJGUef311y9X0kDWrsc999zTUGF6dShE7913392YzOE9q1ev3knlgttTtnLV 8b9PSXv/+9//ChAauF3ZsmV7NWrUqNWvv/5a0LUpnPGvaYODfg/ygTTRuNw3XTdt2pSbCGB3XX31 1d2effbZJiQevJ77v+qZaGFF/WV1T/LDKM3X/z5c/x999NGfyXHSSTgQWawBSQ3z++u6++TG6cpF 2p727bXXXtv1qquuerBz5871SeCYKLO7a8+uhoAhkHERSPF/UBkXEpuZIWAIZBQECMX6FkTdX3VC zD1P2NbcDz744N1pbX5ky97rxqnrf/7zn3d++OGHBk8//fR1KR3r999/X4rcFPVSWj+l9SBWX7/p ppsickxPrg8l5iNs7gMQ6UueeOKJSSTzq3zHHXc0V71evXrVmjVr1nWPPPLI5GbNmi0iZG7nUaNG /UnfPv/88xIq984777Rh3YvpnY6Utte2bduOhPE9TWje8TjTn2jZsuVDYvBEOHfq1Kn7yZMnszz3 3HNfQ8BXuPnmm2//vbeoKH1v0KDBgx06dJi3fPny9+6///65r7zyyjTyibz1wgsvTHjggQc6rFu3 zks++Ntvv+W67777bpw0aVIUyRDLuzZ0Tap/Einmpo2eRYoU2c/YvmB+JQkK0MVfV/fJjdOVj7S9 r7/+OoZwxZ1gItYTHnki61Dlsccea+DasashYAhkDgSMicgc62yzNAQyPQJFixY9DkG3YN++fQEp MkTdDbzvpxNCL0AEkWeiUIUKFR4hOdyrkhj/97//9YhTSaClzZCWIyYmpg8ZqD3p91dffVW8atWq nSUJLlOmzGMCm/wRlQgh+zTnU//617+qns0CQADv/POf/7xpx44d3liT6hdmo1TlypW7urb//e9/ l0Yq3Vnj4b4lBHRZScH1HYaiJGN7HE3BIPJkdJSE3NWTFF113HNSVxL45ejWrVvdYcOGlXvrrbfK U+9hwuD+XRJpRwx37979LvC7RGXAu7Uk9+pTUnwYo0Cm8FB9aqwiZF3/JA2shoR9zYgRI+Yo6zjr NQVGooa+wyTVgLieRlLANST9W4REfAXrVEXfIOaj9+zZk49cIPF6dkdK2luxYkW+jRs3lke7Mh6G 4bfPPvvsm7179xaVZB+twtXskSMkLBzL2m9hjFMxWboeRtDTRnTs2PFWNCEzNPa6deu2/ec//1mX PCKN0TJ12bZtWz6SHC4Cp6s1vu3bt+dm7jFg5YbrXcP1z3zLFitWLHbKlClfqH+Y5gmM9Yply5bl 8zeS3Dhd2Ujbmzp1amn20PzRo0dPh/H5rWHDhgs4vMSLYt5ox/u9uHbtaggYAhkTAWMiMua62qwM AUMABDANyQFxllOnCGyIrTo1a9ZcKnAwLbkWgrAZEu5xb7/99gdIgOsh3fYIVMxSupYsWXIn5Qdz 3UWZDqrTunXrriSw2waR9hzE0yQIwm7z588vAFGZE0lzZQjIKhDZ369atSov5h5dIIrnI6kdD9FV W/XDHFncOCUtZ2yVkR6XJnysl7guTL+5qFfCtcs4csF4FIeoi7v11ltnwMBsHTp06GQxDF26dOml bN0wCzLxOom2oJOrx/PxbNmyKU57yEPmWDKvgrEZxFxqlCpV6tBLL710N1LwKRMmTBiCiVEWiPn6 qrxly5bSwiM2NjYfpmMNIIqPILkeWqJEiVhwbOk6CNUnZjvV8BfI4cpAjGfVWN3zgQMHcsIcxEgL gPQ/G8xc4BtaplybN2/2sEArsXzGjBmfw1isdnV1TUl7x44dE0OQxeUMOXToUDb6zg5jVwLGqVjp 0qW3uD7Ieh5H7pB87AWPiF+5cuXlaAgWa4+sXbu2LMzGJ5hTTWGc5cBuA4zoAXDyuAZlTNeYYUZd c941XP8wvhtYz3ddBRjFCmgldmAOdci90zW5cbqykbb35ptvzkP78JkYHDHS48ePb8JeX6h2pLHp 2rVrT3B5HE1a1XMxyXPjsqshYAikTQTMuSttrouNyhAwBFIBgSeffPIxzkBL+EXsg4ibrhdIS+s3 b958JuYyK/Q8ceLE6dioV0fCvBlCuOyiRYuGRUdHn4Aw+xai6CjEcjFMTspBPL2DRD8BqfbCTz75 pCHS5Uo33njjlhMnTmT/9ttv34dwPSTiCR+ITUivp6ptGINpI0eO9AhoOdZCDHuEcqtWrbbpO8xO YZiVobp3B3b+c9q3b7+VNpPsFy3JLlfef1V2bAjU/RDZx2Ca9kOw1kUqH8dcpqnc+++//xUajMFi XGA0jsnUxl/f3ct/gAzfDZGQl4fIncd83lAODcablYzdBWCmij/88MNrGeMomJ6ABsHVB+/9zHcS hKVMjD5HqzBQUnoYg9NJ9enq6oqJzCIYn5ZPPfVUNSTfOxm/fCKywqRkl1aJ50bgHQ+TVBDG7WoY vHX++sH3KWmvSpUqB7WW+F+0gAn6CaL5eq01jvK50CZEM8cE10+dOnX2cn8ajU0urgfF6GiuaAKq gbe3zyC4LytfvvwqMSVz586tAMP4g6sf6hquf+1Dnaon/w/Mt+5G6/FJcDvJjdOVj7Q9V569URHt x92sSQ4YF8+EjWX+jvWZhnlXVX5jjRhTaxjQWWR//ymYuXHt2NUQMATSJwKmiUif62ajNgQMgQgQ IPPvUIjdXjqnTZv2HA7Mp3r06NFMVXfv3l3syy+/bA4x97JOTDNug7gvsHjx4uhChQrtFgOhcjKD Qto7CRMZhLxFdjqiTd8wJYFejPMkydSJFwOh90icr7jyyivX617HLbfcstG74R8I+vsxi3laJ4S0 VxefiD1unIxLEtz3MA+pLXMlmJmw/bp2dUVqHfJvOiYuRZF4l3RzrVGjRj8yfWeBuUlk9uJvq02b Nk0ZxyOYR62BSO+PVuEzl4SP8Z6CoB4NLo3BaQiakjZInM+IPsXA48RA6BCzIik1WolEZlMQvXXA 8VmdYJAP/4bHdS/NB30fQDr+FcTqbZR7sHbt2kvoe5/aevnll+fCKO169NFHH3r33Xdvgtn4Wdoj /xyC71PaHn19BpNSDg1VbzQhBdHEbIC4j8U/4hjMRADDXbt25WCOJzFd8hIZst887Q4M3GGVEwMF ZtXR6MQiza+A1qgYGqPY4HEGPyfVv8qJoZIj9ocffngLbY7gnB9cP7lx+stH0p4rD5O5gDXrw16Z gPanq3N6JzDACRineTDdb2DKN2LevHnXgNeLmr+ra1dDwBBI/wiE/A8n/U/LZmAIGAKGQFQU0ZlO SeKrE9v8eM4fMSXxIgdhy56A/f6nEL/P6EQq3xdGYwR26jshjApgluIRPJK6Q6jWpO527gv5CSGI wBjMODYEY43kOg6ivbB7DxEVcO6F0BwMAd9Lp0xYXBk3TjEvON8uhHnZigNuyeT6FTPg2sAh9xKe 3WPgiklRAj4IK91cdcVvoT8aFI/YDRT03bRr124JxOlCJOc3QSTeLg2K+6xwtWhJNkBQD0TD8jrM Sw6/qZIrB4aSyHsHzFB+cC1Im/vdO11hplb269dvjE40J1qTr3SPadlsmYXBdC1VPxC3A2AifoPB 8BgFMWAwgZ+yJn3RgrzGGHKi6QjLRKSkPbDKyl45CUE8FFOmvrNnzx7FGsY0adJkB0xLPPcBPw+Y xyKsX6zWUnPDr2Yd5kzXoElZzGMWfEcewOxrKutUCga3OWZ0Y1Qu3BGuf31D+9GV9T2ItmiwfC9C tZXcOF2dSNtDK9MEh/ZaqicmEbO+X1nrvM4vRu/FjPTs2bMm822PH1IhtG4TpJXRNzsMAUMgYyBg TETGWEebhSFgCESAAAToQUfYYgq0CvOl6xSzXyd+BB0xd2lCJKA9SFJ3Y+ZUTU327t27Drbq10Ks 7fvjvWe0rpj/aA1icPYNaBzcEAh5uXT16tUVFcJThBnE7llHWYIwPACBnCtcv0h34yHQouWwLOYG Z+NAPxBsp0Tca0yYba2GwLvchbeV6QvvHnNaAp6vk327G7+uMA470Mr8h3m+hCT9EI67j2Iu1Eum RSLGIej7yAkaZmNbixYtFkBg5/XX1z0E9qX4nXh+CvhQ1EIzsaNixYqH9c31idR+L7iv0wnTdxKt xnrdS+uB/0VxNBJPy6FbJxqHRo0bN/Yk7UQ3akjZO9UW5YpgWnUNZmfL9JzUkZL2GNNp5t4Txq6i 2oVQr4smZAtM2RH6WyoTNzlZ79y5MwcRi5phqhTYDzAJEzF3uxl/mxKYLo3CR+JfaFa24h/xf4qm xHok64Acrn9M6q4El2KY1X0hpldj0CmNgIIDsIc9R/Nw4/SXi7Q9mLU4mMr6OLkXVl9aW96tFCZa C9bsdhiXQZMnT64JEziZMQ4cO3asZ9qX1NrYe0PAEEh/CJhPRPpbMxuxIWAIpBABpPuHILJKynkZ W+3JEDsP4QD6AoRQFhx/t0DweZJhCMWvifjTBd+BlvIrwA5+pLqUMzUmHJ2RvjfH9KkQhPZE+R8E D0cmKkih1xDus7/MbypVqhSWuA2ur2fqHV64cGEFbmcm1a+0KxCtq5s2bdpfJlhEjloLYe8xA5hQ bcJevQQ+ER1wAh6FRmEG5Z+Xb4Sk9hC8H7p+ibTUBVOs15w5lnuvK74IBzDBmQgzNBk79yr4RTTA 1j8rc1pKf4MxzdkIs5MPB/Jx/nq6B5vdYHk/2oWs+BHkwNn8P65MuD5dGfwtNkCIr8ef4HH6KECE p/WYx/ys7zAaP/G9k6I+oRG6FEJ5PJoV+SQkeaS0PSTvk1577bU2jPkYOOQBy2HqBG3EbjQyXyBl /xv75Kh8QCDK33QDkD8DvjbvwGi1Zw+dYq/tAIesMmNSVCf22wRXNqmrpPdJ9U9f5WBkL4W5e81f H+b1eRiUkvTZDswXhRsnDFBpVy7S9mCslxNOV87UA7S/2Xt7WP+vNAb2aif2/kZ8IxTqN84/Lrs3 BAyBjIVAQA2esaaV4WYjFbCtVYZbVptQMghEtO8x35FZRc1k2gr5WVJUaQv0MZjgkckOkuP8fpMj lZMzMpqJohBQcZgtHdO7pA5pCNBeHJctflJlIn0frl8lI0MKfAiCzjOjcW1CeGeF2ckuHwK9U+hP tAuFYXJ2hGJ+XL3krpKzLhg4AAAgAElEQVR6Y2d/WvNDE5JDIWmD6yjR3ccff9wIjcwwojtFi5B1 mo/gssk9S/OBKVS2UDiifSkCoyQtkefDklxb+p6S9qRRYt2jg/eJ2kMbkUt7BWZut55DHTLvgaEo jh9HAsxcklhgAoSl0/CewW2E6z+4bFLPkYwzqbrB7/XbYf2LoDE74f+NuL0RXD4dP/+Kb8vcdDz+ 9DL0iP7ep5fJZJZxGmGaPlbaflzpY51slKmLQET7/lyYiNQdrrXmR8AxEWhG/uF/b/fhEUiKiQhf y76eRwSMiTiP4Pqajujvva+83aYBBMycKQ0sgg3BEDAEDIGMhgDS6Z2Y2szJaPOy+RgChoAhYAj8 joAxEbYTDAFDwBAwBFIdgZYtW8bqTPWGrUFDwBAwBAyBNIGARWdKE8tggzAEDIGMjoB8LDL6HG1+ iRHQmis0rqJi+UMDJy5lT4aAIWAIpE8EjIlIn+tmozYEDIFkECBazhDCY75BdJvXdRI5ZzDRhB5y YU6TqZ6qn3EsvgQn7AGhGiV6zlU4bg5z49QVJ+HnlWxNzrSh6kTyTmFH5ZcQSdlzKUOUq7KEbu1/ Lm3464rYJhpRY0KG9iRrdydlzXbf5UBOUrl2isiEc3Irok4VdN/clZC47ciUHAidmtL21K+SuLFn etxzzz3KlO26iCLL9LVEjOrKeR+J4K4MfPjjhkzaJYl09SDO9/eCT02iGd2KQ3U/ImbdIgfr4PIZ /Zn9PIBoToE1yejztfkZApkFgRT/B5VZALJ5GgKGQPpFgBCnb0FE/lUnWZefT0hIyP3ggw/endZm RFSlvW6cupKp+h0i3zQgY3Qg78PZjpmoRaUgZuudbb2zLU/40t/IQu2FPD3buqHKk2Su1qxZs64j mdlkslcvIhNyZ0eAtm3btiMRnk6TY2E80aFOYC71kGO0CD9bCQaiPQn6biSMbx7XdkraUwhgciw8 QM6QJSTRm0Q+hMpEoGquNpVpmlCv7WFmlhNW9keYwA6EoS3r+iPXwhWDBg26hVC4o4n8NYp6y1iL Mdy/RRbznfARrV1ZuxoChoAhkJ4RMCYiPa+ejd0QMAQiRoAcEccbNGiwgJCkAek1ieJu4H0/nSQB a+AaUwIuYt0/Qiz/V0lK181JtiX5ljZDWg4ky32Ir+9JycmjULxq1aqdSUrWoEyZMo+pnQEDBlQi tOrTnE+R28BLUOfaT+6qkKnkX9hEPgFvrEn1C7NRShJx196///3v0oRB7azxcN8Sxqks0vC79F3S ccb2OCE5B5H7oSPfcrt6hIftoTru2X+VFkXJw2BussAwNCJh37PkBRiorMUqB4FcrEePHnfongRx N5Nor57agzF6CbxbOyL/H//4R3n6vVfl3CFtCXU84ty9o70aMAvTyHS8hlwdi5DorwD/KkqGt3Hj xvIQ5+PJcv0bSey+QapfVG2oLqFrS8JYHEWTk+Da0jUl7cEIVEMTsmbEiBFzlAWafTIFRqKG2vvg gw/qwwhMIcfDLyTMWwv+i1mHOvqmucJk3A6Wo5Qkjj3RmyzWpcDtFkLD9iLXxHyya5dQckOVhxkp D1YPk+H672Sz7uoyPif1XntL2dO198j38Ry5GULuK4UDxrH9Hq21EgS+9957ZdTfXXfd1URrr3sd 7JVO5M6orXsYn6vVPqF/B2kPKRyw3jP2xqqn8UmjQG6UvyhRIP33ZxzPaM+pXLi113d3hNuHroyu yvQtDZfmwB5uo2SDei/Nj/agfoPSFEk7pfeRjFN7+c4772wanFhR9e0wBAyBs0fAmIizx8xqGAKG QDpBgDwJOURQ6RSxM2XKlDrkFFiq4cskBUK0GZLmcUiSPyCrcD2k1h6hCNHUlYy7Oyk/mOsuynRQ HTIkd4Uo2waB9ZwSwD3zzDPd5s+fXwBiNufy5csrk925Srdu3b5XHgIk1F0gfuZD6I0ni69HqKmN JI4sbpySgjO2yhCbpSF4Vqp8mH5zUc/LCK1yjCMXjEdxsm/HkQtiBgzM1qFDh04Ww9ClS5deSM8X Q+DKxOskRG0n1dHB8/Fs2bIpxGLgkDmPGCi0AX3BMa+IdeZxPVqH4RCcI8l50FDviMCUe8uWLaVU kTwEMRCJt6FF+B7Cehg4XQUO1+gbRPUp+kmUywGiuQAJ9a7Wd3eQyC4bBOJJ94z2KNfmzZtLkCBP IcmzQHB7dkVkyM5G2ewwWN788T34jjwOn/Pdy4jt6qekPRimrMLItUGujZx79uyJEZNAFu6iNWrU 2OK+lSpVKg7Nh8fIgElM8eLFd5IA8AgM0HXstSUfffTRTNZhL/tmo/JkYFZ3iIzVHoFOpue7yeg8 ZcKECUOU8BDGqb7aTeo9OJcF8zokO3yPffY1DMs9oXxtYHLaM+Z89D2cPfQTYWMf0Z6Esf2FNamk TNbs6evWr19fDk3PAplqweS1Yo9MRQv0isbw5JNPNtKV/VWYPdOcHBiLWNfPx40bdztn/SFDhoyE AVrH+t6qcuHWXt91JLcPfy8VFSVin2SIXelvvObAOMvAzDVUlnjm0BWcxsE8DIDhOQgz6zFFkYyT dThK3pLSJAEcCJPVwWm4XL92NQQMgbNDINPZZp4dPFbaEDAE0jMCEEKPcQamAAG3D+J4ul4g3a7f vHnzmRBUK/QMATgdk5PqEGmbRawtWrRoWHR09AmI4m8xWzkKoVcMQqkcRNY7SGwTkFYv/OSTTxoi ka5EpuQtZCLO/u23376vrM+YIVXFB2ITUvOpahvGYBqEX0vdy9EWAs+TqpLpeJveQaQXhlkZqnt3 4A8wh2zIW2kzyX4h8ne58v6rEskhJd4PMX4MQnY/hGpdZapmLtNUjkzcXyFBHwzhlRPC6hgM0Ht6 DzGcAzxqQTQ2IP9GVjJuzwKPj/FBSECKfgWEewEI//wwW+sgpF9njglg4hHEqq+jdu3acySh1z0m Wd+hCbgGpmOJskXr1Ptwh7RFjLMROMZDdBaE+L0aAnydsj8LU4jGFhDAP6EFul6YQ0TnSu32yIa9 CIar5VNPPVUNyf1OxiOfiKzyZ4CZiEYSnuD6JAv1HpgXbwwQtsXIfB6vbxDC1ZCmf677pUuXlmFe y0Wsy6ROydmUCJAEegUg6ouDy1rWeRSMY26I5pah3qsdHRDQ3yjhnU7WqRbakgowqqt+/+rttTzs 3etg+AbgNxIvrRYZtm8ggd01w4YN+xVGYTxmfq2VdRxm9WOYnuNad/xnxmhdxZSA8y6S513m2gT7 hTCj8/WMluQA+3YWTMwmZd/u06dPgBlNau1dOzAG1cPtQ1cO5qgWmsBVL7zwgsfwg/lYtAfR7MFa 4L2BPj3mGub/G34nLzutWnLjrFix4mHW4n1p9tiTN8CYPIQgYDearxn0tcgxqG4cdjUEDIHwCJgm Ijw+9tUQMATSMQIQTkMhyHrpnDZt2nM4MJ/C9KaZpoQEvdiXX37ZHMLhZZ2jR4++DeK+AGYx0Zjr 7BYDoXIyg4JYm7RkyRKsK4rsFAOh9zogJrGyiPPMKagTLwZC7zFhuQL79/W614FkeKN3wz8Q9Pdj jvO0Toh3ry6mP3vcOBnX4zAh7y1YsKC2zJUgCMP269rVFWl9yL/pmAEVjY2NLenmCgPQDyYhC8xN IgYAIqz3559//heItLHM60UI2hliINQ2zNhqfA7mQIT2llkLkvbrYXyO6pv/AJ9AWFeItt0wHeX9 33UPA9NFJikQrvfCyJTSvU75E2CuMhcGaBdmOw+9++67N0HM/0w/XkZsvn0GU1EOTVFvCMuCaAE2 MOZAf8H96Dkl7SkzNuZtX2EGdBt05oMQx0tYo31iuGDMjkPsB3CDGcjF2D1mDsn8XnArpH7z5s17 eNu2bfkxgyosDDC92YVWoFmlSpXW6DvtnYIZGs3easxeG4K2qQ2aDhRC2aJCvVcdHTCsgfmCUzxM bbnfv/z+L3uvqNaWPfeUW2+Y4stgFLy9JhMtvkdBzMdDQHvEOOM/zjhLs9H6g/WgefPmVfK3ST97 3TPalBMwpjv0LO0SR0AYmdzaR7oPwS2atfX6UD/suc1i2nlfhD21Se90aJ0Yw1H2RH49RzpOMdbg PpG1eo69NAPmqi377F61YYchYAhEjkDI/3Air24lDQFDwBBIuwiIyIGQ8k5JZTl/xDSmpEaMv0NC 9+7dP4Vwe0YnxGxfGI0RN9xww05Jgo8ePSrzGWkJssoOnbrbuS8k3wC914HpUAwmS2dI15HkxkG0 F/69VFQURFkxd485zGCIuF46JZF27904xby88sorC2FetuIkXDK5fkUwujYw+7hEBGLwgV15AgTu SjdXXfH76A9BusdfFsJ5CrgcxkSlnSISQfwGHJTJPJ0b7c03zKsP0vBPIV5rYQpT2V9f92grAr4W mHqVhFjeH1wGCf/3/fr1G4Md/TQYkl2614mj9FYxVjB3n4J1X4j112CMcuKfsJMxZ2VsJ9F8DKWP vrNnzx4FljFNmjQJEJvB/eg5Je1BlOaF2VsKozIQ7cMAmIjfILQ9RkbMIjhHu77YT9FoSrwxIPXf BsFeUpJxtAOT8J9oxFybgtMoGKa2MIgFYVa/V11J/NE0bVAfaKleZ545YB5aoiGICvXe9cc+DeCr vQzhnAhfNCFHIPRPMcbn3XqDwbMQyrPUBmtXHWZaWqeSaCQ8BoRv5TFTa8r6jhDuMDTTVcYdcmZ3 9+Guya19pPtQ6y2sXF/SxsmnBu3EDv/vSr5LmJ0dw2cnTmUjHafKzp07txDzvBl/pdYwh1vZ77P1 3g5DwBCIHAFjIiLHykoaAoZAOkcAQvAgzIFneoIp0CrMl66Tk6tO/Ag6YsbShIg8eyBsd2PWU03T JTxnHcxVrkUKv++P954zq+yzIXRicLoNaBwcPDgXL8X2uiLtFxXxC1F81lGWILgOQNDlCtcvUvh4 HMWjMRuKFnOD6VCgH4irUyJMNSbMtlbDEFzuwttiblSDd49BdHlDlqOsnE0x9VoAkToEJmYk5iyl kZ7Ldrw9RG4pGIvq+Fm0xSTsJATxciTFm5Dk5nVzdleI+yqaMwxATvqrinZmnb6pb/mh6B4H9C1g vQ6J8FaYpwTd65QmB7OShhB3d6ocJjlFMPe5BnOyZTCEp6nXk7FV1Dc0BHUh/rbAHB3Rc1JHStqj 3+IQpk8zvxw60Yg0aty48Xz1Ib+SyZMn1xHeIm6R/NeC8fT2gMzIOnbsOAUzsI68i8P34W2+j2UP rYG5GIIW4jdMaTzmEmYoN8xJHzFnOAVva9GixQKI8LysmUzCznjv5kfI2Oq6h+iPQTJfBp8Vj4mF OaiG1io/TOduGLe9rJHn36N9isS+H3uxuPxtqN+G8XwKwzMR5sbzqUD7VkKENG3Fae20j0Ixo24M SV2TWntXPtw+FEMgXw2VZZ293498I8TMszfagF8BtHdL2JdX6r3KMZdrCXSw0u1jvUvukFke+/p+ fud9+e3Ib2QYazAM7d/q5Orad0PAEEiMQEANmfi1PRkChoAhkPEQQLp/SBLYP4ipyRCKD2Fj/QIm GVmQ4G7Bv2GMZg2B+jXmOl3wHWgpvwLs70fqvZypIbQ7Q1Q3x/SpEJFqJopw1Df/AbEdi9R0DcRk f5nBQDwu83+P5J56h3E6rkDZmUn1C8EYjxPvapxe+8sEC4JqLQSRZ2qDOcsmJM0lINQ7QLiOwi5+ BuWfl026pPvYp3/oxoGdexcI+NecOZbs3TlHYsKVH0KzLo65DyC5fRmGphkYDtScIOpPYvM/HwYp Ufx/RUgCy+eQqOeEaduOQ7sneafcZUh978RpeInrN9QVgvEnfAQ6YUbVC03PpTAQ49GYeOY0+ENM gghsw3iPQezmYU7DQrXhf5eS9uS7gb39esyuHoeRK8BY1jP2n9UuJk7T8ZOoCI6DIHDzooma5fdJ wOH4f5gEHWRvdWf+ceyvWPZcYbQmRWAOltetW9fT/kDIHmJfLGXNBhOJayP95KOdcZj8XB3qvZsT TFUF2q2BJuMS9td3YkD0DT+CzjB2w2Es1xLu9mMYtvvxv2mscuyF78S4yZlYUb9wTl4KfssZWy0k 8M3Y39MxY2vMuj0Nc5QL/41fCDTQ2DF9ru/krkmtvauH5m9jUvsQ35vSjKMdzOoi/X6IBrUUDJ+T HxN4bsOHYRHtn8ZMcBXap+cZ629gVhBG4l+u/eSuBFIoARN6l4IOwFR9hMbwWHJ17LshYAgkjcD/ 11cmXca+XHwEpEq2tbr462AjuLAIRLTvkZjWYlg1UzI0ObpKW6C6clT1tyFzE6Se+f0mR/qOpD4n momiEI9xyREh0hCgvTgu221/2ym5D9evwlwikT8EcX/K3zZEVlaYneyy5dd7CNB8SJ0LQ0TtCMX8 +Ov67yUNFgEnTJDCx8AgHQw1J951hohdJz8EJO15grHzt5ncPdLwIjBA0v54vimuvCTl4B8dvF7u e1LXlLQnsyZM27KFmqs0K+AqM7EkNSGqj69BURiHODn1hhqb9ggS8RxygNZ3GDZceYb3DH6vb/hL vMn6PYvGIjsMwxG3rvoWfMgJHEYgBmJ8nxiW4O+hnvVbYF/Hy7ROJllow04436BQ5f3vzmbtI92H wg8m/pTzy3H9yTEaTVcemKhY7Uv3Prmr28fJlQv6/iumXXOD3tlj6iMQ0d/71O/WWjwXBIwwPRf0 Llxd+3FdOKytp7SDQET7/lyYiLQz1YwxEkdI4hD+Y8aY0YWfhWMiQvXsmIhImYJQbZyvdxl47Y2J OF+bJnG7Ef29T1zFni42AmbOdLFXwPo3BAwBQyCDIIDN+0Ik7omctTPI1NLENNAgTcKcLE2a4Nja p4ktYoMwBC4oAqaJuKBwp7gz49BTDJ1VTMcIRLTvTRORjlfYhn4GAuE0EWcUthcXAgHTRFwIlKOi Ivp7f2GGYr1EioBFZ4oUKStnCBgC6RIBRdcZO3bspbLDTpcTyASDVihZEvOVlA18JpiuTdEQMAQM gQyBgDERGWIZbRKGgCEQjIBCZxJd5z6i0bxInodO3L+IE+zDckIOLhvpsxyxiXLTQA7LkdbxlzvX +v62gu+JUlNWycKC34d7JqTnbZwtVQYn2hdFyIcrn5JvCiernBOh6hIFqbbWhLwId+JHUQ1znfuI uvO3pKICER2qHbkMEkWDUlnWtqvWGofuK0P1o3dEBqqDqVV3laVOZbeGckAmCVxTjYOwrHcp1Gio NpRXQP2Tw+BRHHpbkKysuCtHZKEYQoa2oY0eJC9r4s8l4sr4r6Hm4caH43qUG59CyMrXIPhUBnJ/ e3ZvCBgChsDFQCBF/xFejIFan4aAIWAInA0ChD3tqoRZxJfvR6jQV4ip/7RyEpCDoPPZtOMvK+Lw 448/votoOinyJzvX+v6xBN8T6vM3cgckG/I0uJ57hhB+nYhHXoQg9+5croQMLUHEoebKS0Ckn0Cy PdcmUYDugoDPQyK0ESQSm0Ciu4WElH1nzJgx/yKqUBU/Q0DI0koQ3u1Jvncj4VIDCfAIa1qBcK/t yd2wnFCwPxIetAOhWcu6PtxVCdZgPm4h18NCQtfOIO/Drb169bpe30lwdwcMwrWYEU0m4lEcDMJj jsFw9XUlMV53LlnIv/AlDs4nIfq9faR8GOQv6E5I2yyM82vmUIE2bvfXdfdJzcM/PqIpRbnxEZXo MGFOF/tPksiVI+xpmvSLcPO0qyFgCGQOBIyJyBzrbLM0BDIVAkqORrz9y8kOPBZH1OOafPHixY+T s2Bs9erVV4mY1wnR3IKwqC9xvgiR2FyaAh2SSksaTAjNp8m/MBDtQ329J3zpg7rSxhMQszkknZYE XPWRUD/y6quvXqHvOsihcI00A0j4B0Ewt5FZVXB9ZeEl58C9v9cI/68SbEFM3q5xwzA0IlfAsxob uROaqCYhTIv16NHjDt0zl5tJeFdPknHNj7j/rRUaVd+S6hOiWFL4SyDiS9aoUaMjOTCa0v4A5Q7w S/9JrncDmPbTCeHfQG2GOiCmo8nGnI98CvHB36U1IfRsXtZnOvk4rmIOXQkvWp58EB0g0pvw/SuS gN3o6hHWtKRyEJBAL8G905WM0PXJgTCF/B6/oPFYy1osRqNRx19G92TXvpJkbj+MGDFiDszDOpyA fyaEanWF/CQEaz3m/IGS3XH9ISEhIQ8hVgPrqPrSalE2D+2M6dKly2ZyDcxk/f8s8yvwvJpM2keU VE65GMgxMpUEb9drnVTXfyQ1D//4yImg5IDe+JS3Q3kn3Alzk5MkiStgnuaJQfOvi78fuzcEDAFD 4EIgYEzEhUDZ+jAEDIELigAS60shXncFh8KEYD9AwqnvIUZPI7muR4bfq5B6D4EY+wdEYM1HHnmk tgaK5qIkDEczpNwfQ6xNRfvQRkwDyds+03fej4SIP96vX7/6xNHfDxH4CqY4cyEu7xYjIoKfZG5d aW88xPBwpMdlIC4bBtcnYdspxpIoD4La9x8kt7scwrEbZkd9ISLzynSGjMrXo3UYTgKukRMnTmyo d2TPzo3WpZTqkqMhBoL4Nvr/HqJ6GP4gVyGlv0bfkuqTuqXRDOTkzLVgwYKasbGxhSDy32Z+8SQn a6G6Mh0Cv2ZPPPHEOCT+H4BdPYhyLzOyvvsPktQtJ5/D5xDCq/3vdT9hwoSr0AAs0D3J25pCtI/+ 8MMPZ8JoFYFRWg7zc5hcCPn1XQdJ075TW2iSEuVaIIFbURieLb+XioqSJoF1inHP7kr734DjT+6Z JH7l2RvrIPajwf+oS2an7zB+u8jenagN5SmAIRp44sSJLOyL0mgeWpGoba1yP+DPUYz7wBjIjREH w5EPDcsZPjhJzSOp8bnx6iozK/ZhC5LeTdAzWZq1h3vS9+NkW67qmER9s8MQMAQMgQuBgDERFwJl 68MQMAQuKAIkRcsj6XC4TrE9r3v77bfPEgEJQRuLRHsm0vwAQQxxPAEJ+TYRt5iP7J82bVoMZT2p uhLNQcRFUX/ZqFGjJqBhOIC5zbb4+PgSmLfkQlJci4Rsq1544YWlSiIGQzEWTcWu4PrKjAxx+N/g cYphkcQfRqUvZj1tYX7WIPXur7Jr164tBIFdAOI1v6TqzON1MhzvD26D7MhzJJ1Ho7Cjbdu23zE3 j4lIqk9/fRJ8HaH8OBijWMx8psJQePb/MFv1kZLP7Nu37wphg8ZjOhqE6sw7O8zSn3WKofG3Feoe jIpitrN7/vz5BTANK0w7O6UVYN4lYLbWkCm8LH4AK0LV9b+DsI8Go4B2AoJ6D9m4c/nL6F5J75SY Tbhi+tQO86rL+vTp8zPMRDQajkT7BOZzL/jmDG5Dz5s3b87du3fvLjBZdVjfTdI2YCYXzf4IjIF9 oOzap2GIzhhHqDb1zj8+GNAoNz5/ebJZ/wWfjTngdlDvMRf7jgSE/dlfP7IujdC0DcS3o5kFEPCj ZveGgCFwPhFIkV3v+RyQtW0IGAKGwLkiAIEXB2FVSk6z/ozHsnWH8L7+tddemwPxWgTp/kbXl+pA OAek3zyLGPQOSathTHK4Z3eFiMwKQ9EdQvLPEHHb3XsRlkjFd7hnmcBwv1mEsnsX7gpT0lvmM2g6 RmMvv8Zf9sknn1yNw+0c2uyNpuEgDr1zxo0bN8lfRvdlypSJde+QmO/Gabqpe07uignUAZcJGE3E USTw3tzRdhT78ssvy6AR+IvaQOuSDbOmnRC+RZHOP613zHsDxPYbuk/qgPDfu3r16kIQxXH4EmTX OuEvUJUs2nupmweNTTMYMU/rk1Qbeg+zcxyGJCDxZ31z0fauUHXQoJSAMevB+DaT8fjv0iJAcBdG gh+or3rgnrN8+fJxodpQHcY6UJmd8Xvoh0ZqBTgdY28E2kA7kgMG8yRZqs8qX4YbH+OPcuNzY0Cz lAsGsjYaqMHuna7a25hTzdMpMzQ0Em3ZOzczpyekbfOXtXtDwBAwBFIbAdNEpDai1p4hYAhcaATO IJaQ+O+AOM2B6UkiJ1uYh6sx/6kLYXwiJiZmO9L9wm6wmLAUh3jc4J4x+zmjXfdNVzEEEPn3QUzO wb6/D1GfhrvvaB12QnAXdM+KsiNfBPec3BVfgyloUg5jgtROkY0UAtXVkX0+DNI3aAf6wGB8iilV LUyHKrvv7oo0Pbe7R+JfEsbgDG2F+x58xSE95NwZUwK+E59CpD6jE0l4XzQ0I5CA7yBfRy+dyTEQ 6gutz/Lx48fX+NOf/nSMaEaT8DHpAUOWDcL7f2h3uqOZ+EXaieBxBT/jsxGPqVi0e0/f0ZdddlmA eXPvMbsqikP1Q4x9/NKlS98XM6BvaDv20G9uf2hZtCpFYG4CDKHKYRJWSn4iutcB8xlH1K8NMEJF 8GGIh3EIjAGzuCLsr1gYrd8dbH6vEvZf//jw04ly43OV8K+5Dt+UrdKauXfuKgYMbVFN9kJ7GONC rVq1mmAMhEMnVa4hfwup0rI1YgikcwSMiUjnC2jDNwQMgSiPIPTj0KRJk901a9acPXTo0BY4+Hra BRxoC2N7fgemSz+qLN+XIp2vJVMc+THgR1GpYcOGK/3tBN/LhInjFKYqOTEryispNpqNpSLakALX cuVxsF0KgVlRvhFiNnDabYPPQQF/fZWdOXPmJfIzcPXcFfv9BRDoQ/CxGLly5crS2O8PxOSlvRzG YSyqY2bUFhOakzghL0eyvonxnJFfYfbs2VUYX1ZFD6KfqvgmrAvXp+s73BXfjFVI4a8TZjrBqyNz 8xy7w9UL/iYzK7Qb2eSYjU/ETzACw+T0jM/AZJii4fikBBiw4Lr+Z0yTFmPOVUdmRWLUIOBrwQCs Vxk5b8t/QfcwezeB33wI7WUyadKp8f9hRrQJHL1ITXyvdvjw4fxE9vK0GXrGbyY/DM129lFlRYNS e+qL9SmFadNi/BKWoikoJzMutYvpWjOYUW8M8mPA9KuK6oQ7/ONjLlFufK4ODvxXsl+XuWdd0UrI f+R2mJhBYFCTsEuDpBQAACAASURBVK+T2QcDyYky1V/O7s8ZgTP+vpxzi9aAIZBBEDBzpgyykDYN QyATI3CG5FlYYJ//BVLZe4jYM5gISfuQzBckStEPMBZz9B2zoLkQhz0x+xmAWcxROdRCFIa1wxez gJnTCgjVZ9asWSPCfg7EXR85/PJ+PXb3m5Cst4J4HIPt+lKIvOcg9vdB6G3DCXpRcH1Mgy7DUfbO l156aYnGFHwgPd/EOVKMENqGukicH4CgfBm7+2aYEQ1Eu7APjclJJNXzaStR/gRFM0J6/RwamZyY yGyHoP5e7SfXZ/AY/M8Q5pOZ00P4HrwA45WF9rcQGWmMv0yk9/PmzfuQcLvNwe1RpPrbkd7vl0M4 65SPvB7eWJNrCwZkOv4iFfFjGASzlhfTsln4DqxSPcZVP2/evEdkSob2pizamOKMt7lrE/OzzTAr r8JYfgTT1wutRj0iM+Vjnd51WgSYhs4wacPF9OALMpX98RhO5jJ1yoL25VtFT9JJngvttb9pH8l/ hvV/U/3AWJR+44032sH4LXL9hroGj4898YYbn8qjiaqAKdYMf9377ruvE9htxDdCoXlDml/5y9t9 ihEI+fclxa1ZRUMgAyEQkX1uBppvep2K1Km2Vul19WzcKUUg4n2PGU0rOgmZKE2mKkiTC0P8xsqM yT8YaQmQ4sZAXCZIKu3/Fu5e5kVImz2HXOzXC2IadQxmJEHtIVXPK8JS9dU3hOUpRffxt+ev73+f 3L3al68CNvjZNG6IyIOY5BwIrqfkZNjGr8Mpey6EeZ6zmVtwW8HP0trIJ0DvU4N4VXuEWy2CeVZu TMN2+n1YgvtO6lkaHRi4BKI6JXKSTqp88Hu3D6SBcAxEcBk9Y/KWjzXNL2f54O/yW0BrJC3G7uBv Z/MMowhfM7xncnXcXkiunH0/JwS2Ydo3/pxasMqRIhDx3/tIG7Ry5x8BI0zPP8ap0YP9uFIDRWsj vSEQ8b6HiSjE5NpxmnYVEBwTgS2/Z7qV3hY+M483UiYiM2N0geYugcMYmIiIhQsXaFwZtZuI/95n VADS47zsP9z0uGo2ZkPAEEiEgP6jh5GYxsvGnJn+7xqmNwtxzj2r6ECJALUHQyBzIyAGYpoxEJl7 E9jsk0cg0/9nmzxEVsIQMATSAwL8h78GRkJhTcVIhDRtSg/zSI0xkgU6rA1+avRhbRgCGRSBbczL GIgMurg2rdRFwJiI1MXTWjMEDIH/x96ZwNlYtn/cOvalwZBClhbZ96XsL1qohKwRyVIiLZIkIu1U vOlte0vxKkpJoZBoI2SL7Ev2fd+X//f36J7/mePMnGMYM2fmej6fx7Pd6+++z7h+93Vd95WICPyz cjgBMpGLZuTj1K5FZraZiGNiVV8YAvjYKIP3z4XltNQXgYBMabQL0zb+hlyUT8tFtMGyGgKGgCGQ IAjoD5wdhkBKQ8DmfUobceuvELB5b/MgJSJg8z4MR93iRIThoFmTDQFDwBAwBAwBQ8AQMAQMgcRE wEhEYqJvdRsChkB8EYggY+H4ZrZ8hoAhYAgYAoaAIWAIpAQETM2XEkbZ+uiPQKB5X55E73DKfvm4 fwZ7NgSSAQKB5n0y6JZ1wRCIEwGb93HCYx8NgfgjYD+u+GNnOcMXATfv5ST9OOc6TgVWO8mpb/s4 7TAEkhsCbt4nt35ZfwyBuBCweR8XOkn0m+1akkQHxq9Z+nHZWPmBYo/JHgE373U9xJk12ffYOmgI nEPA/t7bTEhpCLi/9ymt39ZfQyDBEdCPyw5DIKUh4Oa9NBGPca7lNE1ESpsFKa+/bt6nvJ5bj1My AjbvU/LoW98TFAH7cSUovFZ4EkUg0LyXT8R/OM9wnkii7bZmGQIXg0CgeX8x5VleQyAcELB5Hw6j ZG0MSwTsxxWWw2aNvkgE4pr36Sn7moss37IbAkkRgbjmfVJsr7XJELgUCNi8vxQoWhmGQAAE7McV ABR7lewRsHmf7IfYOhgAAZv3AUCxV8keAZv3YTjEFiciDAfNmmwIGAKGgCFgCBgChoAhYAgkJgJG IhITfavbEDAEDAFDwBAwBAwBQ8AQCEMEjESE4aBZkw0BQ8AQMAQMAUPAEDAEDIHERMBIRGKib3Ub AoaAIWAIGAKGgCFgCBgCYYiAkYgwHDRrsiFgCBgChoAhYAgYAoaAIZCYCBiJSEz0rW5DwBAwBAwB Q8AQMAQMAUMgDBEwEhGGg2ZNNgQMAUPAEDAEDAFDwBAwBBITASMRiYm+1W0IGAKGgCFgCBgChoAh YAiEIQJGIsJw0KzJhoAhYAgYAoaAIWAIGAKGQGIiYCQiMdG3ug0BQ8AQMAQMAUPAEDAEDIEwRMBI RBgOmjXZEDAEDAFDwBAwBAwBQ8AQSEwE0iVm5VZ3wiNw9uzZXNSSjzMzZ+qEr9FqMAQuDQJVqlRJ NWfOnMqXpjQrJUQEzpLuCOe21KlT7w4xjyUzBAwBQ8AQSIEIGIlIpoMOechB1+py5k+mXbRuJXME KlWqpB56/yTzribJ7vE3ZAsNmwGZ2J8kG2iNMgQMAUPAEEhUBMycKVHhT5jK+c//WkpuyXlZCcTM mTOv0HnmzJmE6ZiVaggYApcTAf39aPnP35PLWa/VZQgYAoaAIRAGCBiJCINBupAm+mggorVMH3/8 8dXlypVrV6RIke733ntvrSVLlmR1ZT799NOlSpcu3ZHzvhdeeOEG937fvn3p7r777vrXXnvtgzfd dFPz3377TZqNgEenTp2qZ8qU6cW77rqrZ5MmTR7OnDnzy82bN6/nyET79u1rqhzfzCozR44cA6dP ny5zKzsMAUMgaSKgvyN1//m7kjRbaK0yBAwBQ8AQSBQEjEQkCuwJWqlMmKIJxLp16zI+8MAD3XPl ynVg4MCBX65atSr/HXfc0UEteP3114u98cYbrapVq7asY8eOPw0ZMqTNW2+9VVjfGjdufNfcuXNL de/efWqBAgV23XrrrT0PHTp03nwh302ffvrpbeR7C+IxYO/evc998sknQ6dOnVobUnGLyvI/atSo 0WzZsmU3TJ48eVi9evXM7tofIHs2BJIWAh6RSFpNstYYAoaAIWAIJDYC5wmFid0gqz/+CLBaqFX9 GCZM//vf/wrnyZNnx7Rp075EC7Hp3//+96T169df9+eff2b54IMPat52223T/vOf//z2yCOPrEYb sfjDDz+sevz48dS//PJLjbFjx37Qs2fPNVx/OHbsWKYRI0Zc59+68ePHN2zduvWkDh06bHTfmjVr tq1q1apzIRJ1T548GcOZu1atWk3/+uuv62jP69WrV9/n8tjVEDAEkjQC+f/5+5KkG2mNMwQMAUPA ELh8CBiJuHxYX46atAtTjKNNmzbrJk6c+K57CSEohlZiW4kSJQ7v3Lkzd8WKFTe5b9I4bN++Peqn n36KTJ8+/fGbb745Wsgnz87ly5dHubS6yizq4MGDkffcc88q3/e6b9q06ZITJ05knj9/fnb3rXbt 2nfPmjWrNuTlvQoVKhx07+1qCBgCYYHAeX9fwqLV1khDwBAwBAyBBEHASESCwJpohWob1xhHoUKF juEP4QnsaBsqDh8+vFXbtm2nKBGmR5FoKY65DAULFtyL4J9h4cKFkRkyZDjq3ut6xRVX7Dt8+HCE 77s1a9Zk0TO+Fod93+seTcQuXffs2ePlWbt27XWQjhL58uX7+5lnnrlV3+wwBAyBsELgvL8vYdV6 a6whYAgYAobAJUXASMQlhTPRC4thOuRaIydpNA+dPvroo9vwgxjJOV/fIiIiTm7evNkjAnrG5yED pGJn1qxZTx49ejT6vb5h4hRRtGhRjxjoWQfaBE9TMWrUqCLn3vz/v2PGjCnG01nIxF69xdn60Dff fPMmx8eQifIQiVL/n9ruDAFDIAwQCPj3JQzabU00BAwBQ8AQSAAEjEQkAKhJqUjIQBoE+Y7ZsmU7 hJP1kK5du65z7WN3pD1oCCLd88aNGyOvueaabWgu9uLLkHHFihXRK49oFHKxo9JWl1ZXzJ+OR0ZG bpsxY0Zx3/e6x6eiGN/X8v2UntFAbKEd+9m1aWvDhg2nDhs2rCVO3pn0zQ5DwBAwBAwBQ8AQMAQM gfBCwEhEeI3XBbf25ZdfvmHXrl152EHpSzlM4/OQXqe2X2VXpsU4P1eV8/O3336b5+eff64MUVhb uXLl/VdeeeUGtAXVVOFjjz1W7siRI1nr16+/078BLVu2/I7tX6u++OKL0dvDaqtYIg1X7dat22T/ 9HrGL2NqxowZj5C3WaDv9s4QMAQMAUPAEDAEDAFDIGkjoK377EjGCCDgF9m9e/eVaBhe9e3md999 9+x77703E5Ok6/F3GATByMzWq7OffPLJFUrHTkwfs5tTD7QVNdiZKcugQYPeJRbEeVHk2O1pLgQj AsLxwIABA06lSZPmDLu4pOrbt++HTz311F++dbr77Nmznx48ePAYSEYvtp1d8Oyzz/7pvtnVEDAE DAFDwBAwBAwBQyDpI2A2rkl/jNTCs5xBxwrhvTLpKinDhRzsmHQFmodjBISL4UwtzQWaiihpIAIR CN86lBafh7yYTZ0kvcV+8AXH7uOFADFK4LIjuscrs2VKCAR+T5069dyEKNjKjIFASH/vY+SwB0Mg /BGweR+GY2iaiDActEvd5Jo1a3rOz/7lskPTWQLTbfd/H+hZaYlwvS3QN3tnCBgChoAhYAgYAoaA IZC8EDCfiOQ1ntYbQ8AQMAQMAUPAEDAEDAFDIMERMBKR4BBbBYaAIWAIGAKGgCFgCBgChkDyQsBI RPIaz7DozYEDB9KGRUOtkQmGAFHRc3755Zd52TrYTCoTDGUr2BAwBAwBQ8AQSDgEjEQkHLZJpmSC yr2SLl26YenTp39NZ5YsWYZcd911XeVQfbkbOXPmzCuuuuqqAYHqHTJkSHEcN4e7duqaM2fOZ//1 r3/dpXgXgfKE8g6H76jECG6Hk/ngzz77LH8obQwlzWuvvXatggYydt1at25dW9v06tAWvffcc09d Iod3L1++fDul8y9P0cqVx/d9fMr7448/srE1cMvChQv3qFOnTpPff/89uytTOONf0wwH/W7EA6mn drlvum7YsCEjO4A1v/HGGzs9/fTT9Qg8WI37x/TMbmG5fdPqnuCHqdRf3/dx1f/xxx9fTYyTdsKB ncVqEdQwq29edx+snS5dqOVp3pYqVapj8eLFO7dv374mARxjRHZ35dnVEDAEDAFDwBBITgjEWzBL TiCkhL6wFesbCHWP6USYe5ZtWzN27tz5nqTWd6Jl73Pt1PXDDz98+4cffqjVu3fvCvFt6/fff1+A 2BQ14ps/vvkQVl+75ZZbQnJMD1aHAvOxbe4DCOlLHn300SkE8yt91113NVS+Hj16VJ49e3aFhx56 aGqDBg0WsWVu+9GjR1+lb1988UU+pXv77bebMe559E5HfMtr0aJFW7bxPcvWvBNwpj/VuHHjriJ4 EpzbtWvX5fTp06n79+//NQJ8sVtvvfXOc7WlSqXvtWrV6tymTZt5y5Yte+/++++f+9JLL80gnsgb zz333KQHHnigzZo1a7zgg3///XeG++677+YpU6akIhhiUVeGrrHVTyDFjJTRPVeuXAdo25f0Lz+b AnTwzav7YO106UMt7+uvv45iu+J2kIi1bI88mXEo07Nnz1quHLsaAoaAIWAIGALJFQEjEcl1ZOPo V+7cuU8i0C3Yv39/9CoyQt1NvO+nE0EvWggizkSOYsWKPURwuJe1Yvy///3PE061Ai1thrQcUVFR fYhA7a1+T5w4MW/ZsmXbayW4UKFCPdUM4keUZAvZ3pxPvPPOO2XjaNp5nxCAt1999dUbtm3b5rU1 tnohGwVKly7d0RXw3//+tyCr0u3VHu4bI0AX1iq4vkMo8tO2R9AUDCJORlutkLt8WkVXHvcc25UA fuk7depUffjw4UXeeOONouR7kG1wX9SKtBOGu3Tp0hz8rlAa8G6qlXvVqVV8iFF0pPBAdaqtEmRd /QQNLMcK+6qRI0fOUdRxxmsaRKKivkOSKiJczyAo4CqC/i1iRXw541RG3xDmI/fu3ZuFWCB79OyO +JS3fPnyLOvXry+KdmUChOHv8ePHf7Nv377cWtlHq3Ajc+QoAQvHMfabaON0TJaqQQQ9bUTbtm1v RxPyo9pevXr1Fv/5z3+qE0ekLlqmDlu2bMlCkMNF4HSj2rd169aM9D0KrFxzvWtc9dPfwnny5Nkx bdq0L1U/pHkSbb3uzz//zOJbSLB2urShljd9+vSCzKH5Y8aMmQnx+bt27doLOLzAiyJvlOP9Xly5 djUEDAFDwBAwBJILAkYikstIBukHpiHpEc4idErARtiqWqlSpaXKhmlJKQTCBqxwf/7WW299wApw DVa3PQEVs5SO+fPn3076IVx3kqaN8jRt2rQjAey2IKT1R3iagkDYaf78+dkQKiNYaS6NAFkGIfv7 FStWZMbcowNC8XxWaicgdFVR/jiO1K6dWi2nbaVZPS7I9rFe4Lo46s1AvnyuXNqRAeKRF6Fu1+23 3/4jBGbz0KFDp4owdOjQoYeidUMWZOJ1Gm1BO5eP55Np06bVftUBD5ljybwKYjOIvlQsUKDA4eef f/4eVsGnTZo06RVMjFIjzNdU5k2bNhUUHjt27MiC6VgthOKjrFwPzZcv3w5wbOwqCFQnZjvl8BdI 79IgjKdRW93zwYMHIyAHUdICsPqfFjIX/Q0tU4aNGzd6WKCVWPbjjz9+AbFY6fLqGp/yTpw4IUKQ 2sUMOXz4cFrqTgexywdxylOwYMFNrg6inu8idkgW5oInxP/111/XoiFYrDmyevXqwpCNTzGnmkY7 i4DdOojoQXDyWIMipqvNkFFXnHeNq36I7zrG812XAaJYDK3ENsyhDrt3ugZrp0sbanmvv/76PLQP 40VwRKQnTJhQj7m+UOVIY9OxY8fu4PIImrSyF2OS59plV0PAEDAEDAFDIKkgYE6NSWUkErgdjz/+ eE/O6Frwi9iPEDdTL1gtrdmwYcNZmMss1/PkyZNnYqNenhXmjQjChRctWjQ8MjLyFILZtwhFxxGW 82ByUgTh6W1W9I+xqr3w008/rc3qcsmbb75506lTp9J9++237yO4HpbwhA/EBlavp6tsiMGMUaNG eQK0HGsRhj1BuUmTJlv0HbKTE7IyVPfuwM5/TqtWrTZTZqz1oiXZ6dL7XhUdGwH1AEL2CUjTAQTW 6qzK76IvM5Tu/fffn4gGY4iIC0TjhExtfPO7e/kPEOG7NivkRRFy59GfYYqhQXvTELE7G2Qq74MP PriaNo6G9ERrEFx+8D5Af6cgWMrE6Au0CgO1Sg8xOBtbnS6vrpjILIL4NH7iiSfKsfK9nfbLJyIN JCWdtEo81wHvPZCk7BC3GyF4a3zz+9/Hp7wyZcoc0ljif9EIEvQzQnM1jTWO8hnQJkTSx2OunqpV q+7j/iwamwxcD4noqK9oAsqBtzfPELivKVq06AqRkrlz5xaDMP7g8ge6xlW/5qFO5ZP/B+Zb96D1 +NS/nGDtdOlDLc+lZ25cj/bjHsYkPcTFM2FjmL9jfGZg3lWW31gd2tQUAjqb6O8/+5MbV45dDQFD wBAwBAyBcEHANBHhMlIX2U4i/w5F2O2hc8aMGf1xYD7TrVu3Bip29+7deb766quGCHMv6MQ04w6E +2yLFy+OzJEjx24RCKWTGRSrvVMwkWGRN9d2J7TpG6YkyIu7vJVk8uwRgdB7Vpyvu+GGG9bqXsdt t9223rvhHwT6+zGL6a0TQdrLi0/EXtdO2qUV3PcwD6kicyXITJz1unJ1ZdU64NzGxCU3K975XV8r VqzYj0jfqSE3McxefMtq1qxZfdrxEOZRqxDSn0GrMN4F4aO9ZxCox4BLXXB6BU1JM1acz9t9iobv EoHQIbKiVWq0EjHMphB6q4Lj0zrBIAv+DY/oXpoP6j7I6vhEhNU7SNe5SpUqS6h7v8p64YUX5kKU dj788MNd33333VsgG79Ie+TbB//7+JZHXeMhKUXQUPVCE5IdTcw6hPsd+EecgExEY7hz58709PE0 pkteIEPmm6fdgcAdUToRKDArj0ZnB6v5xdAa5UFjtMO/nf7PsdWvdCJUcsT+6KOPbqPMkZzz/fMH a6dv+lDKc+khmQsYsz7MlUlofzo6p3c2BjgFcZoH6R6GKd/IefPmlQCvweq/y2tXQ8AQMAQMAUMg HBEIKGiFY0eszXEjwO5MZ7TiqxPb/D2cP2FK4u0chC37Mez3P0P4fUonq/J9IRojsVPfjmCUDbMU T+DRqjuCaiXybuU+h68ghBAYhRnHOv9WsHK9C6E9p3uPEBXt3IugOQQBvodOmbC4NK6dIi843y6E vGzGATd/sHpFBlwZOORewbN7jL5iUnQMH4S/XF91xW/hGTQonrAbndDnpmXLlksQTheycn4LQuKd 0qC4z9quFi3JOgTqgWhYXoO8pPc1VXLpwFAr8t4BGcoKrtkp84B7pytk6q9+/fqN1YnmRGMyUfeY lv0qszBI11LVg3A7ABLxNwTDIwoiYJDAzxiTvmhBXqUNEWg64iQR8SkPrNIwV04jEA/FlKnvr7/+ OpoxjKpXr942SMse7qP9PCCPuRi/HRpL9Q2/mjWYM5VAk7KYx9T4jjyA2dd0xqkABLchZnRjlS6u I6769Q3tR0fG9xDaoiHyvQhUVrB2ujyhlodWph4O7ZWVTyQRs77fGevMzi9G70VGunfvXon+tsIP KQdat0nSyuibHYaAIWAIGAKGQLgiYCQiXEfuItuNAHrICbaYAq3AfKmC9uzXiR9BW8xd6rET0F5W Undj5lRO1fXq1asqtuqlENb2//PeM1rXnv9oDaJw9o3WOLjmseXl0pUrV16vLTwlmCHsXvAuSwiG BxGQM8RVL6u7exDQIuWwLHKDs3F0PQhsZyTcq02Yba1EwLvWbW8r0xfe9XRaAp4ryL7dtV9XiMM2 tDIf0s/nWUk/jOPuw5gL9ZBpkYRxBPo+coKGbGxp1KjRAgTszL75dY+AfSV+J56fAj4UldFMbLv+ +uuP6Jurk1X7feC+Riek7zRajbW6l9YD/4u8aCR6y6FbJxqHOnXr1vVW2tndqDZp71ZZpMuFaVUJ zM7+1HNsR3zKo01n6Xt3iN31KhdBvTqakE2QsqPUt1QmbnKy3r59e3p2LGqAqVL0fIAkTMbc7Vb8 bfJhujQaH4l30Kxsxj/i39pNifEI6oAcV/2Y1N0ALnkwq/tSpFdt0CmNgDYHYA57juZxtdM3Xajl QdZ2QSpr4uSeU3VpbHn3lzDRWDBmd0JcBk2dOrUSJHAqbRw4btw4z7QvtrGx94aAIWAIGAKGQDgg YD4R4TBKCdBGVvcPI2Tll/MyttpTEXa64gD6HIJQahx/NyHweSvDCIpfs+NPB3wHGsuvADv4UWqO nKkx4WjP6ntDTJ9yIGhPlv+Bf1NlosIq9Cq2+3xG5jclS5aMU7j1z69n8h1ZuHBhMW5nxVavtCsI rSvr16//jEyw2DlqNYK9RwYwodqAvXo+fCLa4AQ8Go3Cj6R/Vr4RWrVH4P3I1ctOSx0wxXrVmWO5 97rii3AQE5zJkKGp2LmXwS+iFrb+aejTUuobgmnOeshOFhzIP/fNp3uw2Q2W96NdSIMfQXqczT90 aeKq06XB32Idgvha/AkeoY5s7PC0FvOYX/QdovEz39tp1yc0QlciKE9AsyKfhFiP+JbHyvuUV199 tRltPgEOmcByuCpBG7EbjcyXrLI/yTw5Lh8QhPLXXQPkz4CvzdsQrVbMoTPMtW3gkEZmTNrVifk2 yaWN7arV+9jqp64iENkrIXev+uaHvD4LQclPnS3BfFFc7YQAFXTpQi0PYr2M7XTlTD1A85u5t5fx n6g2MFfbMffX4xuhrX53+bbL7g0BQ8AQMAQMgXBHINr8I9w7kszbL9OHoGOF+Y7MKirFBwutokpb oLz+Ao9Mdlg5zuprcqR0ckZGM5EbAWoXZksn9C62QxoCtBcnZYsfW5pQ38dVr4KRsQp8GIHOM6Nx ZSJ4p4HspJMPgd5p60+0CzkhOdsCkR+XL9hVq97Y2Z9V/9CEpNeWtP55FOjuk08+qYNGZji7O0VK kHWaD/+0wZ6l+cAUKm0gHNG+5IIoSUvk+bAEK0vf41OeNEqMe6T/PFF5aCMyaK5A5nbrOdAh8x4I RV78OI5B5mLFAhMgLJ1GdPcvI676/dPG9hxKO2PL6/9evx3GPxcas1O+vxE3N/zTh/Hz7/i2zA3j 9odL00P6ex8unbF2GgIhImDzPkSgklKyoIJpUmpsCm5LSD+uiyERKRjbBO+6IxFoRt5M8MqSUQWx kYhk1MVw64qRiMszYiH9vb88TbFaDIHLhoDN+8sG9aWryMyZLh2WVpIhEBABVqe3Y2ozJ+BHe2kI GAKGgCFgCBgChkAYImAkIgwHzZocXgg0btx4h87warW11hAwBAwBQ8AQMAQMgdgRsN2ZYsfGviQQ AvKxSKCirdgkioDGXFvjalcs362Bk2hzrVmGgCFgCBgChoAhEAQBIxFBAEoOn9kt5xW2xxzG7jav 6WTnnCHsJtTVbXN6OfuIY/EVOGEPCFQnu+cUx3FzuGunrjgJP6tga3KmDZQnlHfadlR+CaGkvZg0 7HJVmK1bn7mYMnzzSthmN6K6bBnanajd7RQ1232XAzlB5VpqRyack5uw61R2981d2RK3JZGSo7dO jW95qldB3Jgz3Vq3bq1I2a6KVESZLsWOUR057yMQ3A3RH/65IZJ2fna66ozz/b3gU4ndjG7Hobof O2bdJgdr//TJ/Zn5PIDdnKLHJLn31/pnCBgChoAhkHwRiLdglnwhSZ49Y4vTNxAiH9NJ1OVnjx07 lrFz5873JLXesqvSPtdOXYlU/TY739QiYnR03IcLbTO7FhVAmK1xofkuND3bl/5NFGpvy9MLzRso PUHmKs+eDs+6rwAAIABJREFUPbsCwcymEr16EZGQ2zsBtEWLFm3Z4eksMRYmsDvUKcylujqixfaz JSEQrQjQdzPb+GZyZcenPG0BTIyFB4gZsoQgelOIh1CaHagaqkxFmmar11aQmWVsK/sTJLAN29AW dvURa+G6QYMG3cZWuGPY+Ws0+f5kLMZy/wZRzLfDI5q6tHY1BAwBQ8AQMAQMgfBCwEhEeI3XJWkt MSJO1qpVawFbkkavXhMo7ibe99NJELBariIF4GKv+4fYy/9lgtJ1civbWvmWNkNaDlaW+7C/vrdK ThyFvGXLlm1PULJahQoV6qlyBgwYUJKtVXtzPkFsAy9AnSs/2FVbphJ/YQPxBLy2xlYvZKOAVsRd ef/9738Lsg1qe7WH+8YQp8KshjfXd62O07ZH2JJzELEf2vIto8vH9rDdlMc9+16lRVHwMMhNaghD HQL2PU1cgIGKWqx0CMh5unXrdpfuCRB3K4H2aqg8iNHz4N3UCflvvvlmUeq9V+ncIW0JeTzh3L2j vIqQhRlEOl5FrI5FrOgvB/8yCoa3fv36ogjnE4hy/TdB7L5hVT+3ylBetq7ND7E4jibnmCtL1/iU BxEohyZk1ciRI+coCjTzZBpEoqLK++CDD2pCBKYR4+E3AuatBv/FjENVfVNfIRl3guVoBYljTvQi inUBcLuNrWF7EGtiPtG18ym4odJDRoqC1YNEuH6RaNYdXcTn2N5rbil6uuYe8T76E5sh4LzSdsA4 trfWWCtA4HvvvVdI9TVv3ryexl73Opgr7YidUUX3EJ8bVT5b/w7SHNJ2wHpP2+sqn9onjQKxUf6l QIHU/wzteEpzTuniGnt9d0dc89Cl0VWRvqXhUh+Yw80UbFDvpfnRHNRvUJoiaaf0PpR2ai7ffffd 9f0DKyq/HYaAIWAIGAKGQCgIGIkIBaVkkIY4CeklUOmUsDNt2rSqxBRYqq7JJAVBtAErzZ+zkvwB UYVrsGrtCYoITR2JuLud9EO47iRNG+UhQnJHhLItCFj9FQDuqaee6jR//vxsCLMRy5YtK0105zKd OnX6XnEIWKHugPAzH0FvAlF8PUFNZcRypHbt1Co4bSuNsFkQgecvpY+j3gzk8yJCKx3tyADxyEv0 7V3EgvgRArN56NChU0UYOnTo0IPV88UIuDLxOo1Q2055dPB8Mm3atNpqLvqQOY8IFNqAvuCYWcI6 /aiG1mEEAucoYh7U1jt2YMq4adOmAspIHIIohMQ70CJ8j2A9HJyKg0MJfUOoPkM9MWI5IDRnI6De jfruDgLZpUVAPO2e0R5l2LhxYz4C5Glr5tQI3J5dERGy05I2HQTL6z++B98Rx+ELvnsRsV3++JQH YUojjFwZxNqI2Lt3b5RIAlG4c1esWHGT+1agQIFdaD48IgMmUXnz5t1OAMCjEKAKzLUlH3/88SzG YR/zZr3iZGBWd5iI1Z6ATqTne4joPG3SpEmvKOAhxKmmyo3tPTgXBvOqBDt8j3n2NYSldSBfG0hO K9qchbpHMId+ZtvYhzQnIba/MSYlFcmaOV1h7dq1RdD0LJCpFiSvCXNkOlqgl9SGxx9/vI6uzK+c zJmGxMBYxLh+8fnnn9/JWfOVV14ZBQFaw/jernRxjb2+6wg2D8+lSpVKwj7BEDtS3wT1gXYWgszV VpR4+tARnD6HPAyA8ByCzHqkKJR2Mg7HiVtSkCCAAyFZbZyGy9VrV0PAEDAEDAFDIBgCKc4mORgg yfU7glBPzujuIcDtRzieqResbtds2LDhLASq5XpGAJyJyUl5hLSNEtYWLVo0PDIy8hRC8beYrRxH 0MuDoFQEIettVmyPsVq98NNPP63NinRJIiVvIhJxum+//fZ9RX3GDKksPhAbWDWfrrIhBjMQ/Brr Xo62CHjeqiqRjrfoHUJ6TsjKUN27A3+AOURD3kyZsdaLkL/Tpfe9KpAcq8QHEMZPIMgeQFCtrkjV 9GWG0hGJeyIr6EMQvCIQrE5AgN7Te4Th9OBRGaGxFvE30hBxezZ4fIIPwjFW0a9DcM+G4J8VsrUG Qfo1+ngMTDyBWPl1VKlSZY5W6HWPSdZ3aAJKQDqWKFq0Tr2P65C2iHbWAcc9CJ3ZEX5vRABfo+jP whShsREC8M9ogaoJc4ToDJe6PKJhL4JwNX7iiSfKsXK/nfbIJyKN/BkgE5GshB9zdRKFei/kxWsD gm0eIp/v0TcE4XKspn+h+6VLlxaiX8skrMukTsHZFAiQAHrZEOrzgstqxnk0xDEjQnPjQO9Vjg4E 6G8U8E4n41QZbUkxiOqKc1+9uZaJuVsBwjcAv5E90moRYfsmAtiVGD58+O8QhQmY+TVV1HHI6ieQ npMad/xnxmpcRUrAeSfB865xZYL9QsjofD2jJTnIvJ0Nidmg6Nt9+vSJJqOxjb0rB2JQPq556NJB jiqjCVzx3HPPeYQfzMehPYhkDlYG73XU6ZFryP83/E5ecFq1YO28/vrrjzAW70uzx5y8CWLSlYWA 3Wi+fqSuRY6gunbY1RAwBAwBQ8AQ8EfANBH+iCTTZwSnoQhkPXTOmDGjPw7MZzC9aaDusoKe56uv vmqI4PCCzjFjxtyBcJ8Ns5hIzHV2i0AoncygENamLFmyBOuKXNtFIPReB8IkVha7PHMK8uwRgdB7 TFiuw/59re51sDK83rvhHwT6+zHH6a0T4d3Li+nPXtdO2vUIJOS9BQsWVJG5EgJhnPW6cnVltT7g 3MYMKPeOHTvyu75CAPpBElJDbmIQAISwXl988cW/ENLG0a/BCLQ/ikCobMjYSnwO5iCE9pJZCyvt 1SA+x/XN9wCf6G1dEdp2QzqK+n7XPQSmg0xSEFzvhcgU0L1O+RNgrjIXArQTs52u77777i0I879Q jxcRm2/jIRVF0BT1QrDMjhZgHW2Ors+/Hj3HpzxFxsa8bSJmQHcgZ3ZGOF7CGO0X4YKYnUTYj8YN MpCBtntkjpX5feCWQ/Vmzpz5yJYtW7JiBpVTGGB6sxOtQIOSJUuu0nfKOwMZGsPcqstcewVtUzM0 HSiE0qYK9F55dEBYo/sLTnsgtUXOfTn3L3Mvt8aWOfeEG29I8TUQBW+uyUSL76kQ5vcgQHvCOO0/ STsLMtGeAetB8+bNK+lbJvXsc89oU05BTLfpWdoljuhFmWBjH+o8BLdIxtarQ/Uw5zaKtPM+F3Nq g97p0DjRhuPMiax6DrWdItbgPpmx6s9c+hFy1YJ5dq/KsMMQMAQMAUPAEIgLgYCCVlwZ7Ft4IiAh B0HKO7Uqy/kTpjH51Rv8HY516dLlMwS3p3QizPaFaIy86aabtmsl+Pjx4zKfkZYgjezQybuV+xzy DdB7HZgORWGydN7qOiu5uxDac55LlSoVQlked485zBCEuB46tSLt3rt2iry89NJLCyEvm3ESzh+s XgmMrgzMPq6QgOh/YFd+DAH3L9dXXfH7eAaBdK9vWgTnaeByBBOVltqRCOE32kGZyNMZ0d58Q7/6 sBr+GcJrZUxhSvvm1z3aimhfC0y98iMsH/BPwwr/9/369RuLHf0MCMlO3evEUXqziBXk7jOw7ouw /irEKAL/hO20OQ1tO43mYyh19P31119Hg2VUvXr1ooVN/3r0HJ/yEEozQ/aWQlQGon0YAIn4G0Hb IzIii+Ac6epiPkWiKfHawKr/FgT2/FoZRzswBf+JOvS1PjiNhjC1gCBmh6x+r7xa8UfTtE51oKV6 jX6mhzw0RkOQKtB7Vx/zNBpfzWUE5xj4ogk5iqB/hjY+68YbDJ5GUJ6tMhi78pBpaZ3yo5HwCAjf imKmVp/xHSncITQzlcYdcmZ393Fdg419qPNQ4y2sXF3SxsmnBu3ENt/flXyXMDs7gc/OLqUNtZ1K O3fu3Bz081b8lZpCDjcz33/VezsMAUPAEDAEDIG4EDASERc6yfgbguAhyIFneoIp0ArMlyrIyVUn fgRtMWOpx448exFsd2PWU05QsD1nVcxVSrEKv/+f954zq+yzEXSicLqN1jg46HAuXort9fWUn1vC L0LxBe+yhMB1EIEuQ1z1sgq/B0fxSMyGIkVuMB2Krgfh6owEU7UJs62VEIJr3fa2mBtV5F1PhC6v yXKUlbMppl4LEFJfgcSMwpylIKvnsh1vhZBbAGJRHj+LFpiEnUYgXsZK8QZWcjO7Prsrwn0Z9RkC EEF9ZdHOrNE31S0/FN3jgL4JrNewIrwZ8nRM9zqlycGspDbC3d1Kh0lOLsx9SmBO9ieE8Cz5utO2 6/UNDUF1hL9NkKOjeo7tiE951JsXwbQ3/UuvE41Inbp1685XHfIrmTp1alXhLeGWlf/KEE9vDsiM rG3bttMwA2vLu134PrzF93HMoVWQi1fQQvyNKY1HLiFDGSEnfUTOcAre0qhRowUI4ZkZM5mEnffe 9Y8tY8vrHqE/ipX5QviseCQWclAOrVVWSOduiNs+xsjz79E8ZcW+H3Mxr/xtyN+M9nwG4ZkMufF8 KtC+5ZMgTVm7NHaaR4HIqGtDbNfYxt6lj2seihDIV0NpGWfv9yPfCJF55kYz8MuG9m4J8/IGvVc6 +lKKjQ7+cvNY74IdMstjXt/P77wvvx35jQxnDIaj/VsZLK99NwQMAUPAEDAEotXvBkXKQoDV/cNa gf1HmJqKoNgVG+vnMMlIzQruJvwbxgoRBNSvMdfpgO9AY/kVYH8/Su/lTI2g3R6huiGmTznYqWay BEd98z0QtnewaroKYfIZmcEgPP7p+z2Ue/Idwem4GGlnxVYvAuMenHhX4vT6jEywEKhWIxB5pjaY s2xgpTkfgnobBNfR2MX/SPpnZZOu1X3s0z9y7cDOvQMC/KvOHEv27pyjMOHKiqBZHcfcB1i5fQFC 0wAMB6pPCPWnsfmfD0GKsf+/dkgCy/6sqEdA2rbi0O6tvJPuGlZ978ZpeImrN9AVgfFnfATaYUbV A03PlRCICWhMPHMa/CGmIAQ2o70nEHYz0afhgcrwfRef8uS7gb39WsyuHoHIZaMta2n7LyoXE6eZ +ElcD46DEHAzo4ma7euTgMPxH5gEHWJudaH/u5hfO5hzOdGa5IIcLKtevbqn/UGQPcy8WMqYDWEn rvXUk4VyPsfk58ZA712fIFXFKLcimowrmF/fiYDoG34E7SF2IyCWq9nu9hMI2/3439RVOubCdyJu cibWrl84Jy8Fv2W0rTIr8A2Y3zMxY6vLuPWGHGXAf+M3Nhqo60ifqzvYNbaxd/nQ/K2PbR7ie1OQ drSErC7S74fdoJaCYX/5MYHnFnwYFlH+WcwEV6B9epa2/g1m2SES77jyg13ZSCEfJLS5Nh2AVH2M xvBEsDz23RAwBAwBQ8AQ8EXg//X0vm/tPqkhIBOKoGPFimll0lWKT+Pl6CptgfLKUdW3DJmbsOqZ 1dfkSN9ZqY9AM5Eb4XFXMCFEGgK0Fydlu+1bdnzu46pX21yyIn8Y4f6Mb9kIWWkgO+lky6/3CKBZ WHXOiRC1LRD58c3re6/VYAlwwoRV+CgI0qFAfeJde4TYNfJDYKU9kz92vmUGu2c1PBcESNofzzfF pddKOfhH+o+X+x7bNT7lyawJ07a0gfoqzQq4ykwsVk2I8uNrkBvisEtOvYHapjnCinh6OUDrO4QN V54R3f3f6xv+Eq8zfk+jsUgHYTjqxlXf/A85gUMEohDG94uw+H8P9KzfAvN6j0zrZJKFNuyU8w0K lN733YWMfajzUPhB4s84vxxXnxyj0XRlgkTt0Lx074Nd3TwOls7v+++Yds31e2ePlx6BkP7eX/pq rURDIFERsHmfqPDHr/Kggmn8irVclxiBkH5cF0MiLnF7U3xxTpDEIfynFA9GPAFwJCJQdkciQiUF gcpIqHfJeOyNRCTUpIlZbkh/72NmsSdDIOwRsHkfhkNo5kxhOGjW5KSPADbvC1lxj+GsnfRbHT4t RIM0BXOyJGmCY2MfPvPIWmoIGAKGgCEQfwRMExF/7C5nzpAYumkiLueQWF0JjUBcmoiErtvKD4iA aSICwnLJX4b09/6S12oFGgKJi4DN+8TFP1612+5M8YItPDNpd51x48ZdKTvs8OxB8m+1tpIlMF9+ 2cAn/95aDw0BQ8AQMAQMAUMgXBEwEhGuI3cB7dbWmeyucx+70QwmzkM77gfjBPugnJAvoJgYSeWI zS43teSwHONDiA8Xmz+uatilprCChcWVxv8bW3rewdlY73GiHSxB3j/NxT5rO1nFnAhUDrsgVdGY EBfhbvwoymGucx+77jwZ265A7A7VklgGMXaDUlrGtqPGGofuGwLVo3fsDFQVU6suSkue0m4M5YBM ELj6agfbsjbXVqOBylBcAdVPDIOHcehtRLCyvC4dOwtFsWVoM8roRvCyer6xRFwa32ugfrj24bie yrVPW8jK18D/VARy3/Ls3hAwBAwBQ8AQMAQuDwLxEgAvT9OslkuFANuedlTALPaX78dWoS+xp35v xSQgBkH7+NYh4fCTTz5pzm468fKrudj8cbWbrT7/JnZA0C1PYysDQfg1djzydgiKLc2FvGfL0Hzs ONRQcQnY6Sc62J4rg12AmiPAZyIQ2kgCiU0i0N1CtpR9e+zYse+wq1AZX0LAlqUlEbxbEXzvZrZL jQ6Ax7amxdjutRWxG5axFexPbA/ahq1ZC7s63FUB1iAftxHrYSFb1/5I3Ifbe/ToUU3fCXB3FwSh FGZEU9nxaBcEoacjGC6/rgTG68IlNfEXvsLB+TRCvzePFA+D+AVd2NI2Ne38mj4Uo4w7ffO6+9j6 4ds+dlNK5drHrkRH2OZ0se9JELkibHuaJP0iXD/taggYAoaAIWAIJFcEjEQk15H9p18KjsZ++9cS HXgcjqgn9Tpv3rwniVkwrnz58iskzOtEaG7EtqjPcw5GSGwoTYEOrUprNZgtNHsTf2Eg2oeaes/2 pZ11pYxHEWbTa3VaK+DKzwr1Qy+//PJ1+q6DGAolpBlghX8QAnMzmVX551cUXmIO3HsuR9z/KsAW wuSdajeEoQ6xAp5W24idUE852cI0T7du3e7SPX25lYB3NbQyrv6x739TbY2qb7HViVCsVfgrEOLz V6xYsS0xMOpT/gDFDvBd/Se43k1g2k8ngn8tlRnoQJiOJBpzFuIp7PH/Lq0JW89mZnxmEo+jOH3o yPaiRYkH0QYhvR7fJxIE7GaXj21N8ysGAQH0jrl3uhIRuiYxEKYR3+M3NB6rGYvFaDSq+qbRPdG1 byCY2w8jR46cA3lYgxPwL2yhWl5bfrIFaw36/IGC3XH94dixY5nYYjV6HJVfWi3SZqKcsR06dNhI rIFZjP/VMr8CzxuJpH1UQeUUi4EYI9MJ8FZN46S8vkds/fBtHzERFBzQa5/idijuhDshNxEESVwO eZonguY7Lr712L0hYAgYAoaAIWAIJAwCRiISBtckUyor1lcivO703woTgf0gAae+Rxg9y8p1DSL8 FmfV+xWEsTcRAis99NBDVdQJNBf5IRwNWOX+BGFtOtqHZiINBG8br++8H4UQf7Jfv3412Uf/AELg S5jizEW4vEdERAI/wdw6Ut4EhOERrB4XQris7Z+fgG1naEuMOAgq3/cguN21CI6dMDvqixCZWaYz RFSuhtZhBAG4Rk2ePLm23hE9OyNalwLKS4yGKATiO6j/e4Tq4fiDFGeVvoS+xVYneQuiGYjgzLBg wYJKO3bsyIGQ/xb920NwskbKK9Mh8Gvw6KOPfs6K/wdgVwOh3IuMrO++B0HqlhHP4QsE4ZW+73U/ adKk4mgAFuie4G31EdrHfPTRR7MgWrkgSssgP0eIhZBV33UQNO07lYUmKUasBQK45YbwbDqXKlUq aRIYpyj37K6U/w04/uyeCeJXlLmxBmE/EvyPu2B2+g7x20n07hhlKE4BhGjgqVOnUjMvCqJ5aEKg ttWK/YA/Rx7uo9tAbIxdEI4saFjO88GJrR+xtc+1V1eZWTEPGxH0bpKeidKsOdyduh8h2nJZRxL1 zQ5DwBAwBAwBQ8AQSBgEjEQkDK5JplSComXS6nBcDcL2vPqdd945WwIkAu0OVrRnsZofLRAjHE9i hXyLhFvMRw7MmDEjirTeqroCzSHEpSL/n6NHj56EhuEg5jZb9uzZkw/zlgysFFcmINuK5557bqmC iEEoxqGp2OmfX5GREQ7/599OERat+ENU+mLW0wLys4pV72eUdvXq1TkQsLMhvGbVqjr9eI0Ixwf8 yyA68hytzqNR2NaiRYvv6JtHImKr0zc/Ab6Okv5ziNEOzHymQyg8+3/IVk1WyWf17dt3ubBB4zET DUJ5+p0OsnS1ThEa37IC3YNRbsx2ds+fPz8bpmE5KWe7tAL0Ox9kaxWRwgvjB7A8UF7fdwj2kWAU rZ1AoN5LNO4Mvml0r6B3CswmXDF9aol51TV9+vT5BTIRiYYjxjyBfO4D3wj/MvS8cePGjL169eoA yarK+G6QtgEzuUjmR3QbmAeKrn0WQnReOwKVqXe+7YOApnLt801PNOt/4bMxB9wO6T3mYt8RgPAZ 5tdPjEsdNG0D8e1oYBsI+KJm94aAIWAIGAKGwKVFIF727Je2CVZaQiKAgLcLwaqAnGZ9Ix7L1h3B u9qrr746B+E1F6v76107lAfBOXr1m2cJg96h1WqISXr37K4IkWkgFF0QJK9GiNvq3kuwZFV8m3uW CQz3GyUou3dxXSElvWQ+g6ZjDPbyq3zTPv744ytxuJ1Dmb3QNBzCoXfO559/PsU3je4LFSq0w71j xXw3TtP13XOwKyZQB10kYDQRx1mB9/qOtiPPV199VQiNwL9UBlqXtJg1bUfwzc3qfG+9o9/rELaH 6T62A8F/38qVK3MgFO/ClyCdxgl/gbJE0d5H3kxobBpAxDytT2xl6D1k5ySEJHrFn/HNQNk7A+VB g5IPYtaN9m0k4vGL0iIgcOdkBT86v/KBe0TRokV3BSpDeWjrQEV2xu+hHxqp5eB0grkRXQbakfQQ zNNEqb6geBmufbQ/lWufawOapQwQyCpooIa4d7pqbmNONU+nzNDQSLRg7txKnx6Vts03rd0bAoaA IWAIGAKGwMUjYJqIi8cwKZVwnrDEiv82hNP0mJ7EcLKFPNyI+U91BONTUVFRW1ndz+k6gglLXoTH de4Zs5/zynXfdBUhQMi/D2FyDvb9fdj1aYT7jtZhOwJ3dvesXXbki+Ceg13xNZiGJuUIJkgttbOR tkB1eWSfD0H6Bu1AHwjGZ5hSVcZ0qLT77q6spmd096z454cYnKetcN/9rzikB+w7bTqG78RnCKlP 6WQlvC8ampGsgG8jXkcPncEIhOpC67NswoQJFa+66qoT7GY0BR+TbhCytAjef6Dd6YJm4jdpJ/zb 5f+Mz8YeTMUi3XvqjrzmmmuiyZt7j9lVbhyqu9L2CUuXLn1fZEDf0Hbspd6MvlvLolXJBbmJJoRK h0lYAfmJ6F4H5HMXu36tgwjlwodhD8Qhug2YxeVifu2AaJ1zsDmXJc5/fduHn04q1z6XCf+aCvim bJbWzL1zVxEwtEWVmAutIMY5mjRpMskIhEPnklwD/hYuSclWiCFgCBgChkDYIWAkIuyGLM4GewKh b4p69ertrlSp0q9Dhw5thIOvp13AgTYntud3Ybr0k9LyfSmr85VliiM/BvwoStauXfsv33L872XC xHEGU5UIzIoyaxUbzcZSCW2sAld26XGwXYqAeb18I0Q2cNpths9BNt/8Sjtr1qwr5Gfg8rkr9vsL ENBfwcdi1F9//VUQ+/2BmLy0ksM4xKI8ZkYtMKE5jRPyMlbWN9Ce8+Ir/Prrr2VoXxrtHkQ9ZfFN WBNXna7uuK74ZqxgFb6CMNMJXm3pm+fYHVc+/28ys0K7kVaO2fhE/AwRGC6nZ3wGpkKKRuCTEk3A /PP6PmOatBhzrqoyKxJRQ4CvDAFYqzRy3pb/gu4he7eA33wE7T9l0qRT7f/HjGgDOHo7NfG93JEj R7Kys5enzdAzfjNZITRbmUeltRuUylNdjE8BTJsW45ewFE1BEZlxqVxM1xpARr02yI8B068yyhPX 4ds++pLKtc/lwYH/Bubrn+5ZV7QS8h+5ExIzCAwqse3rVObBQGKiTPdNZ/cXjcB5f18uukQrwBAw BAwBQyBsETBzprAduoANP2/lWamwz/+SVdnW7NgzhB2S9rMyn51din6AWMzRd8yC5iIcdsfsZwBm McflUItQGKcdvsgCZk7LEVSfWrVqlQT7OQh3feTwy/u12N1vYGW9CcLjWGzXlyLk9UfY34+gtwUn 6EX++TENugZH2buff/75JWqT/8Hq+QbOUSJCaBuqs+L8AALlC9jdN8CMaCDahf1oTE6zUj2fsmLE T9BuRqxe90cjE4GJzFYE6u9VfrA6/dvg+4xgPpU+dcX34DmIV2rK38TOSGN904R6P2/evI/Ybrch uD3Mqv5WVu8PyCGcccpCXA+vrcHKgoDMxF/kevwYBkHWMmNaNhvfgRXKR7tqZs6c+ahMydDeFEYb k5f2NnRlYn62EbLyMsTyY0hfD7QaNdiZKQvj9K7TIkAa2kPSRoj04AsynfnREydzmTqlRvvyrXZP 0kmcC821JzWP5D/D+L+ueiAWBYcNG9YS4rfI1Rvo6t8+5sQw1z6lRxNVDFOsH33z3nfffe3Abj2+ EdqaN6D5lW96u483AgH/vsS7NMtoCBgChoAhENYIhGSXHtY9TB6NlxlBSGOFGU0T0gYMlCZTFVaT cyL87pAZky800hKwihuFcHlMq9K+3+K6l3kRq82eQy7269kxjToBGTmm8lhVzyzBUvlVN4LlGe3u 41ueb37f98HuVb58FbDBT6t2I0QewiTnoH8+BSfDNn4NTtlzEcwzXUjf/Mvyf5bWRj4Ben8phFeV x3aruTDPyohp2HZfHxb/umN7lkYHAneMXZ1iOEnHlt7/vZsH0kA4AuGfRs+YvGVhTLPKWd7/u/wW 0BoncmB1AAAgAElEQVRJi7Hb/9uFPEMU4TUjugfL4+ZCsHT2/aIQ2IJp34SLKsEyh4pAyH/vQy3Q 0hkCYYCAzfswGCT/JoYkmPpnsufLjkDIPy5IRA5a15LTtEyA4EgEtvye6dZlHzmrMN4IhEoi4l2B ZQwVAS04jIVEhLy4EGrBli4gAiH/vQ+Y214aAuGJgM37MBw3EzTDcNDiarL+o4dIzCBNXc4UP76Y 3izEOfeCdgeKC1/7ZgikMAREIGYYgUhho27dNQQMAUMgBARSvJAZAkZhl4T/8FdBJLStqYhEQNOm sOtUPBtMFOg4bfDjWaxlMwRSAgJb6KQRiJQw0tZHQ8AQMATigYCRiHiAFg5Z/lk5nACZyEV783Fq 1yIzXwuHwbM2egjgY6Or949BctkQkEmBdmHaxt+Qi/JpuWwttooMAUPAEDAEDAFDIFYE9B+7HYZA SkPA5n1KG3HrrxCweW/zICUiYPM+DEfd4kSE4aBZkw0BQ8AQMAQMAUPAEDAEDIHERMBIRGKif2nq jqCYwpemKCvFEDAEDAFDwBAwBAwBQ8AQMASSCwKB1Hzl6dw7nLJfPp5cOmr9MAR8EAg0730+260h kCwRsHmfLIfVOhUEAZv3QQCyz4ZAfBFwPy45ST/OuY5TgdVOcurbPk47DIHkhoCb98mtX9YfQyAu BGzex4WOfUuuCNi8D8ORtd16wmPQ9OPSWOl6iDMrpx2GQEpAwP5GpYRRtj76IuD+3vu+s3tDILkj YPM+uY+w9S/RENCPS4c0EY9xruU0TQQg2JGsEXDzPll30jpnCPghYPPeDxB7TBEI2LxPEcNsnUwM BAL9uOQT8R/OM5wnEqNRVqchkMAIBJr3CVylFW8IJDoCNu8TfQisAYmAgM37RADdqkwZCMT140oP BNekDBislykMgbjmfQqDwrqbghCweZ+CBtu6Go2AzftoKOzGELi0CNiP69LiaaWFBwI278NjnKyV lxYBm/eXFk8rLTwQsHkfHuMUo5UWJyIGHPZgCBgChoAhYAgYAoaAIWAIGALBEDASEQwh+24IGAKG gCFgCBgChoAhYAgYAjEQMBIRAw57MAQMAUPAEDAEDAFDwBAwBAyBYAgYiQiGkH03BAwBQ8AQMAQM AUPAEDAEDIEYCBiJiAGHPRgChoAhYAgYAoaAIWAIGAKGQDAEjEQEQ8i+GwKGgCFgCBgChoAhYAgY AoZADASMRMSAwx4MAUPAEDAEDAFDwBAwBAwBQyAYAkYigiFk3w0BQ8AQMAQMAUPAEDAEDAFDIAYC RiJiwGEPhoAhYAgYAoaAIWAIGAKGgCEQDAEjEcEQsu+GgCFgCBgChoAhYAgYAoaAIRADASMRMeCw B0PAEDAEDAFDwBAwBAwBQ8AQCIaAkYhgCNl3Q8AQMAQMAUPAEDAEDAFDwBCIgYCRiBhw2IMhYAgY AoaAIWAIGAKGgCFgCARDwEhEMITsuyFgCBgChoAhYAgYAoaAIWAIxEDASEQMOOzBEDAEDAFDwBAw BAwBQ8AQMASCIWAkIhhC9t0QMAQMAUPAEDAEDAFDwBAwBGIgYCQiBhz2YAgYAoaAIWAIGAKGgCFg CBgCwRAwEhEMIftuCBgChoAhYAgYAoaAIWAIGAIxEDASEQMOezAEDAFDwBAwBAwBQ8AQMAQMgWAI GIkIhpB9NwQMAUPAEDAEDAFDwBAwBAyBGAgYiYgBhz0YAoaAIWAIGAKGgCFgCBgChkAwBIxEBEPI vhsChoAhYAgYAoaAIWAIGAKGQAwEjETEgMMeDAFDwBAwBAwBQ8AQMAQMAUMgGAJGIoIhZN8NAUPA EDAEDAFDwBAwBAwBQyAGAkYiYsBhD4aAIWAIGAKGgCFgCBgChoAhEAwBIxHBELLvhoAhYAgYAoaA IWAIGAKGgCEQAwEjETHgsAdDwBAwBAwBQ8AQMAQMAUPAEAiGQLpgCex7eCNw9uzZXPQgH2dmztTh 3RtrfUpCoEqVKqnmzJlTOZn0+Sz9OMK5LXXq1LuTSZ+sG4aAIWAIGAIpGAEjEcl08CEPOehaXc78 ybSL1q1kjkClSpXUQ++f5NRVfptb6M8MyMT+5NQv64shYAgYAoZAykLAzJmS4XgjpFxLt1pyXhCB 2LVrV/px48Zd+eeff2ZJhrDEu0tr1qzJ9Nlnn+VfsWKFtDl2GAIXi4B+ly3/+Z1ebFmW3xAwBAwB Q8AQSBQEjEQkCuwJV6mPBuI8LVPBggV7Zc2adfDJkydjmDWtW7cuY+nSpe+7+uqrBz/88MPtuB98 7bXXPvjHH39kU0vbt29fU8++rb7pppua58iRY+D06dNlLhX0ePvttwvnypXrmaAJfRI0aNDgDs7G epUtW7bBEuR9Pl+S20ceeaRi69atawcq7MEHH6yifrdq1eruDz/8sNztt99+X758+Z58+umnSwVK X7Vq1Zb/+9//rvL9prTg2VH4vvDCCzf4fvO979KlS9Xrr7++i9KSp/ShQ4e83+a+ffvS3X333fXV DmH+22+/ScN03jF37twcqr9IkSIP33rrrY0mTpyY1yX65ptvomrWrNmMMro1b968nv/4u3TuGqgf gdr37bff5ilXrlx7//OBBx6o7sqya6wI6PdZ95/fa6yJ7IMhYAgYAoaAIZBUETASkVRHJv7tqkvW 8wiEhP09e/bkSZs27Zk333yzmG/x9evX74hpRapNmzb127Zt20tbtmzpnSlTpmNNmzZt75vO3deo UaPZsmXLbpg8efKwevXqhWTf3bJly7+//vrr4a6MC70iCL92yy23bL/QfLGl/+KLL/LdddddDSE3 zTZs2JDHPx19bI4An4l+jgSvSW3atFm4ZMmSt8eOHfvOlClTyvgSgv79+5dE8G6F/f7N27dvz+TK ev3114u98cYbrapVq7asY8eOPw0ZMqTNW2+9Vdh9d9fHHnusPOTjtrp16y7s1KnTj+++++7tPXr0 qKbvjRs3vguCUKp79+5TCxQosAuC0NMRDJdf1zvuuKMLl9TPPPPMV4zxaYR+b+w2b94c0a5duy6n T59OTTu/pg/FKONO37zuPrZ+xNa+woULH/nXv/612Pdcu3ZtkSxZspxwZdo1TgQ8IhFnCvtoCBgC hoAhYAgkUQSMRCTRgYlPs1jVlFYg4Go9wmxFVoz/KF++/B+YLFV05Y8aNarA+vXrrx0zZsy43Llz n9T7vHnznvzvf/87jrQr/Feta9Wq1fSvv/66btq0aa9Xr159nyvH9wphqJMnT56npam455576unb 999/n6dbt2536R6B91a0GzW0Mo5m5HmVefToUW8uIrAXrVChwr1K53sgFGsV/gqE+PwVK1Zs26xZ s/qUPwDNQG/f1f/777//JvrRTyeCfy3fMnzvEaYj9+7dm+WKK67Y4/te99KaHDx4MDOYzHzxxReL 04eO3333XdGbb765DUJ6Pb5P/Pjjj292+RYvXpw/Q4YMx9OnT3/MvdP1gw8+qHnbbbdN+89//vMb Go/VaBkWo9Go6ptG97Nnz76hUaNGP4wcOXIO5GFNw4YNf/nhhx/KHz9+PPUvv/xSgz5/0LNnzzVc fzh27FimESNGXOdbhjRJpM1EOWM7dOiw8aWXXpoFmbla5lfgeWPGjBmP/vzzz+PuvffeTV27dp3+ 008/VfMfV5UXWz9ia1/x4sUPv/LKK3+4E3ITceONNy6HPM3zbZ/dx4lA/n9+t3Emso+GgCFgCBgC hkBSQ8BIRFIbkYtrT77YsiNEVsIsZ16LFi0WcpR1q9msnl+JIL2zRIkSh33zIsgfHD9+/PcIxtpV xjtq165996xZs2ojHL+n7+6971VmNGg9qqF1GDFo0KBRaCtqy5xm9+7dGdF0FFDav//+OwqB+I6H Hnroe4Tq4fhgFGeVvoS+pUuX7gx1ntK970HegmgGIjgzLFiwoNKOHTtyIOS/FRkZuWfAgAGNlFam Q7S5waOPPvo5K/4foDGogVAeTZh8y3v22WeX/fjjj18gCK/0fa/7SZMmFUcDsED37733Xn2E9jEf ffTRLHxGcrHqvgzyc+Tw4cNZ9V3Hl19++Z3KQnuj3Xeij507d+aG8GxyL6RJQLiPcs/uSvnfvPba az+7Z8anKOOxBmE/EiyOQ16iyRomYTuXL18eoww0AscgRANPnTqVGvJXEM1DE0zXVmMedQR/jjzc R7ehcuXKuyAcWdCwnOf3Els/Ymufa6+uMrP65JNPGr3zzjuTfN/bfUgIxPq7DSm3JTIEDAFDwBAw BBIBASMRiQB6AlYZ0PFXgiUCZgSr0Os6d+68DsH0JEJrcbXjwIEDmbRSHaxNmKlcx+p9CVb+/2Y1 /tbY0q9cuTIHAnY2hNesWlWfOnXqayVLljzgn57tO+dodR6NwjaIzXdoKjwSgR/COgTS//mn932O iIg4SvrP8VHYgZnPdAiFZ/+PRqImq/iz+vbtuxztwRY0HjPRIJTHjCsdmoOrdYrQ+JYV6B4ToNyl SpXaPX/+/Gz79+/PSTnbpRWAAOQDw1Xvv/9+YbQ6ywPl9X2HYB+JRiZaO4Ewv/fEiRMZfNPoHsF+ /5VXXnmC8tNj+tQS86pr+vTp8wtkIhINR4yxgfDtA98I/zL0vHHjxoy9evXqAMmqWqxYsQ3SNmCa Fol5UXQbMLsSITkLITqvHYHK1LvY2ueb/sknn/wXPhtzwO2Q73u7DwmBgL/bkHJaIkPAEDAEDAFD IJEQMBKRSMAnULUxHKZdHaz2V8IMJmP+/Pl765Qgy6qzt0KPsLlr69atBeTA69LrKk0Fdvw3SQDX c+bMmQ8hgGMd8+bHkInyEImAzsWPP/74SgTVOZjV9MqZM+cAzIGqUedxleF7FCpUaId7ZsV8N6Sj qHsOdsUE6iDCtachQRNxHIKUXnnQduT56quvGqIReEEnmoo7MEvKNnPmzNyszvfWiUlVm2DlI/jv ExmCMB3HlyCdsHniiScqZM+efR+CeqZ///vfDcBmYbByIDsnISTRK/5gmoGydwbKhwYl33XXXdeP 9mb5/fffX5T2gX6exMwrOr/yQWYiihYtuitQGdI80NaBELcBmEPVwYTtWnA6AVGMLgPtSPo0adKc xhRtb6AyYnsXqH0uLZqlDBC/Kv369fvJvbPrBSEQ8Hd7QSVYYkPAEDAEDAFD4DIjYCTiMgN+uavT Cvq8efMqsGPOOAT/8Tq5/wwTotLa0hVhdRuCcnq0FTEcfl999dUbMUWqjpDumRYhUG+BHOxnd5+t rPZPHTZsWMtVq1ZFOxG7fsk+H43AN2gH+uCQ+xn29JUxHSrtvrsrq+kZ3T0r/vkRmM/TVrjv/lec wKNNrHy/oVE5hu/EZwjeT+mEHPWdMWPGSHY32obdeQ+dkIBhvnkC3ePHsGzChAkVr7rqqhP0dwq+ Id1Y1U+L4P3HnXfe2QXNxG/STgTK6/sOn409aHAi3Tvqjrzmmmu2uWd3xewqNw7VXWn7hKVLl74v MqBvaDv2Um9G361lIXW5WPHf6vLqCkksID8R944drXax09Y6iFAuCNweiEN0GzBry8WY7oBknXHp g11ja5/LN3DgwArMj82+Zlfum10NAUPAEDAEDAFDIHkiYCQieY5rdK9wer0BP4OT2LX/jg/CWp1o E35nhfoIOwyV1O5KBPX6dejQoY3QMHh2/jjz5iT9XfgFBFxZxp9hKgL7ERyom0VX9M8Nvg3lMTNq gQnNaQjLMvwANkBWzjPX+PXXX8vImVq7B+FnURbfhDUqgvsrYttC1b8u/2eceldgvlRB2hOd+HC0 xSHZc+z2TxvXs8ys0G6klWM2PhE/QwSGy+kZ7c1USNEIdrDKHld+9w3TpMVoBarKrEjboSLAV4YA rNV3OW/LzEz3rODfgsnQfEjXnzJp0qn2/2NGtAEcvZ2a+F7uyJEjWdlNy9Nm6HnRokVZITRbGbvS 2g1K5akuaZcwbVqMxmQpmoIiMuNSuYMHD26AJsNrg/wYMP0qozxxHbG1z+Vh96gbmEN/ume7GgKG gCFgCBgChkDyR8BIRDIf488//7wyAt4fvt3EnCVV2bJlFyNseiZN+Ap8SRyGg+weNASTnUFsbzqQ +6UQizm++dw9aU4jjI6RgzOr0CXce10RShesXr26GLsjDWQl/zH5FJBmvm8a3UNijrN63Z9V9wF6 RqD+XlfMka6B5Nyj+ws9EMynouHIgu/Bc6zED8J8KAs7I3nlXmhZaG8+wrQoE+ZeDyvGAtvBNsCZ vC0EqR34bAilPAjITMzAjuLHMAgNxlNoFhbjO7BCeWlXTb5X1T3am8L4eDQEj2HuhBA9qm+QuY8h APW0ExX3rXEi/6/TIkAa2mO2lE/aIrRD0yENPTEhe5a4Fw+hfflWuyeJJOJQ/2WTJk2ehDwMhLTl R1P0pcqm3ILSKOk+riOu9ikfpmjFwGRdXGXYN0PAEDAEDAFDwBBIXgiYLW54jKfMd4KOFeY6lUlX Kb5dktkMK9s52YFohzNjik9Z2OCnZQU+CgH8EILzebs48a59mTJl1qAJmcsqeSatuMennkB5zpw5 kwptRG59I65EQN+BQPlie6fyENRzYZ6VkfgK2xHSz9s5Kra87r20KzhOH2NXpxhO0u57sKtM0oSn NBCOQATKw65NWRjDrBCe80yt5LfA1rzSYoQU1yNQ+Zf7HU7z8KYR3S93vYlQ3++Y6M1NhHqtyqSJ QEh/75Nm061VhkC8EbB5H2/oEi9jUME08ZpmNfsgENKP62JJhE99CXrrSAS2/AHNpRK0cis8bBAw EhE2Q2UNvbQIhPT3/tJWaaUZAomOgM37RB+CC29AugvPYjkMgYtDANObhZgxXdDuQBdXo+U2BAwB Q8AQMAQMAUPAELiUCBiJuJRoWlkhIcC2r4tCSmiJDAFDwBAwBAwBQ8AQMASSJALmWJ0kh8UaZQiE hgBRrXOya1Re7eYUWg5LZQgYAoaAIWAIGAKGwMUjYCTi4jFM8iUQ9OwVtnkdRqTq13Sy/eoQApt1 lcNvfBsvh+N77723loLSxbeMUPOxc9Tgzz77LH+o6YOlI1r3tSVKlOgEBt3Yyai2+qJDW7ES6bpu kSJFuhMbop3S+ZfF9q8Vlcf3fXzK++OPP7IpOnXhwoV71KlTpwkB5qK3jdV2rNoRCkfsbsSpqKd2 +dZHROuM7IbUnB2cOrEdbj12s6rG/WN6dk7lvumT+z1xMe7gbJzc+2n9MwQMAUPAEDAEkhICCS4A JqXOpuS2EGX5DYTRx3QihD6rCNadO3eO11aqwlGC7SeffNKcLVwTfAUcofo1dlo6b8eh+IynAuSx De0DCOlLHn300SnExCjNbkYNVVaPHj0qEweiArE0piKULiJIXvvRo0dfpW9ffPFFPqVjG9lm4JdH 73TEt7wWLVq0Zavds2x/O4Htbk8Rk6Ori5tBZO0uBABM3b9//6+J/1CMXaHuPFdbqlSKq1GrVq3O xLCYt2zZsvfuv//+uS+99NKMOXPmvPHcc89NIpBgG7ZczeTS29UQMAQMAUPAEDAEDIGEQMBIREKg msTLJIbDSQTRBRAAb/VbhAAhvRFRo5/nHEzwsoZudZ5V+YenT5+ey3VJzwpSxhatnfWOFftHFcSM 4GYRbNXaGq3BIKIy9yAGQiGXRzEWiMhc3T37XhU1W9+GDx9e5I033ijK6vuDbGP6YqlSpTo6YZhI zs2p8wqlod1NtXKverSKz/ar0dGYtXI/ceLEvL7la8VeUbTdu5dffrkcfVil4HFdu3ZdhxA+DSLh xcsgVkNFhPsZBHFbJb8N4iwsJ6aCF4wNYT5y7969WYj5sMeVpWt8ytNWrOvXry+KdmUChOHv8ePH f7Nv377c0kCgVbiRQH5HCUw3Dk3PJto4HZOlahoj1de2bdvb0YT8qLYTQbsF8SaqP/XUU3XZlrfD li1bshDMbhE43ai0RCXPQpTxlozpEOJP9H7nnXe8MYntPeN+a/v27WsIR80FYS1io7L8D3C7iXnU T6eC8uk78UauJkL24wSfy6HnBx98sIo0OrrXO2KP3Kf5Bf4Pgdt1ek/gwvx6T1yLBopxgYbofjC/ qlChQo989NFHqaQZUrpgY680OuKah+dSnPtXc5gtiB8C65elwVGd+iKNkLR00t5FRUX1IY6Gp42K q53ETXnOtVNE05XlW5/dGwKGgCFgCBgCyQ2BgAJCcuuk9SdVKsyOPEFfQpYiJU+bNq0qQeiWChui GtcgPkTxKVOmvIIA9CYCbCVW46voG+nzE3QtWtvA81V6RrMxXt8R/EflyZPn5G233daK91kQJEcg EP7M9pwPKe6E0iCQncaM6rTu3TFz5swrEHzvUlA4SEpFIlsffv755+9hJX3apEmTXoHEpEaYr6n0 mzZtKoiQHUGshiyYYNWCQBz9+uuvhyIY70CbEG3GQh0n06ZNq23iog/MhsrhL5DevUAYT+PbFtoc ATmIkrDM6n9atdWlRVuTYePGjfn0jFZi2Y8//vgFxGKl+65rfMo7ceKECEFqF/OBAHlpqTsdAmw+ iFMeguVtcnVAzHYRJyILWocsekesh2vRXiyeP39+NoL6FWasPsWcahrtLAJ26xB8D4JTNqWFXNyM luME0cGHsCPWb0Sebh3Xe2JJRCEs38HYf8/2u8MhG8WJQB4jmKDyK6I4xKcB2H/+1ltvfcC8qYEW p6JIDyRrL6SwCaQr6wcffHA3JOkX5aHumsQeOYCm5yUC9kl7co+IKuOaYenSpeV3796d7dVXX/2Q tueDyDxCgLwfIDGpxo0b10QxLoKNverQEdc8PJfi3L+YiXWE8GzndzCE60760kZfmjZt2hESvIW+ 97/vvvumgGEnYR1XO5mnn7p2SrvE76k7Y/hI7969y8ZGwnzbYveGgCFgCBgChkA4IhAtHIZj463N oSPw+OOP9+SMzoBfxH6Ez5l6QSCz6gj+M2+++eZ9ekYQm6VVeW4DRqxWGtJ6K/Ks9O+SxgASUgEy MAAtwR5WY7dPmDDhJgKFlWAF+XdW3Kcrjw75D6ClqI12oCgC8jy+DWMFfLt8K44cOZIN4S0vK9ir iaY9GtOdaA3CudypUtHuAzgST1HUbUyMvmBVe6BW6SEGZ2Xe49LFdu3Zs+cifBEaP/HEE+WIQL0d oVk+EWkQEtMhtC7guQ5EYQ8mS9khQTciUK6JrSy9j095aHEOEc17A6vXjRBef2a1u9qpU6fSEaQv A9qESPp4zNWJJkFjchaNTQauh0R01Fc0FuVYwV+udGB9DdGoV4iUsOJfDCH/B70nT04IkqdtYlV/ FnB5BCi298pTpUqVOfh9rNY9Wp7vmAclBg0atETP7oBo1oSUzMIszKt/8uTJM/HFKM/3eRDU8cyJ fmi2chEVfaEri4jdfzIvNhF07wR92sLcyMf4qk+p6M8xhPkv1C/auWLnzp2R0gRBRFOhudhPO6KU Lrax1zcdMi2Lax6eS+VF6o6CmBYm7XAFVWTMv0XwPw55zQNhKQLReRtNyDG0JQs//fTT2mh7SqJR 2RZbO1UuBMhrJxh/x1yagSlaWXCqg/lbU8jybDD8GS3LYdcGuxoChoAhYAgYAuGOgGkiwn0EQ2w/ QttQhPQeOmfMmNGfCLlnunXr1kDZMWvKhQ/AelcUZh67EOqzumffKwHtzpszrIbn5n1qyMcTCLIv 6ERIuwYzJ29F3OVv1qxZfVZnHyLY3CqE9GfQKowXgdB3hMUzCNRjMEeqi2D3CivCzVjFTevyumuu XLl2iUDokECqlV+0EjFMmDD1qYp25Gmd9DcLfXtE99J8KII25jcTITJ3kK4zQvMSCaoqSxG0Wcnf +fDDD3d99913b4Fs/KLVald3oGt8y6Ou8ZCUIqyI95KgjyZmHeRihzQHkAlP66D6EKjT08fTmC55 cTUYN0/Twor/EaUTgQKz8mh0drz++uvFtm3bloeV/h3KO3To0CloMSIodwhCcU+0A55ZWmzvlYd0 Xl7dE8tjNwSxqO59D7QGeb766quGbqzHjBlzBxodb6wVfZy2/gIZuob2fOvySWMDueiSOXPmlyAf zd17XdEsHRCB0D3XU6zib9W9Dvp+Bo2QN+DBxj7Uebh48eLIHDly7HZR2WXeB4ZThA/HdhGIc7Wn SsW8gXPt8voWajsV1RySNw9CMgwTspHz5s0rwRgM1li5cu1qCBgChoAhYAiEOwLnCYTh3iFrf2AE 2J3pjFaqdUpbwPkTJjD5lRrBeSsCbU6XE5v9vKxsr3PPMi3SvcxKEEo9EyX3TVfMio5K2Fu7du2z CP5P6UQr8DRaiNm+6Vq2bLmE1diFrJzfAqG4U1uTuu8IxGkxYVmHQD1w1KhRr2Hykx5S0dh9d1fq 91av9cxKclZIQnbKPOC+64oJzV+Yz4zViXnSMXwqJuoek5tfZWKF2c9S1cOK8QBIxN8Iih5RoM3Z EI4/g0D1ZZX8VdoQgaYjThIRn/Jk4oIt/mnwHIopU1/MjUZDFqLq1au3DdKyRyvxrj8IxrkQdndo 3PQOgrcGc6YSaFIW85ga35EHMKeZDvYFIIoNMS8a6/IikJ+hfW9h0tUXR/KFEJd29CsitvfKR3ui tT+Y8eSHYMXAVmlouzD9zI01Jm59IaYj9U1mTPgbVJEw3qdPn3p6x5ilBv/7cBCfA9noQ3tG6L07 RGjdfVzXYGMf6jzEb2Q78yab2qX6pAWDOFbiN7GV+xy+wj6kLAry4/0WQm2nypRmC01KJcamFSQ9 R5MmTSY5oqTvdhgChoAhYAgYAuGOgJGIcB/BeLYfwfmQE8rkG4FZUWXFGpCdOjv9lKxdu/ZfKppV 1T0I1p5zKX4BMnHyDkiDrmdYpY1A+NqNsLnvmWee8b4rdgEr9P0wcfFIAv4TReR0C3HYxirwh3x/ npX0w9jQPywnbJkWSRhHoO8jJ2jIxpZGjRotQKA9j7AgYF+JPb7np4APRWWE1W2smB9RYzCdqSYa bZUAACAASURBVCCnZVbC92FmtEYn5Ok0Wo21upfWA5OrvGgketPu9DrRONSpW7fufOVnd6PapL1b 93Imx7SqBGYuf+o5tiM+5dGms/S9O34B16tcNCLV0YRswqH5KPUtlUmNnKzlsD548OAGELq1rn5I wmTMa27FDyEfpkuj8ZF4B83KZvwj/g25+BLtjucgrPQ4ibcDI62CH8I86FcRPYTb9LG9Vx4ITRmR HJENyiqLaZdnzoVZTmH50igNjsgrGNsKmi86mSttwdcjDPSrKd//xCzpHQjQze+//35B2paZMrNA 4pZKkEYbVVnlXOgR19irrGDzEIG+nIgnhGov83o3GpFyyterV6+q+LuUwsxq/z/vy+q95jFalyic yKPx1/u4Ds0b5tedkMFBmAlWgrBOZZ4NxGci2qQvrvz2zRAwBAwBQ8AQCBcEzCciXEbqErcTE47D CKn5ZUeOr8RcBOzumHEMYOX+OIL5TgSr5aoSW/bZmGS0hkjUw8xkIzvReL4QEgZZFV/Oqu5TlDEQ G/BPsMW/H+1CXbQKV2Da9J0cbVUGOyHVgbTscc/4IhzEfGQyguVU8pWBwNTC1j9NyZIll7IzzhBM c9azIpzlySef/Fz5fQ/q343QfT8r4WnwI0iP4++H7jtO3h0Qel/ljNX2HH+LdQjia/EneIQ6srHD 01r65zn/Igj/zPd22vWJFegrEegnOD8RV4f/Nb7l4Q8xBTv6ZrT5BDhkQjszXGWjjdiNRuZLVq6f 1FjID4CV/dddvSIE+CC8DdFqhS/FGcZkGzikkRmTdnWCYExyacF7Jrb490OUNqNVyYjPh2eXH9t7 5cOc6jgr+v0ZjwjGbCvE4Xu9p9yamCId7dChw0YIxVQE5a7U/Zy0VKTfxPexEJ7ikLiStPc5mXnV r19/Go7JrTFdexkzpzmQ1T5oVI4wb9ZCmjZgytUE5+U5Kj+UI66xV37afjaueYh5VXvMxkaA4Wrm 0NcQqw6QnMbgfAIsR6kMOVPjt9MebVhDtCY5IL6Tqfe0voVykL8d/VuPb4S2Jd4VSh5LYwgYAoaA IWAIhCMCZqMbHqMme/GgY4VfglZ4K8WnSzLtYOU0CoHwmOzafcvAXCUCgTutVsp93+teTtWslHvv ZcLBCnkUJjb7L9SJVPVLCNSWrZh/pJdztn9daDpKEZuizsqVK4ezu1OkBO5/NCL+SYM+S/OBSUta Cbv+iXEmzoXAq1XpU/7fYnuOT3mQhzSsgEcGEjZlOoaWISuC+O7Y6hTeEIq8mKMd0yp8ICxEEhHq cxGHYptvfwK9B4v2CNhr5BtC/Zn854FvO6SxcoHtArXfN6271/aptPWEfA403phgZY6L8GEOhIXW iO7KfyFjH+o8lAmdMPbvp+Y745JbmwbgAH/CtT+Uq5vHoaT1SfM7plJzfZ7tNmUjENLf+5QNkfU+ GSJg8z4MBzWoYBqGfUqOTQ7px3UxJCIcQHOCJCZPb4ZDe8OtjY5EsL3rT0mh7YFIRDIdeyMRSWHC JZ02hPT3Puk011piCFwSBGzeXxIYL28hZs50efG22i4CAVaMt2OjHrL5y0VUlSKzsm3rQvxLvF2g khoANvZJbUSsPYaAIWAIGAIpHQHTRITHDAiJoSd3TUR4DJW18lIh4KuJuFRlJtFyTBORRAcmkZoV 0t/7RGqbVWsIJBQCNu8TCtkELNd2Z0pAcK1oQ+ByIiD/FJzU88s/43LWa3UZAoaAIWAIGAKGQMpD wEhEChhzdp95hW1Fh7Gj0ms62fFnCLsgdWULzyvi23051rLLTy0cri/rHGKHobuJN9Aovu32z0fM gmwElWupHZlwTm4i51+XRtG1cRDvBFbdWrdurcjW7pN3xWE5h777voxPeYpLwG5NdYlJ0Z3IyO1U rytTTsJEE6+PU/uD7ITVXHW6b+7KDlFV9J1dne7Gn6Ecwebuw0H+SXbLKuXS+F7ZyrQl0ZSjt4KN q345GbMFbhNtxcv1rtGjR0fn8y0zlHYqfajlsX1tDpzsU4HJwxpvdvPytgv2rdPuDQFDwBAwBAwB QyDxELisAmDiddNqJlbDGwiLj+lky81niQKcsXPnzvfEFxkJnuyU1JydlC6rXw3bsU4hGvAl23Of mAlt2dXoLDEWJrA71Cl2MeqqXZO0exFxBB4gpsASgt5N+eWXX0qzY1RD4aWdk9jK82a2/7yfHYaK +mIYn/KIn1B59uzZFR566KGpRNdeRDyO9k5Ypz13IVCXwrRnKtuT7kKg7ulL3NhBqDkCfCYC5Y0E l0nEjFhIwLe3x44d+w47ZZVhp6UbXPvY/rQkBKIVcUBuZnvfTO59XPWzleu969evzw8G30CYNrdv 3/5xESWX112DtdOlC7U8thzuojw403+VNm3a02zp296VYVdDwBAwBAwBQ8AQSHwEjEQk/hhc9hYQ I+IkK/oLIADeqrsIAdt0NiJg3POcgxHgGrpVd60EK4CWa6SetRrOVqCd9Y6V80cVFE0rzDi/ts6W LdsgrVq/9957hVwehO8GnTp1qu6e47qyX/+1CKo1CPSWRSvmtGcIq+q9IQ9eeQSEq/Tyyy97QcLY KrSnIg2zbWgfgtf1J66EFyRM5QeqE0G8ErEBooVqBaZDQC6KCdAEolz/TRC7bxDIcyvQm+qgr6uI cTGHmALrCDg2DSLhBdOjrxnZJSiKSNJezAzXn/iWx5ayFSEfMwiGtor2LWLb0+VoCspou1DqrAEh +EDB8rj+APnLxLan16lOBYAjlkHmMWPGzCRfcbQZHdl2tSixLdogfNfj+0SC/N3s2kegv/yKA4E2 6ph7p2ts9WsOECjuBsr/BKKxhgjkvxNEbQNkpYxv/mDtdGlDLU8BBykzE0HsUikuBUH5ZjHHrpaZ loicrxbFlW1XQ8AQMAQMAUPAELi8CBiJuLx4J1ptrF57gr6EfUUenjZtWlVFqlaDCKpWg0i+xVm5 fgUB7U0iDVdiVbyKvpE+P4JqtLaB56v0jGZjvL4TLG0UQclOElyuFe+zILSOwPzmZwT2h5xtPuZU pxFcYw3YJRIikkE5Tw0YMKANROQYQcpuRuA9QQTlIewa9Fu/fv1aq75Nmzbl4oz8574wAn9VAoO9 R/6vCSbWWnv/61ugOuljIchJtFkMAdi0sUBqAqB5dkpEyE5LkLV0mDTlg1il8W0zfYvYu3dvlLQU iitAHIEvEOxnqC53xLc86kyr9rpyIAoZNm7cmI+IyZG04bhvwDsFAoSsRCntpEmTiqMBWKB7SFt9 yMUYIkXPIkKyoiYvw8TpCH3Kqu86CAT4ndqtgG/n3pz7N7b6eZ/666+/fkmRnJVSGhiC2l2NudRq 3/zB2unShloepmXHwHogGwWk0lyF4DUhsN1qRSaX1oj52p3nR4h8XVbj4cq3qyFgCBgChoAhYAhc PgSihcPLV6XVlBgIEJW6J2d01fhF7Mf2fqZeEGSuOoL/TCesQghmaXWaT7Fup0pabxVeAbnk0IuA XgGNxQD8CvawWrydCMw3IdSW0Oo1K/0BzY8UWO7555+vCWmpiqnOeojHV5gQLUdwPlu9evUWCJKe pkSCMRGAV6qt/ger998o2JlO7OYrozkohkZiRWx1+uZHm3KIYGIbWMFvhLnOz2hBqhH9OR1EJAME YRG+Eo2feOKJckTY3o4WQD4RaWT7jxAeMABZfMuTVojy66CB2IOpWXbI141oc9YsXLgwEiLlBfJz 7Ubjsg9iEKHnzZs350bAXjh//vxsaJVyokHaLq0ApCwf2pNVRGMuTOyH5S5vbNfY6tc4YF61S/kg E1FoY+6/4YYblmHGtc23rGDtdGlDLc+lh5SlInJ6B/qWh8CC30tjxjz4jjGYgWlWWQhvHbQtTSFM s4nM7UXjdnntaggYAoaAIWAIGAIJi4Ct4iUsvkmmdAT6oURo7qFzxowZ/YmQe6Zbt24N1ECEtFwI i+tdY4sVK7YLzUX0CrZ7ryurw+fNGUhAbt6nhnw8gYD9gk60BdcgzJ5nO+/K+vbbb/PgqDtgx44d V3D/MlGo38YXYJkETaUZOnToFATiCATzITJbws4/2qTKlaErZGaHe8asaQ++BUXcs64yvULD8bRO NAyVIDcNdC8TKH3HZ2A8QnuR5s2b9xJpgcyso84dimSNf8FEVvjvQCDvXKVKlSWYVu2/8sorAxII laUjPuUpQjTt2YlpVtd33333FsjLL5gNbae+k6y0ZzlX8rl/hQkRwj3Bnn7sA7ccmHsdZ5U/nQgO pKdC9uzZ96HJyIS2qAGr9gt98we6j61+l5YybgKfxxmv3yAMH7j37hqsnS6duwYrz6XLmDFjKvo0 EJI7AMJZB62X53CuyNuYVM1DMzIMM7eR8+bNK8GYDRbJcHntaggYAoaAIWAIGAIJi8B5AmHCVmel JzACngAeqA52ZzqDcO+d0hZw/oSgmV9pEWC3IkjndPkwl8mLoLrOPbMC7wlnMmdBiD1v+1CE2KOY mZzByfhZhN6ndOLo+zRaiNmuDP8rQvp+tAffkacYTrMtMGMq6SsEQibO0Ka3cOLti3PzQgTddqy8 eyvwvmXJP8E9qz/05YB71pWdlQ5jCjVWJ31ahQ/HH/88j5MpDILqafo1lNX9vphOjd65c2cUq97b qDvzAw88sFRmNQiyAyARfyO0b/ct2/8+vuWBVbavvvrqM4hbX/r4KivwEfhjbAejvWCSUW1xde3Z sycXuzRt1TOkbRmkqCLalBMI+VPoWzfSp0WL88edd97ZBc3Eb9JOuLyxXWOrX+kZm6qYTdVEy/Oy fDIY5/OKCdZO3wyhlMcOUwUqVqzY1uWTNuTqq69eB2GKJpIiTPJxQRPVChKco0mTJpMcAXX5wuga 6+82jPpgTTUEDAFDwBBIYQicLxGkMACSWXdj2LrH1TcE4kMQggxKI98IzH8qI6Cmk/Mru/eUxKn1 L31j1XcPAq63AoymwHMs1vt/hMkz2N9HQEh2sxq9D2de7zs28jkRLPvh5Ov5H7AiXgRfiauVzx1a 0Z88efKkLVu29EcY/p0V/wY4fA/QdqZoHbLiaNwOUyetMB/CafhXkRQEx/Quv7tizlJe9zK3oaxC CJwe+XF14vx8Sk7JOrnfh1Zjp+7lKAyxOss2td1x3L1eZaBxqE67NuFLcBTTrLyYyfSmf+l1oiGo w0r8fKWL7YhveTiL127atOndKldO7PhtlGC1/k/5XtCeDeBaTd8QmMuhScpav379nXp+5JFHVmN+ lRaNSS3w+xlCNlyO4Pg+TEUjMwL/Bc8cTGnjOmKrX6QOgf7uwYMHj2Ec9st3RafIkspTezBjyxqs nS5dqOVBfLYyB0pDqP6vvTuBs6n+/zhOGDOWaAZpoqxFsu+yRWhRIUop2lFo3yV+tP1atGjT9mv5 qwfJksoSSVRCpCJ7JPuanfB/f27OPI47987cmTvjzJn7uo/H6dzlnO/3e57fM/p+zvf7PSdQbOu1 UrBYVkObFpqP6uVy9dQMVg9FfQV6k1Q/g0aNGhVyyFxax52Dfov47zYHlZmiIIAAAgjEuABzInLX CXDcWPW0Dk0N9j1qECbbrUw1V+JHNdz6qIE9UBN8D9jkXTXYAmPpdUX7Ww0ZuUaBRGtNZl2joTKB uRB21VfDnhbrqvhDSmOQxqh/qOcS3KQGbCvNKThFgcFkNdDXWhnUsD1fQcs257O7XErvsCZEz7XF Ag31XrTQOP8rtO10jXO/SY33v3RlPl7j9kOOeVeDu5LSrmd56vank7t27bouvTyd/O0YNB9i4rPP PttZQ2UOqnGcoCv7L9vvevbCqldffXVljRo17lQPQVFN9l0ph++cfUOtM5uegppZyq+7PatCDf/T FECMceanaBjaB7LoV6xYsWaacF1YJm9aj5KTv4byvKcApJ3qoq+u1q9XoPS3elZKqWelsIZHTXG2 S2sdLn/1PCTLvpB6D+7TkpKE8hunO1lNUZ310PCvYQowlqdVTmc79XDtjSQ9C440mX6qzqVLFcQ+ pozzKrj8QnNG9ihIvFXH+ofmRjxn82BSCuXvNxH/3fr7MCk9AggggEBuEmAMsT9q04Y7RFRXmpvQ UdsGhill5NDUK5FXV3ZLaWjSfruy7N5XV4Hj1JDOZ1fo3d/be5tUrWFCge9tiInu8FSqevXqO/VM gT3B20b62cqiCcVHLcDRnIYk3YFog42DD95fzw94QbctfUQN5vxqzO5Lb75C8P7OZ7uyrrsWJYZq lNpQIl39z6eelV3O9umtM5ueJrMnqVdoZ/CxOnVjPRDuAMJdDutB0ryBJM0xiVcwtTE4Dfe24d6H yz/c9sHfR1LO4H3S+qw7bg1r3779YJuo72znnBvO51ywXqf5SWNywXFwCFknEPG/91mXJSkh4LkA 573nVZDxAkTUMM14suyRxQIR/3EpiLAnGnfVkut7mZwgIpqAJYvrieSyUEBzHtTBMaxPFiaZ05Ky wPhjBRHHBe05rZCU54QLRPzv/QkvGRkikH0CnPfZZ5ttKTMnIttovUn4WIPEnl+Q6sq9NyXKvlz1 vIKJGpaV5t2Ssi93UkYgKgH7+5xGABGVITsjgAACCHgokOuvVnto61nWapgsU4+E3fq0lZYMD23y rOAZzFh3DJqYwV3YHIGcIGDzdgggckJNUAYEEEAAgUwLEERkmi5n73jsCucYBRN2W8zSWuw2oQxf y9nVRulcAnquh30K/Mf1tV/fWle93YVpg/42t/r1ICg3AggggAACCPhLwBogvBDIbQLldEBxaRwU 530aOPyUawU473Nt1XJgaQhw3qeBw08IRCPAH1c0euybUwUOqGB2bg/XEnjeR1BBOe+DQPgYEwKc 9zFRzRxkkADnfRAIHxHIKgH+uLJKknRyksAOFcbO7UNa7Ba6q7Tcq8WG4NmL8/5fB/4bWwKc97FV 3xztvwKc9z48Exgj749K44/LH/VEKaMX2K0kimixf5vsvOffKCHwiikBzvuYqm4O9pgA5z2nAgLZ JEAQkU2wJOupQHBPxEqV5h4t9ER4Wi1k7rEA/957XAFk74kA570n7GQaCwL8ccVCLcfeMdqcCLtj 0RtamBMRe/XPEYcW4N/70C58m7sFOO9zd/1ydB4K8MflIT5ZZ5tAOaXM3ZmyjZeEfSrAv/c+rTiK HZUA531UfOyMQHgB/rjC2/BL7hXgvM+9dcuRhRfgvA9vwy+5V4Dz3od1e5IPy0yREUAAAQQQQAAB BBBAwEMBgggP8ckaAQQQQAABBBBAAAE/ChBE+LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCAAAII IIAAAgj4UYAgwo+1RpkRQAABBBBAAAEEEPBQgCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqMAAII IIAAAggggICHAgQRHuKTNQIIIIAAAggggAACfhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCfrBFA AAEEEEAAAQQQ8KMAQYQfa40yI4AAAggggAACCCDgoQBBhIf4ZI0AAggggAACCCCAgB8FCCL8WGuU GQEEEEAAAQQQQAABDwUIIjzEJ2sEEEAAAQQQQAABBPwoQBDhx1qjzAgggAACCCCAAAIIeChAEOEh PlkjgAACCCCAAAIIIOBHAYIIP9YaZUYAAQQQQAABBBBAwEMBgggP8ckaAQQQQAABBBBAAAE/ChBE +LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCAAAIIIIAAAgj4UYAgwo+1RpkRQAABBBBAAAEEEPBQ gCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqMAAIIIIAAAggggICHAgQRHuKTNQIIIIAAAggggAAC fhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCfrBFAAAEEEEAAAQQQ8KMAQYQfa40yI4AAAggggAAC CCDgoQBBhIf4ZI0AAggggAACCCCAgB8FCCL8WGuUGQEEEEAAAQQQQAABDwUIIjzEJ2sEEEAAAQQQ QAABBPwoQBDhx1qjzAgggAACCCCAAAIIeChAEOEhPlkjgAACCCCAAAIIIOBHAYIIP9YaZUYAAQQQ QAABBBBAwEMBgggP8ckaAQQQQAABBBBAAAE/ChBE+LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCA AAIIIIAAAgj4UYAgwo+1RpkRQAABBBBAAAEEEPBQgCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqM AAIIIIAAAggggICHAgQRHuKTNQIIIIAAAggggAACfhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCf rBFAAAEEEEAAAQQQ8KMAQYQfa40yI4AAAggggAACCCDgoUB+D/MmawQQQCBbBI4ePZqkhEtrKaQl b7ZkQqIIZINAw4YN88yePbtBhEkf1XZ7tWzImzfv1gj3YTMEEEAgSwQIIrKEkUQQQCAnCCh4KKZy tNKSnBPKQxkQyKhA/fr1bZfAfzKyr879ddp+moKJnRnZj20RQACBzAownCmzcuyHAAI5SkCNqMoq UFctGQogtmzZUmDUqFGn/fbbb4Vz1AF5XJgVK1YkjBw5MnnJkiXWm8Mr5wvYed/12N9Bzi8tJUQA Ad8LEET4vgo5AAQQcPVApOpdPeOMM+4qUqTIkEOHDh03rGnVqlXxNWrUuL5MmTJD+vbt213vh1Su XPm2+fPnFzXRHj16NLfPbt3zzjuvS7FixQZNnTrVhkul+3r99dfLJyUlPZruhq4N2rZte5mWS+2r okWLDrGGvOvnLHl755131rvmmmtahkrstttua2jHffXVV3f63//+V/uSSy65vnTp0g888sgj1UNt 36hRo64fffTR6e7fbFt53mi+Tz75ZBX3b+73PXv2bHT22Wf3tG21T43du3cH/p+0Y8eO/J06dWpj 5TDzH374wXqYUr1+/PHHYpZ/hQoV+l500UXtx48ff6qz0eeff16qefPmnZVG7y5durQOrn9nO2cd 6jhCle+LL74oWbt27R7Byy233NLEScvDtZ3/rY79PXhYDLJGAIFYECCIiIVa5hgRyP0CrXSIqQII a+xv27atZL58+Y689NJLldwMbdq0uVFDP/KsXbu2/4YNG55et27d/QkJCfuvuOKKHu7tnPfNmjXr vGjRoipffvnl0NatW0c0/rxr165/fvbZZy87aWR0rYbwcxdeeOHGjO4XbvtPP/20dIcOHdopuOm8 evXqksHb6Ri7qAGfoON8TV4TunXrtuCXX355/eOPPx4+ceLEmu6AYMCAAeeq4X21xu833bhxY4KT 1gsvvFDpxRdfvLpx48aLbrzxxplPPPFEt1dffbW887uzvueee+oo+Li4VatWC26++eZv3nzzzUv6 9evX2H6/9NJLOyhAqN6nT59JZcuW3aIA4Q4nwHD2t/Vll13WU6u8jz766DjV8WE1+gN199dff8V1 79695+HDh/OqnJ/pGCopjcvd+zrvwx1HuPKVL19+7wUXXLDQvaxcubJC4cKFDzpperwOBBIel4Hs EUAgBgQIImKgkjlEBHKzgK66Wq9AyKv1aszW0xXj+XXq1JmvIUv1HIf333+/7B9//FF5xIgRo0qU KHHIvj/11FMPvfvuu6O07ZLgq9YtWrS44vfffz/rq6++eqFJkyY7nHTcawUM55csWfIR66m48sor W9tvU6ZMKdm7d+8O9l4N3ovUu9HMroyrZ+RxS3Pfvn2Bf4PVYK9Yt27d62w790uNYrsKf4oa8cn1 6tW7tnPnzm2U/kD1DNzvvvp/0003nafj6G+LGv4t3Gm436sxnbh9+/bCp5xyyjb39/beek127dpV SCbTn3rqqao6hhsnT55csWnTpt3USG+t38d/8MEHTZ39Fi5cmFywYMEDBQoU2O98Z+t33nmn+cUX X/zVG2+88YN6PJarl2GhejQaubex999++22V9u3bf/3aa6/NVvCwol27dt99/fXXdQ4cOJD3u+++ a6ZjfueOO+5YofXX+/fvTxg2bNhZ7jSsJ0nbJiidj2+44YY1Tz/99AwFM2Vs+JU8z4mPj983a9as Udddd93aXr16TZ05c2bj4Hq19MIdR7jyVa1adc8zzzwz31kU3MSdc845ixU8zXWXz+P3ycf+Ljwu BtkjgEBuFiCIyM21y7EhEBsCpcMdphqR9TUsZ+5VV121QK9aztVsXT0/TQ3pzdWqVdvj3lcN+V2f fPLJFDWM7a43gVfLli07zZgxo6Uax2/Z78737rUNo1GvR2P1OgwbPHjw++qtaGnDabZu3Rqvno6y tu2ff/5ZSg3iy26//fYpalS/rDkYVXWVvpr9lj9//iPK8x97735p3zPUMxCnpeBPP/1Uf9OmTcXU yH81MTFx28CBA9vbtjZ0SGVue/fdd4/WFf931GPQTI3ylIDJnd5jjz226JtvvvlUDeGl7u/t/YQJ E6qqB+Ane//WW2+1UaN9xHvvvTdDc0aSdNV9kYKfvXv27Cliv9tr7Nixky0t9d7Y3YFSXps3by6h gGet84X1JKhxX8r57KyV/ufPPffcLOez6qei6mOFGvuJsjig4CUlWNOQsM2LFy8+Lg31COxXQDTo n3/+yavg7wz1PHTU0LXlGh61V/M5Sup9ShkaNGiwRQFHYfWwpJr3Eu44wpXPKa+tbZjVhx9+2H74 8OET3N/nkPdh/y5ySPkoBgII+FyAIMLnFUjxEUAgcBvXVAzWsFQDM05XoVfdeuutq9QwPaRGa1Xb 8O+//06wK9Wpdgr6QsNUztLV+2q68v+nrsZfFPRzyselS5cWUwO7qBqvReyq+qRJk54799xz/07Z 4Ngb3b5ztl2dV4/CBgU2k9VTEQgiNA9hlRqkHwVv7/4cFxe3T9uP1hyFTRrmM1UBRWD8v3okmusq /oyHH354sXoP1qnHY7p6EOpoGFd+9RyUscUCGndaod5rCFCJ6tWrb503b17RnTt3Flc6geUCJwAA IABJREFUG61XQAFAaRkue/vtt8urV2dxqH3d36lhn6gemZTeCTXmtx88eLCgext7r4b9ztNOO+2g 0i+goU9dNbyq3IMPPvidgolE9XAcVzcK+HbINy44Dfu8Zs2a+LvuuusGBVmNKlWqtNp6GzQ0LVHD i1LKoGFXFpAcVUCUqhyh0rTvwpXPvf0DDzxwgeZszJbbbvf3OeQ9E+JzSEVQDARyqwBBRG6tWY4L gdgROG7CtHPYutpfX8Ng4pOTk++3xRqyuuocuEKvxuaW9evXl7UJvM72traeCo3jP88a4Pa5UKFC u9UA1+iYlz5QMFFHgUTIycX33nvvUjVUZ2tYzV3FixcfqOFAjZXnAUvD/TrzzDM3OZ91xXyrgo6K zuf01hoCtUuN60APiXoiDihAKmD7qLej5Lhx49qpR+BJW9RTcZmGJRWdPn16CV2dv98WDanqll76 avjvsGBIAdMBzSXIbzb33Xdf3ZNPPnmHGuoJr7zySlvZLEgvHQU7hxSQpFzxl2lBpb051H7qQSl9 1lln9Vd5C8+ZM+cp633QcR7SMK+U/W0/BTNxFStW3BIqDet5UFkHKXAbqOFQ52sIW2U5HVSgmJKG ekcKnHTSSYc1FG17qDTCfReqfM626lkqqMCvYf/+/Wc63+Wwdci/ixxWRoqDAAI+FiCI8HHlUXQE EAgtYFfQ586dW1d3zBmlhv8ntuj9SA0hqmG3dFVjdYMaygXUW3HchN9nn332HA1FaqJGemBokRrU 6xQc7NTdfdbrav+koUOHdl22bFnKJGIndxufrx6Bz9U78KAm5I7UePoGGjpUw/ndWetqerzzXlf8 k9VgTtVb4fwevNYk8JQhVu7f1KOyX3MnRqrh/ZAtCo4enjZt2mu6u9EGjYvvZ4uCgKHufUK91zyG RWPGjKl3+umnH9TxTtTckN66qp9PDe/5l19+eU/1TPxgvROh9nV/pzkb29SDk+h8p7wTy5Urt8H5 7Kw17KqEJlT3UtnH/Prrr29bMGC/qbdju/KNd99aVkFdkq74r3f2tbWCxLI2T8T5Tne02qI7ba1S IJSkAG6bAoeUMmhYW5LqdJOCrCPO9umtw5XP2W/QoEF1dX785R525fzGGgEEEIgFAYKIWKhljhGB GBPQpNcqmmdwSOPa52gOwkpb1JswR1eo9+oOQ+fa3ZX0UK/vn3/++fbqYQiM89dk3uLavoPmBYS8 sqz5DJPUYN+rCdSdgzk1t6GOhhldpSE0hxWwLNI8gNUKVlINJ/n+++9r2mRqu3uQ5lnU0tyEFZaW 3p8S7haqwXkFf9ak3iUavlTXek9s0RyOazUhOTCxO3jbtD7bMCv1buSzidmaEzFLgcDLNulZvTeT FBQN0x2sTk5rf+c3DU1aqF6BRjasyG6HqgZ8AwUAK+13m7xtw8zsva7gX6ghQ/MUdP1mQ5pssfIf G0a0Wo6BOzXp99p79+4tortpBXoz7PPPP/9cRAHNetVdDbsblKVneVnvkoY2LVSPya/qKahgw7gs 3SFDhrRVT0agDDaPQUO/ato+ab3Clc/ZR3ePqqJz6DfnM2sEEEAg1gQIImKtxjleBGJAYPTo0Q3U wJvvPlQNZ8lTq1athWpsBoY0aa7AWD2HYZfuHvSEhuwM1u1NB+n9rwosZrv3c95rm8NqjI6wCc66 Cl3N+d7WapT+tHz58kq6O9IgXcm/x+YUaJt57m3svYKYA7p6PUBX3QfaZzWop9haw5HKKci50t5n 9KWG+ST1cBTW3IP/6Er8YA0fKqw7IwXSzWha6r15T0OLEjTcq689Y0G3g22ryeTXKkDqLp/VkaSn AGS6hoHt0zyGwerBeEg9Cws1d2CJ7atyNdfvjey9em/Ka45HO3kMdRYFRHfbbwrmPlAA0NruRKX3 12gS+btOL4KChh4atlTaeovUOzRVQcMdGkL2mJ57cbt6X76wuydZkKgJ9WM7duz4gIKHQQraktVT NNbSVrpnWI+SvU/rlVb5bD8NRaskk1VppcFvCCCAQG4WYMykP2rXhjFQV/6oK0qZdQIRnfcartNA WdbPbLY2bEZXtovrDkSbnGFMmUlLY/Dz6Qp8KTXAd6vhnOouTvquR82aNVeoJ+RHXSVPsCvumckn 1D5HjhzJo96IEvabnisRcu5AqP3CfWfpqaGepOFZ8Xq+wkY10lPdOSrcvs731ruiidP7dVen4yZJ O7+nt7YhaeZpPRBOABFqH921qbDqsIgCnlRDrWzegm7Na70YET3XI1T6J/o7TZpX3DSsTxbkO0dD 4H7MgnRIAoETIRDRv/cnoiDkEbkADdPIrbzckj8uL/XJ2yuBiM77aIOIE3VwThChsfwhh0udqHKQ T84WIIjI2fVD6bJNIKJ/77MtdxLOlED+TO3FTggggAACGRLQ0JsFGsaUobsDZSgDNkYAAQQQQOAE ChBEnEBsskIAgdgV0G1ff47do+fIEUAAAQRymwATq3NbjXI8CCCAQAwJaIJzwsiRI5Pdt4SNocPn UBFAAAHPBAgiPKMnYwQQyE4BPfTsGd3mdaieVP2cLbr96hN6sFkvm/Cb2XxtwvF1113Xwh5Kl9k0 MrNfixYtOmmCc/vM7Btqn/nz5xe1p0SXL1++3/nnn99RD3pLuX2rnupduVq1ajfLqrfueNTSjtn9 sluk2u/u7zKTnt0CVk/YblWhQoU+eiZFd8vXSdMedKc7LbXRpOzbdHvYLpan85uz1lO+G9rvugtT J80zqa07SF2vuzw9EO5WuXreR1fdoel0Z/+08tetYuNatWrVUc+36Kd1h//7v/9L2c/Z39aRlNO2 izQ93Ta2mCa055FJX6vv8ePHB55KbmnwQgABBHKawAn9H2FOO3jKgwACuVtAT1l+UY3Fe2xZvXr1 Y/YE61tvvTVTt1I1KWt4fvjhh110C9cTOhR0+PDhE3UL2KlZVVtXXXXVtbrl7VHdhnaMbjv7j56N 0cueX2EP0tPtam/R7V1/ufvuuyfq2Rk1dNejdpav3eno+uuvb9q5c+eb9AyJ4560nZn0+vXr10DP n6irZ3hM0oPiftbD+Xo4jXWVp4Ma1NU1yXiSnrmxRQ3qO9yBm26t2kUN+IRFixa9JpcJerbFAj0z 4nU9y2O4HhJXU3fAquJYDRgw4FwFEFfPnj27qZ4ZkfKgwLTy1526rvvjjz+SZfC5Aqa/evToca8F Sk6azjq9cjrbRZqenn3R0/bRMzLG5cuX77AexNfDSYM1AgggkNMECCJyWo1QHgQQyBYBPcPhkK7o /6QAIHDV3QIC3Q61vZ4a/biWIWrAtXOuutuV4KlTpyY5BbHPdjVct2i91b7TlfO77SFmdoVZt2q9 Rs+bGGxXrfUMhDOdfewZC3oicxPnc1prPbegshqqzfRE7cJ2xVzleUJX1e9X8BBI7z//+U/9//73 v7UtjTPPPPOOvn371i9VqtSDehbDAD2DoZaTdqg81RCvr/kYKY1quyWqGsgVNQRoTPfu3f/85JNP PleDvIQ9mM3y0LEus4fM9erVa9VNN930lQKJwHM1dKzxenZCKd0Gd5uTn60zm56eEVFPwcc0PTxu mc0X0fMdFqunoKbd2lV5NlNA8I4emrdC668V/CXotqdnWX72wDo9y6LQiBEjpmu/qurNuFG3t62o J0d3U+O7tX4fr2eANLVt7bVw4cJkez6HeqP2//vNv/8Nl7+dA3rmRxWl/6ECjRUvv/zyHD0Be7WC leMeUJdeOZ28Ik3PnnquNBP0sMA8N9xww5qnn356hs6xMjZMywI5dy+KkzZrBBBAwEsBgggv9ckb AQSyVUBXrwMNfWvs25OSv/rqq0Z6CN2vlqmeatxMz4eoqivXz6iB9pKerFxfV8Ub2m/aPlkN1ZTe Bn0+3T6rZ+MT+/3FF198v2TJkocuvvjiq/V9YTVah2n4zSw12G93xuZrONVhNVwP2/ahXhaEWJCh dB7Sw9S6KRDZ/9BDDzVVg/egnmz9hO7m9IOemnyN7bt27dokLYnH3pdXg7/R+++//5b2/0wPX7vG nlFhv4XKU8d4poKTlGExBw8etFt753WevaAH1eU7fPhwfg1pKq3A6iR3mXVscdu3by9lvRT2XItv vvnmUzXsp1leziuz6SnPfFZeJx0FCgXXrFlTeubMmYkqwwEFBTuc35KSkjYrWCllnydMmFBVPQA/ 2XsFbW0UXIx47733ZugJ4Um64r9IQ5z26piK2O/20hO3J1u5dbx7//3m3/+Gy1/f5/3ss8+eVjAX eI6H9cDoad1lNFxquXv/9MrpbBtpehpatl/Wg3TLYnsI4RkK8DrqAYLLdUevvdZrpPO1jz7fef/9 99ey+nDSZ40AAgh4JZDyP0mvCkC+CCCAQHYJ3HvvvXdoSUle8yJ2auz9dPtCDzJroob/dKexqoBg hl2d1k8hn1ht+2jbwFV4DafZYhN61UCvqx6LgZpXsE1XizeOGTPmPDVqq9nVa13pDzn8SGPeEx9/ /PHmCloaaajOHwo8xmkI0WI1nI82adLkKjUkAz0l1jD+9NNPl1q+wS9dvf/cHipni8bNN1DPQSV7 KnS4PN37qzdlt56qvVpX8NtruM4s9YI0/ueff/IrECmoAOFnzZW49L777qutJ1VvVC+AzYk4ycb+ qxF+0J2O8z6z6VmvkNI/Xz0Q2zTU7GQFX+eoN2fFggULEhVIHfeAOvW47FBgEGd56unTJdTAXjBv 3ryi9mRw9SBttF4BBWWl1Xuy7O233y6vZ3IsdsoXbh0uf6sHDa/aYvspmCil3pibqlSpskjDuDa4 00qvnM62kabnbK+gLI+ewn2Djq2knrw9xXrMdB5MVh1M09CsWgp4z1dvyxUKmL4dPHjwLA232uPs yxoBBBA4kQJczTiR2uSFAAInVEAN+uf37t3bz5Zp06YN0BN8j/Tu3butFUKNtCQ1Fv9wCqQnTW9R z0XKFWzne1vr6nCqfysVBJTQ93kVfNynBvaTtqi3oJwas6nGzjtpffHFFyU1UXegngR9it7/d+nS pa9rLsAia2jaNs8///xENYjj1DB/woYtaZx/ypAqJw1bK5jZ5HzWsKZtmltQwflsaxt6pR6OR2xR D0N9BTdt7b0NgbLfNWfgEzXaK3Tp0uUuC1oUzKxSnpvsSduaXzBeV/gvU4P81oYNG/6ioVU79eTp kAGEpWWvzKRnT+5WeTZraFavN99880IFL99p2NBG5XdIV9oL/5vyv/81k4oVKwYa9jqOHXIrpuFe B3SVP78FOAp66p588sk71JORoN6itrpqv8C9f6j34fJ3tlUa58nnXtXXDwoY3nG+d9bpldPZzlmn l56zXXx8vE3YHqQgd6ACzvPV6xWYcG5PDdeQqrnqGRmqYW6vzZ07t5rqbIgFGc6+rBFAAIETKZDq f4wnMnPyQgABBLJAINAAD5WO7s50RI37wGK9BVpmqqGZbNuqAbteDenizn4aLnOqGqqrnM+6Ah9o nNlwFjViCznfO2s1YvdpmMkRTTJ+TI3eh2zRRN9H1AvxrbNN8FqN9J3qPZisfSpp0uxVGsZ0rrsR qGDiiMr0qibxPqzJzQvU0O2uK++BK/DutGx+gvPZjkfH8rfz2da6s9IeDYX62BYd0zLN4Zh/7PMo GwqjhuphHdfzurr/sIZO/d/mzZtL6ar3BuVd6JZbbvnVhtWoITtQQcSfarRvdKcd/D6z6cmq6Lhx 40YqcHtYx/isrsDHaT7GRhltl0m8lcXJa9u2bUm6S9N6+6ygbZGConrqTTmoRv5EHVtvbZ9PvTjz L7/88p7qmfjBeiecfcOtw+Vv26tuGmnYVHP18vzX5mSonlMlk1453TtEkp7uMFW2Xr161zr7WW9I mTJlVilgSgkkLWCyOS7qibpaQXCxjh07TnACUGc/1zrs34VrG94igAACmRZI/S9jppNiRwQQQMAT gePGuqdVAjWIdysgKGjb2NwIDf9poAZqfpv8qrv3nKtJrb/bb7rqu00N3MAVYPUUBCYW2/fHGpNH NP4+TgHJVl2N3qHJvIHfNUa+uBqW/TXJNzD/QFfEK2iuRBnbz3nZFf0vv/xywrp16waoMTxHV/zb asL3QLudqXodimiicXcNdbIrzLs1afh7C1LUcCzg7O+sNZyljr234TZK60w1OAPBj5OnJj//Y5OS bdH7HerV2GzvbaKwAqujuk1tH03cPdvSUI9DE5VrreYS7NPQrFM1TOZ+HV8BW9RDcL6uxM+z7cK9 MpueJou3vOKKKzpZujaJXfM2qulq/W8290LlWS3XxvabGsy11ZNUpE2bNpvt85133rlcw6/yqcek hfxmKSB72SaCa+7DJPXIDNP8hcBwMNs2rVe4/C2oU4O+05AhQ0aoHnba3BVbLFiy9Kw8GsZWJL1y OttFmp4Cn/U6B2oooAoU23qtFCyW1dCmheajerlcPTWD1UNRX4HeJNXPoFGjRoUcMnfsuCP+uzi2 PSsEEEAAgVwowBWlXFipHFK6AhGd9xpSlKTl9uBFV2j3qrH9jPt7TUp9U+Pt9+jq7r0ajvSIJuyu VyCwXQ3tDWpE/6Ir8nfa9rpy/IGGPh0uVqzY5urVq8/TUJmtCg4G2G8a9vSr5lbsUOP9rmefffYF pbfL0lF++3UlfLyTn8aq/6Sg5Cvnc7i1Jkg/qYDmu1q1av2onolXdWvPA2osrlRwsU69Fl/afuqV mOq8V2BxSGX4Tb//pYnJezXJ+DMn7VB5aujT19dee+1IZxtbq7E+wtJXY/0PBUwbNWymv/O7pWHf a6L31ho1aszRkKHjbNVwf1o9GX8722c2vdGjRw8+9dRTV2sexBJLT899eM9J034rVKjQTrlvtmNU wPOi85ut1WvRx45bk5F/1/yUr+U+Tj0S32sS8kINYXvOva3z3upQ8z+GOp/D5a85B4/rzLRz77hF Ac9Y29f8nXTSKqezXUbS0zGNt3x13m2yc09B5WjLUz0Sy+1cUgD6mFP+CNYpPRjp/qWxAQLeC0T0 7733xaQEbgHGUro1cu57++OirnJu/VCy7BGI+LxXg6qjihAYppSRoqhXIq+u7JbS0KT9dmXZva+u AsdpqE0+u0Lv/t7e26RqDRMKfG9DTHSHp1IKNnZGM8nVyqKA5Kg9q0FzGpLUoNxg4+CD81aQ8YJu W/qIhiLl11yGfWrwpzlfIXh/57NdWdddixJtcrbznbO2oUS6+p9PPSu7nO/SW2c2PU1mT1IQtTP4 WJ26sR4IG5IWKn/rQVIAlKQ5JvF6lsTG4DRC7RP8Xbj8g7cL9zmScobbN9T3uuPWsPbt2w+2ifrO 78654XyOYL1OQfCYCLZjEwRyikDE/97nlAJTDhqmfjkH+OPyS01RzqwUiPi8VxBhTzTuqiXX33HO CSKiCViyspJIK2sFNOdBnSnD+kSRqgWeHyuIOC4ojiI9dkXgRAhE/O/9iSgMeUQmwJyIyJzYCgEE crDAsQaTPb8g1ZX7HFzsTBVNzyuYqKFImep9yFSG7OQnATv/pxFA+KnKKCsC/hXI9Vft/Fs1lBwB BDIioIbTMvVI2K1PW2nJ8NCmjOTl5ba6Y9BEL/Mn7+gENFwtUQ+N26mhaykP2osuxZS91+kdAUQK B28QQCC7BQgisluY9BFA4IQJHLsCO0bBhE0qLa3FbhPKfKITVgNklJ6A7ow1U+dnAc1lGav5Hp/q KelL3PvouR72MfAf9/dh3tsQELsL0wad+1vDbMPXCCCAAAIxLGD/o+CFQKwJcN7HWo3HxvHu0GHa uX1Ii01cX6XFHqvu3E2J814YvGJOgPPeh1XOFTp/VJr9cVFX/qgrSpl1AvxPJessSSlnC+xW8exp 6fbvPP/e5+y6onTZI8B5nz2upIpA4H8qMCAQawIEEbFW47FxvME9ESt12PdooSciNuqfowwtwL/3 oV34FoGoBfjjipqQBHwowHnvw0qjyOkKHNAWNo/hDS2BJ48H7cF5HwTCx5gQ4LyPiWrmIL0Q4I/L C3Xy9FqA897rGiD/7BAop0Tj0kiY8z4NHH7KtQKc97m2ajkwrwX44/K6BsjfCwHOey/UydNrAc57 r2uA/L0Q4Lz3Qj3KPHnYXJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCAAAIIRClAEBEl ILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBB RKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQ pQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAII IBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAA AggggECUAgQRUQKyOwIIIIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggg gAACCCCAQKwJEETEWo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8C CCCAAAIIIIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKy OwIIIIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETE Wo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEK EERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAAC sSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCA AAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcjuCCCAAAII IIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAACsSZAEBFrNc7xIoAA AggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCAAAIIRClAEBElILsj gAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzV OMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBB RJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBr AgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggg gECUAgQRUQKyOwIIIIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAAC CCCAQKwJEETEWo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAvlj7YA5XgQQQAAB BHKjwNGjR5N0XKW1FNKSNzceI8eU4wSOqkR7tWzImzfv1hxXOgqUrQIEEdnKS+IIIIAAAghkr4CC h2LKoZWW5OzNidQRCC+g83Cdfp2mYGJn+K34JTcJMJwpN9Umx4IAAgggEFMCarhV1gF31ZKhAGLL li0FRo0addpvv/1WOKbA0jnYFStWJIwcOTJ5yZIl1pvDK2MCdg52PXZOZmxPtvalAEGEL6uNQiOA AAIIxLqAqwci1aiCM844464iRYoMOXTo0HHDmlatWhVfo0aN68uUKTOkb9++3fV+SOXKlW+bP39+ UfPs0aNHc/vstj3vvPO6FCtWbNDUqVNtuFS6r9dff718UlLSo+lu6Nqgbdu2l2m51L4qWrToEGvI u37Okrd33nlnvWuuuaZlqMRuu+22hnbcV199daf//e9/tS+55JLrS5cu/cAjjzxSPdT2jRo16vrR Rx+d7v7NtpXnjeb75JNPVnH/5n7fs2fPRmeffXZP21b71Ni9e3egLbZjx478nTp1amPlMPMffvjB ephSvX788cdiln+FChX6XnTRRe3Hjx9/qrPR559/Xqp58+adlUbvLl26tA6uf2c7Zx3qOEKV74sv vihZu3btHsHLLbfc0sRJ69jazsVWx87NoJ/4mNsECCJyW41yPAgggAACsSLQSgeaKoCwxv62bdtK 5suX78hLL71UyY3Rpk2bGzXcJM/atWv7b9iw4el169bdn5CQsP+KK67o4d7Oed+sWbPOixYtqvLl l18Obd26dURj3rt27frnZ5999rKTRkbXagg/d+GFF27M6H7htv/0009Ld+jQoZ2Cm86rV68uGbyd jrGLGvAJOs7X5DWhW7duC3755ZfXP/744+ETJ06s6Q4IBgwYcK4a3lfPnj276caNGxOctF544YVK L7744tWNGzdedOONN8584oknur366qvlnd+d9T333FNHwcfFrVq1WnDzzTd/8+abb17Sr1+/xvb7 pZde2kEBQvU+ffpMKlu27BYFCHc4AYazv60vu+yynlrlffTRR8epjg+r0R+ou7/++iuue/fuPQ8f PpxX5fxMx1BJaVzu3td5H+44wpWvfPnyey+44IKF7mXlypUVChcufNBJ07UOBBKuz7zNpQIEEbm0 YjksBBBAAIHcK6ArvdYrEPJqvRqz9XTFeH6dOnXma8hSPUfh/fffL/vHH39UHjFixKgSJUocsu9P PfXUQ+++++4obbsk+Kp1ixYtrvj999/P+uqrr15o0qTJDicd91oBw/klS5Z8xHqYqeZRAAAS90lE QVQqrrzyytb225QpU0r27t27g71Xg/ci9W40syvj6hl53NLct29foO2hBnvFunXrXmfbuV9qFNtV +FPUiE+uV6/etZ07d26j9AeqZ+B+99X/m2666TwdR39b1PBv4U7D/V6N6cTt27cXPuWUU7a5v7f3 1muya9euQjKZ/tRTT1XVMdw4efLkik2bNu2mRnpr/T7+gw8+aOrst3DhwuSCBQseKFCgwH7nO1u/ 8847zS+++OKv3njjjR/U47FcvQwL1aPRyL2Nvf/222+rtG/f/uvXXntttoKHFe3atfvu66+/rnPg wIG83333XTMd8zt33HHHCq2/3r9/f8KwYcPOcqdhPUnaNkHpfHzDDTesefrpp2comCljw6/keU58 fPy+WbNmjbruuuvW9urVa+rMmTMbB9erpRfuOMKVr2rVqnueeeaZ+c6i4CbunHPOWazgaa67fK73 ycfOUddXvM1tAgQRua1GOR4EEEAAgVgQKB3uINWIrK9hOXOvuuqqBXrVcq5m6+r5aWpIb65Wrdoe 975qyO/65JNPpqhhbHfaCbxatmzZacaMGS3VOH7Lfne+d69tGI16PRqr12HY4MGD31dvRUsbTrN1 69Z49XSUtW3//PPPUmoQX3b77bdPUaP6Zc3BqKqr9NXst/z58x9Rnv/Ye/dL+56hnoE4LQV/+umn +ps2bSqmRv6riYmJ2wYOHNjetrWhQypz27vvvnu0rvi/ox6DZmqUpwRM7vQee+yxRd98882naggv dX9v7ydMmFBVPQA/2fu33nqrjRrtI957770ZmjOSpKvuixT87N2zZ08R+91eY8eOnWxpqffG7kiU 8tq8eXMJBTxrnS+sJ0GN+1LOZ2et9D9/7rnnZjmfVT8VVR8r1NhPlMUBBS8pwZqGhG1evHjxcWmo R2C/AqJB//zzT14Ff2eo56Gjhq4t1/CovZrPUVLvU8rQoEGDLQo4CquHJdW8l3DHEa58TnltbcOs Pvzww/bDhw+f4P4+xPuw52iIbfnKhwIEET6sNIqMAAIIIBDzAiEn/lrDUg3MOF2FXnXrrbeuUsP0 kBqtVU3r77//TrAr1enJaZjKWbp6X01X/v/U1fiLwm2/dOnSYmpgF1XjtYhdVZ80adJz55577t/B 2zds2HC2XZ1Xj8IGBTaT1VMRCCI0D2GVGqQfBW/v/hwXF7dP24/WHIVNGuYzVQFFYPy/eiSa6yr+ jIcffnixeg/WqcdjunoQ6mgYV371HJSxxQIad1qh3msIUInq1atvnTdvXtGdO3cWVzobrVdAAUBp GS57++23y6tXZ3Gofd3fqWGfqB6ZlN4JNea3Hzx4sKB7G3uvhv3O00477aDSL6ChT101vKrcgw8+ +J2CiUT1cBxXNwr4dsg3LjgN+7xmzZr4u+666wYFWY0qVaq02nobNDQtUcOLUsqgYVcWkBxVQJSq HKHStO/Clc+9/QMPPHCB5mzMlttu9/ch3oc8R0Nsx1c+FSCI8GnFUWwEEEAAgZgWOG7CtCOhq/31 NQwmPjk5+X5brCGrq86BK/RqbG5Zv359WZvA62xva+up0Dj+86wBbp8LFSq0Ww1wjY556QMFE3UU SIScXHzvvfcuVUN1tobV3FW8ePGBGg7UWHkesDTcrzPPPHOT81lXzLcq6KjofE5vrSFQu9S4DvSQ qCfigAKkAraPejtKjhs3rp16BJ60RT0Vl2lYUtHp06eX0NX5+23RkKpu6aWvhv8OC4YUMB3QXIL8 ZnPffffVPfnkk3eooZ7wyiuvtJXNgvTSUbBzSAFJyhV/mRZU2ptD7acelNJnnXVWf5W38Jw5c56y 3gcd5yEN80rZ3/ZTMBNXsWLFLaHSsJ4HlXWQAreBGg51voawVZbTQQWKKWmod6TASSeddFhD0baH SiPcd6HK52yrnqWCCvwa9u/ff6bzXRrrkOdoGtvzk88ECCJ8VmEUFwEEEEAAAQmkDD1yNOwK+ty5 c+vqjjmj1PD/xBa9H6khRDXslq5qrG5QQ7mAeiuOm/D77LPPnqOhSE3USA8MLVKDep2Cg526u896 Xe2fNHTo0K7Lli1LmUTs5Gfj89Uj8Ll6Bx7UhNyRGk/fQEOHaji/O2tdTY933uuKf7IazKl6K5zf g9eaBJ7qOG0b9ajs19yJkWp4P2SLgqOHp02b9prubrRBY/H72aIgYGhwesGfNY9h0ZgxY+qdfvrp B3W8EzU3pLeu6udTw3v+5Zdf3lM9Ez9Y70TwfsGfNWdjm3pwEp3vlXdiuXLlNjifnbWGXZXQhOpe KvuYX3/99W0LBuw39XZsV77x7lvLKqhL0hX/9c6+tlaQWNbmiTjf6Y5WW3SnrVUKhJIUwG1T4JBS Bg1rS1KdblKQdcTZPr11uPI5+w0aNKiuzo+/3MOunN9CrEPWXYjt+MqnAgQRPq04io0AAgggENMC gcanW0CTXqtonsEhjWufozkIK21Rb8IcXaHeqzsMnWt3V6pfv/73zz//fHv1MATG+Wsyb3Ft30Hz AkJeWdZ8hklqsO/VBOrO7rzsveY21NEwo6s0hOawApZFmgewWsFKqiEs33//fU2bTG13D9I8i1qa m7DC9tf7U8LdQtV+T+ulSb1LNHyprvWe2KI5HNdqQnJgYnda+wX/ZsOs1LuRzyZma07ELAUCL9uk Z/XeTFJQNEx3sDo5eJ9QnzU0aaF6BRrZsCK7Haoa8A0UAKy0bW3ytg0zs/e6gn+hhgzNU9D1mw1p ssXKf2wY0Wo5Bu7UpN9r7927t4juphXozbDPP//8cxEFNOtVdzXsblCWnuVlvUsa2rRQPSa/qqeg gg3jsnSHDBnSVj0ZgTLYPAYN/app+6T1Clc+Zx/dPaqKzqHfnM/prFOdo+lsz88+EyCI8FmFUVwE EEAAAQQkkOoq9+jRoxuogTffraPhLHlq1aq1UI3NwJAmzRUYq+cw7NLdg57QkJ3Bur3pIL3/VYHF bPd+znttc1iN0RE2wVlXoas539tajdKfli9fXkl3RxqkK/n32JwCbTPPvY29VxBzQFevB+iq+0D7 rAb1FFtrOFI5BTlX2vuMvtQwn6QejsKae/AfXYkfrOFDhXVnpEC6GU1LvTfvaWhRgoZ79bVnLOh2 sG01mfxaBUjd5bM6kvQUgEzXMLB9mscwWD0YD6lnYaHmDiyxfVWu5vq9kb1X7015zfFoJ4+hzqKA 6G77TcHcBwoAWtudqPT+Gk0if9fpRVDQ0EPDlkpbb5F6h6YqaLhDQ8ge03Mvblfvyxd29yQLEjWh fmzHjh0fUPAwSEFbsnqKxlraSvcM61Gy92m90iqf7aehaJVksiqtNFy/pTpHXb/xNhcIMF7NH5Vo XYLUlT/qilJmnQDnfdZZkpJ/BCI+7zVkp6MOK+RtXtM7XBs2oyvbxXUHok3OMKb09gn1u8bg59MV +FJqgO9WwznVXZz0XY+aNWuuUE/Ij7pKnmBX3EOlk5nvjhw5kke9ESVsXz1XIuTcgYyka+mpoZ6k 4Vnxer7CRjXSU905Kr30rHdFE6f3665Ox02STm8/53cbkmae1gPhBBDOb+617tpUWHVYRAFPqqFW Nm9Bt+a1XoyInuvhTjcL36/TULQxGUgv4vM+A2myaTYL0DDNZuAsSp4/riyCJBlfCXDe+6q6KGwW CUR83iuIKKY87epyYEJ0FuWfpck4QYTG8occLpWlmZFYThGw4OtjBRHugLGcvlunJdTD6fR1YI4P bVKT8NGL4Uw+qiyKigACCCCAgCNwrJE2TZ8zfMXcSSO71xp6s0APmFuT3fmQfo4RsHNxWlAAYYWz oV12567hWupo4ZULBIj6/FGJEV+Z8sfhUEoEIhLgvI+IiY1ymUCGz/tjPRKt5JCpoU25zI/D8U7A ehpCBRBWIntmhfWcWZBhz7Kw4WevaHlXiw27yvB5r314eSxAEOFxBUSYPX9cEUKxWa4S4LzPVdXJ wUQoYOd9pl56wnEeTda15zzk0ZXgTKXBTghkREABbB7dRSqP7mJlz+7IyK627W4tdpcwO1n5914I vBDIDoFM/08lOwpDmgicIAHO+xMETTY5SoDzPkdVB4XJIoHA07OV1iEtNgHfbj17j5YkLfbivP/X gf8ikOUC/HFlOSkJ+kCA894HlUQRs1yA8z7LSUkwBwjYfAh7bsQbWkLNieC8zwGVRBFypwB/XLmz XjmqtAU479P24dfcKcB5nzvrNdaPqpwA4tJA4LxPA4efEIhGgD+uaPTY168CnPd+rTnKHY0A5300 euzrVwHOex/WHLd49WGlUWQEEEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8rjSIj gAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEvBQgivNQn bwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggf VhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQ RHipT94IIIAAAggggAACCPhQgCDCh5VGkRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCH AgQRPqw0iowAAggggAACCCCAgJcCBBFe6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAAB BLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAII IICADwUIInxYaRQZAQQQQAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAII IIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBA AAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQRHipT94IIIAAAggggAACCPhQgCDCh5VGkRFA AAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQRPqw0iowAAggggAACCCCAgJcCBBFe6pM3 AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8r jSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEvBQgi vNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg4EMB gggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAAC XgoQRHipT94IIIAAAggggAACCPhQgCDCh5VGkRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQ QMCHAgQRPqw0iowAAggggAACCCCAgJcCBBFe6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQ QAABBLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCA AAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCA AAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsB BBBAAAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQRHipT94IIIAAAggggAACCPhQgCDCh5VG kRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQRPqw0iowAAggggAACCCCAgJcCBBFe 6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAABBBDwoQBB hA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEv BQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg 4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgIIIIAAAggg gAACXgoQRHipT94IIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAII IIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCA AAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAAC CCCAwAkX+H+rpIIgkpqmDQAAAABJRU5ErkJggg== --_004_A444A0F8084434499206E78C106220CAB920FECBMCHP058Aglobala_-- From spencer@wonderhamster.org Wed Feb 3 09:25: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 1A90628C19C for ; Wed, 3 Feb 2010 09:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, 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 45uTban5OSTD for ; Wed, 3 Feb 2010 09:25:19 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 3F10C28C11D for ; Wed, 3 Feb 2010 09:25:19 -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 0LwaYR-1NozZn1jQ7-018DgB; Wed, 03 Feb 2010 12:25:58 -0500 Message-ID: <744F3E8844A64E28B589DED58FE1E427@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , "'DRAGE, Keith \(Keith\)'" , "'DOLLY, MARTIN C \(ATTLABS\)'" , References: <14C85D6CCBE92743AF33663BF5D24EBA058BC87C@gaalpa1msgusr7e.ugd.att.com> Date: Wed, 3 Feb 2010 11:25:38 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0175_01CAA4C3.9CCE8A80" 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: V01U2FsdGVkX19m/XDa//Wg7x7nUz3qZR73ARGq3UphJhBFbFS fkEvVI1h4Ap6wL+1XOZ9tvR0lRA2J9p9H1Bc1zPQCitRyNfb0l DCLHJPfwrEbFNuRU9zC/y2BGJArJVYdRHr/X8Y5xZs= Subject: Re: [martini] Doodle Poll Revision X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 17:25:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0175_01CAA4C3.9CCE8A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable thanks, martin and keith, for raising the concern, and thanks, bernard, = for the quick adjustment. spencer ----- Original Message -----=20 From: Bernard Aboba=20 To: 'DRAGE, Keith (Keith)' ; 'DOLLY, MARTIN C (ATTLABS)' ; = martini@ietf.org=20 Sent: Wednesday, February 03, 2010 10:22 AM Subject: [martini] Doodle Poll Revision Due to conflicts with 3GPP, I've added some additional dates before = and after the week of February 22. Let's see if those work better.=20 =20 And also, the times are in PT (GMT -8). =20 =20 Sorry for the conflict and confusion. =20 Doodle poll: http://www.doodle.com/gfd9ramt42v5cxbd =20 =20 =20 From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Wednesday, February 03, 2010 1:58 AM To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org Subject: RE: [martini] Yet another Doodle Poll: Virtual Interim IV =20 As Martin indicates, this is a week when virtually every 3GPP working = group is meeting. Spare hours do not exist in that week. =20 Please find another week. =20 Keith =20 -------------------------------------------------------------------------= --- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of DOLLY, MARTIN C (ATTLABS) Sent: Wednesday, February 03, 2010 8:07 AM To: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Yet another Doodle Poll: Virtual Interim IV The week of the 22nd is 3GPP, so it would be hit or miss for me =20 From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Bernard Aboba Sent: Wednesday, February 03, 2010 1:10 AM To: martini@ietf.org Subject: [martini] Yet another Doodle Poll: Virtual Interim IV =20 The schedule of virtual interims has been somewhat grueling, but it = has been brought to our attention that just one more Virtual Interim = might help.=20 =20 So in that spirit, we're taking a Doodle poll to find an appropriate = meeting time during the week of February 22-26, 2010: http://www.doodle.com/gfd9ramt42v5cxbd =20 =20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_0175_01CAA4C3.9CCE8A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
thanks, martin and keith, for raising the concern, = and thanks,=20 bernard, for the quick adjustment.
 
spencer
----- Original Message -----
From:=20 Bernard Aboba
To: 'DRAGE, Keith (Keith)' ; = 'DOLLY, MARTIN C = (ATTLABS)' ; martini@ietf.org
Sent: Wednesday, February 03, = 2010 10:22=20 AM
Subject: [martini] Doodle Poll=20 Revision

Due to conflicts = with 3GPP,=20 I=92ve added some additional dates before and after the week of = February=20 22.  Let=92s see if those work better.

 

And also, the = times are in PT=20 (GMT -8). 

 

Sorry for the = conflict and=20 confusion.

 

Doodle poll:  = http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

 

From: DRAGE, = Keith=20 (Keith) [mailto:drage@alcatel-lucent.com]
Sent: Wednesday, = February=20 03, 2010 1:58 AM
To: DOLLY, MARTIN C (ATTLABS); Bernard = Aboba; martini@ietf.org
Subject: = RE:=20 [martini] Yet another Doodle Poll: Virtual Interim=20 IV

 

As=20 Martin indicates, this is a week when virtually every 3GPP working = group is=20 meeting. Spare hours do not exist in that week.

 

Please=20 find another week.

 

Keith

 

From:=20 martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of=20 DOLLY, MARTIN C (ATTLABS)
Sent: Wednesday, February = 03, 2010=20 8:07 AM
To: Bernard Aboba; = martini@ietf.org
Subject: Re:=20 [martini] Yet another Doodle Poll: Virtual Interim IV

The week of the=20 22nd is 3GPP, so it would be hit or miss for=20 me

 

From:=20 martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of=20 Bernard Aboba
Sent: Wednesday, February 03, 2010 1:10=20 AM
To: martini@ietf.org
Subject: [martini] Yet = another=20 Doodle Poll: Virtual Interim IV

 

The schedule of virtual interims has been = somewhat=20 grueling, but it has been brought to our attention that just one = more=20 Virtual Interim might help.

 

So in that spirit, we=92re taking a Doodle poll = to find an=20 appropriate meeting time during the week of February 22-26,=20 2010:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

 

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_0175_01CAA4C3.9CCE8A80-- From drage@alcatel-lucent.com Wed Feb 3 11:00: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 BCB9128C163 for ; Wed, 3 Feb 2010 11:00:43 -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 wIBFA5lJuHGS for ; Wed, 3 Feb 2010 11:00:42 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 3F8B028C1F3 for ; Wed, 3 Feb 2010 10:38:59 -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.14.3/8.14.3/ICT) with ESMTP id o13Idexe029318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 3 Feb 2010 19:39:40 +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; Wed, 3 Feb 2010 19:39:40 +0100 From: "DRAGE, Keith (Keith)" To: "martini@ietf.org" Date: Wed, 3 Feb 2010 19:39:37 +0100 Thread-Topic: Numbers and private networks Thread-Index: AcqlAD0riaWcoSHHQV6keflTTJLiTg== 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.64 on 155.132.188.80 Subject: [martini] Numbers and private networks X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 19:00:44 -0000 I just want to assert a couple of things that I have not seen in the ongoin= g discussions so far. 1) PBXs already have a custom and practice on assigning URIs to their exten= sions already. Some of that conforms to what RFCs say, and some of it is qu= estionable. Any solution we come up with to a Martini problem is not going = to change the set of URIs that are used within the PBX. So I would point ou= t that for private numbers we can see all of the following: sip:XXXX@subregion.region.enterprise.com sip:XXXX@subregion.region.enterprise.com;user=3Dphone tel:XXXX;phone-context=3Dsubregion.region.enterprise.com sip:XXXX;phone-context=3Dsubregion.region.enterprise.com@enterprise.com/use= r=3Dphone sip:XXXX;phone-context=3Dsubregion.region.enterprise.com@ngn-operator.com/u= ser=3Dphone sip:XXXX;phone-context=3D+XXXX@enterprise.com/user=3Dphone where XXXX are digits. Ignore the subdomains, I pulled these from a documen= t I drafted some time ago. The one you will probably not see is tel:... The first one is probably one of the most common! E.164 numbers are just a subset of the above usages.=20 For support of private numbers within VPN type scenarios, PBXs are not goin= g to map these numbers, just because the trunking is provided by a SSP. Nor= are they going to suddenly define a whole new set of identities in their D= NS.=20 2) Business trunking is in some ways a replacement for direct PBX connectio= ns or tie lines between those PBXs. Yes there is a certain quantity of traf= fic destined for, or received from, users outside the private network, but = we also need to deal with the case of replacing existing direct connections= with support from the SSP. That means that what may originally have been c= onfigured as a SIP peering link between two PBXs has to be easily replaced = by whatever solution the SSP provides, and therefore with minimal reconfigu= ration. And remember that historically, different countries have had signif= icant differences in the customs and practice of private networking, based = on tariff structures and regulatory restrictions. Therefore consider the de= ployments in a couple of other countries rather than just your own. regards Keith= From adam@nostrum.com Wed Feb 3 11:25: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 79A8B3A68AC for ; Wed, 3 Feb 2010 11:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 7l2xuhLJqKA0 for ; Wed, 3 Feb 2010 11:25: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 B05A43A67EA for ; Wed, 3 Feb 2010 11:25:15 -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 o13JPAU5057701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 13:25:10 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B69CD96.4000708@nostrum.com> Date: Wed, 03 Feb 2010 13:25: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: "Elwell, John" References: <4B6767A4.8000008@nostrum.com> <4B68A66C.50108@cisco.com> <4B69A3D2.6060309@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080803080501010004050609" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Further details around use case 3 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 19:25:22 -0000 This is a multi-part message in MIME format. --------------080803080501010004050609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/3/10 11:12 AM, Elwell, John wrote: > Yes, of course you a right about contact/record-route. I meant to ask > what would go in record-route in the non-B2BUA case, but I forgot. > Presumably the PBX can put anything in the user part, as long as it > keeps the same IP address that it registered in the host part? That's correct. In fact, if it didn't have anything useful to squirrel away in there, it could omit the user portion completely. > Concerning From, I know that sometimes there is a practice of > inserting the default value for the PBX if the request comes from > off-PBX (i.e., if the caller is not reachable from the SP via that > particular PBX), but that can often be misleading, so a value that can > be reached via some other PBX (perhaps via some other SP) would also > make sense. It comes down to policy whether the SP will accept that, > but in principle it should be possible. Right. That's pretty much what I meant by the rather vague disclaimer "subject to policy, configuration, etc." > This is probably a detail MARTINI doesn't need to be concerned with. I agree 100%. > Also I am happy to keep PAI outside the scope of MARTINI, if others agree. It's a separable issue. Reducing scope decreases the time to develop a solution; increasing scope does the opposite. If we're in the hurry that some people seem to think we are, then we should eliminate all separable issues from our work items. > Concerning RFC 4474, what you seem to be saying is that the SP would > have to sign the request, because the PBX would not have the necessary > certificate. I'm saying that my understanding of the types of environments we're interested in -- based primarily on Richard Shockey's characterization of target markets -- is that they will not generally have these kinds of certs. > So it depends on transitive trust, i.e., the SP trusts the PBX to have > trusted the UA. Yep. Not much way around that. > Of course, if the request has originated in a domain that has a domain > name published in DNS and also a certificate, then signing can take > place in that domain, and the Identity header field would simply be > passed through the PBX to the service provider. True. But if all of the above is true, I'm boggled as to why the customer you describe is using MARTINI instead of normal SIP peering. > But again, this is probably beyond the scope of our work. Exactly -- that's what I meant when I said that MARTINI probably doesn't need to open up this can of worms. (I'm personally keeping an eye on things to make sure we don't do anything to *break* the ability to do 4744 in the future, but I don't think the WG needs to spell out exactly how this is handled or by whom.) /a > John > > ------------------------------------------------------------------------ > *From:* Adam Roach [mailto:adam@nostrum.com] > *Sent:* 03 February 2010 16:27 > *To:* Elwell, John > *Cc:* Paul Kyzivat; martini@ietf.org > *Subject:* Re: Further details around use case 3 > > John: > > Thanks for taking a deeper dive into these issues. Some comments > inline. > > On 2/3/10 3:04 AM, Elwell, John wrote: >> To Paul's questions about From, To and PAI, I think we should also add Contact. >> In the following examples I will show only the flows between the SSP and the PBX >> >> 1. Inbound call to PBX. >> >> PBX SSP >> INVITEsip:123456789@10.1.2.3 >> To: Q1 (see below) >> From: Not relevant >> PAI: Not relevant >> Contact: Not relevant >> <------------------------- >> >> 180 >> Contact: Q2 (see below) >> --------------------------> >> >> 2. Outbound call from PBX. >> PBX SSP >> INVITE Any off-PBX value >> To: Q3 (see below) >> From: Q4 (see below) >> PAI: Q5 (see below) >> Contact: Q6 (see below) >> -------------------------> >> >> 180 >> Contact: Not relevant >> <-------------------------- >> >> Questions raised: >> Q1: Value of To URI in inbound INVITE request: >> In principle, it could be any value, since the request may have been retargeted to the PBX. However, in the most common case I would expect it to have a URI of the formsip:+123456789@ssp.net;useer=phone. >> > > I would agree that it can have pretty much any value. I'm not sure > we need to make any assumptions about the form it actually takes > in practice, since the value of the "To" header field is generally > useless for processing purposes. > >> Q2: Value of Contact URI sent by PBX in response to inbound INVITE request: >> >> Option 1: It must be one of the registered contact URIs (i.e., corresponding to one of the registered E.164 numbers). This is not viable for two reasons: >> a) because this would fail to identify the particular UA on the PBX that has accepted the call; >> b) because the call might have been retargeted by the PBX to a destination that is not one of the registered E.164 numbers. >> > > I agree that this approach has shortcomings. We might not see > eye-to-eye on what those shortcomings are, but as long as we all > agree that this approach is sub-optimal, we can discard it and > move on. > >> Option 2: Any value ending in @10.1.2.3. The PBX could then choose a value that identifies the specific UA that accepted the call. >> > > I think you're making some (not universally true) assumptions here > about the way the PBX behaves. In particular, you're assuming it > will act as a B2BUA for all calls. And I acknowledge that the vast > majority of PBXes do exactly this. For these PBXes, the approach > you're describing would work fine. > > Now, if someone wanted to deploy a PBX that acted as a proxy for > some of its calls (which is exactly how the PBX we're using for > our office works), then the contact URI would be whatever the > terminal itself generated. Based on the relatively broad range of > terminals I've played with, this contact URI will end up being > some kind of cookie (like a line identifier) in the user part, and > the phone's own IP address in the hostport part. > > Since the PBX, in these kinds of environments, is often straddling > a NAT boundary, it will usually need to Record-Route so that it > stays in the call. > > How all this works becomes much clearer if you look at the whole > interaction instead of just the interaction between the PBX and > the SSP: > > PBX Terminal > Internet SSP 192.0.2.3 10.20.30.127 > | | | | > | | | | > | | | | > |INVITE sip:+9919990@ssp.example.com | | > |------------------>| | | > | | | | > | | | | > | |INVITE sip:+9919990@192.0.2.3 | > | |Record-Route: > | |------------------>| | > | | | | > | | |INVITE > sip:+9919990@10.20.30.127 > | | |Record-Route: > > | | > |Record-Route: > | | |------------------>| > | | |200 OK | > | | |Record-Route: > > | | > |Record-Route: > | | |Contact: > > | | |<------------------| > | |200 OK | | > | |Record-Route: | > | |Record-Route: > | |Contact: | > | |<------------------| | > |200 OK | | | > |Record-Route: | | > |Record-Route: | > |Contact: | | > |<------------------| | | > | | | | > |ACK sip:line-1@10.20.30.127 | | > |Route: | | > |Route: | | > |------------------>| | | > | | | | > | | | | > | |ACK sip:line-1@10.20.30.127 | > | |Route: | > | |------------------>| | > | | | | > | | | | > | | | | > | | |ACK > sip:line-1@10.20.30.127 > | | |------------------>| > > > > I'll admit that's a bit hard to look at; here it is in a somewhat > less cluttered form: > > > > > The thing that's kind of nice here is that this works for both the > B2BUA case and for the proxy case. > > In any case, I don't think we need to be proscriptive about this > -- in general, having the PBX Record-Route will work; and, if > B2BUA PBXes want to use a Contact that indicates their own IP > address, they can do that. > > >> Option 3: I don't think the PBX would necessarily be able claim gruu properties for a contact URI in accordance with option 2, in which case if it needed a gruu, it would need to obtain one from the SSP using the REGISTER transaction. I really don't know if and how this would work. >> > > I go over GRUUs in the GIN draft. These GRUUs do actually have > GRUU properties (which is the point) and can be used accordingly > (including use in Contact header fields). > >> Q3: Value of To URI in outbound INVITE request: >> In most cases it would reflect the value of the Request-URI. In some cases it could differ, if the request has already been retargeted. > > Yes. > >> Q4: Value of From URI in outbound INVITE request: >> Option 1: Of the formsip:123456789@10.1.2.3. But this is a contact URI. >> Option 2: Of the formsip:+123456789@ssp.net;user=phone. >> Option 3: Of the formsip:+123456789@pbx.com;user=phone. But this brings back the whole argument about domain names. >> Option 4: Of the form tel:+123456789 >> > > Keep in mind that an unauthenticated "From" URI cannot generally > be used for anything. Really. It can't. > > So, it only makes sense to evaluate this question in the context > of RFC 4474, which actually gives some meaning to this value. In > other words, the question about what we want to put in "From" > comes down to how we want to treat identity. > > I'm not sure MARTINI has to open that particular can of worms. > However, I will make the following observations: > > 1. Option 1 would be effectively impossible to apply RFC 4474 > to, as I seriously doubt any legitimate CA will issue a cert > asserting ownership of an IP address. > > 2. Given the types of business relationships we're talking > about, the entity that seems in the best position to make an > assertion about the value in the "From" header field, which > would mean that Option 2 makes the most sense. > > 3. Option 3 gets us mired back down into the domain > conversation. Also, it would require the PBX operator to > operate as a 4474 authentication service, which seems > extremely unlikely for these kinds of deployments. > > 4. For option 4: we haven't even begun to get any kind of a > grip on how to apply identity to naked phone numbers. > > > >> Also, what if the request comes from a source that is not reachable by inbound requests, i.e., it is not from a registered E.164 number? >> > > Using an analog to deployed ISDN-connected PBXes: if I call out > from an internal extension that cannot be direct-dialed, the > calling party ID presented to the called party will generally be > the PBX's lead number. I would assume this is treated in the same > way: if the request comes from a source that is not directly > reachable by inbound requests, then the "From" header field will > generally be the PBX's lead number. Subject to policy, > configuration, etc. > >> Q5: Value of PAI in outbound INVITE request: >> Similar considerations to Q4: In addition, option 2 looks suspect, because it would require the PBX to make an assertion on behalf of the SSP. >> > > I would really rather leave this out of scope for MARTINI. If some > external body -- like SIPForum -- wants to define how this is done > to be "SIP Connect 1.2 Compliant," then that's great. But I don't > think the answer has an impact on the solution we choose, and I > don't think we want to tackle those issues in MARTINI. > >> Q6: Value of Contact URI in outbound INVITE request: >> Similar considerations to Q2, bearing in mind the source of the request might not be a UA bound to one of the registered E.164 numbers. >> > > The answer here is pretty much identical to the answer I gave for > Q2: the contact will come from the phone itself. The PBX can > either Record-Route, or it can act as a B2BUA and mint a new > contact with a state cookie that gives it a handle back to the > correct device. I prefer the latter, but acknowledge that both can > work -- and, as before, I see no reason to be proscriptive about > how this works. > > Really, once we've figured out how to route the first > dialog-establishing request, all the Contact/Route/Record-Route > shenanigans will Just Work. Making sure this particular thing > works is one of the things we did pretty well in SIP. > > /a > --------------080803080501010004050609 Content-Type: multipart/related; boundary="------------080709070900090001070203" --------------080709070900090001070203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/3/10 11:12 AM, Elwell, John wrote:
Yes, of course you a right about contact/record-route. I meant to ask what would go in record-route in the non-B2BUA case, but I forgot. Presumably the PBX can put anything in the user part, as long as it keeps the same IP address that it registered in the host part?

That's correct. In fact, if it didn't have anything useful to squirrel away in there, it could omit the user portion completely.

Concerning From, I know that sometimes there is a practice of inserting the default value for the PBX if the request comes from off-PBX (i.e., if the caller is not reachable from the SP via that particular PBX), but that can often be misleading, so a value that can be reached via some other PBX (perhaps via some other SP) would also make sense. It comes down to policy whether the SP will accept that, but in principle it should be possible.

Right. That's pretty much what I meant by the rather vague disclaimer "subject to policy, configuration, etc."

This is probably a detail MARTINI doesn't need to be concerned with.

I agree 100%.

Also I am happy to keep PAI outside the scope of MARTINI, if others agree.

It's a separable issue. Reducing scope decreases the time to develop a solution; increasing scope does the opposite. If we're in the hurry that some people seem to think we are, then we should eliminate all separable issues from our work items.

Concerning RFC 4474, what you seem to be saying is that the SP would have to sign the request, because the PBX would not have the necessary certificate.

I'm saying that my understanding of the types of environments we're interested in -- based primarily on Richard Shockey's characterization of target markets -- is that they will not generally have these kinds of certs.

So it depends on transitive trust, i.e., the SP trusts the PBX to have trusted the UA.

Yep. Not much way around that.

Of course, if the request has originated in a domain that has a domain name published in DNS and also a certificate, then signing can take place in that domain, and the Identity header field would simply be passed through the PBX to the service provider.

True. But if all of the above is true, I'm boggled as to why the customer you describe is using MARTINI instead of normal SIP peering.

But again, this is probably beyond the scope of our work.

Exactly -- that's what I meant when I said that MARTINI probably doesn't need to open up this can of worms. (I'm personally keeping an eye on things to make sure we don't do anything to *break* the ability to do 4744 in the future, but I don't think the WG needs to spell out exactly how this is handled or by whom.)

/a

 
John

From: Adam Roach [mailto:adam@nostrum.com]
Sent: 03 February 2010 16:27
To: Elwell, John
Cc: Paul Kyzivat; martini@ietf.org
Subject: Re: Further details around use case 3

John:

Thanks for taking a deeper dive into these issues. Some comments inline.

On 2/3/10 3:04 AM, Elwell, John wrote: 
To Paul's questions about From, To and PAI, I think we should also add Contact.
In the following examples I will show only the flows between the SSP and the PBX

1. Inbound call to PBX.

PBX                     SSP
      INVITE sip:123456789@10.1.2.3
      To: Q1 (see below)
      From: Not relevant
      PAI: Not relevant
      Contact: Not relevant
<-------------------------

      180
      Contact: Q2 (see below)
-------------------------->

2. Outbound call from PBX.       
PBX                     SSP
      INVITE Any off-PBX value
      To: Q3 (see below)
      From: Q4 (see below)
      PAI: Q5 (see below)
      Contact: Q6 (see below)
------------------------->

      180
      Contact: Not relevant
<--------------------------

Questions raised:
Q1: Value of To URI in inbound INVITE request:
In principle, it could be any value, since the request may have been retargeted to the PBX. However, in the most common case I would expect it to have a URI of the form sip:+123456789@ssp.net;useer=phone.

I would agree that it can have pretty much any value. I'm not sure we need to make any assumptions about the form it actually takes in practice, since the value of the "To" header field is generally useless for processing purposes.

Q2: Value of Contact URI sent by PBX in response to inbound INVITE request:

Option 1: It must be one of the registered contact URIs (i.e., corresponding to one of the registered E.164 numbers). This is not viable for two reasons:
a) because this would fail to identify the particular UA on the PBX that has accepted the call;
b) because the call might have been retargeted by the PBX to a destination that is not one of the registered E.164 numbers.

I agree that this approach has shortcomings. We might not see eye-to-eye on what those shortcomings are, but as long as we all agree that this approach is sub-optimal, we can discard it and move on.

Option 2: Any value ending in @10.1.2.3. The PBX could then choose a value that identifies the specific UA that accepted the call.

I think you're making some (not universally true) assumptions here about the way the PBX behaves. In particular, you're assuming it will act as a B2BUA for all calls. And I acknowledge that the vast majority of PBXes do exactly this. For these PBXes, the approach you're describing would work fine.

Now, if someone wanted to deploy a PBX that acted as a proxy for some of its calls (which is exactly how the PBX we're using for our office works), then the contact URI would be whatever the terminal itself generated. Based on the relatively broad range of terminals I've played with, this contact URI will end up being some kind of cookie (like a line identifier) in the user part, and the phone's own IP address in the hostport part.

Since the PBX, in these kinds of environments, is often straddling a NAT boundary, it will usually need to Record-Route so that it stays in the call.

How all this works becomes much clearer if you look at the whole interaction instead of just the interaction between the PBX and the SSP:

                                           PBX              Terminal
Internet               SSP              192.0.2.3         10.20.30.127
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |INVITE sip:+9919990@ssp.example.com    |                   |
    |------------------>|                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |INVITE sip:+9919990@192.0.2.3          |
    |                   |Record-Route:<sip:+9919990@ssp.example.com>
    |                   |------------------>|                   |
    |                   |                   |                   |
    |                   |                   |INVITE sip:+9919990@10.20.30.127
    |                   |                   |Record-Route: <sip:+9919990@192.0.2.3>
    |                   |                   |Record-Route:<sip:+9919990@ssp.example.com>
    |                   |                   |------------------>|
    |                   |                   |200 OK             |
    |                   |                   |Record-Route: <sip:+9919990@192.0.2.3>
    |                   |                   |Record-Route:<sip:+9919990@ssp.example.com>
    |                   |                   |Contact: <sip:line-1@10.20.30.127>
    |                   |                   |<------------------|
    |                   |200 OK             |                   |
    |                   |Record-Route: <sip:+9919990@192.0.2.3> |
    |                   |Record-Route:<sip:+9919990@ssp.example.com>
    |                   |Contact: <sip:line-1@10.20.30.127>     |
    |                   |<------------------|                   |
    |200 OK             |                   |                   |
    |Record-Route: <sip:+9919990@192.0.2.3> |                   |
    |Record-Route:<sip:+9919990@ssp.example.com>                |
    |Contact: <sip:line-1@10.20.30.127>     |                   |
    |<------------------|                   |                   |
    |                   |                   |                   |
    |ACK sip:line-1@10.20.30.127            |                   |
    |Route:<sip:+9919990@ssp.example.com>   |                   |
    |Route: <sip:+9919990@192.0.2.3>        |                   |
    |------------------>|                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |ACK sip:line-1@10.20.30.127            |
    |                   |Route: <sip:+9919990@192.0.2.3>        |
    |                   |------------------>|                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |ACK sip:line-1@10.20.30.127
    |                   |                   |------------------>|



I'll admit that's a bit hard to look at; here it is in a somewhat less cluttered form:




The thing that's kind of nice here is that this works for both the B2BUA case and for the proxy case.

In any case, I don't think we need to be proscriptive about this -- in general, having the PBX Record-Route will work; and, if B2BUA PBXes want to use a Contact that indicates their own IP address, they can do that.


Option 3: I don't think the PBX would necessarily be able claim gruu properties for a contact URI in accordance with option 2, in which case if it needed a gruu, it would need to obtain one from the SSP using the REGISTER transaction. I really don't know if and how this would work.

I go over GRUUs in the GIN draft. These GRUUs do actually have GRUU properties (which is the point) and can be used accordingly (including use in Contact header fields).

Q3: Value of To URI in outbound INVITE request:
In most cases it would reflect the value of the Request-URI. In some cases it could differ, if the request has already been retargeted.

Yes.

Q4: Value of From URI in outbound INVITE request:
Option 1: Of the form sip:123456789@10.1.2.3. But this is a contact URI.
Option 2: Of the form sip:+123456789@ssp.net;user=phone.
Option 3: Of the form sip:+123456789@pbx.com;user=phone. But this brings back the whole argument about domain names.
Option 4: Of the form tel:+123456789

Keep in mind that an unauthenticated "From" URI  cannot generally be used for anything. Really. It can't.

So, it only makes sense to evaluate this question in the context of RFC 4474, which actually gives some meaning to this value. In other words, the question about what we want to put in "From" comes down to how we want to treat identity.

I'm not sure MARTINI has to open that particular can of worms. However, I will make the following observations:
  1. Option 1 would be effectively impossible to apply RFC 4474 to, as I seriously doubt any legitimate CA will issue a cert asserting ownership of an IP address.

  2. Given the types of business relationships we're talking about, the entity that seems in the best position to make an assertion about the value in the "From" header field, which would mean that Option 2 makes the most sense.

  3. Option 3 gets us mired back down into the domain conversation. Also, it would require the PBX operator to operate as a 4474 authentication service, which seems extremely unlikely for these kinds of deployments.

  4. For option 4: we haven't even begun to get any kind of a grip on how to apply identity to naked phone numbers. 


Also, what if the request comes from a source that is not reachable by inbound requests, i.e., it is not from a registered E.164 number?

Using an analog to deployed ISDN-connected PBXes: if I call out from an internal extension that cannot be direct-dialed, the calling party ID presented to the called party will generally be the PBX's lead number. I would assume this is treated in the same way: if the request comes from a source that is not directly reachable by inbound requests, then the "From" header field will generally be the PBX's lead number. Subject to policy, configuration, etc.

Q5: Value of PAI in outbound INVITE request:
Similar considerations to Q4: In addition, option 2 looks suspect, because it would require the PBX to make an assertion on behalf of the SSP.

I would really rather leave this out of scope for MARTINI. If some external body -- like SIPForum -- wants to define how this is done to be "SIP Connect 1.2 Compliant," then that's great. But I don't think the answer has an impact on the solution we choose, and I don't think we want to tackle those issues in MARTINI.

Q6: Value of Contact URI in outbound INVITE request:
Similar considerations to Q2, bearing in mind the source of the request might not be a UA bound to one of the registered E.164 numbers.

The answer here is pretty much identical to the answer I gave for Q2: the contact will come from the phone itself. The PBX can either Record-Route, or it can act as a B2BUA and mint a new contact with a state cookie that gives it a handle back to the correct device. I prefer the latter, but acknowledge that both can work -- and, as before, I see no reason to be proscriptive about how this works.

Really, once we've figured out how to route the first dialog-establishing request, all the Contact/Route/Record-Route shenanigans will Just Work. Making sure this particular thing works is one of the things we did pretty well in SIP.

/a

--------------080709070900090001070203 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAxEAAAM+CAYAAABlnYyFAAACLmlDQ1BJQ0MgUHJvZmlsZQAA 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+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AeydB7glRbW2T5ocGIKA mAYBEyoqiGBAxCzqNYuRoF5zzjnniDnrVVF/r4o5omLWq6goohJERJEcJocT/u9dXV+f2j17 77NPGmbOqXqe3mvVSlW9anV3VVd17b6+kooHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeK B4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oHigeKB4oH2nugvz25UIsH igeKB4oHigcm5YHyPGnvruKX9n6ZDepYG6PtaG3Epkwq7dvedcUv7f0yG9R2Md6ONuNll0ae cZcWg8UDxQPFA/PCA+2eH6YBje+IztiR67a9/DVZH0xWvt15TKVjM1mdXH40VcI0w3Z165XW zg+mAY33am97yu3IddtefpisDyYr3+48phJ3k9XJ5Wcj7tud1w4d7G0rXIjFA8UDxQPFA9eo B/KHKrgPKtXEe6lobq+TfC8ynXR7pU+3jOnq5/WcSVu5XfDZtN0saybyeeeomz3kLOtOFNC4 +YbdbLXj5X4D94FsE2+n36Tl9po853uRsexU4XTLmK5+Xu+ZtJXbBZ9N282yZiLvWJ7IVh7P jvWZjPuu5Q915RZm8UDxQPFA8UDxwLgH/CAG5sdAyg+OiwZmmQa55rWjT4fm+tlGM2/6ZGE7 O+1oTbu9yDR1es3btmGver3KzZbdZvm9dpaaes7nnShwd6RGhDsPDt15ofWAA3yiZF8A82Mu x73PuembTvRcrheZXH4yuG0bTka3F9nZstssm1icTkLfNvK4nsm4n7B+ZRAxoYuKQPFA8UDx QPGAPOCHK5CDDhTHgqc97WkH3exmNzti2bJl116wYMHy0dHRgX4l8foEkOkbGxvrHxwc7Eu8 yCeZAegphd2kCgmR/oGBgbBFPsmFgui1DDzKUKrLND/To1592HM9UFCK+qRyKIMyw3b8VDax H3WlHGSy8iKPHaUoAz5HZifyCESBNajOMemGTdcjp6GjVKvnmVQPk6h4CLoo9JCRn8O++dQN P7iOyX5UCHnoPkcKVvK5RSbTjbx/RMfH7sxjI1iyP5rwMWRSqjtD4oVggnUWOWWsEHT0Zc+6 0Gj8gMPDw1euWbPmrNNPP/1zz3ve834g9S060KeDRaptVdmuv7UvJQWOfznmRdync41rFxcr X+J+/JqRO8bTHIv78RPrgvni6CJSWMUDxQPFA8UD89wDfla4EwWkI7/wZS972UMPO+ywg69z netsVieODmn/1q1bB4eGhvrUmVO/dXyAkDqlyPSNjIxEZ1cdk7pjbj465kPDLv4XTKDKQ/Ih Xo1Lp+7omI8dcHhA7Ke6RT7Xh4856oZeZboeFNQdcfgNXihaF6ijrhd288N8ZOigpSSRSo18 Lp/oIet6uY7WyeuEPnbhIW9eZXa8LjkPPCV04/xyG/DIZ3KWbwslGwMDd/qrKtVjhUAqk2PY jYFAGmDQ0a91MSPd0aQfgxDVoR6UZLo2PnrJJZf0/+IXv/j8cccdd6JsrdUxrAO7HlB4MCFS 24TvSMCIV8ES91OI+2bMKR+pavJAw8/C2l4zSCBL3CEjXKhvC1UeuhKiJe6nF/f4sadU3917 ki5CxQPFA8UDxQPz0QPREdWJ89Tm4Nmx6GEPe9jhxxxzzB1333133vAOavAwpA7goDrog4Z6 2IMPOC84lPPh6Zk/wIDDdDoI5ClLNGbM0Q8b2ElHnacMdKwvPvUIHXSTndATHuUgn+yGruWh c1CGccuZlsnWMkk26mw5aNTJdgxlLzro2IVG3rhlgC4n5yOXOkmhazlBt1HYsj2g9RN02SGv jljMypiHbXSwaxqwIo8PwsyD0ZRNPIFKj7qhD8xw+EFDTvTI84Owzj1kkYeWQ3DnEQdHHn8h 67R8+fKx613vejfTgPaCn//85+eL3m7QMF6wFcdh+EhZ7HLMq7iXX32t1ddIu3hGDv/I/3Ws 53Li0UZ1vCJLHrrxnE87pras+cgRF0055d1GIWt7QB2mhUxWZrxMyMrAdMjmMuhX5HkX9zr1 3hJOK6l4oHigeKB4oHigkwf8nMg7UnTs9/jEJz7x0Fvd6lb7bNmyZUgP2wEGEXRKPQMBZEZC D2sexvEgh09BPKyVQOOHzgAJOjME1nEeQaUWG+RJpgOT/SgDnssBV4qlTJQFnXyy4d5C01bw cxmMoI8uNvLZDOSSbPCzvNBWXhKoy0u+sH4uH3VGnzJtJ8+bwbnnMsZTfYOXBOpykDEt4XFe 4C7L9CQHnRQ2KjQqh56zgZNXnaLjDq6DRHkB4yfNNkiRbCSMqP0BGIzZCXVKI29d88mDUw4y yqOIXsxaKD/yl7/85XeHH374y0W7WMfWdHhWwkucRG5J4QBR5mXcqyHi+pD/Ij4EI+7lj7h2 HPfwoXGklOcDb8S2ZUPBukk/5G2TeM7pljWf8lBAzrS83sKhk1rKSvma5rx183IyXYoiRZ0q NE56rsW9T60nONvfREQD91ST+SVU/LL92nv8qTZeZjvaOHf6WGnf9j4sfmnvl9mgtovxdrRe y6btOPIO1SotYdqdgQKDBz1sWwYRovtNegwI3JFAjod7nk+ViDLg0xlMHQAe9NiJfCcdOhG2 gTx1Vao7CbIXttHnwDYdBnBkm/Km5XzT6Dy5bqJxLgLjNjI87H7zm99c9sxnPnOfxYsX1/7X 8q8N+o7k6tve9rZb3vOe9+zyzne+c1d9T8LSHJZZ9d3ylrfc8q53vevK6173uqO//vWvF2rG Z4/Pfe5zlx9xxBF0gPsvuOCCwSOPPHJ36a15wAMesIWTVQo/Z+Vz/sqO1w37Wd1rvHGe1vF5 hhGIuT62M/uwnQdKdCwGAoI4OQYCiCQ67R/nix40eGpnoVUmgZCxPUQ9eAhBnQ+8RIvyOBd4 ogfEsPx4Q4FddVypg8I80ACnfjFiEWymaEMRkeHgjfu8jfv/+q//OuCcc85ZLB/EckP52u3a 98UvfvEfN7/5zSMWxaZdEAvI9ZeloMPjyGMPHeRovpe85CW76JoYe+UrX8kytJCFn+PIKm0T 9widdtppQyeccMKyP/7xj2uxV4VEpW88LxsdpRBI/MAh5vqUx2HZQKo8dInOibjntHpKMz2I qJ2elW4a0HjG3qHQHb1+s+msXs69F5np1LF+yPZopFf5XA7cB8XkvB6L3UasnV9MAxrfRnEH Iezo9ZtNN/Vy7r3ITKeOk43BXuVzOXAf1DXn9VJ3fJB3pHh2LNFykWWahRhkIKF8PZggrwd0 LC+hA8FDWPzoMOhBix2SaeFf0ZGT2viAABnLY0Mp3jpCJ++3oepEhi3o0JTPZxlqnvXz+rge 8MBJOa2ZRyjVJeTowDZlxOc8EKWegxpsDf/oRz/6F+cmfw289rWvXfXqV796969+9auXIHuH O9xh06c+9anLkd+0aVP/gx70oD3e8pa37KKBxJpDDz105Pjjj1//7Gc/e5VsXCGf92lQsstd 73rXLfe73/2G0dcRVXA9BKOO2AOnLmqH+s1yLp/LUuGUwhnC3XaQ7aAaB0nJ8pRrGoV7IEE9 osMJn4M2kiADAHTHlaoyJRJyISOcWAo92aHDT71I0FoGERQOTXEAIDugzuhugst0LNDBzANH 2BHslqgbdeAgxudl3Ou88XcMFGhI8ne84x33VxxfpDjcQB6yrntmIpWtru1KdHx2kLxp1pHd sGe6IKlPH8SvB1HcDpJv2oSnFPYCaZQpu1ER6yNLWUknyuSckl0gKQoCpnrVNPQyPjjJ8hGb FUlEyaZ4pbydMe59KhPCmRpE1I5MTiVvWhOfsFJJwPrd5HuR6abfC286ZUxHt1m3mbSV254t u3kZs4HnD51O9pGxnN80AY2bb9jJTid67jtwH8g38U42mvTcZpPnfC8ylp0qnE4Z09F1fWfC hm11gtujjE5lT5XueO6mn8ezY32qcW8fATnyDhXfFsQ6aGYixKsHETy46TDTUQSmBzIP1EhU HgQAn7xkYk1Cotd85aMzkFSiM4M96dFpCRvoKIUN8bYZRMBDn8MzCeDImg5MqYVGOZZBlzJz eznfcvCpI3l8gAF8Ak02+vUdyYYHPvCBK9auXYvfQg4++MKFC/v0RlfFDIcutl7wghdsOvXU Uxe/4hWvWHHggQeO6G3w4Ec/+tF1shezNOhRD+znZUNT+XHyqRyBSFEmGHx0lOInt4F+zrNM g1brBqJOE3KyQ5YBTN3JT7aD4XKQsSzQR6Jjp6UTpixx4sEHYsxWRJsjq4TffM6cnGc8Fkp2 kQ6WMXkgQdv4GhFaJ+sDOZDjiMHyfIh7+Y2kU66u0Wbcw5Cv45sfZM4888yFr3/963e/8MIL FxxyyCGbXvWqV125yy67jJ599tkL3vve9+6iZY9bvv/97y+5y13usok20gzBQi0zW6BZtg0a ZI+8+93vXsFsnQbPa25961uP/L//9/+WKPU99rGP3fzIRz5y5aMf/ehNmrVbcuWVVw488YlP 3PTf//3fm7Hzn//8Z0CzFUs0Yzd0oxvdaOTpT3/6Fg1sRuClOtbQ5wNdKeiGyMMHzuO4D8dM 5mcmBhF5Q4D74IID56KLm4qgE7xOyfY68adCb9ps5mfCJjZ6sduLzFTq4/Jnw/5s2OzlHKun UC+SrTLWA3L4IcGDw3m/iXIeC+C9JvsEmB8l7rf1oH21LWfqlKbNZn7qlsc1Z8PmuPXO2GTi MLdiPSDHTMW9/QAkvnluxEEHmSN1kOODZT2II28eHW9w6fjhHPbiiS1a4oldd+LpOIZsovl5 gUp0TuFLL5mo9JJsdGzcIchsCq3k4JFRarFBPqXgkaczoXND3kfwJFfLyF5NE+63/ZanvlF/ QfzTrx2DBj7+8Y+vVEdpy6JFi2IW4aKLLhr87Gc/uwxb//rXvwbV2Vr8sY997Gp8Q50YWGjp 0noNPFZ+5Stf6fvgBz+4buXKlXX9qQ+6lAWejuBTOXhKUWnhcV5AiErVyWQdKNPaycDDHr6B 7/IwRLKO6EJby63YrQMFaDrCpmDUNdmwvgdCdR6+M4JeUiZ3VR9jywx4DDaoIPKiMYggbpmN YCARMSlIgh+VjVz1k/sH2XkV98ln+MD+Czy1d/gG33PtazA88IQnPOHaxx577Jp73vOeV374 wx9eqZmE3RWnV6xfv37opz/96ZLLLrts6PGPf/y6n/3sZ4u//vWvL9GAeM3973//TZpVW3XQ QQdtffvb377mS1/60hLB5ZqVW/vPf/5ziOVM1OOss84aet/73rf0bW972wYGCxqgLH3Uox61 denSpf0f+chHFu25555jp5xyynrN1A29+MUvXvzLX/5yo+sP5Ej1ruOT86KZocMnnk1LunUe GXiiz4e451x7TlwU00nhWRkActAKHAue8Yxn3FKjwjtrJLqX8iv9IImWFEEwWgw03Ywinxo7 bKGTUuTd2JV6v6eyEXGQhA30UlDUwe/ys0DBZjw1AKJHXnpCx2+OSQReHNRfqb5JI+/ykEn1 d6DFDd024IGn86ptilbXA9tkqY/lE61+OMCHh4zlx03UbRE8/eCTMGoZdNBXPZplRJ1QVJK4 q1Wfe4tfLYS/krA7C/YP8nEkfv1GSTf40NEPN26JVdv3JfnIJ4F4y2QZwcirbMvUfGyir/rU NIQkO6olBFfpRve32d43vMR9XDsl7ude3Me9QdefIRd9zETQidBBR65lEMH9CR6XoGRJdGpF ru8XYQu5JBPPAl2vISDdtnxkOZIdy4R9ymjas214JPSgpRR6woOZ6KZRf8Qij751wa2T7mVR D8vmZYL/+9//XqD/0bgOhkjq9IzwxlU8zrX/iiuuGFBHayH6vGkVvU9vdheocxUdW2zc+MY3 Hr32ta89evXVV/frWwoVWy/ZwiS+DciPUlVp2UNXvKgveDqHkEn1DRkIPj/oyBpCB+dwMt90 8vCUFxr3fZDIWyfxK4FERC/JB1t4PBOUCTrEijQO29HwRyUaLnNFHXM4h8EDB/2emPURDP8L dkrYyQ/k50Xcc96pvYG0Rfgh0cJv+JzjG9/4xnLF5vDjHve49ehp6d3au93tbntrABG7Nen5 26+Zhqt22223MQYRminYpAEE30/0iTaqmbnNGlTL1OhmDT5WZD6v+xSib9Is3KiOrRpQLNZs 3NAtbnGLUZUzAmSZ301vetOxv//974Pr1q1zmzm2OQXHUeAqw7wS9zhjimk6gwgaiQT0hciF uVAjwYdqvdxtdKPkTcuYpsHW6SbEDVmg6qyrFdEhxU3NeWSgKWDrzjk3MOdzPrt+hAEFB3aR SXmCxEEUMPGbtBDXD3Vw/XyjDNmmHWQ58oFAbps6VEWHHE/MsGc69ki2A6yy1TmDQyA1ZHgK WLht3SqVqn7UibzKjfJtyzIJihwV4K6LzbiYgEro8xSpLzTj6ZziTp3kQl5loRPlcb4QSaLF 0w0+WR0xvQ1dR+DU07yEByHDPSUOPXi64UTdMjsSrwYR8FRPbkoBFTcrxTv4Bje4wSF77LFH vm+4y6VenqmA1imFn8QERqwKlrjvEPfJT2qiKjnfhOJGwCGV85QtcV91DneEuCfeOYh3juhA 6LqKjppg5NVmpjsfHYGqaetrJu4TstFy39Z1GvdibMJLOtGBIcP1LBD3FvAkU3f2k0zURzj8 eHaAwyMvvdpeIgUr8RMI8ZY6cN/LdDFlO4Fji3rbDnxowL333ntYyzOuANef8fWtWLEi7rXI c2iAMXziiSeyBjyUfvvb3w7phcRyLfXY6nu5lnIs1vO0b7/99hvVspElb3zjGzdhPKXqZFOZ yX/BSnVy3QLCoCzLuZ7KBysU9QOf8yblsqZbD37Cc7kwZl6yTZbEeQeSYC0LEftKQQOHpKPW gZfoyKISEJx6mIdO4gHpMHgA4TiOD9WR6ZDQQ9by8yru8SPJcS8/RDyIXgWF8uIN6EP/Beed d96CO9/5zte2H2mLyy+/fAgbiv8RvVCu7TBzAJ2D6+GAAw6I5Ucqis0Z6oGDZbApnfo+ohmI vo0bN4Y+94zjjjtuyZ///OcBDbTrmEEXPaBSHRNNXCKOq5C3zjyPe9zQU5rOIIIC8guMoGLf 8MPufve731Kjy80aPLBGNvb7ptNNnhtiKGaDCOwo1UFJJtmOj8ESnwCMfGpc7NYBwlt1ghnV TD+h1f7C5if9ePCkcuoHF2W4vKoacY7YcZ0MKZs6+6IyPR9E1A83ymzayPOV+fGyXEfXz9By +DNdJFEu9DwPbhs5PZ2bH2BRV/i225CVeH0RxoWWlQMr9Jo65FPZyNQ3BKFc4BSGYtQ36QYd HDpJeAskA482FM83CqNxMyGjhEwc6OgGA8BeGN9rr73GFJ8P1RrjM/Um8DtibdTB1DapKlRV rrIdf6kkbe9jXsW9zht/q4mrN7rk8UVqu4hHbuzkkQmkkgke+X/84x8LtGPKCA+QpA85Evnz zz9/SPu7j3Bdk1cKuWbc5zxwmjnFXuDQfGAj1bnE/eTiPu5z8iPJ/oTGHvJx303XJddmxIba v/4mAr8nOu3odgka9tQmQQumZLFFQUpRFmW4XRO0fMjk7Z1s1Hx0k52QtT4ZcKBSOxnzaxls KdXn4nIrE1XshUBFCJuUkcrsW7VqFYHMPca8pFrp5vXRLP6oOmADF1988SCzD3/9618HP/Sh Dy36zGc+s0EdqDHtyLRMH18Pa0aCC811jXskdnIahZiWys7zUYeMH3l+cloTt1BOT2WaVUNk MAchyfs+2yIjXuQTFAjfJbU4p9pGIuby2I4j8ep2U73Cluj14Fe4YzraIgxt+2MZOJabN3GP /1Ob5vfLGAgkf0R7Sm6A/+NgpzHNNrD7FXr9it0BYlcza/g9ZJNe3KO5zrFvHvnISJ+yk6zb zvfuSkFMZNQH7NcuZ4tf+MIXbv3CF76wWf3N/n333Xdp0g9z4Hk5xmHmvBBu0HJ+J5vYE8/q NUzydcxKbhshZKyboEBNC9x60DEuGGXkMMPtH6lNOe7rc+gFmeogoq6oCgGn8bG1633ve9+b 6y3LaBpAQItBBA8KggSIM1KeE0U/8oI4CBnQ+IGPPHk6hOlGHnnkUEfHnYukGzalg3ptH134 dHDQgZXzRRe7LjZsm48tH5SFrPWxm+oYdt/61rfuqVHx0k9/+tPnpzpQx9BHx3a+9a1vLV+9 evUw03M5nTpY3rI5vxPussR3feqysPf+979/8ZOe9KTNmsEJfrITMvBJOpfaJzBS2sYedOTN T/kWcrKJYc4niVYXLvnEZ+kR9msZcFI7Gr6GVbErHcnRFv7QTtn6Y8N6MAExVXeMdZZaW3x/ DSJ+IzvsG07CJoMHnxO0ZjIPyFHivoob2qq+dpJv5O66cxM4dK1p3UPrYXeRPMs2hg4++OAN b37zmy/lYYOQ+Ku0Yw3T2bzFGtTONJvVTlckft8+++xzPV1/FMZLiT69eRp+zGMes+Fxj3vc RvRpZnSV3EaQI1Z9nZJPyddBifvucW9/AWu/gsunHjiEU8njcNohO2JgkPze0kaWxXCj7SDl ZdU2bDcEZIB2tW3rJJltbMDvUk4tn9tE3vdk4VHPVG/LB3Qlkv2oe1avlvODntUj7lO8WYWu AfTgBz7wgcU3uclNhnnpwfNK210u0T1rq64X3or0sx5cHadF3/nOdzYyO5HKyW2GLZcB3zj6 TXnnOZFek+zRseO+GW1PvlPqxst1VI8wQl1zXDIitXauoOW6xpNc6Gc4bDqz0ScR5N4d9Rbs JeWxOC/iXk6pz1l+dPzgV+P4La4nxeVWDXCXa9nekO7Ro1retFjfRSwTvJI2QBCIbp5yXqLX ss43ZBxvIo/1X3XVVf16jvTrxWBcF5rtq/u01sOOcEBdvnnN+iA0UcLWPIr7idwRF9SEQh0E HGBcjBxcoKv0sN+DAQR5rYOLvcPJq7FialvO900cnRhdCtC48TDiZu08iFKUA7/KVm/+hceg AkVkaNj0AEMMsvWcD/uQzUOOgzKhWR9cyXrbyDsgM32fk+tCXRklE9AtZZC37c9//vO7aqeC DXpYtOyDzAMMOfsi18noQscvctvM+OGTVFiM2F/2spct104Hw6wdxHa6kELEeWguN8dTWVGm y0r6QeNHqdatslG/hFYg6XBFx1VNXikGAMJxjkB90wkl6Mkn8bCVjAceyCKDEXAygUg+dA3h pXMM2ZneN3w+x718TyzVg2raABoQn6dMvz58W6aPR3dTx+ef+ofjUX1gOvTSl750Dx176uO4 S3/wgx8s0YNoF31UepGWnMEf1NLIXcXfTfwrbVQfll6u9bPMHvX/+Mc/XqidO3Y96qijhlev Xh2DQMLAZbou5EWP+gBNL3EfA2dfj9y3us3Chd8kE/c3wUhcm/apoXnkdThruZZ7T9KhzYJu KCWaDd34AUn26jw0EnRSgjVNCOQ6bzwI+rEeeXCBtvK2m2QQr5N5EJo2RGqpq2UNraN/U16o jhgf/vbpJceodmca0fImts7s++QnP7lIH1vzMXZ8LMo5aH34Fr2EWqq14Que85znsCSna8rL 6yRIO6br1ecRotApk6OZZLdJQheaQMuLIZTNoJ1q3HSUuqWk0k0k6q161rZdZ+lSvuMWSDLN eOgFp/UHOcsCI82HuPe5Jv/FuSfcrIC6H2/VzNgGtibWs3Bk8+bN/dr+dU2LkDK5LrjbJ8nV vm3qdcprxUvfQx7ykGF9zL2YmT5dQ6P6j5VR7da0QH2dahlCQ7lZbon79oPxhts6ZutRW0eJ zgxfVFyQHuEv0SzEUg8evO2f3qTE1DaDCd2k4kZvSBARSUr5hc3NLAIKhhpd2SqvsqC3yIvn 2QXoJGptJOSZPVCwREenySOP/Sy44maa5ATGbWFUckGDzpHrUlcO6AwitDvBrnwX8pvf/GbJ n/70pyXa5myj9v6+VLMUK7XudYmmqRcR/JrB2fg///M/K0SPt7APf/jD1z/5yU9ehx11oNjf uv/3v//9wv3333/4d7/73QJtd7ZRU4fLNRIf0FZnG3Rs4rz1QdGAOl3L1LlasHr16hHtgLCJ fcb15gobfbrYVnzve99bpweV/Vhf2OhTjh8a4D5XeMJDByElkUI+MvBoB6DpwKSzzc0Zuo7Q 9Q/5nG4+9dFBgSKFDP7NBx71oAJbCCFPMoSW6+v8Z3Tf8PkY9579k5vrWAInJRiDvyCIpCVM i7QUgw/gWOY3qIFCnwYJV+tj94Vqp0HxFzJLxHpx+Bpo9CuW1/7hD39YmO4hMhvtGzuCUMyd 7nSnEX3nMqKP9RZp+VN8qAedMqkDR5aP+phGSAhHIIDqELKQxEusOoZDqBI3Wj0U50nchz/4 SQknxIsZE3qF9jvy1WVZ+TPHbasdTY0kcjXTkdrO4m1hbgO8rVArsZbJdRHhfkJ7TybpI9It +vgzvodop6cdazbp2My5pPPJv7nrO/7447eccMIJEdvSj7pxneiZEvvoN236HDv5RnyX01Sl PVp4eR6cJLsgcU/GFynvtgwhy4ZC+jHN9+ScZ7wbz/qWNRQdnwhU0PQ2MJ7LiY5O3c5tZHNS Lgde4l5O0Mugi9O1EP7RLkvrNCu8kd3H+G6HGTLajC2J9YeLV0kl5HRP3+A4x8k//OEP15Dn /qv+0chPfvITXqr2vfzlL49rAvwXv+2J0O8AACAASURBVPhFfC+EDM8dybAMOexppnqLlk71 852EvrsIO9pEheWD/drJaQv6KTYith2/0J2oZ6pTkPI8OMl6xOg8ifs474l+pjKIiIbDp+ng wuSI2QcGChzk6UTL8fW/mHowQYOqEWo7kgGPO3PCa75kY3o80WnIKFcg5KUHqe7AZkEddP0Q QFz0BFfLIAIe+hzUiQMaP8ibR16pzqe61zTrWl556hYdJe1hvEBvjFaoM3+ZOv7rNBuwx8kn n7xSa1o3qqO/jOUa+gh9i6b9lmmwsFJbl13F0g1dkLsqjT30oQ/drO3/hrTeb6l2M9iof4zc rH8uXap9lwff8Y53rP3Vr361QH9atFxvY7fowdL33Oc+dznT4prWW3/GGWcMPuIRj1iuC2md PsTbrDfBC7Wkienv8Ad19DlzvsbTeQiMd6bImJ9D6ErhHGwkP9UXbcWuftHTEQ8gUaorE2Sc bjwUKtHgQ2/SwhZ0HbSrlzMhF7sz0d7ikTwwqjKpEyK5Gds3fL7EfX4d4Gh8KxAHPB3b5KEp 0eHfrAH00IMf/OB9NP288fa3v/1mtva7/vWvH99Pic82f4O6NvbUYHeT/oBrq/jD4m9JbRlx Bq5jjD/l+u53v7tQg49Bzejxp1sRz9wDXC/KBTctuz9ErFoHuXQeAUWv88jYjiFMpVBCNum7 3IqbflMZO2vct5zLdDPyE85s66fp2u5Fn/IlF+3Wi3wu4zjIaZPB8ziZTj1cZm7PtBx24lO2 Uj0IyHXA0SPRTgl29JllgclurW+ertWaZnvmkQfP89DyBM91yek5nuu7HvBF52Sb+lNq/7y8 yeLUiXOgPpPVnQl5ypedWS+bnZb08ifONSvPZRtO+ZQ4D8WTB9m1HS37q9uYe7z6Ti0x5fMn FojH9Byo9UHgkWinBDvW17JAbANzGvrzJe6nMogI//KTEh1m7MQhx8WyJcHYBk302PYvo0fn n3zSVxtUiTwYIOercZJE1bpkRIvvIJJK3CiQkx5smwpb5JFPdmpeLgfPfAwohZzt53kYSmEb mOsKjwEENAZN4g8cddRRG44++mh20ug/8sgjN5577rkL1ZHaxB+rMFDQCHrgpJNOWqHZhw3i 831EPzMNGnwskdxWbGk0P/ya17wm/hlSdhgsbGA7Mx1sdzYmm0P6w5YxDUYWamp8rd7OjrFe XMtDRtXRWqDBSHw8LDrqtZ84L+zLb/Z98PlRCro7YBCQRQc/+0JUXuTq5iiImC8sZOH5AquY yY5lq2x1s0dXCR0UQy/J1bQkkPPAo6AkSwxyoxCo/nQIZbUHgw0veaH9prpvOFWY93Gf2qG+ DuTbiCGg3B0D9ny2QoOBMQ2gL9aAeJneTC3Tco1dVuubIL1xWqMBxVZiVt9LXC7+kq997Wvs F75i3333HdEgeZ0GFPzDF0Uya7drIPrhGtIuNpuYtaCtSbS9EmjEBdBxkGRCXXUMmfgJSv2Q LXFf+WOH+NV125fiKO4ryntQGA9q2pdjeyXiRofrFOHjWOqhDm07JjLSQsc+qXle7eSaMnkd sAO/qWeZicqBbxnrAG3PfMpoJ8e1mOhxQunaNA1YnWhuPOGwOFJZ20iYvw0jEdCbSKaT7o5A n8m4lx9m4gLBn3JrZSq1S692I74n0qG9SC7D7dDUQ64pY1lg4keZOd34ROXAt4x1gK6H+dSh ndx8ivupDiLCn/qJDjO+TXgMHNJMRCw5EJ0dPJALqI4dV7Z8X80k0Ahkkr7xkMlkxe6rP54W jnwcyRY3dOsgG7zUyTUefHjQ0bMc5UOjnsCqOlVV4LkM5Ek6v4D6CYL0atswbBd76F7rWteK D82xrU5PP29Qk09CFlxbpA3qz4WWa0lTLF1SGX2rtRzJ9WQQgVxlvq9PW6ZFfcmzW8eGDRsG tMVadH7uc5/7LFcdIjEr0fz3RtmMc0y2kaMe4RMe1sZdlsqNepI3Lcm0yPrhHsTqR0W0DASw E3cJ6MaT/eruAVE+Ew2+L9D8ZlDPONh2COoHHWjUEag8cSe0HqDEeYjm9vK+4THYg67DMS20 bcpljM+buCeGleTiqrOOb8lzwHM+tUH42TrI6KO7Me0hvl7ruNfzZ0L6A63lWt+9SsuRLkdH A+E+8Tbq2KRrYkAfWi971rOetfL//u//YtcP2ejTkr+1TJFTB01Zs9YxyqH9wZFRasKguV4h MS4TJwSN+iNDkr04L/KmQZcMoJadJ3Ef5zzNn/w67miKzlOKpRYZtUFHfdqEg3YiDvL26qbX UsAEmaYd4iMvZwJ16hT1d/w4300PWfmi43mjm9nraMo+6VTf5DuB8c5mLuu6uiwKgoY8cjnd lYCW6NQ/UtJxtgXCo562Bd5M1m/Ha8pm51yX35TJ8r5fZKQZQ7u2n0uZzbjHbypnm3OUr8Xa huwq1YyGfltbVhIMfkOnbtdMriNKDEw17vNyiQHuJZ3OkXKQxw+uTC5rW8g5WR65nG4+tESv lZKORVogPOppW+1i2/rteC3GlEGGuqHT5LXJ1+fdhtcTaTqDCAqgAvQq6kMnEB1nIAc8XRzx YTVQeZxFhyMe/MpG5wM5cB0keORDVs6AHge6ZPmR/bBBkMg2JN7+By/hgFqW+pBPdgMPARFs C5hkAqZMTot6UKZSlA+TepHPcGyGEHRwyaBD8vkFRFfrwMee+tSnrtOHSZvh82GSBxvJdvgC Hgagme681gOO8d8ZrB/0x9P8cVFam5jroU9l7d8acv6+6DL7nBbFhJ5Anq/xjF/bb0dTGZBb UiorBgiJXzsLHvXV4QFE8KDLCOQaCg+7DWj9iDsJ2HfEow/aqm6vMNL5h/IsHzC1b7QzOPy5 GPe4hAZPPsf5bv+Y/UnsnM41iUy/BgO7aj/8rdohbAN6+oZhVAOKDRr0LlmzZs2AlvqtYLCs b4Hi+x59/M4HpBu1nnyR/mBrkPimfP1Tb0xXg2PXdSEv3/t+UgWsRKCnFHEglbp+1iXmuCeZ Z3nyJMkBgp/yNZ7ygJBr6NQ0ymimVP7OEPf2YxM2T6ltXj7BgdZtkcG3+Cz5uIVHppvuNsIZ IbeH/ana6VYHl4H9TqlZLnnHKXrt+LJVG0z+6eg/l+u6KI47yloGnXZl21aCYSddG3U9cxuS Q4a2q+ub8pYnG21rvQwKrTtc0fkJ4Q4/1uvArsmpD1DnOyB5fblft/0IV3TLNWEHs63kZtvm XM6HNuh0Xt10cztNPLfXro3FF9mn09TuLe8ybEewbcw16SmWQrbJa+Ypo0mjdqYZNuuSn0FT JunXNnLZDC9xnzljInQ6gwii0JHIRQg+oA9ahrT3ez2QgKbA0X2tekMILlp0sB3MooUtNbg7 BKAtgwTJRqcfnaQXMskWOIERtkVzHlinZnnImeb6kcemUtSpQis5yfhmGR2jNMXOuQWdgpJ+ 6GZ48Mmnc43zR88DBe2xvFXLjhbd6173iu1e9cHpcjpZz3/+8/mAyKm2j61kP3jg6nSN8Scu X/7ylxfoA6dhvcntv9/97rdEsxub2bGA6ukfJPvZ05mOHeVTZwwAsJFgjSe2y887aTXNiGRl ourw2455QPg6f2zHAQkFpcjnZYkW9Uq8eFAl3yEv0WqUneSCph/bpbicFrZSeXnbxBI80fOZ iOBjoEPK+fMu7mk/xU34wLFMG5DwF4A8KEfiBe02t7kNe3kv1TcPm9m6Ep52YlokfISPqcXn D7kWaSC9BT62tAnAQv6oCH6yGzDhUWYqSyAS11i8fUImVSt0wOFBzK7Zmif5GreejXKu6LRL kpXqnI/7dqceNM69ExPfiNeWn/wdMdP0d2avo34m0wmtdR0TCOZ4B8Vaz3zOMa8j/9+gDzp3 1XdpfDBN3PRB09asK3TfHWIp6fHHH79ecczIsV9bfg996lOfWsp/P+gPubbovrxZGwtIjaIk oNjUMcY/+2oXpsX82Rz3/6c85Smb9Y1cJSQ55BWHzDz3a7nfIv5gi3/r1TUzzD0eW7YJrjr1 aTZvgbaN7T/kkEPGtJPNCH/IRVlKca3k52U6uk7wbRO+6CibbbgtQTKWS1BgGzHrt0DaCFkO yic/UUIG2QnShAIT6Nds1a2jLfupFs6Q/Ly61Df8nKlNBq1181jP8aYxvrvUrPAeiulLXCfF Yh+75Wlji8WaIebfqNekeK7Vsak+TJ++tVzxt7/9bSHLq/VSaJN2F4vd8/j3aH3DuUS7iw0q /rbKxqZ07w0blIWv9KH0gi996UuLKJOlq4rTrbwIJcnGgPowCzVzPXDYYYeN6CXUFq+YQFci AlU8I68XTwtPOOGEYdWhDjYtFx/U8vCBJUuW9GmJ+Ki+uRvVddqn7cV5wY0aCTt8uzd23HHH xfOHtkqMKMf5IFY/dRmmuX3JJ3mBbcQs3gLxp/WpC/mJEjLZOXQSr0+yk8BU6e2fihNbyysE zoGtjbpZhbZOLAYScgity82qzue4OrO8sY3OtWUxAB6GEm6e6YZih33nLWe6ymqxbb4hZTR1 mzzn83pDo+6CoW8ZIDZTqvGMHvWBrwtiq3ZvWvbtb3970ROf+MSNets6oODeVW9edwVnx6Vc L8PDvPIEWV0GF5ZuAuyrv/DII49cctRRRy1lS9c0gOjXw2uEt7oMJDCAPWyko7YTxtMPvEp0 vCzrULZxQ2QV0C1XDHkOybusZH1bkNlBlhT1tKTydd2z8qMeyLhs5NAlJbzl/DRDww4Q8YAX hNfCV75dymWsM6/iXj7npUAdw6k98HXLIefVvjLvmGOO2ahY3KpvGvbQjXw3xfpuDJzf9KY3 rUNG3wFtEn/kHve4xyptILBS8buLbvwL1VmKrS5TWdEu1AEkp+VlOjZyGdcDmvkNfViRRAcK lLivPDK1X1+PubZ8n2drPJfN8VqgB6Sp18znJmjb1L45ucbRbepz79TW3Mtf9KIX7aGNKxbV wkL07c4qyfdpdm3twoUL+VZnVz0j+jTL1q/BwCqWtbKMT9+vDeqbttiFz/qui66FJT/60Y+G uPfrG6JRXRPL+AdfEjKGKmOxOm0DsrNFHbdR/YfEEu2Ko+Jb7716mbQIf2tHnGE9H8ZUj/h3 xzCUfpo6TZ7rZii+0Pq5ER2dPN/EkbeObWNAKT+nlrzlcpjXM9d1POX8XA8c+e2Z2tXF9WzW I5fN8aZct3xTr5nPde076qPdHNmEZRd9l7a3BqSLczkNKnbT95VL1Ie4WstQhxU7ezoWcznN IK8655xzFqgPs1Z/kshAYbdLL710QAPdPm0Qs4vK6X/605++QbtLLtC9fGmuS12kO6CXpsvY tlurMTZpA5gFGnDHdsfU7wlPeMIS6qpY36wdyQa1SQzX3TYNqmcJ19VCDVqG+P8It7m+w2NZ 7JCeO6PaBW2EgYMGR4Psinnve997jEMDH45RbVTTz0AD/9lPhpRpHEid8nwTT3UUebyqZJTq eKyy4/ncN8bztsx1KZ+U861jiPxsp+nMROR1c03XqvEuE2Ov5omlRqk7FnxXQKc3yUUHxAZ1 4iLXbzRNriF83saI0DIIgm4h28jygeL4Tm8ULWuY7EVdTGtCZHTUZM5HF9M66q/Urz8EWmsc AtugYRAdfUi9iTdS+k6ij2VICuw1jLaRX716NU7AP32ajYjRO/awwYfT0CkbqC3S1punnZ6G daGN6EHFv0WO6YNTVCJoNRrfopmi2AotiK0/Mle9mfIov5VdB2vUnXJ1cOIt55/p1E7hXDlI DahsK8/8zI7LqfUp2xdQLmccG9QNGWTJp3ixSN9ZZ531H2W8TVxd11qgN8R68y7ucU/WVhGr ItXXX+LL/eMkYvx1r3vdWr0pWq8/JRq84Q1vOMLbJgsRd+pErdc1syHxR1m6lNv4y1/+wt7j YdTlZ3zaI3iiBd5GhqrlSSIl7nOHzBbutsB+1mYdi3MbdhTowkCXdm0nktfD/JzWrW5soa17 9JDeyA5feOGF8fykHLba1hbeC/UC52J2yWMmQv9nslQdpCH+70SzCsO6j8eW3fqH3Q3anWw3 zUr0+/5MPRhw/O///u8idYbW6M3v6OGHHz6iHfsW/fKXvxzSC6DYGAM56iraoOQ28I3R7W53 u1ENbNgFcEhvUOsNCDR4oZPITMRWri02NmB3NL1AqZcDYs/3SXBS03fNfCXVfhkTPPsSPedN sy5503wvz/PCSSEO37jtJTvbgFTXkBcOrOuQhCuj22jOHiGvO3WaKCW/TSzYxlA6/7a6eT2s SjzrjfxCDXC3aifJOp6RVTytUFz9WzE2wr9Rq3POt2mL1MdgyXUk5LTl/CLJxR+GitivTvtS Zpi1UxPbdY9pZ8r4H6xjjz12ozr5K3X/35D3MTQYH9ILpS2K3djSldUY2j52gQYtW7SD5ZCe AWP6z4lY4qpBwBbRF2tQvNk27FNtl9/P1sccqkfdzqeeeuqA+mTD2qky/pBOA/MRXZuDmikc 0eCbFRpxP1L/a0AvrkYf9rCHxe6OHXzpeNrGx/YvejiHvGnklZQdp82VuJ+pQUQ4SD+b1KH9 i0aj10mdg2hMdeAYMjFtRMcu/vQLXAdeFQinuyOCLVLQ4acMtoKGPIjy0Vig6Yi85ZMM2UiV inPVzVI5Ou217cRFNepjHnThcSSZGodOIkCEk+pzEQ4raIamocLexmlQEwOjfbUbTZITqDro 2Et+iPMmn2RcTm2fOvC/FFpbXl8clgVyQQpG3bN6QIIWdrGRJ+RMQyblfWK1vVTHXLXGrQ8B G+R9JKF6psJ587Pyo2zXATlkyPtBg6xTkkMnDtvTx+Z9H/3oR/9PcnRI8Tfn0P71qBgTJHTn Vdzjj+RngSo2s0Fa0Joy5Eno6eEywlaACCoFzRAZ8frUuYrOkNrMcYYsvg6IfAOv89DJOKGH HWAbvaBLFiGrBETWNOtiByb5BJFpKS+U04/1k6yycybu89PcBk/+Cb/QOfYDfxvBaRDyMqZh pkUVm0ot7SlaLaPBw8gLXvCCq/74xz8u1JvVxcjC9/3H58kbWw4txRhiq2K91V1D2yOrpUoL +G8TxXhLPGpQMsgmGeq0xb0IeWYjWM6hQYRjLuJUu5dt8DInBgpnnnnmgN7QshFH1FXl0IHr 1/dxm3hhp/ryZ3WDDDh4A9tMyIsWJ5rqKTDuB/h5PtOPAsXLSBUKLacnXGCcDp5s5/q1sTa8 FpsoIYP/BWMgBkx27bMa5oXMBk5dqBK2d8S4l1/cxqpqfx/xrNmxyzQAXqwYWYLfSFp+tEAv N0cVY/W3IsxGaKXJAsVz/PdCCOrZqaVGl2rJacSsYrGfgbNmFrZqidKiAw44gN0lo20UyyN6 iTnAP0xr0BJ+wl+add6iJa5b+H5Ts2uDn/jEJxZp9mMzeipvQH/GWz+bdd2M8v3cFVdcgY2o guusF7RM2fVrADIIzeXqpdSwY57yNNswoAF62CSPjq69vje84Q2DGrSwVXg6tSq2lB+/AdSc ehA9TkmYyzYj2ROYm3Hf8ibfJ90DtJeBHDRIHGqEM7U85yzW+jN48AGfBuMwLYfmZbDWRS7X s0xTv5m3nHWzfNh23UV3/ev6ZbJB65Cv7cCn/OSHXCdkzAdSbptzQjfXq2WaZTflzDc9BWuL LfG2uZFGVFftF7LopfoFNG46eXAOyjIOTDfx2k7OA3cdhdcd/ga9lnE51qEw7JOgAdEFpHzz XE2vbVIushpAcNP7hR7Cv5U+b/fqNsOeDpJhlRv/NR3IYd3ReRb3js36usS/+MRx7bZr5k0H puuFdqnvDaYDcTvQB/aNA20bOrJK7ky0yOU6IURlVV0OeIbwLJvk6rzlRQ955+dJ3Ic7+JlM ohM1lUQbbE89l9Wp3KytowNveaB1NCAY1ezDVv1/zwrtkjekbyOW830Dy594G8s/sCP/1a9+ dZE6+8v1RnWD72nQSfwrdXqLWhH0yxp0Xnq4DjBUZh+dKXCWguh7iCXMVLCsCRpJ8nXHh0GG 1pEv+OIXvzikP/Pie7iwV4lV14HrQjlZUrbiJzrMoCGT8zrhuS3rJlvb1KFpkzz1SvJRsbwc 84FTSPmJ5njTVDdeUzbyO1vctzsJzQQPMaDF32qDiHvF8Ai7PSLvuNc9mFiMC50BM0uZNFDd ohfJw5rZGOD7S6XQTwON+J6nWSYy2qFvSJtvLLvsssv6991334hlrglsIE9dZAM8vu0EQndd wPMEHR0G2yxRYnmVBkxDp5122gCzEfAc95qhG9Ry21G+KZWN0IPPQd60yCS6+e0gcinVuslW bdN6yBm3zA4Q967/hHA6MxE0cjgog9A2aD3bKWefffblWmt2gEafu2kUGG9sFHDxcBeMQCQA 5TRwBhzVFi66QSoxuIEWfAUDic44URHyiR/C4CnFoEi4xKo/IIOe8SMwIZmeeMwGhBz2KRc6 R47n+cpsJYMtEroAlNFL+aDxg74S/Mjyo4Q45YQyGeE1XYjlA4odEHlkM0Gy5Guo8iMPLcNt r5bLdSxL/Uk5L8tzrvCiDqZD00EFOJfQTTSXH3Tkkz5oXMjY8gUNG33ypnO+zme6Ub7ytV3k 0bUNeGS0dGC9YvIiveX4jf6jgFkIloDxRiUfSBAfjmuhbZP52PUBbd7FPW0iX+dxH0vx8At0 QUA0hgC+Mq1iiBUClUzoWM4w2RDYNu4rtdYYRa8Kh36uoxrHgOWNOw/kIFRK3OOdySX5jrbD 1/gx4GQsoCN5YsNwMupRZlKIWJuMcioblZ51OU+nDO9XB2WN1lvvomVGS/S922bNBm/dt5pZ jg009B3FSr6HeM973nO11n9HxyvT79N3FPH9hG0D6bQxG2Ea8qpzZLXVMWvMF2od+VatG6/f +OY2keW/iPT2dbP+lJHv4hYdddRRI0cccYTExs8Dg7q/MjCnAcN+Kge5Ft/gM2SgI5PkQqf5 E4IiIk8yzO/lpgGpQwjqx+U4D7QsvJye48jApwxmhgxzmQaOrY72GrJ1ljJcR8Oa2QOCjsTw rWEPWuMiSR9CS/uMS0wek+9ktj9WMzBrYAvQ2TFSm7e0vKmnbOT1XcWSD33oQyu1JGmdZhFi Mxh2heTbTvHj/IhllrQymHA72j42tLR7q46rP/nJTy7Ssqel+pPcter8j/n7BmT4iBsbzNbl NuDleds11DLYftVrgf68dEyrZbbkf0anOlL/AQ1i6mtIejJX4t7+6wanOojwBQfkBscNkc6Y j41as3m6jn+KtlIHH+zkW2k66A3FjgvBeaBx84Ckdrxctg78SrzFTs7L7eT6zTLMawdtwzzs 5zi2XKah7QNJttHEg5l+niz4wZyQ8FwXUp7Py2ujWpNc35owgZ1O8ujnvBy3beLFsZPTjAPN z2GOW9a0PA8tP4hNpjgZLPBnf1fp4JsdljGxrhOeYxZZjqZdkepkHnA+x70dQhu7nXPYxMn7 2sh52MnjFJ758DrFPbxmauqan9NzPOfnuMvP6wXfdMvmtJyX45Z1TDoPdCyZ5nwOc7wpl+eR y4+ZjnuXBWxXp+D7DWzqIOY6HXF3MDoKzCJjsmVbvtlZobPBuatzM6aXFJeryhED2iBgT333 o9VEw3zXtpLZCu2ct4bOlWXy09N3ECP83w/LPej4U47eCA9oSQjt2ZL4BkJruBdoZmPD6tWr q55fJUH7qKr9Y6effjpLQ4be/e53byEvub6DDz54lJ2aMC5adLaRR5Xy6MSjTN4JXcSdRy6J RCyQb5dyeo6n+BCpftMbZQdBhqBTJnLgkOInySc+vDgH5Mw3pH7YIG8IPo3kkzSsTe1McW9f 4Lr6BBoIPL29H1aHnWVDg2np6Zh2cBrcf//9q6/8k45k+Y5nqeJ6GbGvGONlMFz+E2hEM/T1 5gPMKrCkiUFAnvTdz2Jm6vhjXej3v//9t+o7niV07hksqNNfbwYgG/0qY7RpQ2q0i4qu2px6 cZDn+1B9j7FA32YMyzaz3tApKn60K9SAth4f4z+K0HFCV6n2U7IHO4RyWesEM7ORy+ykcZ+f Wlu8tTXbimxDjMZKVK5eH/lAgk4bD2FoV+sgCJqDiPwh7YYy7MazTDtomoqLAGnmm3T4nWSQ JeUyE+GudxO6DOvneZeRwyZO/gJ+UrIdsrZlPM+bBiTlvBzvxMtlwJv5ph55Ui47flVWPOcN K2r1mz8szTdEArxb3vrIgDsmiUcGDbwhYQYCyKACugcSyFovL0PkSNB8/o75vAwGI/Mh7nGG 4xvcKacZdxx0gujmPNuyn8k34x5aziefJ/MM4Rk3NI18k2YekNSLTCXZKtuMIecNrQN03IKb b2hat7z1kcljcibinvI7Jr25Hm23Y0tHhYzBQ1rZ3P8ZtzOa9BDgKR9vmlOnwB2HujPQfIjr zbT9ONlyu9aV8rUb0+764PNq1oxr6dCS/fbbbyvfoLE2XB+vsqvMWr5PSJ0J/ng0TlIzows1 czGspUtj6swMq1O2ULszbRZ9AW9h1WmKPx3Vv7kv0D+7D2swwgYEi/TnpBtZW84yDRIzGRyS G2TNt5ZXjWqL5EG9YR3Qx7Cj6kz1a+0730ZskV/q88ef5DMf1ucKDR8iQxm5Xsq7Q0a2Tug4 GW/YaWkj8Uh1WR5AQMvqFSZdF9sHQss7aTkPHDszmeZ63POthAYMmxVLy9QBX6vvDJbqW4RB BgH4UUvWlxx66KG80R/T9q4r2epYscggOOKKgbJmvTa/733vW843EgwG9B3i0rT1ax9LnRSL fFC9VZsOjGgAspjYZrmSPnpeoCVRfMcwpj/K3Srbi4lddfIpaxGzeLSnbPRr+9nBo48+OupE nOTtbJzNBDR4GJGtUa4V5JhxZpZDqV/XZ782OmBmo8T9FC6SqQwiXIyvyvyhReeBwYJvUObR yNDh+7AM0LjQGjfNEJ47J+Ckpm47WlOmme+kY7phXg9oeV1sswmbcu3y1oGX4+TzxGCMlJdb UVpp7fjIYdspx00DNsu3nKFlPzo/gQAAIABJREFUrNOJbv5EkBhyHFnWeUPoTTnzDC1jSNzB I+7cuWcQwcET1wMJ05BB1npCt6kXNJLLdGyji8/nS9x3ixHHQzvouMz1cxzfWgbcqd6NyYQu sGkP0XY2J6I1648d07rh8HpJxJDjyPLOG0JvyplnaBlDx+9sxD1l5CnqpjX/g7wVdMfOMBec Cl49z+WA1Pmjg8iD33kg+U4JPp0FUlanGHRAa2ePpS+2L5G6V5308/bHREuiLlrKsfbEE09c oW27x9j1Rh0oZj77NCOwgB2djjzyyD1yJXXQrmCpkrbIXC6dtXobO6yBxnrtcb+C/0tha1h1 gDbof5dCTR+ILtEAYIN2expjqYl2kVmW29OuN5u1leZWbf+6SEudNmkwM8oyJ+0CuEjl6NTG 2H52mKUcSuTrc1L9W/K53RzPfWk6drsl+NYDz+WdN8ROzrdem0GFxMZtWScfSEi3XsoEHdPZ QX4qaaePe/xifwGb1xV80kte8pLLFS976fvB5cTza17zmss9A6CPkHfTUrrL9Qego7oHsPtR S2yzQ6Vib4N2IlunbYZX0WFnJk6DhaspkwGE7C3XIOJKDTa2agn8YuG7aCAyykBCSwN5yRc7 imlp0ybtorScbzR0jYxpFi5GzfoQfFDXziINIqpRdNW+dUyjT+IbCH2nxPVYz2hoMDP6gx/8 YAtxr80HBvhfCfuk0mr9dRyKWtvvJo82fOuB5/LOG1oeSLLeDhT3VcXa/NYOacPrRrIeHScG Iobs7UtD5dA85Ljrc6Df7gnQCw1dly+0JeX6uYzxJkTZtBxvR2vHR64p63zOy3HskJo061Xc 6te0zyj7mIzR1DWrGz2XMQ50Gd3wiXjm57agtUt+4hhaplO+SUceWk5vl887+XT0PWDg5sTB jQfIrITf2DIrQQeMI7evbCSfn2PaMI93x795czHucUanWMuvwVwul89xywBJ9jF4HvemG8Lv lJr2LWfdThA585o67XimNXWsm0PHk6F5nfJNOvLQcnq7/EzHPedGLHM4tnmFvkTH9bXr0LF6 485uKEOakYA/qLftQ3o4s8RnEKgH4YB3LRJfz8d+vgGjQ4/tgOSVlK3jqpaBDhMZBJRCL8/D Nx1cKXSggZsnnRpPg4ZaDx6yqld825PbR5+864zRlFp0dM79fJS6WrMH6CjFDzDLh47zrpNl 6DhoydEgH08zgMAIKRkIkHQSqXqzSt2gI5rLs5MNhz52JV6ClWRCFj3y6Bq3YcuRJ5HPYWQy OnnZMDmg84Zmkte5hnDGE1p3uGqeO1MqH1otgyw0+InOySDjzRpGdF6jmtG5St+ovEn0v+ng xQTb7fIM8P2fZ0QYESRxonMy7uWPuCZTWwpEo3K+gTsOyONfDYAXeBkSvBCqYiy/ViReXZeV OYv197G5gOJvgHjOeH4JgLmIO5buMYPBjBy2XBaG2fUJG/umD67ho4cMiYxSRazyQTY/icAP eoKRR0bnGfpmJltkI+XypgFNB8dXeXLe0DzyO3Dcu5o9Qzo4U0nRyFKMizUzUN1hxuncSCnD HSkuygjWho71IDf5meiEPMt2suFyDC0PbOr0ImP9XDfHc77LaNJyersyLX+lkE5805vQujm0 DLQct0xOy/Gc345u/lShr0BD2+mU70aHx0H88WBgcOClS0APJMBNt2zTrkTqBI9zBzYfOAiZ Pl/innMmdRo4VNzqt50MHPzZLp5Mi7e5lYkJf9vZsh0rO2/YpJNv8kxrR7f+VKHjzdB2OuW7 0eFxOJZnKu7b1YlyrtK65Uv1IN2LcgWj/AQFIk9ngGulbv/0EI0HMHiSo4zwL3kl6we9nYzl ESBZRjBsA5P9SqD6rctABRJ6STfqmPC6EpWaTrC1rlEGPOoK0MF/H42ps8RbTc4bWui5M0Od OJB1OSkT+tBko18DM9owBOErUUeg9WocOuUphQ0YSjWuN8DxBle0qGeqbwjxgx40OuJZnUMW frId9RYOKc6Jcp1Mdz6HTR55HSSLxbmR9yFGMFPe5x519YACXqo7dpStDCZ6EFIdx7SpBv8L xAw0sYhtH0InTHVFJQm+08S9fCEXtMRF+Axa8k20qz0ALdMhHvr1XQ/3EbEqHjGCTNLBH/US PclEXjRkopPPdv/aoaz+ViKTibqgj03+oZ0yyGcyUU/p92lpYCzrQwY+kHoAs+TybTvs6Yf6 2Dgy8EPfcW8+svBtO8lBghZ6kUl5402IbJ7I6yCZ7HMIu4nuskPW5yZYfyOEHHnLZ4jPKeyq kOnGvevZFU51EGGjnDA3Oye3JnQuVkb3+QDCDxJDy6Of4+TzZPmc1g5vJ2e7hk29Jn0y+U6y OT3HXXa7eppnaD3DTp0p89EzbmhbhpOlT8emy+wE6yupg0DeSe8gUl3sYjZtWRdIfBKHQHeq PHAwhIesj6Y9sVoS/Pkc9zijXSyZZmin5fmJYh/ZXJ7Bc7eUy+Y4OpPN5+VY1zDntbPd5HfK TxRbjt1O+tBtw9Cy1gXOZNxTjssCYh+4mf8F0tr7fbwNIw83H+oYRKdADzl8WD8whUfKOiPw pVY9GAXJUEbs7AJdR8iIFnbIQg9DlbJlMlLNRz1k0UspaInu8qlvCEBX8s4yoQLNfBsRhJTX A4LrVovLVv3WFH+ggxx0Duzgj8xu2CGf+FEQ2USr5W1P9LpnAZ7bswxl5gk6eeoDnjpUrj9l w3eZcQ5NG+jbDji2gE6Wl0wsLwKmNI4knnWBmVz4IKOFXrIbchZO+rQjMviYpWV9Wgbm/wUi rnyETLMuKQ9o8ne6uOca1HnIDePtDm46J5nznM9p4DrwRW0k0RCPZBlBx1PQaUOVZRx227iX XPAQTCbaxn2Db508WOq4x2aSjzLBnXIeuAcSDT7nHPXgHFwvyyRe7pOQN9/ysr+zxb1PoSc4 nUGEHYYTCVQSnTXo5D0VCI0o4kDWnYja+aI1k3mGOX86tNwOuG0ZNvnO5/wcNx+Y03PcMu1o 7Xid5PxNRCd+sw7t8u3KM82wm/1cphc5y/cCiRvHVDv5bjzkzTf0DR/IQRzmgwkGFM4DLS+0 a7J9zh8dEvrQyc+3uNcpTxj7TRnypDyGcrziVr/EfSdeLtdOplcadtrJ5vYt04tcU69bnrhx TLWT68ZD3nxDxzGQg9h0nBPzU417qUZZlGPbo/oo8c+rV6++nrZmvLHWS8egIe+g6AHKtqHx Fo0HMQ9s6XPEkiFBJ7bwDj5QiQ6CeYHrh3LNoLMQeUgmS4b6IR9JOJmqh6KHOTh1kK6NIxf0 NjZiUIEOvMQPWwnHGPoklytWXb5p1rcwMORUjxaZRMdAXadkEGB98Dol2VreNugYeRkZtFRX 9OrywW1IMmFfckGiHYzbJnnZjcrDJ8FDNzKNnyRf85G1zaSrbKWayoi6JVqN4ydolJNglKS6 +Fxcfg2R1Ye0YyeddNLPta7/NCnw0ojBdf7SCDvWAW+X4HPs7HEvN9Zbw/si47zkKjVMinHn 8V/CQ0B4+J92VxuETi6TyVovoOgWdlu5o4+NkEn1Ik8xlJND6wfNP8ikw+UFK4v70Et1hef6 GA952bBc5NP5mReQmJuHcR/nPtFP1VITSXXnY4OANDTupUuG5udl5rhLaUczDzgRP5fN5XvR a8o0803bzk9Wrld51/88Ifu6sAxOZKcTvxM9M12jk5GtlYTkely800kT6Tf55E3jxp8/NPJO lemGud5E9eX8HOtA4453w1zONnPfdKOZB2ynk/ObuOUNm/w835Rp5nPZHJ+s3GTlz1Nh++YF JnyydnIT09HN7XTCc/uOwU6yE9En0m/yyZs2U3HP+XAQz3zzwMG2jRx8G8GxUrsB3fpe97rX jbSUZ1f+F4jvIvRwHtCDN76HMOSBLnmxqpR1RnhjmXfK6zzyHPAFowMDrkSW6y4MYsvfOSTz oZf4AA9cQtcyTb0kH3ZThyLKdl3DUFWXsJOfWxAkALTdZC8qC13JDqhZ0JJa8IznEAHXJztP 5K1TQ8vBM55DbCmJHeWGDfIQkXOyjvOpLGcDcp4tBGUk5zisWfJTjcNXqgcU8KwDXSl+rJPR Qg+BxEMuaMjIBoWM6X+B1mkJ08X6z4HffOtb3/qNaJfq4IXEWh3N7yEYWPMMyOvMOXHMtbiX i6pmlr9arhfO18wEm/m4JpNcXIdZHIZR6ytuWvJhKMWpcJmIsvgxbtVtIAKOw6y80G0KWw67 xnOILSWrteDIOVnHeexx5An/5XlwyeQxFGzHsPnEKQdpB4z7qNdkfrZxwmSUM1ns5AetQR7o ljF0mYYS6TnZRs8KPQhOph69yvYq5+oh303nYvFZdzyZ1M1eJzu96vQq16mcJn2bC68p0Cbf SSeng8dDJUFwDj8wnLdMriuxCRN+yA/ikzzQsWponxlKpOdkGz0r9CA4mXr0KturHNWzrGG7 Kk8l7nPb7Wy2o3WrQy7fq1yu0w2fbLxhq5NOTgd3TOcxPpW49znTmWLmOh9IeBDBR9bsFMS2 P73+L1Ae05ThcoRugzd5eT63gy7JfGCON3nknSxreehNWjNP2bm862Jo28286bmuacg+Vcf7 EiHXbSfvOlnfsEnP7VimCdvZt0wn/W466OZx2cx347lc61gWaLzJI755ScSggI+mGTT4f4EY OPBBNYMIeN5Yw7Nzvl7EiuTzmktx73PiBN2eTYiMD+Ry3Hmgk/XJN2VznuUtl+fBkXXc53rY 7JaaZSKb03JbtjORTdvIoXUNJ7KRxyg6eT7HmzzbN92yQONN3kzGfV5+T/h0ljPlBfjkgDQa J4WTuTDzRswdn+MSC3ngTKWm/Zmy26ud/Lx71ekmxy4SU0lNPzTzU7GZ68yEPcdPbneyeG7D eA79kIDG4c4V5YBPJeX2S9xXHixx33skOX5619hWMrdhPIfTjXts+Rr3NQP0g4tOG8tEHP90 3GKXJkE6YNDRz+OCvG0K3YYHzXxD05wHGm/ynG9Cyxuan+ehdaqr6cjnR1Mnl4NHsnyVq36b 5eb5f2WCphvCMt6EOa8bDo/UTj+nh1Am1ylvehM6FrvRmzLkJ0NDNo9JBgbeeY/nJgd5duhr DhrQa5ewad/Mhbj3uXCu4M47VpsQOdPALZ9D4+Y7b2h6DsFJTRnnHffOG1Za43q90C3TCTbr 4TIMref8RPK5XDN+zcvpOQ6f/GRoyM503FOPSaWZGkRQqE/eFyUNwOE8MiTTq9z0f9s19PSt 7jgWfH48qJ1Mc77AbT3QjDvn8wvVtG21e6eUuO/dV5ORdIyXuJ+M17a93zrGpxv3eZx7AEEn g4GC24qy4HHwbIFHQg4ZyxnCM96E8EjNjozlKm6rXdNynaaNdjK2aYgMeKe8eeY7bz1gsw45 z3rQ8pTrMBjL85bLyzLNsCnfzFsO6DoY5jzjOS/Hc33LTgQdP4a5fJOW53McHedzCM5B3HmQ wIDBu/B5K1doze8irGt7EmlJpju2GTTj150x7mlDt+NUcDsm121Hcxk5D7xJNz+PU2aKmqld eU2Z3Aa8Zh7aRHba1a9Ja+ax2y05fgxz2SYtz+c4Os7nEJxjNuKeMntKMzmIcIH5SU7W4bYB nI5ubqcXfHuW1Ut92slw8ypp8h7whZZrOkZz2nRx2wROJ56mozvZc9ieZU22bpYvcW9PTA7O dNzTiSJeeDi7Q8XDy4M8l0d70ZHj2YIsh/WEtqR2D/peaRjKZZux7HwTomdajrejmZ/z8jLh N/PIWr4JkXcyj3yOm88ggpTzjDdhJTn+C98y49RxLOflOBJ5PsfHtWcey++duXXHVE4znvPA iUnHJTHJwaCBw0uXwD3IIE6J39yOstukuRj3blegcU48z+e4ndKOZl5+HXSTg+eU46Z5Nz7z DOEbN7RODuG145tmiE6ON23k+dnCiT2SYZXrHpN5vILPVty7LhPC2RhE5IU2nZPzJsKnozuR 7Z2Rzw2vpJ3DA9OJ3eno7hzemVwtS9xPzl+zIU1M8sAF8tBy8kPYdNqKZ4oHEH5bazn08s4G eXg5H1qemvLm5TrGDS0DNM2wycvpOW45aL3Q29XTeoa2adikkzct39LbNEPr59A8Q/OaedMN c36Omw/sRM9lpoI373XNPDabtHZ5aBzEpgcH+UCCGQkPKoCWQb5pT6Q6wePcbdsM+8P0nSnu qbvrz/nkOPlOcdyU6yQL3bKG0PLUpJM3bbJxj13rGuY08Dz1ImP5XNa0mYDNmGvmKaNJa5eH xjHTcU/5PafZHkT0XJEiWDxQPFA8UDywQ3uAB1Y+qPNDNn+Q5QMId0gMLc9J5njzpOF141ve dp03nEi/aXsy+W6yOS/HXS/DTvU2H+g/F+1mx/JNGecNLZfDqfJyG7OBE0t5auZzXj6gBffB IMEHgwbPPhiHZ1lgtzLEDv5cj/s8HnKc88/znXDkSDm/ooz/bq+471SPTnXrRB+v+exjzRhs 5vMaELNOeRw75oGOdWLf+GTj3mV0hWUQ0dU9hVk8UDxQPFA8IA/4ocYD1w8xHkrQyTPrwAGN zgIHsu44dHtQm2cotTr1SkOhnWxtKCGWMWzync/5OW4+sElv5i3biW5+O1vt1oa3k+tmw7xu 5XfjWd9wMrLWyaFjKKf1gud6OW5daD7cqSIOOehEGQcyGPDRzpbYLckynPvOHvcTtV+T38zj mCatmc+d141nuabMVOK+Xb060brRXacmbNaxyZ8o7xiaSK7Jz/Vy3HLQfMx03LuMCWEZREzo oiJQPFA8UDxQPCAP8MDiYcXAwB0qoYGTp5OWL2HyQAIZUruHcTtaJV39TsTPZY1bx9D0drAp 08y304HWq5z1c/kcN78J3ZnqJtuNl9vrJteNl9vY3ni7TlNeh5xv3B0px6ljMh88QGMQAUTO ukI7Jtub73E/lVjJdXK8k7NL3HfyTEXP49X4bMV995okbhlE9OSmIlQ8UDxQPFA8IA/kHSp3 xty5MsRR4CR3HAwram+/6ExFbyLrk7XZq3yvcq6f5Q1NB051S+/cRju7Ob8XfCZsdCvHHaFu Mu147fQcm4buXBGnTRp5jl6T9YnrEvetXptsjFjeMLdW4j73xrZ4u5h1bBrOZNxvW4MGpQwi Gg4p2eKB4oHigeKBrh7wwwohd6roEPDw8uABXt5JyPEmj/x0U9P+dO1NRZ86zFQ9ZqIz5XNo 1qmZt9yOCtt1nKhrk06+0+GOFXrgU0nYtm6J+3EPlrgf98VMYs34tu0mvVPMO14ds4a2MyOw DCJmxI3FSPFA8UDxwLzygB9kfjC5I+G8nWG689OFO1sHeKrny3ak7c61HW2qZcwVPXei8vNx HOY803K5yeIl7ifrscnJl7jv3V95bFvLMZ7zTLPMjMIyiJhRdxZjxQPFA8UD88oD7lQBp9PB nY7uVBy+vcubbB1ZMlPS5D2Qd57QdnxO3lJ3Ddstcd/dT5PllrifrMcq+e0V91OrXdG6xj3g G9Y1XpFSgeKB7eiBEvfb0dmlqB3GAyXud5imKBXZjh4ocb8dnT1TReXrV2fKZrFTPFA8UDxQ PFA8UDxQPFA8UDxQPDCHPVAGEXO4ccupFQ8UDxQPFA8UDxQPFA8UDxQPzIYHyiBiNrxabBYP FA8UDxQPFA8UDxQPFA8UD8xhD5RBxBxu3HJqxQPFA8UDxQPFA8UDxQPFA8UDs+GBMoiYDa8W m8UDxQPFA8UDxQPFA8UDxQPFA3PYA2UQMYcbt5xa8UDxQPFA8UDxQPFA8UDxQPHAbHigDCJm w6vFZvFA8UDxQPFA8UDxQPFA8UDxwBz2QBlEzOHGLadWPFA8UDxQPFA8UDxQPFA8UDwwGx4o g4jZ8GqxWTxQPFA8UDxQPFA8UDxQPFA8MIc9UAYRc7hxy6kVDxQPFA8UDxQPFA8UDxQPFA/M hgfKIGI2vFpsFg8UDxQPFA8UDxQPFA8UDxQPzGEPlEHEHG7ccmrFA8UDxQPFA8UDxQPFA8UD xQOz4YEyiJgNrxabxQPFA8UDxQPFA8UDxQPFA8UDc9gDZRAxhxu3nFrxQPFA8UDxQPFA8UDx QPFA8cBseKAMImbDq8Vm8UDxQPFA8UDxQPFA8UDxQPHAHPZAGUTM4cYtp1Y8UDxQPFA8UDxQ PFA8UDxQPDAbHiiDiNnwarFZPFA8UDxQPFA8UDxQPFA8UDwwhz1QBhFzuHHLqRUPFA8UDxQP FA8UDxQPFA8UD8yGB8ogYja8WmwWDxQPFA8UDxQPFA8UDxQPFA/MYQ+UQcQcbtxyasUDxQPF A8UDxQPFA8UDxQPFA7PhgTKImA2vFpvFA8UDxQPFA8UDxQPFA8UDxQNz2ANlEDGHG7ecWvFA 8UDxQPFA8UDxQPFA8UDxwGx4YGg2jBabO44HxsbGdldt9taxVEf/jlOzUpPige4euN3tbtf3 61//+tDuUjsMd0w12aDjov7+/st3mFqVihQPFA8UDxQPFA/MkgfKIGKWHHtNm9XgYRfV4Sgd +1zTdSnlFw9MxQO3ve1tUYufqehfUzq69i5U2T/UYOLqa6oOpdzigeKB4oHigeKB2fZAWc40 2x6+BuyrE3OAij1GRxlAXAP+315FrlmzZvArX/nKXj/5yU923bp1a5ll2l6On7gcrrtj0nU4 sXSRKB4oHigeKB4oHtgJPVAGETtho3WrcjYDUc8yXeta13rxs571rEPQu8ENbvDMlStXvubi iy9eYDtXXXXVkN6avvfPf/7zsnvd6173k8yzzDM86KCDjrv1rW99LHnbe8hDHnK3wcHBEzmk /24O5+973/ve++Uvf/ktsNs8hoaG3mm7E8EPfvCD++6+++4vn0iuVz6d7Yc97GFH3fCGN3za bW5zm8e+/e1vZ8AV6fe///2Kww8//Jh99933GXe5y10e+Jvf/GaleYaHHXbYMZ/73Oeu4/xU 7VHugQce+Pgb3ehGT37kIx955OjoqE32vfSlL73FLW95yxN0HPfGN77xJjUjIZ///Of3uelN b/rfd7rTnR4j/9z22c9+9tF77rnny+6jRFs25ed6ftWqVa866aST6jbZQc6XdjgqXY87SJVK NYoHigeKB4oHigdmzgNlEDFzvtxRLLGEqWtHcvPmzYuPPfbYe7Wr8OMe97jf/vOf/7zh6aef vtx83nj/5S9/OfABD3jAb0wDfvGLXzxlZGTkmRx3vOMdf6LlJ79y/hvf+Ma3kdljjz3+o47U 0/JjeHj42fB6Scccc8wFX//619/Ti2wvMs94xjMO/elPf3rwU5/61O/e4x73OP2Vr3zlse6A PvzhD3/0wMDA2Ktf/eqTFy1aNHy/+93vSRs3boxr5BWveMXNNYB4hNbo31EDsCUuayr2zj77 7CUveclLnnDEEUf86TnPec53fvGLX9xSvr0nNt/1rnftf+KJJz5Cg5kzTzjhhJ+94Q1veNT7 3//+fV3eW97ylhu99rWvvc8XvvCFz37ve987SXp//v73v/954Sfe5CY3uVjjiAdbtsBr3AMx kLjGa1EqUDxQPFA8UDxQPDALHiiDiFlw6jVlUh11PqKecAnT0Ucffcqpp556p29961vXatb1 oQ996H/U8b/o3e9+90HmqVN7Y3WuR5773Of+1bTZgBow3EWzHC/dZZddXq3ZgrtShjrI13ry k5/8APD73//+99bg504HHHDAk5cvX/76O9/5zg92J1/13e/ggw9+DHJO3/zmN/eUTnTOTZO9 QzRY+KHO5ew3velNp+uN/l80s3CQBknL/vGPf+ynzvnJj33sYy/QAOmbequ/BzbQ/eMf/7iP BhabFyxYsMm2gFOxp4HArTUTcvYHPvCBXz/pSU86TwO3UzSQiJmij3/840doIHDKhz70oV9p 9ugczUb88ZOf/ORhlMW5apDxX1/72tdO0mzO2K1udatn//znP7+e/HYfzSA9421ve9tp//73 v/e+4oorYhCpdttPvnrKkiVL3nSLW9zihHPPPTcGP53ozFI9/elPv61mNV606667vuKFL3zh rSi3mf7zn/8sPPTQQx+5YsWK165evfoZH/3oR2+AjGLnrmqDR1teM1ePfcpTnnI78hr43CzN gr2WGS1mvaCr7kehR/2YUWB2S+d9sMp/uWZc+j7xiU9cH7lubQ/fiVkaZtKoG3U5//zzF5uX Qw0UD2SGCznN6Dzksssui5k5Zn6IwYULF76VmSJmp9DrVk/568WuZ15GwvdJ12UbViEVDxQP FA8UDxQP7LweKIOInbft2tV873bEJu0617nOlep0nqK36A9t8sirU/XbH//4x3UHUjMBB6nj 9wd13MfX3LRTbEPbtGnTYr1tPzg/1Cm+XlNUHeO9fvCDHxyust6rDuenvv3tbx9JB/7yyy9f /K9//SvkL7jggj3VSby/ZhG+LxvvUUf0pnpTfyC21KkeVQd/OLerTvOKP/zhDzfLaZopGVQH ccQ01W+RZl723rJlC98U9KvDHee4fv36QckOaUlT+FTfHnxPPvmy+OzAU6ep2NMSqAHVta7D 2rVrF1555ZV7Mki49NJL9zjkkEP+5QKud73rXaaZjxjIyCd77rXXXhfvt99+GzUAOlgzP3/6 9Kc//ZNrX/vaV6kz/w8N9PqWLVu2/pxzzokO+utf//qHPeEJTzhFs0Jv1XKpfg2cjsBuJ7r8 vK98ftinPvWpjz7+8Y//ugYsj2QWynUx1CDnEarzMpX93gc96EE/f9rTnvbUv/3tb0tf9apX /UptcnPNshxEe//973+/oWZ6fsdSLQ3yHnj88cf/QLNAb8bO8573vLsANSBZpba/593vfvfT 1a5f/tKXvvRfOo5461vf+imdV5/a92jkurU9fBIDBpXxDM3i/FE234mPFeePrbjjvxpA7/q6 173uBJV3Mueget5Ag7kjf/azn63SOZwgP31Jg4dXadnfOg1mY1DUrZ4aqJ3reo6X0oL1dF22 aJRM8UDxQPFA8UDxwA549L0DAAAgAElEQVTuga7LXnbwupfqbesBtnHtKakT/kN1PA+nw/eC F7zgz7mSOlenaanP0Sy7uf71r7/pT3/60y31hvZjuUyvuDrpS08++eQ75PLqFJ9+3HHHXZDT zjrrrF3UcV+hjv9yDW7OVUf67RrsbFLnMTrEltW2n7/mDT35H/3oR9/TTMCBGnT8SW+8z+Ow XCeo2YvfaSByF81AXKFO50p1fm8mP5yrbz7Wqbzz1Wm8rzrAP3/nO995uJZdDakTvaiTLehT sffMZz7zdHV07/f85z//1npbfrHqwzcRA3zPoMHEbnoTvsllyv9XavASdVDH9lp77733FfDU Eb613qZ/GfyMM864gepxJp11Bm2aJbh63bp1Axs2bFihTv1e8ss5mnU6SbMUizvRsUNSB/qb 6nhfxqGO+KGaLdlfMxJ/q7h9fcSElrodrAHfq/TdyBVaTnUx7fve9773wPe85z2/USf+5Pe9 730P1uBqQN92fEaDnq1q7wX6PubztCuDEvn50r/+9a+rbVO+/8M73vGO08hrlmTtAx/4wJ9q EHP+d77znb5TTjklBlDwOrU9PJIGBrfRDMZl8ucPyX/sYx/7mmZy3sDMiQYkW6CRNDg6dP/9 9//ba17zmjPIy+f/q5mo3TSTc6j8fd6LXvSiv0LXMrJv6ruZN3o2o1M9FScD0tlmsIKNlHq+ Lq1QYPFA8UDxQPFA8cCO7oEyE7Gjt9Dk6tfzDj1aOjKsD3K/SIdPb7/rj6wp7q53vevl6qz+ U52tW6gTuZ/e8g+rAxgd98lVp69P5Vxx3nnnvTs/9A3Cj5t29Gb6LH1z8Gt1Qp/Nsha9aT98 n3322dyU01KVS0y78Y1vfLkGHfs5b6iO4/EsSVHH9THqQF4PnIPvCTQY+j8tP7lUy3ae9JGP fORe6sz/QuVcjK54X9Sg4oZaXvNsdSxXahbgPHUc6/JsP4dTsadZnbWPetSjvqZlQPfXG/D/ Vuf4T5rluZqOrmZJtqqzXw+c1OlfpLpfSpl6432Vlt2wdW/f0qVLN1x44YXLtQxqFT7Q0ptL NStwj5vf/OZnw2fWSIOhz2ogcNRuu+321gc/+MEP0UzHYCc6OiR921Kfr/x0hWYOblhxql8t n9pDy3P6NRvxfM3KvJFDMxirNVCIZT8s0RK/T535K1784hdHZ1z136p6Xp/lQ/L1a3/729/e PLepcq5yXrMpw5phuYi8Psjv08CoftExUdtrOdoel1xyyT6ulwaiL6OuGvjU/sSu/Lab2jbK IK+Y+6di4w+i766YOh8aiXZS7G9WTMT3QZ3qySxYXs9Ku+W35+uyRatkigeKB4oHigeKB3Zg D5RBxA7cOFOoGn941XPSUpM/603xhU984hNbvhvAwJFHHvlbvW2+ld4yH6RO3e9YKjObSYOM xfo24ZvqBL5Ib8O/oM7roarfLZtlaraiXuN+2mmn7aNO8ZqmjN7wf/9lL3vZ57WO/ocakFwK zqEPpf995plnrvjqV7/6BXXOX6LO+tu0jGmhvk+4mKVEixcvHtHMxztUxkt++ctfnqTB1Z4a UNWdzWY55KdiT53SpVpmdIYGKq/W7MOrNIi4QB3tGMjoe5ArtLxmN5elpVa7aaYk6qC3/heq w74Pb8Y1O/AdfT9xF53r3eWnkzRgeriWfq387Gc/+310eeP/iEc84jzK0PKkt+s8F2hQcb9O dJenQVftX5W9jzrOLf7V4HKjYmFUdXylfPZiDvngpZqF+Ck21Ha3ofOvQcU+GqDGAES8/bRM 7e5q3w/gdw1oTkXGSfZ6ituJ2l7fN2zSQOuvrhfwV7/61cs1MLrSZQFpb3xlGt8G8U2NZicu UvytMl26u2hJ1Ja73e1ul0HrtZ7Wz2BP55fJF7R4oHigeKB4oHhgh/fA7PYMd/jTn3MVbFmv 38vZqfP0Ra0Fv1NTVh3O3+kN943VUb+1PjT+bZPfa15vaPvpNDcP0VtMaE35bfTB98O1pn9E HeIz9ab4fL1132YZiDr3B6lzOKABwEL9P8KttCzpXAzxXwlsjQr+mMc85l9aMnSuBj//1lvp TeAckl2vJSxHqhP7IOQ0SNpdy30O1C5If9bb5DHpPe3Nb37zjeFphuD2mhn4lzqlG8l3SlOx p3L3Usf0BXzMy6EZkbscddRRsZyH9fzf/e53D2PrWDq3evN/6B3ucIe/U77W6I88+tGPPuXe 9773o0W7TN8+vF/8/9WM0tkaXLxVsxAX6BuO6ARrMLRYg5MXMTjTR8EXasvd36kTvrQT3een LWNvA65O/556M38DLWuLJWIaHNyaHbu0hOlyDdyuUhvFh+B8R6A39i/T7lB7sdRJ+g9Rfb6g Ac+3NbiJbyr0Ufre8uW/Zesy2k5L0A5mtmKyqVPb284973nPsxSzBxAL0NjWWLRnMgBmQMDS Pehq5zO0fO7GfBuhncr6FRsPkf9WKM7/pGVWN4GOnM7lFtqC96/oTzNN+rqcZnlFvXigeKB4 oHigeGDWPVAvFZj1kkoB28MDXd+at6sAa9/VgT1VHdeW2Qit1V+rjvw/9CZ7VfP7hXZ2OtG0 U9De2nr0LU2+lp48T8tT6rX/6uD9Tp3Re2hnqFerk3q1OvUjWvN/mmYNWvb/Z4ckvQ1/hdbc L9Tb+/9oV5x48y651R/+8IcfpI+G/9QsK8+rw/hzfSPwWP4L4qKLLrq2BhAn6011LKfR9xDf 0br4h2hd/hZ1dpdoFmbCrWWnYo9vN7Te/u9advUsvZlfobr8XXX/BfXUEqdT5fsbaznQa9XB XaqP3H+af5OgD45/ryVB6zQIeaLO/zKt4b9Eb/1XadZkdw0azrz97W8fb921vGm9BhVnqBP8 hute97r/UDnLZOdLnej2kQZV+8vuIZqx2FWDle8xAIGnpW3HKh7eq+Vd52i7289owPY4fWx+ FHJa2vQ9Bm76FuNRKut8fZx8hvx3pup2qP4D4x76vuTUL3/5y0ep3V6gwdEifb/xK33vcJQH fS57Itip7a2nGbV/qM1+rIHOK/k2glkmfSfxP/D1wfj1VY9jNFg9XYPVS7Qb1Bny4Ss0aL1a /rxQ39WcLvtjitW/afbplarrBfLZSg0kPmz704CTvi6nUVZRLR4oHigeKB4oHtguHhhfU7Bd iiuFTNEDvLbtqa30hveBkp1wm9cp1mNW1Vhqo8HMnlpWso716M3CRDtWndhz+Q5Bb9SX8AFx U6bXvN6G766Ziqv5NiTX4U25PmTejcFVTp8In4o9Zmf08fNgu3Plbbre3rM8p+NMCPr61mAP DRwu01r+tm+79fH5bldfffUCPoDOz6EdXX8U+C7NGrxUMxZDGjBs5BuNXCfH+QhcA4E91Rm/ moFJzuuEa7ZiDw2KrtDs0ChLsrT8aFjfa7T4P9fVrk/6Xvu9T4M2mbbXQGiZzmOVBgsXMXuT 28xx/KdvUEY1iKsHs/D5k0HNdC3RIOoSBha5zhTwC7V06+Qp6BWV+euBnu/389dF5cznoAdK 3O+EjdpTx3QnPK+5VuWeLy4NInbRyR+jY87NMrkjqZ2lfjbXGnhHOB8PInodFEy3zlr+tJtm K65WR71tR7/dIGIna3sGSJ/XIGLKg93p+rjo75Qe6Pl+v1OeXal08UB7D5S4b++XHZo65zqa O7S3t0Pl6LBoIMEWl0fpmFPtq/Xtf9Ab91iusx1cOe+K0Jv772g5WcfZh5l2iD64fgW7GunD 8Z/r37t/ppmllm1/8/J2wrZnAPHDMoDIW7HgxQPFA8UDxQNzyQNlJmLnaM1Jj9DTjAQDiZ1y adPO0SylltPxgD58fqv+Y2GJOtoj+nh5WEuL1unj95/oG4tf6ZuE9flMxHTKuQZ0+Y6kDCCu AcfPkSInfb+fI+ddTmN+e6DE/U7Y/mUQsXM0GhfXlJL25u9Th4z/FYh996dkpCgVD2wnD2gw sUGzE0v/P3tnAm9T1f5x8zx1cemWWZR5SqKMIZXeEhEiovQm8ja8KWN6NYgGmmdSKlEoY1Ia EDJFkXnmmuf5/312rfs/Tveee+69OOfc+zufz7b32XtN+7vWPZ5nPc+z1ty5c4kTv4rT3Ksu UNUprcb+Ri0uZRtK0a6UFqb8aZqAhKk03f1p9uU17tNs1+vFzzeBZCsR57thKl8EUkDAVsWy sX2CwwLpbSnbhzjyc9hH4/4vDvo3bRHQuE9b/a23/YuAxr1GggicJwL64zpPYFVsSAnYjuQ2 e/8Gh7c/hV9rNO79gOhrmiCgcZ8mulkv6UdA494PiL6KwLkioD+uc0VS5YQTgeI0JkuABmnc B4CjR6mWgMZ9qu1avVgAAhr3AeDokQikhID+uFJCT3kjlYDGfaT2nNqdEgIa9ymhp7yRSkDj PgJ7LkMEtllNFgEREAEREAEREAEREAERCCEBKREhhK+qRUAEREAEREAEREAERCASCUiJiMRe U5tFQAREQAREQAREQAREIIQEpESEEL6qFgEREAEREAEREAEREIFIJCAlIhJ7TW0WAREQAREQ AREQAREQgRASkBIRQviqWgREQAREQAREQAREQAQikYCUiEjsNbVZBERABERABERABERABEJI QEpECOGrahEQAREQAREQAREQARGIRAJSIiKx19RmERABERABERABERABEQghASkRIYSvqkVA BERABERABERABEQgEglIiYjEXlObRUAEREAEREAEREAERCCEBKREhBC+qhYBERABERABERAB ERCBSCQgJSISe01tFgEREAEREAEREAEREIEQEpASEUL4qloEREAEREAEREAEREAEIpGAlIhI 7DW1WQREQAREQAREQAREQARCSEBKRAjhq2oREAEREAEREAEREAERiEQCUiIisdfUZhEQAREQ AREQAREQAREIIQEpESGEr6pFQAREQAREQAREQAREIBIJSImIxF5Tm0VABERABERABERABEQg hASkRIQQvqoWAREQAREQAREQAREQgUgkICUiEntNbRYBERABERABERABERCBEBKQEhFC+Kpa BERABERABERABERABCKRgJSISOw1tVkEREAEREAEREAEREAEQkhASkQI4atqERABERABERAB ERABEYhEAlIiIrHX1GYREAEREAEREAEREAERCCEBKREhhK+qRUAEREAEREAEREAERCASCUiJ iMReU5tFQAREQAREQAREQAREIIQEpESEEL6qFgEREAEREAEREAEREIFIJCAlIhJ7TW0WAREQ AREQAREQAREQgRASkBIRQviqWgREQAREQAREQAREQAQikYCUiEjsNbVZBERABERABERABERA BEJIQEpECOGrahEQAREQAREQAREQARGIRAJSIiKx19RmERABERABERABERABEQghASkRIYSv qkVABERABERABERABEQgEglIiYjEXlObRUAEREAEREAEREAERCCEBKREhBC+qhYBERABERAB ERABERCBSCQgJSISe01tFgEREAEREAEREAEREIEQEpASEUL4qloEREAEREAEREAEREAEIpGA lIhI7DW1WQREQAREQAREQAREQARCSEBKRAjhq2oREAEREAEREAEREAERiEQCUiIisdfUZhEQ AREQAREQAREQAREIIQEpESGEr6pFQAREQAREQAREQAREIBIJSImIxF5Tm0VABERABERABERA BEQghAQyhbBuVS0CIiAC54XAmTNn8lNwYY4cHOnPSyUqVATOA4Grrroq3dy5c2ueh6JVZMIE zvDoMMe29OnT70o4mZ6IgAj4EpAS4UtD1yIgAhFNAOUhLy/QkCMmol9EjU+zBK688kp7d++f NAshhC/Ob8gWqp+JMrEvhM1Q1SIQEQTkzhQR3aRGioAIJEaA//wvI00bDikQicGK4Of79+/P +MUXXxT6/vvvLzpx4oSsTBHcl2HadPv9aPP370mYNlHNEoHwICAlIjz6Qa0QARFIAQEfC0Sc dbVgwYK9H3zwwRpWbLFixXrmyZPnye3bt2d21ezduzcTs40jfvvtt5zXX399c9I86J65c+XK le+qWrVqR/vuymvZsuV1GTNmfMkO8r9sh/t+0003Nevbt29FK9f/yJQp0wuu3MTOr7/+eon8 +fP3TSxdsM9N2L799tsblixZsnu1atU6DB061BQu7/Prr7/mvvrqq9uUKFGiR4MGDW795Zdf 8rhn7lyrVq02H3/88SXue3LLs3rLly/fpUyZMve1bdu2/unTp12R6Z544omKlSpV6sxx19NP P3153IO/L8aMGRNzxRVX3HPttdfeCZ8re/XqdWN0dHSfG/hYX/qnt763OnzvB6r/3nvvrVW2 bNl7rQ20pdLBgwfj/f8xsXa6+oIpzzi2aNGicenSpe+H8R0DBgyo4PLrHFICNp4a/v27EtKG qHIRCGcC8f5IhnOD1TYREAERiIdAQ+79Q5D0TXfs2LFsHTt2vN73nru+++6752/YsKHk4sWL c7l7NuO9YsWK8rfccssv7p6dx44dO+PUqVM97bjmmmu+x/1kjvs+adKkyZamQIECWxFAuvse J0+e7GXPgvm0adNm48SJE4cHkzaYND169Kg5e/bs6vfff//UJk2aLO7fv3/H0aNHe0pB69at 22fIkOHMwIEDx2fNmvVk8+bNux05csT7v6Ffv34VTLjFR/8aFLDsrq7klLdq1arsjz/+eNe6 desu/c9//jPlp59+qgTbplbmiy++WPqll166A2VmeefOnX8YPHhwu1dffbWEq++5554rM2jQ oBs+/fTTj6ZNmzaafL9Nnz59DNcvXX755dvRI25zaceNG1fYykXRaLl+/fqC7n6g+h966KFq KEk3NGzYcFGXLl2+e+utt27kHa92ed05sXa6dMGWB/vr5syZU+XOO+/89uabb170zDPPdEAh csXoHFoCniIR2iaodhEIbwIB/9MN76ardSIgAiKQLh2CugVRJ+rCdOONN874+uuvr+OYg9C5 05ddq1attiL4b3v55Zcrv/POOz/aM4TasgjXpxAIf/dNe66vURgafPPNN7WPHz+epWnTpt8j KH+DgFzwqaeeaopS8z7CZbOLLrroIEJ3ha1bt15avXr1hVOmTBmfPXv207S31AcffFB7wYIF o1y7vvrqq+g33nij6oQJE6a6e5RXA4F1Ju+yyu5RXwWE5spYJfauW7eu1LfffvvOJZdccpxZ 8c1wuNbKwOKybcmSJTEoFscyZ8581JVl5+SUN3XqVAwhJVe99tprc62MnTt3zoDxrVxOfffd d+vSJzNo9xx79tlnny15//33a/373/9eawoNwvu/UIJGwChDlSpVel133XVzUBYq8t6VKOcp rCjX7N69O1NUVNTJpUuXRu3ZsycnzHZbWe6DIlI1ofop+3KsSN+6tmGN+Qkm1cjrjQVXRqB2 ujR2Dra8P//885IHHnhgYu/evb0x9vbbb2/ctGlTWd+ydB1SAjH2+4JVUcHWIe0GVR6uBGSJ CNeeUbtEQASCJVA4mIQIyXtwW5rBDHOr+NLjJjP/u+++q+KeYQmojCvToly5cv2/z417mMj5 6NGj2Zhtr+57IBQX8c+GoF8Igf5q6hrBTPvIyZMn1zcBfteuXdkQJr30GzdujMaV52asCNMp YzjuV1cwU1/eysJF6jQC/knfclevXp170aJF5XzvYSnJmCVLllPuHu3LiuWlMEK5xRSkN4XE nh06dCgjaTMhRHtMiT2YBpNxPLeVa+I+ySkP150MtDWuDQcOHMiCsB9tSgKKQIEaNWpschUU KVIkFstHtH2HSXShQoW2lypV6ggz9dWx/CwdNWrU9xdffPHe4sWLr0PRS5czZ85DCOQ5LT1W luXWZlyfVtp39wlU/4gRI77C1SlOYYBfKdyuVru87hyonS6NnYMtDyXtfVMgUMryd+vWrRZ9 Xrxo0aK+Rek69ASC+n0JfTPVAhG48ASkRFx45qpRBETg3BKwZVyD+iCEz4yNjS2IW01l/wwI 6QvWrl1bxtxecH1Kz4x2JWbv5/unC+Y7QnqO8ePH1/E9EBRL+udduXJlXgT33Aj+uVBuVjNb P7RChQr7/dOx7OdcfPz/NOsAbZpGWZ4SYTP1uMN87J/e/3u9evUWoog0eO+994qa3/0ff/xR zhQJYj4OolytJ17iJiw0Bdu3b98Mt6tMuHJl9S/D93tyyuvZs+di3rfsI488UtXiGzgsJiKD xTOgTEQRc3LU1YEgvQcFx2sDMRsFCxcu7FkVZs2aVRVryTJLt2zZsmK0Y4XFVZjSVrNmzYCr 6QSq3/KilBy3mBmLD8ENqvhjjz32k2uPOwdqp0tj52DLc3lQJJrhQtXG3OCIr3G3dQ4PAkH/ voRHc9UKEbhwBOTOdOFYqyYREIHzQyDoFXry5ct3koDcscOGDWvdqVOns2aqGzVqtAthdQOu MxUvu+yy3czyn0Sw/zM5Taae3SgkLyeW9+GHH16J8D6XtvRCiTlIvMDczz//fIp/PoK+d7h7 BP/uwuWpsfvuzgQEd8LdKQbhO/Phw4fzIJQ/Yc8Q2j8jUHkesQ7FcZ3pljdv3t0Iyj/houFl 5dlY0rTBpasms/fLsQKsRbmIq8+V73tOTnlYdQ60a9duAi47NyMwp2/cuPFshPICJrxjJTmx efNmz5Jg9RDUnJX277Rr+mIv7luV7DpHjhyHt2zZkgvXrnwoXqVQor5DqWiC4uW5aVmahD6B 6rc8xLoUJjbmPt5/A5aYZ+B8lvXF0gRqpz33/QRTnks/f/78D1FgPiH+pBt1u9s6hweBoH9f wqO5aoUIXDgCskRcONaqSQREIAwI4O7yG+4xW1g9p6l/c+rXrz8f96IqWBAq4zaz0FxlzucH RSMbsQlf7dix4zHiFT7Fl74m7fMEZt96sVZkc9+JA4jBxeof1goUgel9+vQZQwzFTJSYnXZt B8rD5uXLl+f+8ssvP0U4fxxh/XkUjSzEB2w3V6Js2bKdwmVqGHU8/vPPP4/GZScahWqbqy++ c3LKw/qRo2vXrstQHAZifRiAdWUjisJ2K98UmzVr1kS5unC1isJVyWsDQdJbcPOJwTqQ7b// /e8U4hIa8K6N4TSalbBa4/qV56OPPpru8iZ0DlQ/SkoBAqq7MSbGY+F4Jz4FwsoN1E7feoMt z1apMoXI8jImT6BELsIK5FuUrkVABEQgbAmc3/8hw/a11TAREIG0TICA5LE//PDDtf4MiGFY yAx3WQT1qh06dEiWK5OViYtNehNa/Q/fJU0tHbEN1Qj4bo1P/ykEYrMCrMfd6h/uEwj3lU3g RwHIwv4IVbAYeP76tleCLTlqZbHCzyZcdlaj/GwmhuGoXdtB2kNPPvlk/dtuu62FpUNJyk9c RXlWQfoNa8sZ8nV/9tlny9oz/PJrYxnYxOz/Efue0Cc55VFvIQKiH+X9MtuBNaIBqyEtsDqw jCzBlauWLXlqblU//vhjzTp16qyxZyzNewo3qxnNmjVrz71YYh9e5flnWJRWoVwMwQqxkdl7 TxC39Al9AtWPsnU9LkgLUOR+M5cmOyxQ28qy5XbNDcyuA7XTN12w5aHAHUEZqmsuXVYn/VmV 5V6tKn1EQAREIOwJyJ0p7LtIDRQBETjXBAiwjkWAnYXgepY1gpWPDiDIr2O2PN9dd921Mbn1 IoAWZunR5/zzsxLSw7gmxfn+E5uxEDebJvjCD8S6sA+h/hRLrS7AanCJb15bIQlXq34ENGdh 9n4rQq0380664m+++WaL//3vf0t90/tfo0z8iOtPB9sLYtu2bRejQIxneVpvLVHiIaY8//zz LVkp6TiKSnasMIkuLZuc8ix+g2Vb1+B29SAWkdy0ZQ1t9+IOcHGaBfuyrKg0iHiUHAS5z8bq 8Id7jyFDhvwaExNzECXkXt4/lpiJHQjd+bCa5Meisbx27dp7XNqEzoHqxyJUAsWxEIzjxgOW gQ2weo4Vo+riRnUEl7MNgdrpmy7Y8swdi1iXey+99NJatPsMCsRKKREJ9aDui4AIhBsB+fqF W4/E354z3FZfxc9Gd1MvgaDGPUsw1gTBlZGKwfajQJmJRng8aH77/u/BvY7EKKy2OATcjrIn FkDsn9/3u60ChKVin8WG+N43KwcrGkWZcuV7P7Hr5JRn1hliNjLG965mWcEScjSQJcTy4wJU AMUhNiG3o0DtDlR/oHy+z4Jpp2/6QNdm8Zg5c2YBXOl2oUye6N69O4s7jegeKI+eXVACvxA/ NO+C1pg2Kwvq9z5tognft5ZgGr5949sy/XH50tB1WiEQ1LiPdCUisc50SgQrS/2QWFo9j3wC UiLCrg+lRFyYLgnq9/7CNEW1BEtA7kzBklI6ERABEQgBATagW8SMe6LuOiFomqoUAREQARFI wwSkRKThzteri4AIhD8BNlhbHP6tVAtFQAREQATSGgGtzpTWelzvKwIiEBICFvsQkopVacgI WJ+z63chi6GwladC1hBVLAIiIALngYCUiPMAVUWKgAiEngAbgw1htaMXMmfOPNQOllEdzLr8 3Uygu9CtY6fli9gZekB89bLM6xUEbg537bQzgc/9WYnoFgt4ji9PMPe++uqraJaN9ZZ/DSZ9 ctPY0qb58+fvm9z8/vlM2GbFqIbsY9G9WrVqHYYOHXqZS8Pu1bltR2lbZapBgwa3srRrHvfM ndmwrQ17b8StbpXc8qze8uXLd7G9HNq2bWu7a7sq0tmyuqwy1ZnjLgLeL4978PeF7cjN0rr3 sMrUnfC5kuVob4yOju5zAx9bztU/fWr/zngeMHr06Lg+Se3vq/cTgbRCINn/QaUVQHpPERCB yCXwyiuvvIQQ+ZAdbFbW/+jRo9nuueee28PtjVjeda9rp50Jon7922+/rffoo49WT25bWTmp CMLsP/bCSG55CeVr06bNxokTJya6LGxC+f3vs0t4TTbdq84O3lObNGmymH0UOjoBtHXr1u3Z APAMy+COZ9nbk9f/n7YAACAASURBVGyk180pWv369auAAnHH3Llzr2H51+yu3OSUt2rVquws v9uVzd+WsnfIFFaDqsSmd97yr+xoXprlcO9AmVnOUrk/oAS2Y+naEq6+5557rsygQYNuYFfx j6ZNmzaafL/RF2O4follf7ejR9zm0uosAiIgApFMQEpEJPee2i4CIhA0AVs+s169egv37dsX N3t999131+F+HzvatWtXzxU2Z86cvCy5ej+bgT1Xrly5Lm5m22a+zZphVg5mlh974YUXvFny CRMmFKpSpUpHNm6rxz4QPa2cAQMGVGC50kc5HmE/hCqu7GDOCJ7b2TtgPfsUeG1NqF6UjSI2 I+7KtE3RbDUnaw/XzVGcSjAb3sqe2+w4bXswd+7cg9iTob3tAO3ysaTqfZbHffc9mxUFq8i/ UG7SozA0YJ+GJ9i5eSDWgkaWDgG54H333XeLXbNbdrOOHTtea+WhGP0P3rc5IZ8N/kpR752W zn3MWkKeuL0Z7D7l1UBZmMnGb6ssHoQZ/RXwr7xixYqc7LNRCuF8PBsBbhw7duxXzOoXsDIs 35IlS2JsPw0sOXH7cCS3PBSBqlhCVr322mtz2YBvLeNkBopEDSuPHbProgjMYF+IOezx8Cf8 l9APts9DOntXlIx/wXK0beTHmOjFxnhF4HYDy+f2YD+OBWwYWNhtZIcyUgpW/2ZzwGcqVqzY mY0OPeUnofs2th544IErbeyxp0Y/9tKId1xt3bo1C0sBt7W+ZufvHuxvUcza16pVq0bW93Zt H8ZKB/aquMquUXzKWfls7jfIxhAbEua0+7S9oeWz9plFoWXLltfx3tWpvy/t6O024gvU91aO +wQahy6NnVEUy5uFy96BMdzSNii0+2b5sTFof4NmKTLrlN0Ppp02llu0aNHYxpLl0UcERCBl BKREpIyfcouACIQxATY1y2wClR0m7MyYMaMW+yQssyabSwqCaBNmmj9nJvndKVOmXMustSco IjR1ZnOz7aQfzHknadpZHnZ97oxQtgUBqx+b0U3p3bt3FzYpy40wm2X58uWV2AW7cpcuXabb XgTMUHdC+FmAoDee3ZI9Qc3KSOCT3rXTZsFpWyWEzaIIPL9b+gD1ZiVfYVcm7ciK4lGIPQdi 2Qn7OxSYzcOGDZtqCgObpfWwHZcRcM3F6xRCbQeXj+8nMmbMaEssxn3MnccUKKwBj8Mxhwnr vMfVWB1GIHCOnDx5cn27t2vXrmzsHF3EMrKPRTRC4s1YEaYjWA+H0xVwKG/PEKpPU89Z+1Mg NOdetGhROXvuPmyolxEB8ZT7jvUo64YNGwofP37cYgrSI3B7fkWHDh3KSNpMKFje+xN7MI29 Lsbx/LDLa+fklIfClMEYuXIOHDiQhQ0Io01JYIO7AjVq1NjknrE5YSyWD0+RgUk0m9RtL1Wq 1BEUoOqMtaWjRo36nn7Yy7hZhxUlHW51h9h12xNi2STw9q5du86YNGnSENvlHMWprpWb0H04 l4B5rZEjR77NOJuIwtI2vlgblJw7aHNO6h7BGPqRZWPvtzGJYjuHPqmAlaUyY7r6mjVrSmLp WWiuWih5tzJGvsEK9Ky14eGHH25gZ8ZXPsZM08aNGy+mX8d9/vnn/+KoywaAI1GAVtO/N1q6 QH1vz+2T2Dj8K1W6dCbsP/XUU52pb7y9A+0shjJXn7+vfLxDZzh9jvIwAIXnIMqspxQF0076 4djKlSuLsu/KQJSsds7C5erVWQREIGkE0pxvZtLwKLUIiEAkE0AQ6skR9woIcPsQjmfZDWa3 67J86vcIVCvsOwLgLFxOqiGkbTBhbfHixcOjoqJOIhR/jdvKMQS9gghKJRGyXmfG9iiz1Ys+ +eST+sxIV2D3500nT57M9PXXX7/DzPkh3JCqEAOxnlnzb6xsFIOZCH7N7doCbRHwvFnVW2+9 dYvdQ0jPh7IyzK7dh3iAuXfcccdmykywXoT8nS697xnh6hSzxPsRxo8jyO5HUK3NzHEs7zLT 0r3zzjsTmEEfjOCVBcHqOArQ23YfYTgzPGoiNNZj/40MzZo1mw2PD4lBOMosehkE99wI/rlQ tlYjSA/lHY/CxBOILb992EF6rs3Q2zUuWdOwLJRH6VhqO0bbYfcDfcxaRDsbwHE3QmcehN9y COCrEfwOGlOExpsQgH/ECnS1MUeIznquy2NH7sUoXM0feeSRqszcb6c9FhORweIZUCaimAk/ 6upk9+w9KC9eGxBsC7Lr9W57hiBcldn0cXa9bNmyYrzXchPWzaXONgykzzOw6V5uhPpCcPmT fh6N4pgNobl5fPetHPsgQH9lmwLaQT/VxFpS2nd3b1NCGbvVUfgGEDey26xa7EJehw3syg8f PvwXFIXxuPndhnKVAWX1Q5SeE9bvxM+MsX41pQTOO3///ffiXoX8A/tFKKML7DtWkgOM29ko Mevhn+Gxxx6LU0YT6ntXDopBtUDj0KVDOaqJJfCPJ5980lP4Yf4Z1oMoxmBNeK+lTk+5Rvn/ ir+Tp51VLbF22uaE9MU7ZtljTNZBMenGRMAuLF/fUddip6C6dugsAiIQmIAsEYH56KkIiEAE E0BwGoZA1sMOdgXuRwDzaVxvmtgrMYNe8Msvv2yK4PC0HR999NHNCPe5cYuJwl1nlykQls7c oBDWpixduhTvivzbTYGw+/ZBmMTLItZzpyDPblMg7D4uLGXwf19j1/ZhZnidd8E/CPR3447z qB0I715eXH/2uHbSrgdRQt5euHDhVeauhEAYsF5Xrp2ZrY/3Nx03oAI7duyIce+KAtAHJSE9 AudZCgBCWK9x48Zdh5D2Ge/1FALtd6ZAWNkoYyuJOZiLENrL3FqYab8axeeYPfP9wGeH+47Q tgulo5T77s4oMJ3MJQXB9U4UmSJ2bYfFE9jO3ChAO3Hb6fbWW29djzD/E/Vst7w8G4tSURJL US8EyzxYAdbS5rj6XPm+5+SUhzvPAdzbJuAGdDNy5j0Ix0vpo32mcKGYnUDYj+OGMpCVtnvK HDPze+GW1+rPkSPH4S1btuTCDSqfMcD1ZidWgSYVKlRYZc8p7zTK0EeMrYaMtSFYm1pi6cAg lDFdfPctj31QWOPeF067UWpL/vXkr38ZewWsbxlzj7j+RikujqLgjTVz0eJ5OoT53QjQnjBO +0/QzqIMtL6wHjR//vwKvmVSz173HWvKSRTTbfbdrEt84iYjE+v7YMch3KLoW68Oq4cxt8GU du7nZ0ytt3v2sX6iDccYE7nse7DtNMUa7pPpq36Mpe9Qrlozzu60MvQRAREInkC8/+EEn10p RUAERCDkBM5yw/FtjQk5CFLeYbOyHD/gGhNjaYh3OHrvvfd+iuDW2w6E2cdRNF6rU6fOdpsJ PnbsmLnPmJUgg/mhk3cr13ktNsDu2wfXoWhclv4xu85MbixCe76/UqVLh1BW0F3jDjMYIa6H HTYj7e67dpry8uyzzy5CedlMkHBMYvWawOjKwO3jIhMQ/T/4lR9FwP3dvaudifvoi0B61iZ2 CM4z4HIYF5U2tiIRwm9cgPLatWuzYb35ivd6jNnwTxFea+IKU8m/LqwVcbEWuHrFICzv90/D DP/0Pn36jMGPfiYKyU67toNA6c2mWKHcfQrrxxHWn0cxykJ8wnbanIG2ncLyMYw6Hv/5559H wzK6UaNGccKmfz32PTnlIZTmQNlbhqIyEOvDAJSIjQjaniJjyiKco1xdjKcoLCVeG5j134LA HmMz41gHphA/0YB3bQyn0ShMrVEQ86CsTre8NuOPpWmt1YGVaijvmRnloTkWgnTx3Xf1MU7j +NpYRnA+iy+WkCMI+qdpY3/X3zB4AkF5tpVB31VDmTarUwwWCU8B4Vkp3NQa07+vGXcUmlmW xn0smN1dBzon1vfBjkPrb2Pl6jJrnMXUYJ3Y5vt3ZbFLuJ0dJ2Yn1tIG205LO2/evLy8ZzPi lW5DOdzMeP/Z7sfzCerd48mnWyKQ6glIiUj1XawXFIFUT+AsH/hAb4sgeBDlwHM9wRXoD9yX qluQqx3EEbTHjaURK/LsQbDdhVtPVSuL5Tlr4a5SkVn4fX/f94JZzT8bQSeaoNs4i4Orm+Di Zfhel6X8Aib8IhQneZUlBK4DCHRZA9XLLPxuAsWjcBuKMuUG16G4ehCuTptgam3CbWslCsFl bnlb3I1qcK8nQpfXZAuUtWBTXL0WIqQOQYkZiTtLUWbPzXf8DoTcIigW1YizaI1L2CkE4uXM FK9nJjeHe2d3RrivbO+MApCF+qpgnVltz6xui0OxawLQN8F6NTPCm1Gejtq1HWbJwa2kPsJd C0uHS05+3H3K4072GwrhGfJ1p21l7RkWgtoIf5tQjo7Y94Q+ySmPegshmD7K+2W2A4tIg4YN Gy6wOiyuZOrUqbWMtwm3zPzXRPH0xoC5kbVv334GbmDtuRdL7MOrPP+MMbQK5WIIVoiNuNJ4 yiXKUDaUk8dMOSMoeMtNN920ECE8B31mLmH/uO/ejyVjq9k1Qn80M/PFiFnxlFiUg6pYrXKh dO5CcdtLH3nxPTZOmbHvw1gsZK5O5G9Jez5F4ZmMcuPFVGB9K2yCNGXFWt/ZOIpPGXVtSOic UN+79IHGoSkEFqthaeln7+/HYiNMmWdstIRfbqx3SxmXl9t9S8e7VGShg9/dOLZ7iX3MLY9x fTd/54/zt2NxI8Ppg+FY/1YmkDfo35cE8uu2CKRaAnFmyFT7hnoxERCB1E4g4Ey078szu3/I ZmD/FqamIih2w8f6SVwy0jODu4n4hjGWHgF1Iu46nYgdaG5xBfjfj7T7FkyNoN0Roboprk95 WalmsgmO9sz3g7C9g1nTVQiTfc0NBuHxN9/nwVyT7zBBx6VJ+31C9SIw7iaIdyVBr33NBQuB 6k8EIs/VBneW9cw0F0ZQb4fgOhq/+O9I39980m12H//0D1w78HPvhAD/vHPHMn93jpG4cOVC 0KxNYG5XZm6fRqFpAsOB9k4I9afw+V+AgnTW+v+2QhIs+zGjngWlbSsB7d7MO+mKM+vbgqDh pa7e+M4IjD8SI9ABN6oeWHouRoEYj8XEc6chHmIKQmBL2nscYTc77zQ8vjJ87yWnPIvdwN9+ DW5XD6LI5aYta2j7T1YuLk6ziJMoC8dBCLg5sETN9o1JIOD4V1yCDjK27uX9YxlfOxhz+bCa 5Ec5WF67dm3P+oMge4hxsYw+G8xKXOuoJyflfI7LT7n47rt3QqkqTbk1sGRcxPiaZgqIPSOO oCOK3QgUyz9Z7vZDFLa7ib9paOkYC9NMcbNgYlv1i+DkZfBbTttqMgPfhPE9Cze2hvTboyhH WYnfmMNCAw2d0ufqTuycUN+7fFj+1iU0Dom9KUo72qCsLra/H1aDWgbDfhbHBM8txDAspvwz uAn+gfWpP23dCLM8KBJvuvITO7OQQmGU0Fa26ABK1SgshscTy8PzoH9fgihLSUQgVRH4f3tl qnqtVPcyZk5VX6W6btULJUIg6HHPrOmtlOW5KSVS5lmPLdDVrAV20wJVfR+auwmznrl8XY7s OTP1WbBMFEB4jE1MCDELAdaLE+a77Vt2cq4D1WvLXDIjfwjh/rRv2QhZGVB2Mpkvv91HAM3J rHM+hKht8Sk/vnl9r2022AQ4Y8IsfDQK0sH43ol7HRFiV1scAjPt2f3Z+ZaZ2DWz4flRgMz6 48WmuPQ2Uw7/KP/+cs8TOienPHNrwrUtY3zvapYVuJqbWIKWEMtPrEEBFIdYC+qNr202RpgR z2wB0PYchY1QnhHd/e/bM+IlXqT/nsBikQmF4YjrV3vm/7EgcBSBaITxfaaw+D+P77v9LTCu d5trnblkYQ076WKD4kvvey8pfR/sODR+KPGnXVyOq88Co7F0ZUeJ2mHj0t1P7OzGcWLpfJ5v wa1rvM93XZ4/AkH/3p+/JqjkpBKQYJpUYqFJrz+u0HBXraElEPS4R4nIS1PbcMi6GsI+c4Ik AeE/hLAZEV21UyLiewmnRASrFMRXxvm6lwr73pTXMSgRcXFL54udyvUIBP17L17hQ0D/4YZP X6glIiACySRg/9GjSMwke0MO/a4lk2NKs+HzvogZd89dJ6VlKf8/CWBBmoI7WTAuOP/MfJ7v pLK+NwViphSI8zxoVHzEE5AlIjK6UBp6ZPSTWnluCSR53P9tkTBFIsmuTee26SpNBOInQDxO FLEI+3DD+UcsjeUIZImIv0TdPccELMZECsQ5hhpEcUn+vQ+iTCU5zwQ0Y3eeAat4ERCBC0fg 75nD8SgT+am1MIetHqTJkgvXBaopEQIEOP/A+MxMPMMXBMSPY1fmP3yz4O9vX71/fO/r+rwS MAHWYla28Ruy67zWpMJFQARE4AITsB84fUQgrRHQuE9rPZ423tdWmrKxfYLDAu7Xcti26qb4 2kfj/i8O+jdtEdC4j8D+1gxdZHSa/XGpryKjr9TKc0dA/6mcO5YqKbwJHKR5tuuy/c7r9z68 +0qtOz8ENO7PD1eVKgKamdIYSJMEpESkyW5P9S/tb4mwjeoe4pAlItV3vV4wAAH93geAo0ci kBIC+uNKCT3ljVQCGveR2nNqdyACx3ho/vdvcHi7T/sl1rj3A6KvaYKAxn2a6Ga9ZCgI6I8r FNRVZ6gJaNyHugdU//kgUJxCswQoWOM+ABw9SrUENO5TbdfqxUJNQH9coe4B1R8KAhr3oaCu OkNNQOM+1D2g+kNBQOM+FNRTWGeGFOZXdhEQAREQAREQAREQAREQgTRGQEpEGutwva4IiIAI iIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERABEUhjBKREpLEO1+uKgAiIgAiIgAiIgAiI QEoJSIlIKUHlFwEREAEREAEREAEREIE0RkBKRBrrcL2uCIiACIiACIiACIiACKSUgJSIlBJU fhEQAREQAREQAREQARFIYwSkRKSxDtfrioAIiIAIiIAIiIAIiEBKCUiJSClB5RcBERABERAB ERABERCBNEZASkQa63C9rgiIgAiIgAiIgAiIgAiklICUiJQSVH4REAEREAEREAEREAERSGME pESksQ7X64qACIiACIiACIiACIhASglIiUgpQeUXAREQAREQAREQAREQgTRGQEpEGutwva4I iIAIiIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERABEUhjBKREpLEO1+uKgAiIgAiIgAiI gAiIQEoJSIlIKUHlFwEREAEREAEREAEREIE0RkBKRBrrcL2uCIiACIiACIiACIiACKSUgJSI lBJUfhEQAREQAREQAREQARFIYwSkRKSxDtfrioAIiIAIiIAIiIAIiEBKCUiJSClB5RcBERAB ERABERABERCBNEZASkQa63C9rgiIgAiIgAiIgAiIgAiklICUiJQSVH4REAEREAEREAEREAER SGMEpESksQ7X64qACIiACIiACIiACIhASglIiUgpQeUXAREQAREQAREQAREQgTRGQEpEGutw va4IiIAIiIAIiIAIiIAIpJSAlIiUElR+ERABERABERABERABEUhjBDKlsffV64qACIiACIhA qiRw5syZ/LxYYY4cHOlT5UvqpVIlgauuuird3Llza6bKlwvflzpD0w5zbEufPv2u5DRTSkRy qCmPCIiACIiACIQJAZSHvDSlIUdMmDRJzRCBJBG48sorLb33T5IyKvE5IcBvyBYKmokysS8p BcqdKSm0lFYEREAEREAEwogA//lfRnPacEiBCKN+OddN2b9/f8Yvvvii0Pfff3/RiRMnZGU6 14BVnv1+tPn79yRoGlIigkalhCIgAiIgAiIQPgR8LBBxXgUFCxbs/eCDD9awVhYrVqxnnjx5 nty+fXtm1+q9e/dmYrZxxG+//Zbz+uuvb06aB90zd65cufJdVatW7WjfXXktW7a8LmPGjC/Z Qf6X7XDfb7rppmZ9+/ataOX6H5kyZXrBlZvY+fXXXy+RP3/+vomlC/a5Cdu33357w5IlS3av Vq1ah6FDh5rC5X1+/fXX3FdffXWbEiVK9GjQoMGtv/zySx73zJ1r1arV5uOPP77EfU9ueVZv +fLlu5QpU+a+tm3b1j99+rQrMt0TTzxRsVKlSp057nr66acvj3vw98WYMWNirrjiinuuvfba O+FzZa9evW6Mjo7ucwMf60v/9Nb3Vofv/a+++iq6bt26LS+77LL7WrVq1SghJWTUqFGX0u8d jNedd95Zb+nSpblcOYm109JZuS1atGhcunTp+2F3x4ABAyq4/NZWe0Yb/l2nTp1Wc+bMMetZ gp/43iOh9sGmlY1X38PqT7BwPUiIgI2nhn//riSU5qz7UiLOwqEvIiACIiACIhAxBMyF6R+C pG/rjx07lq1jx47X+95z13fffff8DRs2lFy8eHGcsGgz3itWrCh/yy23/OLS2Xns2LEzTp06 1dOOa6655nvcT+a475MmTZpsaQoUKLAVAaS773Hy5Mle9iyYT5s2bTZOnDhxeDBpg0nTo0eP mrNnz65+//33T23SpMni/v37dxw9erSnFLRu3bp9hgwZzgwcOHB81qxZTzZv3rzbkSNHPJmo X79+FUwIxUf/GhSw7K6u5JS3atWq7I8//nhXhPil//nPf6b89NNPlWDb1Mp88cUXS7/00kt3 oMws79y58w+DBw9u9+qrr5Zw9T333HNlBg0adMOnn3760bRp00aT77fp06eP4fqlyy+/fDt6 xG0u7bhx4wpbuSgaLdevX1/Q3d+8eXOWDh063Etfpee9JqIYlG7WrNm/3HN3Xrt2bbauXbt2 R4nbD5MvaHfMzTff3MmeJ9ZOVwZMr0M5qIIC8i15Fz3zzDMdpkyZUsCew/eWefPmVezevfvU IkWKxNKGngcPHvyHDJrQewRqX6NGjVZcd911S9xh77pv3764Me3ap3NQBDxFIqiUJAr44xNs IUonAiIgAiIgAiJw4QggqFsQdaIuTDfeeOOMr7/++jqOOQidO31byKz0VgT/bS+//HLld955 50d7hlBbFuH61EMPPfS7b9pzfY3C0OCbb76pffz48SxNmzb9HkH5GwTkgk899VRTlJr3EUKb XXTRRQcRuits3br10urVqy9EIB2fPXv207S31AcffFB7wYIFo1y7bLb9jTfeqDphwoSp7h7l 1UCwncm7rLJ71FcBy0JlrBJ7161bV+rbb79955JLLjnODPlmOFxrZWBx2bZkyZIYFItjmTNn PurKsnNyyps6dSoT+yVXvfbaa3OtjJ07d86A8a1cTn333Xfr0iczaPcce/bZZ58tef/992v9 +9//XmsKDcL7v1CCRsAoQ5UqVXohJM9ByK7Ie1einKewolyze/fuTFFRUSdRDqL27NmTE2a7 rSz3gVW5bNmyHfnxxx8/s3u7du365rHHHuuK1eBL3s8Ca70PXEpgddoxY8aML+xGuXLlJtWo UWOwWawCtfOv3H/9++eff17ywAMPTOzdu7c3dt5+++2N9GtZLD276Mdrv/vuu/4ooHt79uy5 mn5sMmLEiDK05axxltB7BGofFo9lrh1m4cBi0QQF8CV3T+ckE4ix3xesiokGW/9DC0xyVcog AiIgAiIgAiJwoQkUDqZChOQ9uC3NYBa9VXzpcQWZj3BXxT3DElAZt5BFuXLl+n+fG/cwkfPR o0ezMdte3fdAKC7inw1BvxAC/dXUNYKZ9pGTJ0+ubwI8Am62TZs2eek3btwYjSvPzVgRplPG cITZK5ipL29l4SJ1GgH4pG+5q1evzr1o0aJyvveYkc6YJUuWU+4e7cuK5aUwQrnFFKQ3hcSe HTp0KCNpM+HS5DEl9mAaTMbx3FauifskpzyE9Qy0Na4NBw4cyIKwH21KAopAAQT1Ta4Cm6HH 8hFt32ESXahQoe2lSpU6wox+dSw/SxGOv7/44ov3Fi9efB2KXrqcOXMeQnDPaemxsiy3NuP6 tNK+uw9cChYtWjSujpo1a8Zincq5fPlyL59L165du7X0y1vuO+xLY5XYhhvWoUDtdOntjPL1 vikQKFv5u3XrVou+LI5VYsUPP/wQBYNjpkC49JS9E4uX967unp0Teo9A7fPNT31tb7vttm9x 0zvqe1/XSSYQ1O+LlIgkc1UGERABERABEQg5AVvGNagPQvjM2NjYgrjVVPbPgJC+AFeRMuZ2 g3CZnpngSszez/dPF8x3hPQc48ePr+N7IFCW9M+7cuXKvAjuuRFwc6HcrGa2fmiFChX2+6dj 2c+5+Mb/adYB2jSNsjwlwmbqmXH+2D+9//d69eotRBhu8N577xU1//w//vijnCkSxHwcRLla T7zETVhoCrZv374ZbleZcOXK6l+G7/fklMes+2Let+wjjzxS1eIbOCwmIoPFCKBMRDH7Hyfs IuzvQcHx2kDMRsHChQt7VoVZs2ZVxVrizbYvW7asGO1YYXEVprShFARcTWfLli1RKBtxdeCm ZYL8GcbDWe9qQjfK4wF7X4tHGD58+B1wmWLfA7XTnvt/UCSavfXWW23MvY2YnBMod1FYdo74 psNispcxkMX3XqDrQO1z+V555ZWSWGbyY8H5xd3TOdkEgvp9kTtTsvkqowiIgAiIgAiEjEDQ K/Tky5fvJAG5Y4cNG9a6U6dOZ81U40++C2F1A4JXRYJedzPLfxLB/s/kvBX17EYheTmxvA8/ /PBKhPe5tKUXSsxB4gXmfv75557A6psXwXGH+162bNlduMY0dt/dmYDkTrg7xSB8Zz58+HAe hPIn7BlC+2cEKs/DF784Ljbd8ubNu5vYg59w0fCy8mwsadrg0lWT2fvlWAHWolzE1efK9z0n pzwTzJlFn4Brz80I1ukbN248G6G8ABaF41hJThCzEGcRIEYgK+3faXXSF3tx36pk1zly5DiM MpALl6B8KF6lUKK+Q6loguLluWlZmoQ+CO/HUY7i6sCqkNnc1WrXrr3HP48pNgQ930VdMYyH 17AmrLU0KtzTbgAAIABJREFUgdrpX4Z9nz9//odYVD5BYelGDMSNd9111xwsL3FtsDQorFmw ssTadbCfhNrn8uMWVh/XuB+xesS5ablnOieZQFC/L1IiksxVGURABERABEQgsgjgJvIbQcVb 7r333qb+La9fv/583IuqMMu9C7eZheYqcz4/FiSLj/tXCLiTmPEug3LTivZtYSb+LGsEM9XZ XDuIA4jBxeqs5/YMRWA6s89ZEVwvQeiu06dPn0/tPoHU23DZyf3ll19+anEPds9WY0Jh2Giu RMQJnMJlapjdt1WFmDEfjEK1zb4n9ElOeVg/chCwvMzFnDz//PNleJftVocpNmvWrIly9eFq FYWrktcGgqS3/Pe//40hSDob5ynEijTH5WsnnEazElZrBPC1uDyNc3kTOsfExOxG+bjUPSc2 Ij8xFDucK5e7b0wQ+jujCO6nfwab4umeBWqnS2NnW30Kq9fHKCh7ccU6gXK4iPoqokjtgXE2 Y4Ey6LmImcUAhWWrb/5A14HaZ/ksdoOjIpzHBipHz84tgfP7S3Fu26rSREAEREAEREAEkkmA INux+Kdf65+dGIaFzHCXRbityko+yXJlsjJxsUlvgqL/4bukqaUjtqEaAd+tcbM5hUBsVoD1 uNf8w33i559/rmzCo60wxP4IVVAAVlt+2yvBlhy1a3zgN1mgLsrPZgTjo3ZtB2kPPfnkk/Xx j29h6VCS8iNklmcVpN+wtpwhX/dnn322rD1jxr02loFNzP6f5XJjz3w/ySmPegsREP0o75fZ DqwRDRo2bLjAykWpWYIrVy1TYsytCoG7JoL1GnuGUnMKd6IZrGLUnnuxxD68asHRWJRWEWsw BCvERmI48lnaQB/edxnKUkmLOcE6kBllpAkKiFeHBSE7FzdWgrqc9hX85JNPvjC3Nktrh/Vd oHbasrzmLmZtsABulJy6ZjGwvPRTVd71V3O5gu96+vpqS0ege1WsRrmwynhWl7+/26MEP4Ha Z5lGjhx5GUvfbmUc/EPRTLBQPUgxAVkiUoxQBYiACIiACIhA+BMgwDoWoW4WgutZ1ghWPjqA IL8ON5t8uJ5sTO6bMLtcmKVHn/PPz0pID/sGuiK4LmR2ugk+8wOxLuxDqD/FsqILsBpc4pvX VkjC1aofAc1ZcPPZirA63Z6Trvibb77Z4n//+99S3/T+1ygTP+L608H2gti2bdvFCNTjXXAv 8RBTsAq0ZKWk4ygq2YnjGO6f3/97csqz+A2WbV2D29WDuCvlpi1raPtPVjYuTrNgX5b4gEEI 7jkIcp+N1eEPV++QIUN+xZJwECXkXt4/FkvNDoTzfLgk5SdeZHl8Lkkurzubu9odd9zxxa23 3vpf3JKOobjtR3l40Z6jWBR94YUX2qDULeZeSQLbL8YS8rzLa2eWk+0fqJ24ENXF3eoIrmkb zM2KeIp7L7300lpkPcN+EStRHBZaOazENArFrQdWjWuJ5chJQP1bzhqC61RHVuOyZAl+ArUP ZcRWf7qM+jz3qwQL0YNzTiAon6dzXqsKTCoB8+9TXyWVmtJHOgGN+0jvQbU/OQSCGvcswViT wq9MTgXhkMf2o0CZiUbwO+gCen3bxb2OxCistjgEZtKzJxZA7JvX/9pWC2KGep+vi46lMSsH KxpFmXLlnyfQ9+SUZ9YZZt8zxveuZllhpv5oIEuI5UdQLoDiEOtcggK10f8ZDLP+/vvvNvuf 6LKd/nnd92DaiSKZaebMmQVwkduFknjC5bWzWTisz80C4RQI95zYCfSMEd3dd51DTuAX4ofm JdYKCaaJEQqP50H9pxIeTVUrROCcEdC4P2coVVAEEQhq3Ee6EpFYfzglAh/7HxJLq+eRT0BK RNj1YVBKhNyZwq7f1CAREAEREAERSNsEWGVnETPu/1hBKG1T0duLQHgRkBIRXv2h1oiACIiA CIhAmifABmuL0zwEARCBMCeg1ZnCvIPUPBEQAREQARGIVAIW+xCpbVe7zw0BVgTLxy7ghSxe 4tyUqFLChYCUiHDpCbVDBERABERABFJIgBV4hrDa0QtsuDXUDlbjGcz6/d0sKDaFRSc5Ozst X8QeDQPiy8iKQFcQuDnctdPOBD73ZyWiWyzgOb48wdyzpUxZEchb/jWY9OcqTe7cuZ9iM7yY c1Xe0KFDLytfvnwX23uhbdu2tsu1V7QtB8vKUg1LlizZvVq1ah0snX+dtuO05fG9n5zy2DU7 t+2tYatbNWjQ4FaWlM3jyjTO7APRkmDw+9iwr5G1yz2zs+1vwWpTrcqVK9eF5Xgbsbzw1Vw/ ZN9Z8amAb1q7ZuWqdPa+vvcD1T9q1KhLiZvpYBxY9akeO63n8s3rrhNrp0sXbHk2bitWrNiZ JYTv6dixY11bftiVkRbPyf5DTYuw9M4iIAIiIAIiEO4EXnnllZcQ6h6yA2GuP0tqZrvnnntu D7d2s7zrXtdOOxNE/fq3335b79FHH62e3LayclKRMWPG/GMvjOSWF2w+hNWhrPLkbSIXbJ6E 0q1atSo7y+B2RUhfyh4eU1iVqRKbz3nL8rKbeM3Zs2dXZ6fvqWyot5h9GTqyiaC3NO64ceMK Wzr2bmhJvxd05Se3vNatW7dn48EzLL87nuV2T7L7dze3bwf7idzL0rvp+/XrNxEBvjT7WfzL 1WeCdb169e5hp+75bND39t133z2PPTlmzp079yX22pjE5nvt2Jcku6W3VaNYVvgaNgpMx8Z7 pVwZdk6oftuskDK658+ffz9t+4L3i2GJ2E6+ee3a2hGonS59sOVNnDgxmn02OqBErGEp3sn0 Q2WW/a3nykmLZykRabHX9c4iIAIiIAJpgoAts4lAt3Dfvn1xs8gIdXW438cOBL04Icg2H2PJ 1fvZNOw5mzFmV2lPOLUZaLNmmJWDDb0eY28Bb/Z7woQJhapUqdLRZoLZB6KnAR0wYEAFlit9 lOMR9kOokhTICMDb2WNgPXs6eG1NqF6UjSLsu9DZlW2bndlqTtYerpsjQJewWXB7jkIRQ9se xFIwiD0Z2tsMuctns+iWx31P6GybxHXp0qU2u2uXZF+JUuT7N0uUPmMz0k4YZifwVvC7yNLA +zabubc6bRYfxShuV+r46rS2miDr6mdjtarMsK967bXX5rIR3lr6awaKRA17jpJUA+F6Jhu0 rbK4EWbEV9BPle0ZwnwUe33kZN+J3fbdfZJT3ooVK3Kyv0cprCvjEcQ3jh079is2kStgM/tY FcrZxnK2+R19v4k2foPL0tUogp41gk3ybsQS8p21nSVpW7OXRO3evXs3xMrUacuWLTnZPG8x nMpZ+7Zu3ZqNd4+GlWuudw5UP+9bgn0zdsyYMeMLqx+leRJtLWO7VvsWklg7Xdpgy2PjwKKM oQUfffTRLNtPhWVsF/K53Mox5Y1yvL8XV25aOEuJSAu9rHcUAREQARFIMwRwDcmMcJbFDhOw EbZqsU/CMgNgOz0jEDZhhvtzNkF7lxnga5nd9gRU3FI6s7nZdtIP5ryTNO0sD7s+d2YTsi0I af0QnqYgEHZhd+vcCJVZmGmuhABZGSF7uu1lgLtHJ4TiBczUjkfousryB/ikd+202XLaVonZ 46ItWrT43fIEqDcr+Qq7cmlHVhSPQgh1seyE/R0KzOZhw4ZNNYWBTdB62I7LKAvm4nUKa0EH l4/vJzJmzGhL6sb7MXcsc69CsRnEu9RgQ75DbHB3O7PgMyZNmjTEduhGmK9rmdlFuqjx2LFj R05cx+ohFB9h5noYm+XtgGNzV0F8deK2U5V4gcwuDcJ4Bmur+37gwIEsKAfRZgVg9j8jylzc M6xMWTds2OCxwCqxnH0vxqFYrHR57Zyc8o4fP24KQXq3n8OhQ4cyUncmFLvCKE4F2fhuk6uD PTxi2QMiJ2PBE+LZj+IyLARLbIyw03YJlI1PcKeaQTtLwm4tiugBOHlag+3/YW1GGXXFeedA 9aP4rqU/33IZUBRLY5XYhjvUIXfPzom106UNtjw2xZuP9WGsKTimSLNBYSPG+iIrxyw2bGbY HS4PYkmrkhKXPNeuSDgryCUSekltFAEREAEREIEgCTz88MM9OeJSExexDyFult1gtrQuy6d+ j7vMCvs+efLkWfioV2OGeQOCcInFixcPj4qKOolg9jVC0TGE5YK4nJREeHrddp1mVnvRJ598 Up/Z5Qrs/rzp5MmTmb7++ut3EFwPmfBEDMR6Zq+/sbJRDGaOHDnSE6AtsBZh2BOU2T15iz1H 2cmHsjLMrt0HP/+57LC8mTITrBcryU6X3vecJ0+eUwio+xGyj6M07Udgrc2sfCzvMtPSvfPO OxOwYAw2xQVF47i52vjmd9cWP8AuzfWZIS+FkDuf93kBd5nttDcDG8blRpkqxO7Mf9LG0Sg9 cRYEl992heZ9pyBYpsPFaBxWhYE2S49icCahOl1eO+MisxjFp/kjjzxSlZnv7bTfYiIyoKRk MqsS3xvAezdKUh4Ut3IoeKt98/tfJ6c8Nvo7aH1J/MVNKEE/IjRfbX1NoHxWrAlRvONRV0+t WrX2cn0Gi01WzgdN0bF3xRJQFd7eOEPgLl6qVKk/TCmZN29eaRTGb13++M6B6rdxaIfls/gP 3Ldux+rxiX85ibXTpQ+2PJeesVEW68ft9ElmFBfPhY1unkb/zMS9qwp/Yw1o020ooLPZmftH f+XGlZMazrJEpIZe1DuIgAiIgAiIwN8E2Pl3GMJuDzvYPbgfAcyn77vvvib2eNeuXQW//PLL pghzT9uBa8bNCPe5lyxZEpU3b95dpkBYOnODYrZ3Ci4yTPLm3+6ENnuGKwnyYqw3k0ye3aZA 2H1mnMtcfvnla+zaPjfccMM674J/EOjvxi3mUTsQpL28xETsce2kXTaD+zbuIVeZuxLKTMB6 Xbl2ZtY6XlkGF5cCzHjHuHetUaNGHzbpS49yc5bbi29ZLVu2bEw77sc9ahVCel+sCmNNgbA0 tPc0AvVHcGkIpyFYSloy4/yP1adoeKwpEPYxZcVmqbFKnOU2hdBbC45P2AGDnMQ3PGjXZvmg 7gPMjk9AWL2ZdPdcddVVS6l7n5VlO3ijKO184IEHur311lvXo2z8ZNYjr7IE/kluedQ1FiWl JBaqXlhC8mCJWYtwv4P4iOMoE3EMd+7cmZl3PIXrkrevB+PNs+6gwB22dKZAwawaFp0dzOaX xmpUEIvRjgSaG3c7ofotgSlUFoj9wQcf3ECZr3EsiMv490Vi7fRNH0x5Lj1K5kL67DHGyiSs P51d0LvtiI7iNB+l+wVc+V6bP39+eXg9Ze/v8qa2c7x/eKntJfU+IiACIiACIpBWCLA602mb 8bUD3/zdHD/gSuKtHIQv+1H89z9F+O1tB7Pyj6NovIaf+nYEo9y4pXgCj826I6heSd6tXOf1 FYQQAqNx41jrz5OZ61iE9nzuPkJUXHAvguZgBPgedpgLi0vj2mnKC8G3i1BeNhOAG5NYvaYM uDIIyL2I7+5r3BmXoqPEIPzu3tXOxC30xYLiCbtxCX0u2rRpsxThdBEz59cjJP7LLCjusS1X i5VkLQL1QCwsQ1FeMvu6Krl0MLQZee+DMpQLrnkoc7+7Z2eUqd/79Okzxg4sJ9YnE+wa17Kf zS0MpWuZ1YNwOwAlYiMKhqcomAKGEvgpffI4VpDnaUMWLB0BlYjklAerDIyVUwjEw3Blevzn n38eTR9GN2rUaBtKy26u4+I8UB7z0387rC/t3YirWY07U3ksKUv4mp7Yka64fX1DPxVBwW2K G90YSxfoE6h+e4b1ozP9exBr0WCLvYivrMTa6fIEWx5WmUYEtNe0fKYk4tb3C32dw8XF2H1T Rth9+0re9w7ikPJidZtkVhl7lho/UiJSY6/qnURABERABETgbwIIoAedYIsr0B+4L1W3Nfvt II6gPe4ujVgJaA8zqbtwc6pq2Xr16lULX/WKCGv7/r7vOa3bmv9YDaIJ9o2zODjQLHm5bOXK lWVtCU8TzBB2k7zKEoLhAQTkrIHqZXZ3NwJalAUsm3JDsHFcPQhsp024tzbhtrUSAe8yt7yt ub5wr6ezEvC9uvm3u/bbGcVhG1aZ93nP/zGTfojA3QdwF+phrkUmjCPQP2ZB0CgbW2666aaF CNg5fPPbNQL2xcSdeHEKxFDUxDKxjd23D9szVyez9nvhvtoOlL5TWDXW2LVZPYi/KIRF4lEL 6LYDi0ODhg0bejPtrG5Un7QtrCzS5ce1qjxuZ7/Z94Q+ySmPNp3h3buj2JW1chHUa2MJ2YRS doT6lpmLmwVZb9++PTMrFjXBVSluPKAkTMbdrRnxNoVxXRpNjMSbWFY2Ex/xiq2mRH8kGoAc qH5c6i6HS0Hc6r4wpdfaYIdZBGxxAMawF2geqJ2+6YItD2UtFqWyLkHu+awu61vu/W5MrC/o s3+huAyaOnXqlSiBU2njwM8++8xz7UuobyL9vmIiIr0H1X4REAEREAERCECA2f1DCFkxFryM r/ZUhJ1uBIA+iSCUnsDfTQh83swwguJEVvzpROxAc4srwA9+pBVrwdS4cHRk9r0prk95EbQn W/yBf5XmosIs9CqW++xr7jcVKlQIKNz657fv5Du8aNGi0lx+n1C9Zl1BaF3ZuHHjvuaCxcpR fyLYe8oALlTr8VcvTExEO4KAR2NR+I70/S02wmbtEXg/cPWy0lInXLGed+5Y7r6diUU4gAvO ZJShqfi5VyYuoh6+/hl4p2XUNxjXnHUoOzkJIP/cN59dw2YXLO/GupCBOILMBJu/79IEqtOl Id5iLYL4GuIJHqSO3KzwtAb3mJ/sOYrGjzzvYKs+YRG6GEF5PJYVi0lI8JPc8ph5n/L888+3 pM3H4ZAdlsOtEqwRu7DIfMEs+38ZJ8csBgSh/EXXAItnINbmdRStOxhDpxlr2+CQwdyYbFUn xtsklzahs83eJ1Q/dZVEkb0Y5e553/wor/1RUGKosw3MFwdqJwpQUZcu2PJQrJeznK4FUw+w 8c3Y20P/T7A2MFY7MPbXERthS/3G+rYrNV/HmQNT80umgnczU5j6KhV0pF4hSQQ07pOES4lT CYGgxj3uO+ZWcWVy3tlmUc1aYHn9BR5z2WHmOJevy5Gls2BkLBMFEKBicVs6bvcS+piFAOvF CfPFTyhNsPcD1WubkTELfAiBznOjcWUieGdA2clkMQR2z5b+xLqQDyVnW3zKj8uX2NlmvfGz P2PvhyUksy1J65/HNrr78MMPG2CRGc7qTlEmyDrLh3/axL6b5QNXqIzxccT6kh9FyaxEXgxL YmXZ8+SUZxYl+j3Kf5xYeVgjstpYQZnbZd/j+5h7DwpFIeI4jqLMJcgCFyA8nUZ09y8jUP3+ aRP6Hkw7E8rrf9/+duj//FjMTvr+jbix4Z8+gr//QmzLvMTaL8E0MULh8Tyo/1TCo6lqhQic MwIa9+cMpQqKIAJBjfuUKBERxCLimuqUCCwjL0dc40PY4ISUiBA2Ka1XHZQSIXemtD5M9P4i IAIiIAIiIALnhACz09txtZl7TgpTISIQ5gSkRIR5B6l5IiACIiACIiACkUGgefPmO+yIjNaq lSKQMgJanSll/JRbBERABERABEQgAQIWY5HAI91OpQSsz21pXFsVy3dp4FT6umn6taREpOnu 18uLgAiIgAikJgKsljOE5TFfYHWboXawcs5gVhPq5pY5vZDvSmDxRQRhD4ivTlbPuYLAzeGu nXYmSLi/bbZmwbTx5Qnmni07anEJwaRNSRpWuSrB0q19U1KGb14TtlmNqCFLhnZn1+4Otmu2 e24B5Gwq18ZWZCI4+VZWncrjnrkzS+K2YafkuKVTk1ue1WubuDFm7mvbtq3tlO2qSMcu0xVZ Maozx11sBHd53IO/L9hJO4aVru4h+P5O+FzJakY3ElDdhxWzbrAAa//0qf0743kAqznF9Ulq fN9k/6GmRhh6JxEQAREQARGIdAIscfoSQuRDdrDrcv+jR49mu+eee24Pt/diVaW9rp12Zqfq 11n5ph47Rsft+5DUNrNqURGE2WuTmi+p6Vm+dCO7UHtLniY1b3zp2WSu5uzZs6uzmdlUdq9e zE7IHZ0A2rp16/as8HSGPRbGszrUSdylujlFi+VnK6BA3MEGfdewjG92V3ZyyrMlgNljoSt7 hixlE70p7IdQiRWomlqZttM0S73egTKznGVlf0AJbMcytCVcfey1UGbQoEE3sBTuR6z8NZp8 v9EXY7h+iV3Mt6NH3ObS6px6CEiJSD19qTcRAREQAREQgbMIsEfEiXr16i1kSdK42Ws2iqvD /T52sAlYPZfBNuBirfv7Wcv/OTal6+Jmtm3m26wZZuVgZvkx1tf3ZsnZR6FQlSpVOrIpWb1i xYr1tHIGDBhQgaVVH+V4hL0NvA3qXPmJnW3JVPZfWM9+Al5bE6oXZaOIzYi78t57772iLIPa 0drDdXMUpxLMhrey5zY7TtseZEnOQez90J5n2Vw+loe9z/K4775ns6LY5mEoN+lRGBqwYd8T 7Asw0HYttnQIyAXvu+++W+yaDeKasdHetVYeitH/4H2bE/JffvnlUtR7p6VzH7OWkMcTzt09 yquBsjCTnY5XsVfHYmb0V8C/sm2Gt27dulII5+PZ5Xojm9h9xax+ASvD8rJ0bQyKxTEsOUdd WXZOTnkoAlWxhKx67bXX5tou0IyTGSgSNay8d999ty6KwAz2eJjDhnl/wn8J/VDLntm7omT8 C5ajbZM4xkQvdrEuArcbWBq2B3tNLGB37cK2uaGlRxkpBat/s8P1M+xm3dnt+JzQfRtbtnu6 jT32++jH3gzxjitbDpjA9rbW17ZB4Ntvv13M6mvVqlUj63u7tg9jpQN7Z1xl1yg+5ax8lv4d ZGPIlgO2+7S9oeWz9plFgb1RrrONAqm/L+3obWPO0gXqe3vuPoHGoUtjZ9vp2yxc9g6M4Za2 2aDdN8uPjUH7GzRLkVmn7H4w7bSx3KJFi8b+Gyta/pR+pESklKDyi4AIiIAIiEAYEWCfhMwm UNlhws6MGTNqsafAMmuiuaQgiDZhpvlzZpLfZVfha5m19gRFhKbO7Li7nfSDOe8kTTvLww7J nRHKtiBg9bMN4Hr37t1lwYIFuRFmsyxfvrwSuztX7tKly3Tbh4AZ6k4IPwsQ9Mazi68nqFkZ CXzSu3baLDhtq4SwWRSB53dLH6DerOTzdoS2dLQjK4pHIXbfjmUviO9QYDYPGzZsqikMnTp1 6sHs+RIEXHPxOoVQ28Hy2IfvJzJmzGhL6sZ9zJ3HFCisAY/DMYcJ67zH1VgdRiBwjmTPg/p2 jxWYsm3atKmIZWQfgmiExJuxIkxHsB4OpyvgUN6eIVSfpp6z9nJAaM7Nhnrl7Ln7sJFdRgTE U+471qOsGzZsKMwGebYUf3oEbs+viB2yM5I2EwqW9/7EHkxjH4dxPPd2xHb5k1MeClMGY+TK YK+NLHv27Ik2JYFduAvUqFFjk3tWpEiRWCwfniIDk+hChQptZwPAIyhA1RlrS0eNGvU9/bCX cbPO9snAre4QO1Z7Ajo7Pd/Ojs4zJk2aNMQ2PERxqmvlJnQfziVgXovNDt9mnE1EYWkbX6wN Ss4dtDkndY9gDP3IsrH325hEsZ1Dn1SwnawZ09XXrFlTEkvPQnPVQsm7lTHyDVagZ60NDz/8 cAM7M77yMWaasgfGYvp13Oeff/4vjrpDhgwZiQK0mv690dIF6nt7bp/ExuFfqdKlM2GfzRA7 U994ewfaWQxlrr7tEs87dIbT5ygPA1B4DqLMekpRMO2kH46xb0lRNgEciJLVzlm4XL0pOac5 H7WUwFJeERABERABEQh3AghCPTnimokAtw/heJbdYHa7btOmTb9HoFph3xEAZ+FyUg0hbYMJ a4sXLx4eFRV1EqH4a9xWjiHoFURQKomQ9ToztkeZrV70ySef1GdGugI7JW9iJ+JMX3/99Tu2 6zNuSFWIgVjPrPk3VjaKwUwEv+Z2bYG2CHjerCo7HW+xewjp+VBWhtm1+xAPMJfdkDdTZoL1 IuTvdOl9z7aRHLPE+xHGjyPI7kdQrW07VfMuMy0dO3FPYAZ9MIJXFgSr4yhAb9t9hOHM8KiJ 0FiP/TcysOP2bHh8SAzCUWbRyyC450bwz4WytRpBeijveBQmnkBs+e1z1VVXzbUZervGJWsa loDyKB1LbbdoO+x+oI9Zi2hnAzjuRujMg/BbDgF8te3+bEwRGm9CAP4RK9DVxhwhOuu5Lo/d sBejcDV/5JFHqjJzv532WExEBotnQJmIYib8qKuTXaj3oLx4bUCwLcjO57vtGYJwVWbTx9n1 smXLivFey01YN5c625zNNgJkA73cCPWF4PIn/TwaxTEbQnPz+O5bOfZBgP7KNryzg36qibWk NIrqH3899cZadsZudRS+AcSN7DarFjts12EDu/LDhw//BUVhPG5+t9mu4yirH6L0nLB+J35m jPWrKSVw3snmecVdmbBfhDK6wL5jJTnAuJ2NErPedt9+7LHH4pTRhPrelYNiUC3QOHTpUI5q Ygn848knn/QUfph/hvUgijFYE95rqdNTrlH+v+Lv5GlnVUusnWXLlj1MX7xjlj3GZB0Uk25M BOzC8vUddS12CqprR1LOskQkhZbSioAIiIAIiECYE0BwGoZA1sOOmTNn9iOA+TSuN02s2cyg F/zyyy+bIjg8bcdHH310M8J9btxionDX2WUKhKUzNyiEtSlLly7FuyL/dlMg7L59ECbxsoj1 3CnIs9sUCLuPC0sZ/N/X2LV9mBle513wDwL93bjjPGoHwruXF9efPa6dtOtBlJC3Fy5ceJW5 KyEQBqzXlWtnZuvjlWVwAyqwY8eOGPeuKAB9UBLSo9ycpQAghPUaN27cdQhpn/FeTyHQfmcK hJWNMraSmIO5CKG9zK2FmfarUXyO2TPfD3zilnVFaNuF0lHK97ldo8B0MpcUBNc7UWSK2LUd Fk9BbTdaAAAgAElEQVSAu8o8FKCduO10e+utt65HmP+JerwdsXk2FqWiJJaiXgiWebACrKXN cfX512Pfk1Oe7YyNe9sE3IBuRs68B+F4KX20zxQuFLMTCPtx3FAGstJ2T5ljZn4v3PJavTly 5Di8ZcuWXLhB5TMGuN7sxCrQpEKFCqvsOeWdRhn6iLHVkLE2BGtTSywdGIQypovvvuWxDwpr 3PvCaTdKbcm/nvz1L2OvgPUtY+4R198oxcVRFLyxZi5aPE+HML8bAdoTxmn/CdpZlIHWF9aD 5s+fX8G3TOrZ675jTTmJYrrNvpt1iU/cJHxifR/sOIRbFH3r1WH1MOY2mNLO/fyMqfV2zz7W T7ThGGMil30Ptp2mWMN9Mn3Vj7H0HcpVa8bZnVZGcj/x/uEltzDlEwEREAEREAERuCAEznLD 8a3RhBwEKe+wWVmOH3CNibE0xDscvffeez9FcOttB8Ls4ygar9WpU2e7zQQfO3bM3GfMSpDB /NDJu5XrvBYbYPftg+tQNC5L/5hdZyY3FqE931+p0qVDKCvornGHGYwQ18MOm5F29107TXl5 9tlnF6G8bCZIOCaxek1gdGXg9nGRCYj+H/zKjyLg/u7e1c7EffRFIN3jmxbBeQZcDuOi0sZW JEL4jQtQZufpbFhvvuK9HmM2/FOE15q4wlTyzW/XWCviYi1w9YpBWN7vn4YZ/ul9+vQZgx/9 TBSSnXZtB4HSm02xQrn7FNaPI6w/j2KUhfiE7bQ5A207heVjGHU8/vPPP4+GZXSjRo3ihE3/ eux7cspDKM2BsrcMRWUg1ocBKBEbEbQ9RcaURThHuboYT1FYSrw2MOu/BYE9xmbGsQ5MIX6i Ae/aGE6jUZhaoyDmQVmdbnltxh9L01qrAyvVUN4zM8pDcywE6eK77+pjnMbxtbGM4HwWXywh RxD0T9PG/q6/YfAEgvJsK4O+q4YybVanGCwSngLCs1K4qTWmf18z7ig0syyN+1gwu7sOdE6s 74Mdh9bfxsrVZdY4i6nBOrHN9+/KYpdwOztOzE6spQ22nZZ23rx5eXnPZsQr3YZyuJnx/rPd j+cT1LtLiYiHnG6JgAiIgAiIQJgTOMsHPlBbEQQPohx4rie4Av2B+1J1C3K1gziC9rixNGJF nj0Itrtw66lqZbE8Zy3cVSoyC7/v7/teMKv5ZyPoRBN0G2dxcHUTXLwM3+uylF/AhF+E4iSv soTAdQCBLmugepmF302geBRuQ1Gm3OA6FFcPwtVpE0ytTbhtrUQhuMwtb4u7UQ3u9UTo8pps gbIWbIqr10KE1CEoMSNxZynK7Ln5jt+BkFsExaIacRatcQk7hUC8nJni9czk5nDv7M4I95Xt nVEAslBfFawzq+2Z1W1xKHZNAPomWK9mRngzytNRu7bDLDm4ldRHuGth6XDJyY+7T3ncyX5D ITxDvu60raw9w0JQG+FvE8rREfue0Cc55VFvIQTTR3m/zHZgEWnQsGHDBVaHxZVMnTq1lvE2 4ZaZ/5oont4YMDey9u3bz8ANrD33Yol9eJXnnzGGVqFcDMEKsRFXGk+5RBnKhnLymClnBAVv uemmmxYihOegz8wl7B/33fuxZGw1u0boj2ZmvhgxK54Si3JQFatVLpTOXShue+kjL77Hxikz 9n0Yi4Us3ob8LWnPpyg8k1FuvJgKrG+FTZCmrFjrOxtH8Smjrg0JnRPqe5c+0Dg0hcBiNSwt /ez9/VhshCnzjI2W8MuN9W4p4/Jyu2/peJeKLHTwuxvHdi+xj7nlMa7v5u/8cf52LG5kOH0w HOvfygTyBvX7EmeOSaAQ3RYBERABERABEQg/AgFnon2by+z+IZuB/VuYmoqg2A0f6ydxyUjP DO4m4hvGWHoE1Im463QidqC5xRXgfz/S7lswNYJ2R4Tqprg+5WWlmskmONoz3w/C9g5mTVch TPY1NxiEx998nwdzTb7DBB2XJu33CdWLwLibIN6VBL32NRcsBKo/EYg8VxvcWdYz01wYQb0d guto/OK/I31/80m32X380z9w7cDPvRMC/PPOHcv83TlG4sKVC0GzNoG5XZm5fRqFpgkMB9o7 IdSfwud/AQrSWev/2wpJsOzHjHoWlLatBLR7M++kK86sbwuChpe6euM7IzD+SIxAB9yoemDp uRgFYjwWE8+dhniIKQiBLWnvcYTd7LzT8PjK8L2XnPIsdgN/+zW4XT2IIpebtqyh7T9Zubg4 zSJOoiwcByHg5sASNds3JoGA419xCTrI2LqX949lfO1gzOXDapIf5WB57dq1PesPguwhxsUy +mwwK3Gto56clPM5Lj/l4rvv3gmlqjTl1sCScRHja5opIPaMOIKOKHYjUCz/ZLnbD1HY7ib+ pqGlYyxMM8XNgolt1S+Ck5fBbzltq8kMfBPG9yzc2BrSb4+iHGUlfmMOCw00dEqfqzuxc0J9 7/Jh+VuX0Dgk9qYo7WiDsrrY/n5YDWoZDPtZHBM8txDDsJjyz+Am+AfWp/60dSPM8qBIvOnK T+zMQgqFUUJb2aIDKFWjsBgeTywPz4P6ffl/u00QJSpJyAiYWUl9FTL8qjhEBDTuQwRe1YaU QNDjnlnTW2mp56aUlBZboKtZCyyPBar65jV3E2Y9c/m6HNlzZuqzYJkogPAYm5gQYhYCrBcn zHfbt+zkXAeq15a5ZEb+EML9ad+yEbIyoOxkMl9+u48AmpNZ53wIUdviU3588/pe22ywCXDG hFn4aBSkg/G9E/c6IsSutjgEZtqz+7PzLTOxa2bD86MAmfXHi01x6W2mHP5R/v3lnid0Tk55 5taEa1vG+N7VLCtwNTexBC0hlp9YgwIoDrEW1Btf22yMMCOe2QKg7TkKG6E8I7r737dnxEu8 SP89gcUiEwrDEdev9sz/Y0HgKALRCOP7TGHxfx7fd/tbYFzvNtc6c8nCGnbSxQbFl973XlL6 PthxaPxQ4k+7uBxXnwVGY+nKjhK1w8alu5/Y2Y3jxNL5PN+CW9d4n+8JXkowTRBNWD0I+j+V sGq1GiMCKSOgcZ8yfsodmQSCHvcoEXl5xTYc8ioIYV87QZKA8B9C2IyIrtopEfG9hFMiglUK 4ivjfN1LhX1vyusYlIi4uKVA7PTDE4iOnomACIiACIhAmBKw/+hRJGbSvIYc+v88RP2Ez/si Ztw9d50QNSFVV4sFaQruZMG44FxwDqms702BmBmsAmGwZYm44EMuWRUGPTOVrNKVSQTCk4DG fXj2i1p1fgkkedz/bZEwRSLJrk3n91VUuggERyCQJSK4EpQqhQQsxiRJCoTVp5mLFFJXdhEQ AREQAREIJYG/Zw7Ho0zkpx2FOWz1IE0ShrJTVHeSCODvb+m9f5KUUYlTQsAmLCxmZRu/IbtS UpDyhjcB62h9RCCtEdC4T2s9rvc1Ahr3GgepkUBxXipLgBfTuA8AR49EICUE9MeVEnrKG6kE NO4jtefU7pQQ0LhPCT3lDVcCtsu3je03Obw9H/waqnHvB0RfReBcEdAf17kiqXIiiYDGfST1 ltp6rgho3J8rkionnAjYnhc2tk9w2NK/azke5jAXPPto3P/FIaL+lc9kZHSX/XGpryKjr9TK c0dA4/7csVRJkUNAwlTk9JVamjICB8mei8PkG/3ep4ylcotAggT0n0qCaPQgFRPQuE/FnatX S5CAxn2CaPQgggn4WyLW8C4PccgSEcGdqqZHBgH9pxIZ/aRWnlsCGvfnlqdKiwwCGveR0U9q ZdIIWEyErQT0BodiIpLGTqlFIEUE9J9KivApc4QS0LiP0I5Ts1NEQOM+RfiUOUwJFKddWp0p TDtHzUrdBPSfSuruX71d/AQ07uPnorupm4DGferuX71d/AQ07uPnEtZ3M4R169Q4ERABERAB ERABERABERCBsCMgJSLsukQNEgEREAEREAEREAEREIHwJiAlIrz7R60TAREQAREQAREQAREQ gbAjICUi7LpEDRIBERABERABERABERCB8CYgJSK8+0etEwEREAEREAEREAEREIGwIyAlIuy6 RA0SAREQAREQAREQAREQgfAmICUivPtHrRMBERABERABERABERCBsCMgJSLsukQNEgEREAER EAEREAEREIHwJiAlIrz7R60TAREQAREQAREQAREQgbAjICUi7LpEDRIBERABERABERABERCB 8CYgJSK8+0etEwEREAEREAEREAEREIGwI5Ap7FqkBomACIiACIiACCSZwJkzZ/KTqTBHDo70 SS5AGUQgRASuuuqqdHPnzq0ZourTarVnePHDHNvSp0+/KzkQpEQkh5ryiIAIiIAIiECYEEB5 yEtTGnLEhEmT1AwRSBKBK6+80tJ7/yQpoxKfEwL8hmyhoJkoE/uSUqDcmZJCS2lFQAREQARE IIwI8J//ZTSnDccFVSBmzZp1kR2nT58OIxpqigiIQDIJ2O9Hm79/T4IuQkpE0KiUUAREQARE QATCh4CPBSLOq2DUqFGXVq1atUPJkiW733nnnfWWLl2ay7X4iSeeqFipUqXOHHc9/fTTl7v7 e/fuzdSiRYvGl1122b/r1KnTas6cOWbZiPfTpUuX2tmzZ3/mlltu6Xnrrbc+kCNHjudatWrV yCkTHTt2rGvl+Ga2MvPmzTvwm2++MXcrfURABMKTgP2ONPz7dyWoFkqJCAqTEomACIiACIhA 2BEwF6Y4BWLt2rXZunbt2j1//vz7Bw4c+MWqVatibr755k7W6hdffLH0Sy+9dMfVV1+9vHPn zj8MHjy43auvvlrCnjVv3vyWefPmVezevfvUIkWKxDZr1qznwYMH/yEfkK/OJ598cgP5XkXx GLBnz54nP/zww2FTp06tj1JxvZXl/7n22mtbLl++/PLJkye/0KhRo2T5XfuXqe8iIALnjYCn SARb+j9+JILNqHQiIAIiIAIiIAKhIcBsoc3qn+XC9PHHH5coWLDgjhkzZnyBFWLTK6+8Mmnd unVlfvvtt5zvvvtu3RtuuGHGG2+8MefBBx/8E2vEkvfff7/WsWPH0v/000/Xjhkz5t2ePXuu 5vzt0aNHs48YMaKM/5uNHTu2adu2bSd16tRpg3vWsmXLbbVq1ZqHItHwxIkTZwVz16tX77bf f/+9DO15sXbt2ntdHp1FQATCmkDM378viTZSSkSiiJRABERABERABMKOgK3CdNanXbt2aydM mPCWu4lCUBqrxLby5csf2rlzZ4EaNWpscs/M4rB9+/boH374ISpz5szHrrnmmjghnzw7V6xY Ee3S2tncog4cOBB1++23r/K9b9e33Xbb0uPHj+dYsGBBHvesfv36Lb7//vv6KC9vV69e/YC7 r7MIiEBEEPjH70t8rZYSER8V3RMBERABERCB8CZgy7ie9SlWrNhR4iE8gR1rQ43hw4ff0b59 +ymWCNejKKwUR12GokWL7kHwz7po0aKorFmzHnH37XzRRRftPXToUBbfe6tXr85p34m1OOR7 366xRMTaeffu3V6eNWvWlEHpKF+4cOGNffv2bWbP9BEBEYgoAv/4fYmv9VIi4qOieyIgAiIg AiIQ3gTOch1yTbUgaSwPXT744IMbiIN4jWOBPcuSJcuJzZs3e4qAfSfmIStKxc5cuXKdOHLk SNx9e4aLU5ZSpUp5ioF9tw/WBM9SMXLkyJJ/3fn/fz/66KPSfDuDMrHH7hJsffCrr756mc8o lIlqKBIV/z+1rkRABCKAQLy/L/7tlhLhT0TfRUAEREAERCACCaAMZECQ75w7d+6DBFkP7tat 21r3GqyOtBsLQZT7vmHDhqjixYtvw3Kxh1iGbH/88UfczCMWhfysqLTVpbUz7k/HoqKits2c OfMK3/t2TUxFaZ6v4flJ+44FYgvt2MeqTVubNm069YUXXmhDkHd2e6aPCIhA6iEgJSL19KXe RAREQAREIA0TeO655y6PjY0tyApKX1jANDEPme2w5VdZlWkJwc+1LPj566+/Lvjjjz/WRFFY U7NmzX0XX3zxeqwFVxu6hx56qOrhw4dzNW7ceKc/yjZt2kxj+ddazzzzTNzysLZULDsN17rv vvsm+6e378RlTM2WLdth8raM77nuiYAIRC4BW8pJHxEQAREQAREQgQgngIBfcteuXRdjYXje 91WmTZvW/+23356FS1JZ4h0GoWDkYOnV2f/973//sHSsxDSK1Zx6YK24lpWZcg4aNOgt9oL4 xy5yrPY0DwUjCwpH1wEDBpzMkCHDaVZxSff444+/37t3799963TXefLkOfXUU099hJLRi2Vn F/bv3/8390xnERCByCYQlM9TZL9iqmj9Gd5CfZUqulIvkQQCGvdJgKWkqYZAUOMe4b0mb3xl Ut+aFZMuwvJwlA3hzgqmNssFlopos0DEp0D41mNpiXkohNvUCdJr7wdfOLpOFgH2KEGXHdE9 WZmV6XwQ+CV9+vTzEitYlojECOm5CIiACIiACKQSAnXr1vWCn/1fhxWazrAx3Xb/+/F9t7Ts cL0tvme6JwIikHYIKCYi7fS13lQEREAEREAEREAEREAEzgkBKRHnBKMKEQEREAEREAEREAER EIG0Q0BKRNrpa72pCIiACIiACFxQAvv37894QStUZWFHgF3R833xxReFWDpYLvRh1zspa5CU iJTxU24REAEREAERCBsCbCo3JFOmTC9kzpx5qB05c+YcXKZMmW4WUH2hGzlr1qyLLrnkkgHx 1Tt48OArCNwc7tpp53z58vW/7rrrbrH9LuLLE8w9Ar6jQ7G5HUHmT3366acxwbQxmDRDhw69 zDYNpO/ua9u2bX1bptc+tkTv7bff3pCdw7tXq1atg6XzL892K7c8vveTU96vv/6am6WB25Qo UaJHgwYNbv3ll1/yuDKNM/E1LQnQv4/9QBpZu9wzO69fvz4bK4C1KleuXJcnnniiERsPXs31 Q/ad1cIK+Ka1azY/TGfv63s/UP2jRo26lD1OOhgHVharx6aGuXzzuuvE2unSBVuejduKFSt2 vuKKK+7p2LFjXTZwPGtnd1deWjkn+w81rQDSe4qACIiACIhAJBFgKdaXEOoesgNhrj/Ltma7 5557bg+3d2C37L2unXZ+//33X//222/rPfroo9WT29bp06cXYW+Ka5ObP7n5EFaHXn/99UEF pidWh23Mx7K5XRHSl/7nP/+ZwmZ+lW655Zamlq9Hjx41Z8+eXf3++++f2qRJk8Usmdtx9OjR l9izcePGFbZ0r7/+ekv6vaDds09yy2vdunV7lvE9w9K84wmmP9m8efNupuCZ4NyhQ4d7T506 lb5fv34TEeBLN2vW7F9/1ZYunT2vV6/ePe3atZu/fPnyt+++++55zz777Ez2E3npySefnNS1 a9d2q1ev9jYf3LhxY9a77rrrmilTpqRjM8RSrgw7J1Q/Gylmo4zu+fPn30/bvuD9YlgUoJNv XrtOrJ0ufbDlTZw4MZrlijugRKxheeTJ9EPlnj171nPlpMWzlIi02Ot6ZxEQAREQgTRBoECB AicQ6Bbu27cvbhYZoa4O9/vYgaAXJwSxz0Te0qVL38/mcM/ZjPHHH3/sCac2A23WDLNyREdH P8YO1N7s94QJEwpVqVKlo80EFytWrKcBZf+ICiwh+yjHI2+++WaVpEBGAN5+6aWXrt+2bZvX 1oTqRdkoUqlSpc6u7Pfee68os9IdrT1cN0eALmGz4PYchSKGtj2IpWAQ+2S0txlyl89m0S2P +57Q+f/YOxM4Hcv9/499XxoMOQdZSots2VL2gxYqUYiIlJSUTnUkipROKdXhl85pOSfFUZIW hUKWSoRj3/esY4ydsf/fn7uu53/P45lnHmMwy/d+vW73dq2f63rGd/+SwC9Ht27d6g4bNqzc W2+9VZ56DxMG9++SSDtiuHv37neB3yUqA96tJblXn5LiwxgFMoWH6lNjFSHr+idpYDUk7GtG jBgxR1nHWa8pMBI19B0mqQbE9TSSAq4h6d8iJOIrWKcq+gYxH71nz5585AKJ17M7UtLeihUr 8m3cuLE82pXxMAy/ffbZZ9/s3bu3qCT7aBWuZo8cIWHhWNZ+C2OcisnS9TCCnjaiY8eOt6IJ maGx161bt+0///nPuuQRaYyWqcu2bdvykeRwEThdrfFt3749N3OPASs3XO8arn/mW7ZYsWKx U6ZM+UL9wzRPYKxXLFu2LJ+/keTG6cpG2t7UqVNLs4fmjx49ejqMz28NGzZcwOElXhTzRjve 78W1mxmuxkRkhlW2ORoChoAhYAhkGgQwDckBcZZTpwhsiK06NWvWXCoAMC25FoKwGRLucW+/ /fYHSIDrId32CFTMUrqWLFlyJ+UHc91FmQ6q07p1664ksNsGkfYcxNMkCMJu8+fPLwBRmRNJ c2UIyCoQ2d+vWrUqL+YeXSCK5yOpHQ/RVVv1wxxZ3DglLWdslZEelyZ8rJe4Lky/uahXwrXL OHLBeBSHqIu79dZbZ8DAbB06dOhkMQxdunTppWzdMAsy8TqJtqCTq8fz8WzZsikvR8hD5lgy r4KxGcRcapQqVerQSy+9dDdS8CkTJkwYgolRFoj5+qq8ZcuW0sIjNjY2H6ZjDSCKjyC5Hlqi RIlYcGzpOgjVJ2Y71fAXyOHKQIxn1Vjd84EDB3LCHMRIC4D0PxvMXOAbWqZcmzdv9rBAK7F8 xowZn8NYrHZ1dU1Je8eOHRNDkMXlDDl06FA2+s4OY1cCxqlY6dKlt7g+yHoeR+6QfOwFj4hf uXLl5WgIFmuPrF27tizMxieYU01hnOXAbgOM6AFw8rgGZUzXmGFGXXPeNVz/ML4bWM93XQUY xQpoJXZgDnXIvdM1uXG6spG29+abb85D+/CZGBwx0uPHj2/CXl+odqSx6dq1a09weRxNWtVz Mclz40oPV3NySQ+rZGM0BAwBQ8AQMAQiRODJJ598jDNQGr+IfRBx0/UCaWn95s2bz8RcZoWe J06cOB0b9epImDdDCJddtGjRsOjo6BMQZt9CFB2FWC6GyUk5iKd3kOgnINVe+MknnzREulzp xhtv3HLixIns33777fsQrodEPOEDsQnp9VS1DWMwbeTIkR4BLcdaiGGPUG7VqtU2fYfZKQyz MlT37sDOf0779u230maS/aIl2eXK+6/Kjg2Buh8i+xhM034I1rpI5eOYyzSVe//9979CgzFY jAuMxjGZ2vjru3v5D5DhuyES8vIQufOYzxvKocF4s5KxuwDMVPGHH354LWMcBdMT0CC4+uC9 n/lOgrCUidHnaBUGSkoPY3A6qT5dXV0xkVkE49Pyqaeeqobkeyfjl09EVpiU7NIq8dwIvONh kgrCuF0Ng7fOXz/4PiXtValS5aDWEv+LFjBBP0E0X6+1xlE+F9qEaOaY4PqpU6fOXu5Po7HJ xfWgGB3NFU1ANfD29hkE92Xly5dfJaZk7ty5FWAYf3D1Q13D9a99qFP15P+B+dbdaD0+CW4n uXG68pG258qzNyqi/bibNckB4+KZsLHM37E+0zDvqspvrBFjag0DOovs7z8FMzeunYxwNU1E RlhFm4MhYAgYAoaAIfAHAmT+HQqx20vntGnTnsOB+VSPHj2a6fPu3buLffnll80h5l7WiWnG bRD3BRYvXhxdqFCh3WIgVE5mUEh7J2Eig5C3yE5HtOkbpiTQi3GeJJk68WIg9B6J8xVXXnnl et3ruOWWWzZ6N/wDQX8/ZjFP64SQ9uriE7HHjZNxSYL7HuYhtWWuBDMTtl/Xrq5IrUPSMpi4 FEXiXdLNtUaNGv3I9J0F5iaR2Yu/rTZt2jRlHI9gHrUGIr0/WoXPXBI+xnsKgno0uDQGpyFo StogcT4j+hQDjxMDoUPMiqTUaCUSmU1B9NYBx2d1gkE+/Bse1700H/R9AOn4VxCrt1Huwdq1 ay+h731q6+WXX54Lo7Tr0Ucffejdd9+9CWbjZ2mP/HMIvk9pe/T1GUxKOTRUvdGEFEQTswHi Phb/iGMwEwEMd+3alYM5nsR0yUtkyH7ztDswcIdVTgwUmFVHoxOLNL8CWqNiaIxig8cZ/JxU /yonhkqO2B9++OEttDmCc35w/eTG6S8fSXuuPEzmAtasD3tlAtqfrs7pncAAJ2Cc5sF0v4Ep 34h58+ZdA14vav6ubka7hvzhZbRJ2nwMAUPAEDAEDIHMggDRmU5J4qsT2/x4zh8xJfEiB2HL noD9/qcQv8/oRCrfF0ZjBHbqOyGMCmCW4hE8krpDqNak7nbuC/kJIYjAGMw4NgTjieQ6DqK9 sHsPERVw7oXQHAwB30unTFhcGTdOMS843y6EedmKA27J5PoVM+DawCH3Ep7dY+CKSVECPggr 3Vx1xW+hPxoUj9gNFPTdtGvXbgnE6UIk5zdBJN4uDYr7rHC1aEk2QFAPRMPyOsxLDr+pkisH hpLIewfMUH5wLUib+907XWGmVvbr12+MTjQnWpOvdI9p2WyZhcF0LVU/ELcDYCJ+g8HwGAUx YDCBn7ImfdGCvMYYcqLpCMtEpKQ9sMrKXjkJQTwUU6a+s2fPHsUaxjRp0mQHTEs89wE/D5jH IqxfrNZSc8OvZh3mTNegSVnMYxZ8Rx7A7Gsq61QKBrc5ZnRjVC7cEa5/fUP70ZX1PYi2aLB8 L0K1ldw4XZ1I20Mr0wSH9lqqJyYRs75fWeu8zi9G78WM9OzZsybzbY8fUiG0bhOkldG3jHgY E5ERV9XmZAgYAoaAIWAI/IEABOhBR9hiCrQK86XrFLNfJ34EHTF3aUIkoD1IUndj5lRN1Xr3 7l0HW/VrIdb2/fHeM1pXzH+0BjE4+wY0Dg5oQl4uXb16dUWF8BRhBrF71lGWIAwPQCDnCtcv 0t14CLRoOSyLucHZONAPBNspEfcaE2ZbqyHwLnfhbWX6wrvHnJaA5+tk3+7GryuMww60Mv9h ni8hST+E4+6jmAv1kmmRiHEI+j5ygobZ2NaiRYsFENh5/fV1D4F9KX4nnp8CPhS10EzsqOUm hnUAACAASURBVFix4mF9c30itd8L7ut0wvSdRKuxXvfSeuB/URyNxNNy6NaJxqFR48aNPUk7 0Y0aUvZOtUW5IphWXYPZ2TI9J3WkpD3GdJq594Sxq6h2IdTrognZAlN2hP6WysRNTtY7d+7M QcSiZpgqBfYDTMJEzN1uxt+mBKZLo/CR+Beala34R/yfoimxHsk6IIfrH5O6K8GlGGZ1X4jp 1Rh0SiOg4ADsYc/RPNw4/eUibQ9mLQ6msj5O7oXVl9aWdyuFidaCNbsdxmXQ5MmTa8IETmaM A8eOHeuZ9iW1Nun9vflEpPcVtPEbAoaAIWAIGAJhEEC6fwgiq6Scl7HVngyx8xAOoC9ACGXB 8XcLBJ8nGYZQ/JqIP13wHWgpvwLs4EeqWTlTY8LRGel7c0yfCkFoT5T/QXCXMlFBCr2GcJ/9 ZX5TqVKlsMRtcH09U+/wwoULK3A7M6l+pV2BaF3dtGnT/jLBInLUWgh7jxnAhGoT9uol8Ino gBPwKDQKMyj/vHwjJLWH4P3Q9UukpS6YYr3mzLHce13xRTiACc5EmKHJ2LlXwS+iAbb+WZnT UvobjGnORpidfDiQj/PX0z3Y7AbL+9EuZMWPIAfO5v9xZcL16crgb7EBQnw9/gSP00cBIjyt xzzmZ32H0fiJ750U9QmN0KUQyuPRrMgnIckjpe0heZ/02muvtWHMx8AhD1gOUydoI3ajkfkC Kfvf2CdH5QMCUf6mG4D8GfC1eQdGqz176BR7bQc4ZJUZk6I6sd8muLJJXSW9T6p/+ioHI3sp zN1r/vowr8/DoJSkz3ZgvijcOGGASrtykbYHY72ccLpyph6g/c3e28P6f6UxsFc7sfc34huh UL9x/nFl5PuAOjAjTzIDzE2qMFurDLCQNoWzQsD2/VnBZYUzCAIR7XvMd2RWUTMlc5YUVdoC 1Q0meGSyg+Q4v9/kSOXkjIxmoigEVBxmS8f0LqlDGgK0F8dli59UmUjfh+tXyciQAh+CoPPM aFybEN5ZYXayy4dA7xT6E+1CYZicHaGYH1cvuauk3tjZn9b80ITkUEja4DpKdPfxxx83QiMz jOhO0SJkneYjuGxyz9J8YAqVLRSOaF+KwChJS+T5sCTXlr6npD1plFj36OB9ovbQRuTSXoGZ 263nUIfMe2AoiuPHkQAzlyQWmABh6TS8Z3Ab4foPLpvUcyTjTKpu8Hv9dlj/ImjMTvh/I25v BJdPx8+/4tsyN7nxG2GaHEJp43tE/6mkjaHaKAyBVEPA9n2qQWkNpSMEItr358JEpCMs0t1Q HROBZuQf6W7wF3HASTERF3FImb3riJgIM2fK7NvE5m8IGAKGgCFgCBgCqYIA0umdmNrMSZXG rBFDII0jYExEGl8gG54hYAgYAoaAIWAIpA8EWrZsGaszfYzWRmkInBsCFp3p3PCz2oaAIWAI GAKGgCGQBALysUjik73OoAhozRUaV1Gx/KGBM+h0M/W0jInI1MtvkzcEDAFDwBDISAgQLWcI 4THfILrN6zqJnDOYaEIPuTCnF3KuOBZfghP2gFB9Ej3nKhw3h7lx6oqT8PNKtiZn2lB1Inmn sKPyS4ik7LmUIcpVWUK39j+XNvx1RWwTjagxIUN7krW7k7Jmu+9yICepXDtFZMI5uRVRpwq6 b+5KSNx2ZEoOhE5NaXvqV0nc2DM97rnnHmXKdl1EkWX6WiJGdeW8j0RwVwY+/HFDJu2SRLp6 EOf7e8GnJtGMbsWhuh8Rs26Rg3Vw+Yz+zH4eQDSnwJpkxPmm+IeaEcGwORkChoAhYAgYAukd AUKcvgUR+VedZF1+PiEhIfeDDz54d1qbF1GV9rpx6kqm6neIfNOAjNGBvA9nO2aiFpWCmK13 tvXOtjzhS38jC7UX8vRs64YqT5K5WrNmzbqOZGaTyV69iEzInR0B2rZt245EeDpNjoXxRIc6 gbnUQ47RIvxsJRiI9iTou5Ewvnlc2ylpTyGAybHwADlDlpBEbxL5ECoTgaq52lSmaUK9toeZ WU5Y2R9hAjsQhras649cC1cMGjToFkLhjiby1yjqLWMtxnD/FlnMd8JHtHZl7ZpxEDAmIuOs pc3EEDAEDAFDwBBIhAA5Io43aNBgASFJA9JrEsXdwPt+OkkC1sBVUAIuYt0/Qiz/V0lK181J tiX5ljZDWg4ky32Ir+9JycmjULxq1aqdSUrWoEyZMo+pnQEDBlQitOrTnE+R28BLUOfaT+6q kKnkX9hEPgFvrEn1C7NRShJx196///3v0oRB7azxcN8Sxqks0vC79F3Sccb2OCE5B5H7oSPf crt6hIftoTru2X+VFkXJw2BussAwNCJh37PkBRiorMUqB4FcrEePHnfongRxN5Nor57agzF6 CbxbOyL/H//4R3n6vVfl3CFtCXU84ty9o70aMAvTyHS8hlwdi5DorwD/KkqGt3HjxvIQ5+PJ cv0bSey+QapfVG2oLqFrS8JYHEWTk+Da0jUl7cEIVEMTsmbEiBFzlAWafTIFRqKG2vvggw/q wwhMIcfDLyTMWwv+i1mHOvqmucJk3A6Wo5Qkjj3RmyzWpcDtFkLD9iLXxHyya5dQckOVhxkp D1YPk+H672Sz7uoyPif1XntL2dO198j38Ry5GULuK4UDxrH9Hq21EgS+9957ZdTfXXfd1URr r3sd7JVO5M6orXsYn6vVPqF/B2kPKRyw3jP2xqqn8UmjQG6UvyhRIP33ZxzPaM+pXLi113d3 hNuHroyuyvQtDZfmwB5uo2SDei/Nj/agfoPSFEk7pfeRjFN7+c4772wanFhR9c/1MCbiXBG0 +oaAIWAIGAKGQBpCgDwJOURQ6RSxM2XKlDrkFFiqIcokBUK0GZLmcUiSPyCrcD2k1h6hCNHU lYy7Oyk/mOsuynRQHTIkd4Uo2waB9ZwSwD3zzDPd5s+fXwBiNufy5csrk925Srdu3b5XHgIk 1F0gfuZD6I0ni69HqKmNJI4sbpySgjO2yhCbpSF4Vqp8mH5zUc/LCK1yjCMXjEdxsm/HkQti BgzM1qFDh04Ww9ClS5deSM8XQ+DKxOskRG0n1dHB8/Fs2bIppG7gkDmPGCi0AX3BMa+IdeZx PVqH4RCcI8l50FDviMCUe8uWLaVUkTwEMRCJt6FF+B7Cehg4XQUO1+gbRPUp+kmUywGiuQAJ 9a7Wd3eQyC4bBOJJ94z2KNfmzZtLkCBPofizQHB7dkVkyM5G2ewwWN788T34jjwOn/Pdy4jt 6qekPRimrMLItUGujZx79uyJEZNAFu6iNWrU2OK+lSpVKg7Nh8fIgElM8eLFd5IA8AgM0HXs tSUfffTRTNZhL/tmo/JkYFZ3iIzVHoFOpue7yeg8ZcKECUOU8BDGqb7aTeo9OJcF8zokO3yP ffY1DMs9oXxtYHLaM+Z89D2cPfQTYWMf0Z6Esf2FNamkTNbs6evWr19fDk3PAplqweS1Yo9M RQv0isbw5JNPNtKV/VWYPdOcHBiLWNfPx40bdztn/SFDhoyEAVrH+t6qcuHWXt91JLcPfy8V FSVin2SIXelvvObAOMvAzDVUlnjm0BWcxsE8DIDhOQgz6zFFkYyTdThK3pLSJAEcCJPVwWm4 XL/ncs10NmrnApbVNQQMAUPAEDAE0joCEEKPcQaGCQG3D+J4ul4g3a7fvHnzmRBUK/QMATgd k5PqEGmbRawtWrRoWHR09AmI4m8xWzkKoVcMQqkcRNY7SGwTkFYv/OSTTxoika5EpuQtZCLO /u23376vrM+YIVXFB2ITUvOpahvGYBqEX0vdy9EWAs+TqpLpeJveQaQXhlkZqnt34A8wh2zI W2kzyX4h8ne58v6rEskhJd4PMX4MQnY/hGpdZapmLtNUjkzcXyFBHwzhlRPC6hgM0Ht6DzGc AzxqQTQ2IP9GVjJuzwKPj/FBSECKfgWEewEI//wwW+sgpF9njglg4hHEqq+jdu3acySh1z0m Wd+hCbgGpmOJskXr1Ptwh7RFjLMROMZDdBaE+L0aAnydsj8LU4jGFhDAP6EFul6YQ0TnSu32 yIa9CIar5VNPPVUNyf1OxiOfiKzyZ4CZiEYSnuD6JAv1HpgXbwwQtsXIfB6vbxDC1ZCmf677 pUuXlmFey0Wsy6ROydmUCJAEegUg6ouDy1rWeRSMY26I5pah3qsdHRDQ3yjhnU7WqRbakgow qqt+/+rttTzs3etg+AbgNxIvrRYZtm8ggd01w4YN+xVGYTxmfq2VdRxm9WOYnuNad/xnxmhd xZSA8y6S513m2gT7hTCj8/WMluQA+3YWTMwmZd/u06dPgBlNau1dOzAG1cPtQ1cO5qgWmsBV L7zwgsfwg/lYtAfR7MFa4L2BPj3mGub/G34nLzutWnLjrFix4mHW4n1p9tiTN8CYPIQgYDea rxn0tcgxqG4cZ3M1TcTZoGVlDQFDwBAwBAyBNI4AhNNQCLJeOqdNm/YcDsynML1ppmEjQS/2 5ZdfNodweFnn6NGjb4O4L4BZTDTmOrvFQKiczKAg1iYtWbIE64oiO8VA6L0OiEmsLOI8cwrq xIuB0HtMWK7A/n297nUgGd7o3fAPBP39mOM8rRPi3auL6c8eN07G9ThMyHsLFiyoLXMlCMKw /bp2dUVaH5KWwQyoaGxsbEk3VxiAfjAJWWBuEjEAEGG9P//8879ApI1lXi9C0M4QA6G2YcZW 43MwByK0t8xakLRfD+NzVN/8B/gEwrpCtO2G6Sjv/657GJguMkmBcL0XRqaU7nXKnwBzlbkw QLsw23no3XffvQli/mf68TJi8+0zmIpyaIp6Q1gWRAuwgTEH+gvuR88paU+ZsTFv+wozoNug Mx+EOF7CGu0TwwVjdhxiP4AbzEAuxu4xc0jm94JbIfWbN2/ew9u2bcuPGVRhYYDpzS60As0q Vaq0Rt9p7xTM0Gj2VmP22hC0TW3QdKAQyhYV6r3q6IBhDcwXnOJhasv9/uX3f9l7RbW27Lmn 3HrDFF8Go+DtNZlo8T0KYj4eAtojxhn/ccZZmo3WH6wHzZs3r5K/TfrZ657RppyAMd2hZ2mX OAJC+OTWPtJ9CG7RrK3Xh/phz20W0877IuypTXqnQ+vEGI6yJ/LrOdJxirEG94ms1XPspRkw V23ZZ/eqjZQeIX94KW3M6hkChoAhYAgYAobAxUVARA6ElHdKKsv5I6YxJTUq/B0Sunfv/imE 2zM6IWb7wmiMuOGGG3ZKEnz06FGZz0hLkFV26NTdzn0h+QbovQ5Mh2IwWTpDuo4kNw6ivfDv paKiIMqKuXvMYQZDxPXSKYm0e+/GKebllVdeWQjzshUn4ZLJ9SuC0bWB2cclIhCDD+zKEyBw V7q56orfR38I0j3+shDOU8DlMCYq7RSRCOI34KBM5uncaG++YV59kIZ/CvFaC1OYyv76ukdb EfC1wNSrJMTy/uAySPi/79ev3xjs6KfBkOzSvU4cpbeKsYK5+xSs+0KsvwZjlBP/hJ2MOStj O4nmYyh99J09e/YosIxp0qRJgNgM7kfPKWkPojQvzN5SGJWBaB8GwET8BqHtMTJiFsE52vXF fopGU+KNAan/Ngj2kpKMox2YhP9EI+baFJxGwTC1hUEsCLP6vepK4o+maYP6QEv1OvPMAfPQ Eg1BVKj3rj/2aQBf7WUI50T4ogk5AqF/ijE+79YbDJ6FUJ6lNli76jDT0jqVRCPhMSB8K4+Z WlPWd4Rwh6GZrjLukDO7uw93TW7tI92HWm9h5fqSNk4+NWgndvh/V/JdwuzsGD47cSob6ThV du7cuYWY5834K7WGOdzKfp+t9yk9jIlIKXJWzxAwBAwBQ8AQSAcIQAgehDnwTE8wBVqF+dJ1 cnLViR9BR8xYmhCRZw+E7W7MeqppSoTnrIO5yrVI4ff98d5zZpV9NoRODE63AY2DgwDn4qXY Xlek/aIifiGKzzrKEgTXAQi6XOH6RQofj6N4NGZD0WJuMB0K9ANxdUqEqcaE2dZqGILLXXhb zI1q8O4xiC5vyHKUlbMppl4LIFKHwMSMxJylNNJz2Y63h8gtBWNRHT+LtpiEnYQgXo6keBOS 3Lxuzu4KcV9Fc4YByEl/VdHOrNM39S0/FN3jgL4FrNchEd4K85Sge53S5GBW0hDi7k6VwySn COY+12BOtgyG8DT1ejK2ivqGhqAuxN8WmKMjek7qSEl79FscwvRp5pdDJxqRRo0bN56vPuRX Mnny5DrCW8Qtkv9aMJ7eHpAZWceOHadgBtaRd3H4PrzN97HsoTUwF0PQQvyGKY3HXMIM5YY5 6SPmDKfgbS1atFgAEZ6XNZNJ2Bnv3fwIGVtd9xD9MUjmy+Cz4jGxMAfV0Frlh+ncDeO2lzXy /Hu0T5HY92MvFpe/DfXbMJ5PYXgmwtx4PhVo30qIkKatOK2d9lEoZtSNIalrUmvvyofbh2II 5Kuhsqyz9/uRb4SYefZGG/ArgPZuCfvySr1XOeZyLYEOVrp9rHfJHTLLY1/fz++8L78d+Y0M Yw2Gof1bnVzdcN8D6phwheybIWAIGAKGgCFgCKRPBJDuH5IE9g9iajKE4kPYWL+ASUYWJLhb 8G8Yo5lBoH6NuU4XfAdayq8A+/uRei9nagjtzhDVzTF9KkSkmokiHPXNf0BsxyI1XQMx2V9m MBCPy/zfI7mn3mGcjitQdmZS/UIwxuPEuxqn1/4ywYKgWgtB5JnaYM6yCUlzCQj1DhCuo7CL n0H552WTLuk+9ukfunFg594FAv41Z44le3fOkZhw5YfQrItj7gNIbl+GoWkGhgM1J4j6k9j8 z4dBShT/XxGSwPI5JOo5Ydq249DuSd4pdxlS3ztxGl7i+g11hWD8CR+BTphR9ULTcykMxHg0 Jp45Df4QkyAC2zDeYxC7eZjTsFBt+N+lpD35bmBvvx6zq8dh5AowlvWM/We1i4nTdPwkKoLj IAjcvGiiZvl9EnA4/h8mQQfZW92Zfxz7K5Y9VxitSRGYg+V169b1tD8QsofYF0tZs8FE4tpI P/loZxwmP1eHeu/mBFNVgXZroMm4hP31nRgQfcOPoDOM3XAYy7WEu/0Yhu1+/G8aqxx74Tsx bnImVtQvnJOXgt9yxlYLCXwz9vd0zNgas25Pwxzlwn/jFwINNHZMn+s7uWtSa+/qofnbmNQ+ xPemNONoB7O6SL8fokEtBcPn5McEntvwYVhE+6cxE1yF9ul5xvobmBWEkfiXaz+5K4EUSsCE 3qWgAzBVH6ExPJZcnUi//3+9TaQ1rNzFQEAqNVuri4G89XkxEbB9fzHRt74vFgIR7XskprUY YM2UDFKOrtIWqK4cVf1tyNwEqWd+v8mRviOpz4lmoijEY1xyRIg0BGgvjst22992Su7D9asw l0jkD0Hcn/K3DZGVFWYnu2z59R4CNB9S58IQUTtCMT/+uv57SYNFwAkTpPAxMEgHQ82Jd50h YtfJDwFJe55g7PxtJnePNLwIDJC0P55viisvSTn4Rwevl/ue1DUl7cmsCdO2bKHmKs0KuMpM LElNiOrja1AUxiFOTr2hxqY9gkQ8hxyg9R2GDVee4T2D3+sb/hJvsn7PorHIDsNwxK2rvgUf cgKHEYiBGN8nhiX4e6hn/RbY1/EyrZNJFtqwE843KFR5/7uzWftI96Hwg4k/5fxyXH9yjEbT lQcmKlb70r1P7ur2cXLlgr7/imnX3KB3ZzwaYXoGJGnyRUT/qaTJkdugDIGUI2D7PuXYWc30 i0BE+/5cmIj0C03aHLkjJHEI/zFtjjDtj8oxEaFG6piISJmCUG2cr3cZeO0jYiLMnOl87Sxr 1xAwBAwBQ8AQMAQyPALYvC9E4p7IWTvDT/oCThAN0iTMyVLNBCc1h57Z1940Eam5m85fWxFJ ps5f99ayIXBRELB9f1Fgt04vMgIR7XvTRFzkVbLuUxWBcJqIVO3IGosUgYg0ERadKVI4rZwh YAgYAoaAIZBOEFB0nbFjx14qO+x0MuRMN0yFkiUxX0nZwGe6yduEMwQCxkRkiGW0SRgChoAh YAgYAlFRCp1JdJ37iEbzInkeOnH/Ik6wD8sJOaX4yBGbKDcN5LCckjbOtX64PolSU1bJwsKV Cf5GSM/bOFvqPU60L4qQDy5zrs8KJ6ucE6HaIQpSba0JeRHuxI+iGuY69xF1529JRQUiOlQ7 chkkigalsqxtV601Dt1XhupH74gMVAdTq+4qS53Kbg3lgEwSuKYaB2FZ71Ko0VBtKK+A+ieH waM49LYgWVlxV47IQjGEDG1DGz1IXtbEn0vElfFfQ83DjQ/H9Sg3PoWQla9B8KkM5P727P7i I5CiPwgXf9g2AkPAEDAEDAFDwBAIRoCwp12VMIv48v0IFfoKMfWfVk4CchB0Di4b6bOIw48/ /vguoumkyI/yXOuHGyehPn8jd0CyIU+TagNC+HUiHnkRgpIqczbvCRlagohDzZWXgEg/gWR7 rg2iAN0FAZ+HRGgjSCQ2gUR3Cwkp+86YMWP+RVShKn6GgJCllSC825N870bCpQYS4BHWtALh XtuTu2E5oWB/JDxoB0KzlnV9uKsSrMF83EKuh4WErp1B3odbe/Xqdb2+k+DuDhiEazEjmkzE ozgYhMccg+Hq60pivO5cspB/4UscnE9C9Hv7SPkwyF/QnZC2WRjn18yhAm3c7q/r7pOah398 RFOKcuMjKtFhwpwu9p8kkStH2NM06Rfh5pkZr8ZEZMZVtzkbAoaAIWAIZDgElByNePuXkx14 LI6oxzXB4sWLHydnwdjq1auvEjGvE6K5BWFRX+J8ESKxuTQFOiSVljSYEJpPk39hINqH+npP +NIHdaWNJyBmc0g6LQm46iOhfuTVV1+9Qt91kEPhGmkGkPAPgmBuI7Oq4PrKwkvOgXt/rxH+ XyXYgpi8XeOGYWhEroBnNTZyJzRRTUKYFuvRo8cdumcuN5Pwrp4k45ofcf9bKzSqviXVJ0Sx pPCXQMSXrFGjRkdyYDSl/QHKHeCX/pNc7wYw7acTwr+B2gx1QExHk405H/kU4oO/S2tC6Nm8 rM908nFcxRy6El60PPkgOkCkN+H7VyQBu9HVI6xpSeUgIIFegnunKxmh65MDYQr5PX5B47GW tViMRqOOv4zuya59JcncfhgxYsQcmId1OAH/TAjV6gr5SQjWesz5AyW74/pDQkJCHkKsBtZR 9aXVomwe2hnTpUuXzeQamMn6/1nmV+B5NZm0jyipnHIxkGNkKgnertc6qa7/SGoe/vGRE0HJ Ab3xKW+H8k64E+YmJ0kSV8A8zROD5l8Xfz92f+ERMCbiwmNuPRoChoAhYAgYAqmOABLrSyFe dwWHwoRgP0DCqe8hRk8jua5Hht+rkHoPgRj7B0RgzUceeaS2BoPmoiQMRzOk3B9DrE1F+9BG TAPJ2z7Td96PhIg/3q9fv/rE0d8PEfgKpjhzIS7vFiMigp9kbl1pbzzE8HCkx2UgLhsG1ydh 2ynGkigPgtr3HyS3uxzCsRtmR30hIvPKdIaMytejdRhOAq6REydObKh3ZM/OjdallOqSoyEG gvg2+v8eonoY/iBXIaW/Rt+S6pO6pdEM5OTMtWDBgpqxsbGFIPLfZn7xJCdroboyHQK/Zk88 8cQ4JP4fgF09iHIvM7K++w+S1C0nn8PnEMKr/e91P2HChKvQACzQPcnbmkK0j/7www9nwmgV gVFaDvNzmFwI+fVdB0nTvlNbaJIS5VoggVtRGJ4tv5eKipImgXWKcc/uSvvfgONP7pkkfuXZ G+sg9qPB/6hLZqfvMH67yN6dqA3lKYAhGnjixIks7IvSaB5akahtrXI/4M9RjPvAGMiNEQfD kQ8Nyxk+OEnNI6nxufHqKjMr9mELkt5N0DNZmrWHe9L342RbruqYRH2z48IjYEzEhcfcejQE DAFDwBAwBFIdAZKi5ZF0OFzD2J7Xvf3222eJgISgjUWiPRNpfoAghjiegIR8m4hbzEf2T5s2 LYaynlRdieYg4qKov2zUqFET0DAcwNxmW3x8fAnMW3IhKa5FQrZVL7zwwlIlEYOhGIumYldw fWVGhjj8b/A4xbBI4g+j0heznrYwP2uQevdX2bVr1xaCwC4A8ZpfUnXm8ToZjvcHt0F25DmS zqNR2NG2bdvvmJvHRCTVp78+Cb6OUH4cjFEsZj5TYSg8+3+YrfpIyWf27dt3hbBB4zEdDUJ1 5p0dZunPOsXQ+NsKdQ9GRTHb2T1//vwCmIYVpp2d0gow7xIwW2vIFF4WP4AVoer630HYR4NR QDsBQb2HbNy5/GV0r6R3SswmXDF9aod51WV9+vT5GWYiGg1Hon0C87kXfHMGt6HnzZs35+7d u3cXmKw6rO8maRswk4tmfwTGwD5Qdu3TMERnjCNUm3rnHx8MaJQbn7882az/gs/GHHA7qPeY i31HAsL+7K8fWZdGaNoG4tvRzAII+FG7cPcpsm+8cMOzngwBQ8AQMAQMAUMgEgQg8OIgrErJ adaf8Vi27hDe17/22mtzIF6LIN3f6NpTHQjngPSbZxGD3iFpNYxJDvfsrhCRWWEoukNI/hki brt7L8ISqfgO9ywTGO43i1B278JdYUp6y3wGTcdo7OXX+Ms++eSTq3G4nUObvdE0HMShd864 ceMm+cvovkyZMrHuHRLz3ThNN3XPyV0xgTrgMgGjiTiKBN6bO9qOYl9++WUZNAJ/URtoXbJh 1rQTwrco0vmn9Y55b4DYfkP3SR0Q/ntXr15dCKI4Dl+C7Fon/AWqkkV7L3XzoLFpBiPmaX2S akPvYXaOw5AEJP6sby7a3hWqDhqUEjBmPRjfZjIe/11aBAjuwkjwA/VVD9xzli9fPi5UG6rD WAcqszN+D/3QSK0Ap2PsjUAbaEdywGCeJEv1WeXLcONj/FFufG4MaJZywUDWRgM12L3TVXsb c6p5OmWGhkaiLXvnZub0hLRt/rJ2f34RME3E+cXXWjcEDAFDwBAwBM4HAmcQS0j8eIqKdQAA IABJREFUd0Cc5sD0JJGTLczD1Zj/1IUwPhETE7Md6X5hNyBMWIpDPG5wz5j9nNGu+6arGAKI /PsgJudg39+HqE/D3Xe0DjshuAu6Z0XZkS+Ce07uiq/BFDQphzFBaqfIRgqB6urIPh8G6Ru0 A31gMD7FlKoWpkOV3Xd3RZqe290j8S8JY3CGtsJ9D77ikB5y7owpAd+JTyFSn9GJJLwvGpoR SMB3kK+jl87kGAj1hdZn+fjx42v86U9/OkY0o0n4mPSAIcsG4f0/tDvd0Uz8Iu1E8LiCn/HZ iMdULNq9p+/oyy67LMC8ufeYXRXFofohxj5+6dKl74sZ0De0HXvoN7c/tCxalSIwNwGGUOUw CSslPxHd64D5jCPq1wYYoSL4MMTDOATGgFlcEfZXLIzW7w42v1cJ+69/fPjpRLnxuUr411yH b8pWac3cO3cVA4a2qCZ7oT2McaFWrVpNMAbCoZMq15C/heCWjYkIRsSeDQFDwBAwBAyBtI+A RxD6h9mkSZPdNWvWnD106NAWOPh62gUcaAtje34Hpks/qizflyKdryVTHPkx4EdRqWHDhiv9 7QTfy4SJ4xSmKjkxK8orKTaajaUi2pAC13LlcbBdCoFZUb4RYjZw2m2Dz0EBf32VnTlz5iXy M3D13BX7/QUQ6EPwsRi5cuXK0tjvD8Tkpb0cxmEsqmNm1BYTmpM4IS9Hsr6J8ZyRX2H27NlV GF9WRQ+in6r4JqwL16frO9wV34xVSOGvE2Y6wasjc/Mcu8PVC/4mMyu0G9nkmI1PxE8wAsPk 9IzPwGSYouH4pAQYsOC6/mdMkxZjzlVHZkVi1CDga8EArFcZOW/Lf0H3MHs3gd98CO1lMmnS qfH/YUa0CRy9SE18r3b48OH8RPbytBl6xm8mPwzNdvZRZUWDUnvqi/UphWnTYvwSlqIpKCcz LrWL6VozmFFvDPJjwPSriuqEO/zjYy5RbnyuDg78V7Jfl7lnXdFKyH/kdpiYQWBQk7Cvk9kH A8mJMtVfzu7PGYEz/r6EatHMmUKhYu8MAUPAEDAEDIG0jcAZkmcNF/v8L5DK3kPEnsFESNqH ZL4gUYp+gLGYo++YBc2FOOyJ2c8AzGKOyqEWojCsHb6YBcycVkCoPrNmzRoR9nMg7vrI4Zf3 67G734RkvRXE4xhs15dC5D0Hsb8PQm8bTtCLgutjGnQZjrJ3vvTSS0s0puAD6fkmzpFihNA2 1EXi/AAE5cvY3TfDjGgg2oV9aExOIqmeT1uJ8icomhHS6+fQyOTERGY7BPX3aj+5PoPH4H+G MJ/MnB7C9+AFGK8stL+FyEhj/GUivZ83b96HhNttDm6PItXfjvR+vxzCWad85PXwxppcWzAg 0/EXqYgfwyCYtbyYls3Cd2CV6jGu+nnz5j0iUzK0N2XRxhRnvM1dm5ifbYZZeRXG8iOYvl5o NeoRmSkf6/Su0yLANHSGSRsupgdfkKnsj8dwMpepUxa0L98qepJO8lxor/1N+0j+M6z/m+oH xqL0G2+80Q7Gb5HrN9Q1eHzsiTfc+FQeTVQFTLFm+Oved999ncBuI74RCs0b0vzKX97uU4xA yL8vwa1FZKcYXMmeLzgCUivZWl1w2K3Di4yA7fuLvADW/UVBIOJ9jxlNK0YYMlGaTFWQJheG +I2VGZN/JtISIMWNgbhMkFTa/y3cvcyLkDZ7DrnYrxfENOoYzEiC2kOqnleEpeqrbwjLU4ru 42/PX9//Prl7tS9fBWzws2ncEJEHMck5EFxPycmwjV+HU/ZcCPM8ZzO34LaCn6W1kU+A3qcG 8ar2CLdaBPOs3JiG7fT7sAT3ndSzNDowcAlEdUrkJJ1U+eD3bh9IA+EYiOAyesbkLR9rml/O 8sHf5beA1khajN3B387mGUYRvmZ4z+TquL2QXDn7fk4IbMO0b3wkLRhhGglKF79MxP+pXPyh 2ggMgVRDwPZ9qkFpDaUjBCLe9zARhZhXO06zKgAEx0Rgy++ZbqWjNc/0Q42Uicj0QJ1/ACRw GAMTEZFwwf7wnP8FsR4MAUPAEDAEDIFUR0D/0cNITKPhxpyZ/v9zTG8W4px7VtGBUn1RrEFD IP0iIAZiWqQMhKaZ6f/opN+1tpEbAoaAIWAIZHYE+A9/DYyEwpqKkQhp2pRZMCILdFgb/MyC g83TEEgBAtuoc1YMhPowJiIFSFsVQ8AQMAQMAUMgrSDwh+RwPMxEEcZUglNRi8xcOa0skI0j WQTwsVEZ759kC1uB1EJAppOKwrSDvyHn5NOSWgOyds4PAlpoOwyBzIaA7fvMtuI2XyFg+972 QWZEwPZ9Olx1yxORDhfNhmwIGAKGgCFgCBgChoAhYAhcTASMibiY6FvfhoAhYAgYAoZA5Ajk pGjZyItbSUPAEDAEDIHMjoCp+TL7Dsic87d9nznXPbPPOtS+rw4o/+KU/fLRzA6QzT9DIhBq 32fIidqkDIELjYD9uC404tZfWkDA9n1aWAUbw4VGwO17OUk/ybmBU4nVjnPq215OOwyBjIaA 2/cZbV4Zej4WvSF9LK9+XLZW6WOtbJSph4Dt+9TD0lpKPwi4fa/rQc786WfoNlJD4JwQMDrn nOCzyoZAaAT0n4kdhkBmQ8D2fWZbcZuvEHD7XpqIv3Ku5zRNBCDYkaERcPs+Q0/SJmcIXAwE 7Md1MVC3Pi82ArbvL/YKWP8XA4FQ+14+Ef/kPMV57GIMyvo0BM4zAqH2/Xnu0po3BDIHAvbj yhzrbLNMjIDt+8R42FPmQCDcvs8BBJdlDhhslpkMgXD7PpNBYdM1BFIXAftxpS6e1lr6QMD2 ffpYJxtl6iJg+z518bTW0gcCtu/TxzolGqXliUgEhz0YAoaAIWAIGAKGgCFgCBgChkByCBgT kRxC9t0QMAQMAUPAEDAEDAFDwBAwBBIhYExEIjjswRAwBAwBQ8AQMAQMAUPAEDAEkkPAmIjk ELLvhoAhYAgYAoaAIWAIGAKGgCGQCAFjIhLBYQ+GgCFgCBgChoAhYAgYAoaAIZAcAsZEJIeQ fTcEDAFDwBAwBAwBQ8AQMAQMgUQIGBORCA57MAQMAUPAEDAEDAFDwBAwBAyB5BAwJiI5hOy7 IWAIGAKGgCFgCBgChoAhYAgkQsCYiERw2IMhYAgYAoaAIWAIGAKGgCFgCCSHgDERySFk3w0B Q8AQMAQMAUPAEDAEDAFDIBECxkQkgsMeDAFDwBAwBAwBQ8AQMAQMAUMgOQSyJ1fAvhsChoAh kN4QOH36dBHGXIIzL2eW9DZ+G2/mRaB27dpRc+bMqZV5EbgoMz9Nr4c5d2TJkmX3RRmBdWoI pEMEjIlIh4tmQzYEDIHQCMA8FOJLY86SoUvYW0MgbSNQs2ZNDdD7J22PNGOOjr8h25jZNJiJ fRlzhjYrQyD1EDBzptTD0loyBAyBi4gA//lfTvftOC8oAzF9+vRLdJ46deoizt66NgQMgVRC QH8/2v3x9ySVmrRmDIGMiYAxERlzXW1WhkCmQsCngQhoVz/66KM/V6tWrVO5cuV63nvvvQ2W LFmS34Hy7LPPXlu5cuWunPe9/PLLV7r3e/fuzX7nnXc2vfzyyx++4YYb7vrll1+k2Qh5dOvW rW6ePHn+fscddzzWqlWrR/PmzfvqXXfd1cQxE507d66vdvyV1WahQoUGTp06VeZWdhgChkDa REB/Rxr/8XclbY7QRmUIpAEEjIlIA4tgQzAEDIFzRkAmTAEGYsOGDbkfeOCBnkWKFNk/cODA L9asWVPytttu66Je3nzzzQpvvfVW++uvv355165dfxw8eHCHt99+u6y+tWzZ8o65c+de27Nn z8mlSpWKu/nmmx87ePDgGX8nqXfDJ598cgv13obxGLBnz54XPv7446GTJ09uCFNxk9oKPurV q9dm+fLlV06cOPGNJk2amN11MED2bAikLQQ8RiJtDclGYwikLQTO+M8xbQ3PRmMIGAKGQHgE kBZKqp/IhOm///1v2WLFisVOmTLlC7QQW/7v//5vwsaNG69YtmxZvg8++KD+LbfcMuWf//zn L48//vhatBGL//Of/9Q5evRolp9//rnemDFjPnjsscfWcf0hISEhz/Dhw68IHsFnn33W/J57 7pnQpUuXze5bmzZtdtSpU2cujETj48ePJ3LmbtCgQeuVK1dewXjerFu37l5Xx66GgCGQphEo +cfflzQ9SBucIXCxEDAm4mIhb/0aAoZAaiGgKEyJjg4dOmz46quv3nUvYQgqoJXYcc011xza tWtX0Ro1amxx36Rx2LlzZ8yPP/4YnSNHjqM33nhjgMinzq4VK1bEuLK6yizqwIED0Xffffca /3vdt27desmxY8fyzp8/v6D71rBhwztnzpzZEOblveuuu+6Ae29XQ8AQSBcInPH3JV2M2gZp CFwABIyJuAAgWxeGgCFwXhFQGNdER5kyZRLwh/AIdrQNNYYNG9a+Y8eOk1QI06NotBQJrkLp 0qX3QPjnWrhwYXSuXLmOuPe6XnLJJXsPHTqU0/9u3bp1+fSMr8Uh/3vdo4mI0zU+Pt6rs379 +itgOq4pUaLEb/37979Z3+wwBAyBdIXAGX9f0tXobbCGwHlEwJiI8wiuNW0IGAIXBIFEpkOu RzlJo3no9uGHH96CH8QIzvn6ljNnzuNbt271GAE94/OQC6ZiV/78+Y8fOXIk8F7fMHHKWb58 eY8x0LMOtAmepmLkyJHlfn/z//8dPXp0BZ5Ow0zs0VucrQ9+8803/+D4CGaiOozEtf+/tN0Z AoZAOkAg5N+XdDBuG6IhcN4RMCbivENsHRgChsCFRgBmICuEfNcCBQocxMl68EMPPbTBjYHo SPFoCKLd8+bNm6Mvu+yyHWgu9uDLkHvVqlUBySMahSJEVNruyuqK+dPR6OjoHdOmTbvK/173 +FRU4Pt6vp/QMxqIbYxjH1Gbtjdv3nzyG2+80Q4n7zz6ZochYAgYAoaAIZCeETAmIj2vno3d EDAEQiLw6quvXhkXF1eMCEpfyGEan4ccOhV+lahMi3F+riPn52+//bbYTz/9VAtGYX2tWrX2 XXrppZvQFlyvRv/6179WO3z4cP6mTZvuCu6kXbt23xH+tc7f//73QHhYhYol03CdHj16TAwu r2f8Mibnzp37MHXbhPpu7wwBQ8AQMAQMgfSEgEKY2WEIGAKGQIZCAAK/3O7duy9Fw/Caf2Lf fffd8++99950TJIq4u8wCAYjL6FXZ/3tb39bpXJEYvqIaE690FbUIzJTvkGDBr1LLogzssgR 7WkuDEZOGI4HBgwYcCJr1qyniOIS1bdv3/8888wzK/19uvuCBQuefPHFF0fDZPQm7OyC559/ fpn7ZldDwBAwBAwBQyC9IWC2fuljxU4zTFur9LFWNsrUQyCifQ/xXosua55tt0RMugTNQwIJ 4RI5U0tzgaYiRhqIUAyEvx+VxeehOGZTxylvuR/84Nh9ihAgRwm87PCeKapslc4HAr9myZJl 7vlo2NpMhEBEf+8T1bCHi46AaSIu+hLYAAwBQ+BiIFC/fn3P+Tm4byI0nSYx3c7g96GeVZYM 1ztCfbN3hoAhYAgYAoZARkbAfCIy8ura3AwBQ8AQMAQMAUPAEDAEDIHzgIAxEecBVGvSEDAE DAFDwBAwBAwBQ8AQyMgIGBORkVfX5mYIGAJpBoH9+/dnSzODsYFcFATIil74iy++KE7oYDMl vigrYJ0aAoZAaiJgTERqomltGQKGQJpBgKRyQ7Jnz/5Gjhw5XteZL1++wVdcccVDcqi+0IOc Pn36JX/6058GhOp38ODBV+G4OcyNU9fChQs//5e//OUO5bsIVSeSdzh8x1yM5HY4mb/46aef loxkjJGUef311y9X0kDWrsc999zTUGF6dShE7913392YzOE9q1ev3knlgttTtnLV8b9PSXv/ +9//ChAauF3ZsmV7NWrUqNWvv/5a0LUpnPGvaYODfg/ygTTRuNw3XTdt2pSbCGB3XX311d2e ffbZJiQevJ77v+qZaGFF/WV1T/LDKM3X/z5c/x999NGfyXHSSTgQWawBSQ3z++u6++TG6cpF 2p727bXXXtv1qquuerBz5871SeCYKLO7a8+uhoAhkHERSPF/UBkXEpuZIWAIZBQECMX6FkTd X3VCzD1P2NbcDz744N1pbX5ky97rxqnrf/7zn3d++OGHBk8//fR1KR3r999/X4rcFPVSWj+l 9SBWX7/pppsickxPrg8l5iNs7gMQ6UueeOKJSSTzq3zHHXc0V71evXrVmjVr1nWPPPLI5GbN mi0iZG7nUaNG/UnfPv/88xIq984777Rh3YvpnY6Utte2bduOhPE9TWje8TjTn2jZsuVDYvBE OHfq1Kn7yZMnszz33HNfQ8BXuPnmm2//vbeoKH1v0KDBgx06dJi3fPny9+6///65r7zyyjTy ibz1wgsvTHjggQc6rFu3zks++Ntvv+W67777bpw0aVIUyRDLuzZ0Tap/Einmpo2eRYoU2c/Y vmB+JQkK0MVfV/fJjdOVj7S9r7/+OoZwxZ1gItYTHnki61Dlsccea+DasashYAhkDgSMicgc 62yzNAQyPQJFixY9DkG3YN++fQEpMkTdDbzvpxNCL0AEkWeiUIUKFR4hOdyrkhj/97//9YhT SaClzZCWIyYmpg8ZqD3p91dffVW8atWqnSUJLlOmzGMCm/wRlQgh+zTnU//617+qns0CQADv /POf/7xpx44d3liT6hdmo1TlypW7urb//e9/l0Yq3Vnj4b4lBHRZScH1HYaiJGN7HE3BIPJk dJSE3NWTFF113HNSVxL45ejWrVvdYcOGlXvrrbfKU+9hwuD+XRJpRwx37979LvC7RGXAu7Uk 9+pTUnwYo0Cm8FB9aqwiZF3/JA2shoR9zYgRI+Yo6zjrNQVGooa+wyTVgLieRlLANST9W4RE fAXrVEXfIOaj9+zZk49cIPF6dkdK2luxYkW+jRs3lke7Mh6G4bfPPvvsm7179xaVZB+twtXs kSMkLBzL2m9hjFMxWboeRtDTRnTs2PFWNCEzNPa6deu2/ec//1mXPCKN0TJ12bZtWz6SHC4C p6s1vu3bt+dm7jFg5YbrXcP1z3zLFitWLHbKlClfqH+Y5gmM9Yply5bl8zeS3Dhd2Ujbmzp1 amn20PzRo0dPh/H5rWHDhgs4vMSLYt5ox/u9uHbtaggYAhkTAWMiMua62qwMAUMABDANyQFx llOnCGyIrTo1a9ZcKnAwLbkWgrAZEu5xb7/99gdIgOsh3fYIVMxSupYsWXIn5Qdz3UWZDqrT unXrriSw2waR9hzE0yQIwm7z588vAFGZE0lzZQjIKhDZ369atSov5h5dIIrnI6kdD9FVW/XD HFncOCUtZ2yVkR6XJnysl7guTL+5qFfCtcs4csF4FIeoi7v11ltnwMBsHTp06GQxDF26dOml bN0wCzLxOom2oJOrx/PxbNmyKU57yEPmWDKvgrEZxFxqlCpV6tBLL710N1LwKRMmTBiCiVEW iPn6qrxly5bSwiM2NjYfpmMNIIqPILkeWqJEiVhwbOk6CNUnZjvV8BfI4cpAjGfVWN3zgQMH csIcxEgLgPQ/G8xc4BtaplybN2/2sEArsXzGjBmfw1isdnV1TUl7x44dE0OQxeUMOXToUDb6 zg5jVwLGqVjp0qW3uD7Ieh5H7pB87AWPiF+5cuXlaAgWa4+sXbu2LMzGJ5hTTWGc5cBuA4zo AXDyuAZlTNeYYUZdc941XP8wvhtYz3ddBRjFCmgldmAOdci90zW5cbqykbb35ptvzkP78JkY HDHS48ePb8JeX6h2pLHp2rVrT3B5HE1a1XMxyXPjsqshYAikTQTMuSttrouNyhAwBFIBgSef fPIxzkBL+EXsg4ibrhdIS+s3b958JuYyK/Q8ceLE6dioV0fCvBlCuOyiRYuGRUdHn4Aw+xai 6CjEcjFMTspBPL2DRD8BqfbCTz75pCHS5Uo33njjlhMnTmT/9ttv34dwPSTiCR+ITUivp6pt GINpI0eO9AhoOdZCDHuEcqtWrbbpO8xOYZiVobp3B3b+c9q3b7+VNpPsFy3JLlfef1V2bAjU /RDZx2Ca9kOw1kUqH8dcpqnc+++//xUajMFiXGA0jsnUxl/f3ct/gAzfDZGQl4fIncd83lAO DcablYzdBWCmij/88MNrGeMomJ6ABsHVB+/9zHcShKVMjD5HqzBQUnoYg9NJ9enq6oqJzCIY n5ZPPfVUNSTfOxm/fCKywqRkl1aJ50bgHQ+TVBDG7WoYvHX++sH3KWmvSpUqB7WW+F+0gAn6 CaL5eq01jvK50CZEM8cE10+dOnX2cn8ajU0urgfF6GiuaAKqgbe3zyC4LytfvvwqMSVz586t AMP4g6sf6hquf+1Dnaon/w/Mt+5G6/FJcDvJjdOVj7Q9V569URHtx92sSQ4YF8+EjWX+jvWZ hnlXVX5jjRhTaxjQWWR//ymYuXHt2NUQMATSJwKmiUif62ajNgQMgQgQIPPvUIjdXjqnTZv2 HA7Mp3r06NFMVXfv3l3syy+/bA4x97JOTDNug7gvsHjx4uhChQrtFgOhcjKDQto7CRMZhLxF djqiTd8wJYFejPMkydSJFwOh90icr7jyyivX617HLbfcstG74R8I+vsxi3laJ4S0VxefiD1u nIxLEtz3MA+pLXMlmJmw/bp2dUVqHfJvOiYuRZF4l3RzrVGjRj8yfWeBuUlk9uJvq02bNk0Z xyOYR62BSO+PVuEzl4SP8Z6CoB4NLo3BaQiakjZInM+IPsXA48RA6BCzIik1WolEZlMQvXXA 8VmdYJAP/4bHdS/NB30fQDr+FcTqbZR7sHbt2kvoe5/aevnll+fCKO169NFHH3r33Xdvgtn4 Wdoj/xyC71PaHn19BpNSDg1VbzQhBdHEbIC4j8U/4hjMRADDXbt25WCOJzFd8hIZst887Q4M 3GGVEwMFZtXR6MQiza+A1qgYGqPY4HEGPyfVv8qJoZIj9ocffngLbY7gnB9cP7lx+stH0p4r D5O5gDXrw16ZgPanq3N6JzDACRineTDdb2DKN2LevHnXgNeLmr+ra1dDwBBI/wiE/A8n/U/L ZmAIGAKGQFQU0ZlOSeKrE9v8eM4fMSXxIgdhy56A/f6nEL/P6EQq3xdGYwR26jshjApgluIR PJK6Q6jWpO527gv5CSGIwBjMODYEY43kOg6ivbB7DxEVcO6F0BwMAd9Lp0xYXBk3TjEvON8u hHnZigNuyeT6FTPg2sAh9xKe3WPgiklRAj4IK91cdcVvoT8aFI/YDRT03bRr124JxOlCJOc3 QSTeLg2K+6xwtWhJNkBQD0TD8jrMSw6/qZIrB4aSyHsHzFB+cC1Im/vdO11hplb269dvjE40 J1qTr3SPadlsmYXBdC1VPxC3A2AifoPB8BgFMWAwgZ+yJn3RgrzGGHKi6QjLRKSkPbDKyl45 CUE8FFOmvrNnzx7FGsY0adJkB0xLPPcBPw+YxyKsX6zWUnPDr2Yd5kzXoElZzGMWfEcewOxr KutUCga3OWZ0Y1Qu3BGuf31D+9GV9T2ItmiwfC9CtZXcOF2dSNtDK9MEh/ZaqicmEbO+X1nr vM4vRu/FjPTs2bMm822PH1IhtG4TpJXRNzsMAUMgYyBgTETGWEebhSFgCESAAAToQUfYYgq0 CvOl6xSzXyd+BB0xd2lCJKA9SFJ3Y+ZUTU327t27Drbq10Ks7fvjvWe0rpj/aA1icPYNaBzc EAh5uXT16tUVFcJThBnE7llHWYIwPACBnCtcv0h34yHQouWwLOYGZ+NAPxBsp0Tca0yYba2G wLvchbeV6QvvHnNaAp6vk327G7+uMA470Mr8h3m+hCT9EI67j2Iu1EumRSLGIej7yAkaZmNb ixYtFkBg5/XX1z0E9qX4nXh+CvhQ1EIzsaNixYqH9c31idR+L7iv0wnTdxKtxnrdS+uB/0Vx NBJPy6FbJxqHRo0bN/Yk7UQ3akjZO9UW5YpgWnUNZmfL9JzUkZL2GNNp5t4Txq6i2oVQr4sm ZAtM2RH6WyoTNzlZ79y5MwcRi5phqhTYDzAJEzF3uxl/mxKYLo3CR+JfaFa24h/xf4qmxHok 64Acrn9M6q4El2KY1X0hpldj0CmNgIIDsIc9R/Nw4/SXi7Q9mLU4mMr6OLkXVl9aW96tFCZa C9bsdhiXQZMnT64JEziZMQ4cO3asZ9qX1NrYe0PAEEh/CJhPRPpbMxuxIWAIpBABpPuHILJK ynkZW+3JEDsP4QD6AoRQFhx/t0DweZJhCMWvifjTBd+BlvIrwA5+pLqUMzUmHJ2RvjfH9KkQ hPZE+R8ED0cmKkih1xDus7/MbypVqhSWuA2ur2fqHV64cGEFbmcm1a+0KxCtq5s2bdpfJlhE jloLYe8xA5hQbcJevQQ+ER1wAh6FRmEG5Z+Xb4Sk9hC8H7p+ibTUBVOs15w5lnuvK74IBzDB mQgzNBk79yr4RTTA1j8rc1pKf4MxzdkIs5MPB/Jx/nq6B5vdYHk/2oWs+BHkwNn8P65MuD5d GfwtNkCIr8ef4HH6KECEp/WYx/ys7zAaP/G9k6I+oRG6FEJ5PJoV+SQkeaS0PSTvk1577bU2 jPkYOOQBy2HqBG3EbjQyXyBl/xv75Kh8QCDK33QDkD8DvjbvwGi1Zw+dYq/tAIesMmNSVCf2 2wRXNqmrpPdJ9U9f5WBkL4W5e81fH+b1eRiUkvTZDswXhRsnDFBpVy7S9mCslxNOV87UA7S/ 2Xt7WP+vNAb2aif2/kZ8IxTqN84/Lrs3BAyBjIVAQA2esaaV4WYjFbCtVYZbVptQMghEtO8x 35FZRc1k2gr5WVJUaQv0MZjgkckOkuP8fpMjlZMzMpqJohBQcZgtHdO7pA5pCNBeHJctflJl In0frl8lI0MKfAiCzjOjcW1CeGeF2ckuHwK9U+hPtAuFYXJ2hGJ+XL3krpKzLhg4AAAgAElE QVR6Y2d/WvNDE5JDIWmD6yjR3ccff9wIjcwwojtFi5B1mo/gssk9S/OBKVS2UDiifSkCoyQt kefDklxb+p6S9qRRYt2jg/eJ2kMbkUt7BWZut55DHTLvgaEojh9HAsxcklhgAoSl0/CewW2E 6z+4bFLPkYwzqbrB7/XbYf2LoDE74f+NuL0RXD4dP/+Kb8vcdDz+9DL0iP7ep5fJZJZxGmGa PlbaflzpY51slKmLQET7/lyYiNQdrrXmR8AxEWhG/uF/b/fhEUiKiQhfy76eRwSMiTiP4Pqa jujvva+83aYBBMycKQ0sgg3BEDAEDIGMhgDS6Z2Y2szJaPOy+RgChoAhYAj8joAxEbYTDAFD wBAwBFIdgZYtW8bqTPWGrUFDwBAwBAyBNIGARWdKE8tggzAEDIGMjoB8LDL6HG1+iRHQmis0 rqJi+UMDJy5lT4aAIWAIpE8EjIlIn+tmozYEDIFkECBazhDCY75BdJvXdRI5ZzDRhB5yYU6T qZ6qn3EsvgQn7AGhGiV6zlU4bg5z49QVJ+HnlWxNzrSh6kTyTmFH5ZcQSdlzKUOUq7KEbu1/ Lm3464rYJhpRY0KG9iRrdydlzXbf5UBOUrl2isiEc3Irok4VdN/clZC47ciUHAidmtL21K+S uLFnetxzzz3KlO26iCLL9LVEjOrKeR+J4K4MfPjjhkzaJYl09SDO9/eCT02iGd2KQ3U/Imbd Igfr4PIZ/Zn9PIBoToE1yejztfkZApkFgRT/B5VZALJ5GgKGQPpFgBCnb0FE/lUnWZefT0hI yP3ggw/endZmRFSlvW6cupKp+h0i3zQgY3Qg78PZjpmoRaUgZuudbb2zLU/40t/IQu2FPD3b uqHKk2Su1qxZs64jmdlkslcvIhNyZ0eAtm3btiMRnk6TY2E80aFOYC71kGO0CD9bCQaiPQn6 biSMbx7XdkraUwhgciw8QM6QJSTRm0Q+hMpEoGquNpVpmlCv7WFmlhNW9keYwA6EoS3r+iPX whWDBg26hVC4o4n8NYp6y1iLMdy/RRbznfARrV1ZuxoChoAhkJ4RMCYiPa+ejd0QMAQiRoAc EccbNGiwgJCkAek1ieJu4H0/nSQBa+AaUwIuYt0/Qiz/V0lK181JtiX5ljZDWg4ky32Ir+9J ycmjULxq1aqdSUrWoEyZMo+pnQEDBlQitOrTnE+R28BLUOfaT+6qkKnkX9hEPgFvrEn1C7NR ShJx196///3v0oRB7azxcN8Sxqks0vC79F3Sccb2OCE5B5H7oSPfcrt6hIftoTru2X+VFkXJ w2BussAwNCJh37PkBRiorMUqB4FcrEePHnfongRxN5Nor57agzF6CbxbOyL/H//4R3n6vVfl 3CFtCXU84ty9o70aMAvTyHS8hlwdi5DorwD/KkqGt3HjxvIQ5+PJcv0bSey+QapfVG2oLqFr S8JYHEWTk+Da0jUl7cEIVEMTsmbEiBFzlAWafTIFRqKG2vvggw/qwwhMIcfDLyTMWwv+i1mH OvqmucJk3A6Wo5Qkjj3RmyzWpcDtFkLD9iLXxHyya5dQckOVhxkpD1YPk+H672Sz7uoyPif1 XntL2dO198j38Ry5GULuK4UDxrH9Hq21EgS+9957ZdTfXXfd1URrr3sd7JVO5M6orXsYn6vV PqF/B2kPKRyw3jP2xqqn8UmjQG6UvyhRIP33ZxzPaM+pXLi113d3hNuHroyuyvQtDZfmwB5u o2SDei/Nj/agfoPSFEk7pfeRjFN7+c4772wanFhR9e0wBAyBs0fAmIizx8xqGAKGQDpBgDwJ OURQ6RSxM2XKlDrkFFiq4cskBUK0GZLmcUiSPyCrcD2k1h6hCNHUlYy7Oyk/mOsuynRQHTIk d4Uo2waB9ZwSwD3zzDPd5s+fXwBiNufy5csrk925Srdu3b5XHgIk1F0gfuZD6I0ni69HqKmN JI4sbpySgjO2yhCbpSF4Vqp8mH5zUc/LCK1yjCMXjEdxsm/HkQtiBgzM1qFDh04Ww9ClS5de SM8XQ+DKxOskRG0n1dHB8/Fs2bIpxGLgkDmPGCi0AX3BMa+IdeZxPVqH4RCcI8l50FDviMCU e8uWLaVUkTwEMRCJt6FF+B7Cehg4XQUO1+gbRPUp+kmUywGiuQAJ9a7Wd3eQyC4bBOJJ94z2 KNfmzZtLkCBPIcmzQHB7dkVkyM5G2ewwWN788T34jjwOn/Pdy4jt6qekPRimrMLItUGujZx7 9uyJEZNAFu6iNWrU2OK+lSpVKg7Nh8fIgElM8eLFd5IA8AgM0HXstSUfffTRTNZhL/tmo/Jk YFZ3iIzVHoFOpue7yeg8ZcKECUOU8BDGqb7aTeo9OJcF8zokO3yPffY1DMs9oXxtYHLaM+Z8 9D2cPfQTYWMf0Z6Esf2FNamkTNbs6evWr19fDk3PAplqweS1Yo9MRQv0isbw5JNPNtKV/VWY PdOcHBiLWNfPx40bdztn/SFDhoyEAVrH+t6qcuHWXt91JLcPfy8VFSVin2SIXelvvObAOMvA zDVUlnjm0BWcxsE8DIDhOQgz6zFFkYyTdThK3pLSJAEcCJPVwWm4XL92NQQMgbNDINPZZp4d PFbaEDAE0jMCEEKPcQamAAG3D+J4ul4g3a7fvHnzmRBUK/QMATgdk5PqEGmbRawtWrRoWHR0 9AmI4m8xWzkKoVcMQqkcRNY7SGwTkFYv/OSTTxoika5EpuQtZCLO/u23376vrM+YIVXFB2IT UvOpahvGYBqEX0vdy9EWAs+TqpLpeJveQaQXhlkZqnt34A8wh2zIW2kzyX4h8ne58v6rEskh Jd4PMX4MQnY/hGpdZapmLtNUjkzcXyFBHwzhlRPC6hgM0Ht6DzGcAzxqQTQ2IP9GVjJuzwKP j/FBSECKfgWEewEI//wwW+sgpF9njglg4hHEqq+jdu3acySh1z0mWd+hCbgGpmOJskXr1Ptw h7RFjLMROMZDdBaE+L0aAnydsj8LU4jGFhDAP6EFul6YQ0TnSu32yIa9CIar5VNPPVUNyf1O xiOfiKzyZ4CZiEYSnuD6JAv1HpgXbwwQtsXIfB6vbxDC1ZCmf677pUuXlmFey0Wsy6ROydmU CJAEegUg6ouDy1rWeRSMY26I5pah3qsdHRDQ3yjhnU7WqRbakgowqqt+/+rttTzs3etg+Abg NxIvrRYZtm8ggd01w4YN+xVGYTxmfq2VdRxm9WOYnuNad/xnxmhdxZSA8y6S513m2gT7hTCj 8/WMluQA+3YWTMwmZd/u06dPgBlNau1dOzAG1cPtQ1cO5qgWmsBVL7zwgsfwg/lYtAfR7MFa 4L2BPj3mGub/G34nLzutWnLjrFix4mHW4n1p9tiTN8CYPIQgYDearxn0tcgxqG4cdjUEDIHw CJgmIjw+9tUQMATSMQIQTkMhyHrpnDZt2nM4MJ/C9KaZpoQEvdiXX37ZHMLhZZ2jR4++DeK+ AGYx0Zjr7BYDoXIyg4JYm7RkyRKsK4rsFAOh9zogJrGyiPPMKagTLwZC7zFhuQL79/W614Fk eKN3wz8Q9PdjjvO0Toh3ry6mP3vcOBnX4zAh7y1YsKC2zJUgCMP269rVFWl9yL/pmAEVjY2N LenmCgPQDyYhC8xNIgYAIqz3559//heItLHM60UI2hliINQ2zNhqfA7mQIT2llkLkvbrYXyO 6pv/AJ9AWFeItt0wHeX933UPA9NFJikQrvfCyJTSvU75E2CuMhcGaBdmOw+9++67N0HM/0w/ XkZsvn0GU1EOTVFvCMuCaAE2MOZAf8H96Dkl7SkzNuZtX2EGdBt05oMQx0tYo31iuGDMjkPs B3CDGcjF2D1mDsn8XnArpH7z5s17eNu2bfkxgyosDDC92YVWoFmlSpXW6DvtnYIZGs3easxe G4K2qQ2aDhRC2aJCvVcdHTCsgfmCUzxMbbnfv/z+L3uvqNaWPfeUW2+Y4stgFLy9JhMtvkdB zMdDQHvEOOM/zjhLs9H6g/WgefPmVfK3ST973TPalBMwpjv0LO0SR0AYmdzaR7oPwS2atfX6 UD/suc1i2nlfhD21Se90aJ0Yw1H2RH49RzpOMdbgPpG1eo69NAPmqi377F61YYchYAhEjkDI /3Air24lDQFDwBBIuwiIyIGQ8k5JZTl/xDSmpEaMv0NC9+7dP4Vwe0YnxGxfGI0RN9xww05J go8ePSrzGWkJssoOnbrbuS8k3wC914HpUAwmS2dI15HkxkG0F/69VFQURFkxd485zGCIuF46 JZF27904xby88sorC2FetuIkXDK5fkUwujYw+7hEBGLwgV15AgTuSjdXXfH76A9BusdfFsJ5 CrgcxkSlnSISQfwGHJTJPJ0b7c03zKsP0vBPIV5rYQpT2V9f92grAr4WmHqVhFjeH1wGCf/3 /fr1G4Md/TQYkl2614mj9FYxVjB3n4J1X4j112CMcuKfsJMxZ2VsJ9F8DKWPvrNnzx4FljFN mjQJEJvB/eg5Je1BlOaF2VsKozIQ7cMAmIjfILQ9RkbMIjhHu77YT9FoSrwxIPXfBsFeUpJx tAOT8J9oxFybgtMoGKa2MIgFYVa/V11J/NE0bVAfaKleZ545YB5aoiGICvXe9cc+DeCrvQzh nAhfNCFHIPRPMcbn3XqDwbMQyrPUBmtXHWZaWqeSaCQ8BoRv5TFTa8r6jhDuMDTTVcYdcmZ3 9+Guya19pPtQ6y2sXF/SxsmnBu3EDv/vSr5LmJ0dw2cnTmUjHafKzp07txDzvBl/pdYwh1vZ 77P13g5DwBCIHAFjIiLHykoaAoZAOkcAQvAgzIFneoIp0CrMl66Tk6tO/Ag6YsbShIg8eyBs d2PWU03TJTxnHcxVrkUKv++P954zq+yzIXRicLoNaBwcPDgXL8X2uiLtFxXxC1F81lGWILgO QNDlCtcvUvh4HMWjMRuKFnOD6VCgH4irUyJMNSbMtlbDEFzuwttiblSDd49BdHlDlqOsnE0x 9VoAkToEJmYk5iylkZ7Ldrw9RG4pGIvq+Fm0xSTsJATxciTFm5Dk5nVzdleI+yqaMwxATvqr inZmnb6pb/mh6B4H9C1gvQ6J8FaYpwTd65QmB7OShhB3d6ocJjlFMPe5BnOyZTCEp6nXk7FV 1Dc0BHUh/rbAHB3Rc1JHStqj3+IQpk8zvxw60Yg0aty48Xz1Ib+SyZMn1xHeIm6R/NeC8fT2 gMzIOnbsOAUzsI68i8P34W2+j2UPrYG5GIIW4jdMaTzmEmYoN8xJHzFnOAVva9GixQKI8Lys mUzCznjv5kfI2Oq6h+iPQTJfBp8Vj4mFOaiG1io/TOduGLe9rJHn36N9isS+H3uxuPxtqN+G 8XwKwzMR5sbzqUD7VkKENG3Fae20j0Ixo24MSV2TWntXPtw+FEMgXw2VZZ293498I8TMszfa gF8BtHdL2JdX6r3KMZdrCXSw0u1jvUvukFke+/p+fud9+e3Ib2QYazAM7d/q5Orad0PAEEiM QEANmfi1PRkChoAhkPEQQLp/SBLYP4ipyRCKD2Fj/QImGVmQ4G7Bv2GMZg2B+jXmOl3wHWgp vwLs70fqvZypIbQ7Q1Q3x/SpEJFqJopw1Df/AbEdi9R0DcRkf5nBQDwu83+P5J56h3E6rkDZ mUn1C8EYjxPvapxe+8sEC4JqLQSRZ2qDOcsmJM0lINQ7QLiOwi5+BuWfl026pPvYp3/oxoGd excI+NecOZbs3TlHYsKVH0KzLo65DyC5fRmGphkYDtScIOpPYvM/HwYpUfx/RUgCy+eQqOeE aduOQ7sneafcZUh978RpeInrN9QVgvEnfAQ6YUbVC03PpTAQ49GYeOY0+ENMgghsw3iPQezm YU7DQrXhf5eS9uS7gb39esyuHoeRK8BY1jP2n9UuJk7T8ZOoCI6DIHDzooma5fdJwOH4f5gE HWRvdWf+ceyvWPZcYbQmRWAOltetW9fT/kDIHmJfLGXNBhOJayP95KOdcZj8XB3qvZsTTFUF 2q2BJuMS9td3YkD0DT+CzjB2w2Es1xLu9mMYtvvxv2mscuyF78S4yZlYUb9wTl4KfssZWy0k 8M3Y39MxY2vMuj0Nc5QL/41fCDTQ2DF9ru/krkmtvauH5m9jUvsQ35vSjKMdzOoi/X6IBrUU DJ+THxN4bsOHYRHtn8ZMcBXap+cZ629gVhBG4l+u/eSuBFIoARN6l4IOwFR9hMbwWHJ17Lsh YAgkjcD/11cmXca+XHwEpEq2tbr462AjuLAIRLTvkZjWYlg1UzI0ObpKW6C6clT1tyFzE6Se +f0mR/qOpD4nmomiEI9xyREh0hCgvTgu221/2ym5D9evwlwikT8EcX/K3zZEVlaYneyy5dd7 CNB8SJ0LQ0TtCMX8+Ov67yUNFgEnTJDCx8AgHQw1J951hohdJz8EJO15grHzt5ncPdLwIjBA 0v54vimuvCTl4B8dvF7ue1LXlLQnsyZM27KFmqs0K+AqM7EkNSGqj69BURiHODn1hhqb9ggS 8RxygNZ3GDZceYb3DH6vb/hLvMn6PYvGIjsMwxG3rvoWfMgJHEYgBmJ8nxiW4O+hnvVbYF/H y7ROJllow04436BQ5f3vzmbtI92Hwg8m/pTzy3H9yTEaTVcemKhY7Uv3Prmr28fJlQv6/ium XXOD3tlj6iMQ0d/71O/WWjwXBIwwPRf0Llxd+3FdOKytp7SDQET7/lyYiLQz1YwxEkdI4hD+ Y8aY0YWfhWMiQvXsmIhImYJQbZyvdxl47Y2JOF+bJnG7Ef29T1zFni42AmbOdLFXwPo3BAwB QyCDIIDN+0Ik7omctTPI1NLENNAgTcKcLE2a4Njap4ktYoMwBC4oAqaJuKBwp7gz49BTDJ1V TMcIRLTvTRORjlfYhn4GAuE0EWcUthcXAgHTRFwIlKOiIvp7f2GGYr1EioBFZ4oUKStnCBgC 6RIBRdcZO3bspbLDTpcTyASDVihZEvOVlA18JpiuTdEQMAQMgQyBgDERGWIZbRKGgCEQjIBC ZxJd5z6i0bxInodO3L+IE+zDckIOLhvpsxyxiXLTQA7LkdbxlzvX+v62gu+JUlNWycKC34d7 JqTnbZwtVQYn2hdFyIcrn5JvCiernBOh6hIFqbbWhLwId+JHUQ1znfuIuvO3pKICER2qHbkM EkWDUlnWtqvWGofuK0P1o3dEBqqDqVV3laVOZbeGckAmCVxTjYOwrHcp1GioNpRXQP2Tw+BR HHpbkKysuCtHZKEYQoa2oY0eJC9r4s8l4sr4r6Hm4caH43qUG59CyMrXIPhUBnJ/e3ZvCBgC hsDFQCBF/xFejIFan4aAIWAInA0ChD3tqoRZxJfvR6jQV4ip/7RyEpCDoPPZtOMvK+Lw448/ votoOinyJzvX+v6xBN8T6vM3cgckG/I0uJ57hhB+nYhHXoQg9+5croQMLUHEoebKS0Ckn0Cy PdcmUYDugoDPQyK0ESQSm0Ciu4WElH1nzJgx/yKqUBU/Q0DI0koQ3u1Jvncj4VIDCfAIa1qB cK/tyd2wnFCwPxIetAOhWcu6PtxVCdZgPm4h18NCQtfOIO/Drb169bpe30lwdwcMwrWYEU0m 4lEcDMJjjsFw9XUlMV53LlnIv/AlDs4nIfq9faR8GOQv6E5I2yyM82vmUIE2bvfXdfdJzcM/ PqIpRbnxEZXoMGFOF/tPksiVI+xpmvSLcPO0qyFgCGQOBIyJyBzrbLM0BDIVAkqORrz9y8kO PBZH1OOafPHixY+Ts2Bs9erVV4mY1wnR3IKwqC9xvgiR2FyaAh2SSksaTAjNp8m/MBDtQ329 J3zpg7rSxhMQszkknZYEXPWRUD/y6quvXqHvOsihcI00A0j4B0Ewt5FZVXB9ZeEl58C9v9cI /68SbEFM3q5xwzA0IlfAsxobuROaqCYhTIv16NHjDt0zl5tJeFdPknHNj7j/rRUaVd+S6hOi WFL4SyDiS9aoUaMjOTCa0v4A5Q7wS/9JrncDmPbTCeHfQG2GOiCmo8nGnI98CvHB36U1IfRs XtZnOvk4rmIOXQkvWp58EB0g0pvw/SuSgN3o6hHWtKRyEJBAL8G905WM0PXJgTCF/B6/oPFY y1osRqNRx19G92TXvpJkbj+MGDFiDszDOpyAfyaEanWF/CQEaz3m/IGS3XH9ISEhIQ8hVgPr qPrSalE2D+2M6dKly2ZyDcxk/f8s8yvwvJpM2keUVE65GMgxMpUEb9drnVTXfyQ1D//4yImg 5IDe+JS3Q3kn3Alzk5MkiStgnuaJQfOvi78fuzcEDAFD4EIgYEzEhUDZ+jAEDIELigAS60sh XncFh8KEYD9AwqnvIUZPI7muR4bfq5B6D4EY+wdEYM1HHnmktgaK5qIkDEczpNwfQ6xNRfvQ RkwDyds+03fej4SIP96vX7/6xNHfDxH4CqY4cyEu7xYjIoKfZG5daW88xPBwpMdlIC4bBtcn YdspxpIoD4La9x8kt7scwrEbZkd9ISLzynSGjMrXo3UYTgKukRMnTmyod2TPzo3WpZTqkqMh BoL4Nvr/HqJ6GP4gVyGlv0bfkuqTuqXRDOTkzLVgwYKasbGxhSDy32Z+8SQna6G6Mh0Cv2ZP PPHEOCT+H4BdPYhyLzOyvvsPktQtJ5/D5xDCq/3vdT9hwoSr0AAs0D3J25pCtI/+8MMPZ8Jo FYFRWg7zc5hcCPn1XQdJ075TW2iSEuVaIIFbURieLb+XioqSJoF1inHP7kr734DjT+6ZJH7l 2RvrIPajwf+oS2an7zB+u8jenagN5SmAIRp44sSJLOyL0mgeWpGoba1yP+DPUYz7wBjIjREH w5EPDcsZPjhJzSOp8bnx6iozK/ZhC5LeTdAzWZq1h3vS9+NkW67qmER9s8MQMAQMgQuBgDER FwJl68MQMAQuKAIkRcsj6XC4TrE9r3v77bfPEgEJQRuLRHsm0vwAQQxxPAEJ+TYRt5iP7J82 bVoMZT2puhLNQcRFUX/ZqFGjJqBhOIC5zbb4+PgSmLfkQlJci4Rsq1544YWlSiIGQzEWTcWu 4PrKjAxx+N/gcYphkcQfRqUvZj1tYX7WIPXur7Jr164tBIFdAOI1v6TqzON1MhzvD26D7Mhz JJ1Ho7Cjbdu23zE3j4lIqk9/fRJ8HaH8OBijWMx8psJQePb/MFv1kZLP7Nu37wphg8ZjOhqE 6sw7O8zSn3WKofG3FeoejIpitrN7/vz5BTANK0w7O6UVYN4lYLbWkCm8LH4AK0LV9b+DsI8G o4B2AoJ6D9m4c/nL6F5J75SYTbhi+tQO86rL+vTp8zPMRDQajkT7BOZzL/jmDG5Dz5s3b87d u3fvLjBZdVjfTdI2YCYXzf4IjIF9oOzap2GIzhhHqDb1zj8+GNAoNz5/ebJZ/wWfjTngdlDv MRf7jgSE/dlfP7IujdC0DcS3o5kFEPCjZveGgCFwPhFIkV3v+RyQtW0IGAKGwLkiAIEXB2FV Sk6z/ozHsnWH8L7+tddemwPxWgTp/kbXl+pAOAek3zyLGPQOSathTHK4Z3eFiMwKQ9EdQvLP EHHb3XsRlkjFd7hnmcBwv1mEsnsX7gpT0lvmM2g6RmMvv8Zf9sknn1yNw+0c2uyNpuEgDr1z xo0bN8lfRvdlypSJde+QmO/Gabqpe07uignUAZcJGE3EUSTw3tzRdhT78ssvy6AR+IvaQOuS DbOmnRC+RZHOP613zHsDxPYbuk/qgPDfu3r16kIQxXH4EmTXOuEvUJUs2nupmweNTTMYMU/r k1Qbeg+zcxyGJCDxZ31z0fauUHXQoJSAMevB+DaT8fjv0iJAcBdGgh+or3rgnrN8+fJxodpQ HcY6UJmd8Xvoh0ZqBTgdY28E2kA7kgMG8yRZqs8qX4YbH+OPcuNzY0CzlAsGsjYaqMHuna7a 25hTzdMpMzQ0Em3ZOzczpyekbfOXtXtDwBAwBFIbAdNEpDai1p4hYAhcaATOIJaQ+O+AOM2B 6UkiJ1uYh6sx/6kLYXwiJiZmO9L9wm6wmLAUh3jc4J4x+zmjXfdNVzEEEPn3QUzOwb6/D1Gf hrvvaB12QnAXdM+KsiNfBPec3BVfgyloUg5jgtROkY0UAtXVkX0+DNI3aAf6wGB8iilVLUyH Krvv7oo0Pbe7R+JfEsbgDG2F+x58xSE95NwZUwK+E59CpD6jE0l4XzQ0I5CA7yBfRy+dyTEQ 6gutz/Lx48fX+NOf/nSMaEaT8DHpAUOWDcL7f2h3uqOZ+EXaieBxBT/jsxGPqVi0e0/f0Zdd dlmAeXPvMbsqikP1Q4x9/NKlS98XM6BvaDv20G9uf2hZtCpFYG4CDKHKYRJWSn4iutcB8xlH 1K8NMEJF8GGIh3EIjAGzuCLsr1gYrd8dbH6vEvZf//jw04ly43OV8K+5Dt+UrdKauXfuKgYM bVFN9kJ7GONCrVq1mmAMhEMnVa4hfwup0rI1YgikcwSMiUjnC2jDNwQMgSiPIPTj0KRJk901 a9acPXTo0BY4+HraBRxoC2N7fgemSz+qLN+XIp2vJVMc+THgR1GpYcOGK/3tBN/LhInjFKYq OTEryispNpqNpSLakALXcuVxsF0KgVlRvhFiNnDabYPPQQF/fZWdOXPmJfIzcPXcFfv9BRDo Q/CxGLly5crS2O8PxOSlvRzGYSyqY2bUFhOakzghL0eyvonxnJFfYfbs2VUYX1ZFD6Kfqvgm rAvXp+s73BXfjFVI4a8TZjrBqyNz8xy7w9UL/iYzK7Qb2eSYjU/ETzACw+T0jM/AZJii4fik BBiw4Lr+Z0yTFmPOVUdmRWLUIOBrwQCsVxk5b8t/QfcwezeB33wI7WUyadKp8f9hRrQJHL1I TXyvdvjw4fxE9vK0GXrGbyY/DM129lFlRYNSe+qL9SmFadNi/BKWoikoJzMutYvpWjOYUW8M 8mPA9KuK6oQ7/ONjLlFufK4ODvxXsl+XuWdd0UrIf+R2mJhBYFCTsEuDpBQAACAASURBVK+T 2QcDyYky1V/O7s8ZgTP+vpxzi9aAIZBBEDBzpgyykDYNQyATI3CG5FlYYJ//BVLZe4jYM5gI SfuQzBckStEPMBZz9B2zoLkQhz0x+xmAWcxROdRCFIa1wxezgJnTCgjVZ9asWSPCfg7EXR85 /PJ+PXb3m5Cst4J4HIPt+lKIvOcg9vdB6G3DCXpRcH1Mgy7DUfbOl156aYnGFHwgPd/EOVKM ENqGukicH4CgfBm7+2aYEQ1Eu7APjclJJNXzaStR/gRFM0J6/RwamZyYyGyHoP5e7SfXZ/AY /M8Q5pOZ00P4HrwA45WF9rcQGWmMv0yk9/PmzfuQcLvNwe1RpPrbkd7vl0M465SPvB7eWJNr CwZkOv4iFfFjGASzlhfTsln4DqxSPcZVP2/evEdkSob2pizamOKMt7lrE/OzzTArr8JYfgTT 1wutRj0iM+Vjnd51WgSYhs4wacPF9OALMpX98RhO5jJ1yoL25VtFT9JJngvttb9pH8l/hvV/ U/3AWJR+44032sH4LXL9hroGj4898YYbn8qjiaqAKdYMf9377ruvE9htxDdCoXlDml/5y9t9 ihEI+fclxa1ZRUMgAyEQkX1uBppvep2K1Km2Vul19WzcKUUg4n2PGU0rOgmZKE2mKkiTC0P8 xsqMyT8YaQmQ4sZAXCZIKu3/Fu5e5kVImz2HXOzXC2IadQxmJEHtIVXPK8JS9dU3hOUpRffx t+ev73+f3L3al68CNvjZNG6IyIOY5BwIrqfkZNjGr8Mpey6EeZ6zmVtwW8HP0trIJ0DvU4N4 VXuEWy2CeVZuTMN2+n1YgvtO6lkaHRi4BKI6JXKSTqp88Hu3D6SBcAxEcBk9Y/KWjzXNL2f5 4O/yW0BrJC3G7uBvZ/MMowhfM7xncnXcXkiunH0/JwS2Ydo3/pxasMqRIhDx3/tIG7Ry5x8B I0zPP8ap0YP9uFIDRWsjvSEQ8b6HiSjE5NpxmnYVEBwTgS2/Z7qV3hY+M483UiYiM2N0geYu gcMYmIiIhQsXaFwZtZuI/95nVADS47zsP9z0uGo2ZkPAEEiEgP6jh5GYxsvGnJn+7xqmNwtx zj2r6ECJALUHQyBzIyAGYpoxEJl7E9jsk0cg0/9nmzxEVsIQMATSAwL8h78GRkJhTcVIhDRt Sg/zSI0xkgU6rA1+avRhbRgCGRSBbczLGIgMurg2rdRFwJiI1MXTWjMEDIH/x96ZwNlYtn/c OvalwZBClhbZ96XsL1qohKwRyVIiLZIkIu1UvOlte0vxKkpJoZBoI2SL7Ev2fd+X//f36J7/ mePMnGMYM2fmej6fx7Pd6+++z7h+93Vd95WICPyzcjgBMpGLZuTj1K5FZraZiGNiVV8YAvjY KIP3z4XltNQXgYBMabQL0zb+hlyUT8tFtMGyGgKGgCGQIAjoD5wdhkBKQ8DmfUobceuvELB5 b/MgJSJg8z4MR93iRIThoFmTDQFDwBAwBAwBQ8AQMAQMgcREwEhEYqJvdRsChkB8EYggY+H4 ZrZ8hoAhYAgYAoaAIWAIpAQETM2XEkbZ+uiPQKB5X55E73DKfvm4fwZ7NgSSAQKB5n0y6JZ1 wRCIEwGb93HCYx8NgfgjYD+u+GNnOcMXATfv5ST9OOc6TgVWO8mpb/s47TAEkhsCbt4nt35Z fwyBuBCweR8XOkn0m+1akkQHxq9Z+nHZWPmBYo/JHgE373U9xJk12ffYOmgInEPA/t7bTEhp CLi/9ymt39ZfQyDBEdCPyw5DIKUh4Oa9NBGPca7lNE1ESpsFKa+/bt6nvJ5bj1MyAjbvU/Lo W98TFAH7cSUovFZ4EkUg0LyXT8R/OM9wnkii7bZmGQIXg0CgeX8x5VleQyAcELB5Hw6jZG0M SwTsxxWWw2aNvkgE4pr36Sn7moss37IbAkkRgbjmfVJsr7XJELgUCNi8vxQoWhmGQAAE7McV ABR7lewRsHmf7IfYOhgAAZv3AUCxV8keAZv3YTjEFiciDAfNmmwIGAKGgCFgCBgChoAhYAgk JgJGIhITfavbEDAEDAFDwBAwBAwBQ8AQCEMEjESE4aBZkw0BQ8AQMAQMAUPAEDAEDIHERMBI RGKib3UbAoaAIWAIGAKGgCFgCBgCYYiAkYgwHDRrsiFgCBgChoAhYAgYAoaAIZCYCBiJSEz0 rW5DwBAwBAwBQ8AQMAQMAUMgDBEwEhGGg2ZNNgQMAUPAEDAEDAFDwBAwBBITASMRiYm+1W0I GAKGgCFgCBgChoAhYAiEIQJGIsJw0KzJhoAhYAgYAoaAIWAIGAKGQGIiYCQiMdG3ug0BQ8AQ MAQMAUPAEDAEDIEwRMBIRBgOmjXZEDAEDAFDwBAwBAwBQ8AQSEwE0iVm5VZ3wiNw9uzZXNSS jzMzZ+qEr9FqMAQuDQJVqlRJNWfOnMqXpjQrJUQEzpLuCOe21KlT7w4xjyUzBAwBQ8AQSIEI GIlIpoMOechB1+py5k+mXbRuJXMEKlWqpB56/yTzribJ7vE3ZAsNmwGZ2J8kG2iNMgQMAUPA EEhUBMycKVHhT5jK+c//WkpuyXlZCcTMmTOv0HnmzJmE6ZiVaggYApcTAf39aPnP35PLWa/V ZQgYAoaAIRAGCBiJCINBupAm+mggorVMH3/88dXlypVrV6RIke733ntvrSVLlmR1ZT799NOl Spcu3ZHzvhdeeOEG937fvn3p7r777vrXXnvtgzfddFPz3377TZqNgEenTp2qZ8qU6cW77rqr Z5MmTR7OnDnzy82bN6/nyET79u1rqhzfzCozR44cA6dPny5zKzsMAUMgaSKgvyN1//m7kjRb aK0yBAwBQ8AQSBQEjEQkCuwJWqlMmKIJxLp16zI+8MAD3XPlynVg4MCBX65atSr/HXfc0UEt eP3114u98cYbrapVq7asY8eOPw0ZMqTNW2+9VVjfGjdufNfcuXNLde/efWqBAgV23XrrrT0P HTp03nwh302ffvrpbeR7C+IxYO/evc998sknQ6dOnVobUnGLyvI/atSo0WzZsmU3TJ48eVi9 evXM7tofIHs2BJIWAh6RSFpNstYYAoaAIWAIJDYC5wmFid0gqz/+CLBaqFX9GCZM//vf/wrn yZNnx7Rp075EC7Hp3//+96T169df9+eff2b54IMPat52223T/vOf//z2yCOPrEYbsfjDDz+s evz48dS//PJLjbFjx37Qs2fPNVx/OHbsWKYRI0Zc59+68ePHN2zduvWkDh06bHTfmjVrtq1q 1apzIRJ1T548GcOZu1atWk3/+uuv62jP69WrV9/n8tjVEDAEkjQC+f/5+5KkG2mNMwQMAUPA ELh8CBiJuHxYX46atAtTjKNNmzbrJk6c+K57CSEohlZiW4kSJQ7v3Lkzd8WKFTe5b9I4bN++ Peqnn36KTJ8+/fGbb745Wsgnz87ly5dHubS6yizq4MGDkffcc88q3/e6b9q06ZITJ05knj9/ fnb3rXbt2nfPmjWrNuTlvQoVKhx07+1qCBgCYYHAeX9fwqLV1khDwBAwBAyBBEHASESCwJpo hWob1xhHoUKFjuEP4QnsaBsqDh8+vFXbtm2nKBGmR5FoKY65DAULFtyL4J9h4cKFkRkyZDjq 3ut6xRVX7Dt8+HCE77s1a9Zk0TO+Fod93+seTcQuXffs2ePlWbt27XWQjhL58uX7+5lnnrlV 3+wwBAyBsELgvL8vYdV6a6whYAgYAobAJUXASMQlhTPRC4thOuRaIydpNA+dPvroo9vwgxjJ OV/fIiIiTm7evNkjAnrG5yEDpGJn1qxZTx49ejT6vb5h4hRRtGhRjxjoWQfaBE9TMWrUqCLn 3vz/v2PGjCnG01nIxF69xdn60DfffPMmx8eQifIQiVL/n9ruDAFDIAwQCPj3JQzabU00BAwB Q8AQSAAEjEQkAKhJqUjIQBoE+Y7ZsmU7hJP1kK5du65z7WN3pD1oCCLd88aNGyOvueaabWgu 9uLLkHHFihXRK49oFHKxo9JWl1ZXzJ+OR0ZGbpsxY0Zx3/e6x6eiGN/X8v2UntFAbKEd+9m1 aWvDhg2nDhs2rCVO3pn0zQ5DwBAwBAwBQ8AQMAQMgfBCwEhEeI3XBbf25ZdfvmHXrl152EHp SzlM4/OQXqe2X2VXpsU4P1eV8/O3336b5+eff64MUVhbuXLl/VdeeeUGtAXVVOFjjz1W7siR I1nr16+/078BLVu2/I7tX6u++OKL0dvDaqtYIg1X7dat22T/9HrGL2NqxowZj5C3WaDv9s4Q MAQMAUPAEDAEDAFDIGkjoK377EjGCCDgF9m9e/eVaBhe9e3md9999+x77703E5Ok6/F3GATB yMzWq7OffPLJFUrHTkwfs5tTD7QVNdiZKcugQYPeJRbEeVHk2O1pLgQjAsLxwIABA06lSZPm DLu4pOrbt++HTz311F++dbr77Nmznx48ePAYSEYvtp1d8Oyzz/7pvtnVEDAEDAFDwBAwBAwB QyDpI2A2rkl/jNTCs5xBxwrhvTLpKinDhRzsmHQFmodjBISL4UwtzQWaiihpIAIRCN86lBaf h7yYTZ0kvcV+8AXH7uOFADFK4LIjuscrs2VKCAR+T5069dyEKNjKjIFASH/vY+SwB0Mg/BGw eR+GY2iaiDActEvd5Jo1a3rOz/7lskPTWQLTbfd/H+hZaYlwvS3QN3tnCBgChoAhYAgYAoaA IZC8EDCfiOQ1ntYbQ8AQMAQMAUPAEDAEDAFDIMERMBKR4BBbBYaAIWAIGAKGgCFgCBgChkDy QsBIRPIaz7DozYEDB9KGRUOtkQmGAFHRc3755Zd52TrYTCoTDGUr2BAwBAwBQ8AQSDgEjEQk HLZJpmSCyr2SLl26YenTp39NZ5YsWYZcd911XeVQfbkbOXPmzCuuuuqqAYHqHTJkSHEcN4e7 duqaM2fOZ//1r3/dpXgXgfKE8g6H76jECG6Hk/ngzz77LH8obQwlzWuvvXatggYydt1at25d W9v06tAWvffcc09dIod3L1++fDul8y9P0cqVx/d9fMr7448/srE1cMvChQv3qFOnTpPff/89 uytTOONf0wwH/W7EA6mndrlvum7YsCEjO4A1v/HGGzs9/fTT9Qg8WI37x/TMbmG5fdPqnuCH qdRf3/dx1f/xxx9fTYyTdsKBncVqEdQwq29edx+snS5dqOVp3pYqVapj8eLFO7dv374mARxj RHZ35dnVEDAEDAFDwBBITgjEWzBLTiCkhL6wFesbCHWP6USYe5ZtWzN27tz5nqTWd6Jl73Pt 1PXDDz98+4cffqjVu3fvCvFt6/fff1+A2BQ14ps/vvkQVl+75ZZbQnJMD1aHAvOxbe4DCOlL Hn300SkE8yt91113NVS+Hj16VJ49e3aFhx56aGqDBg0WsWVu+9GjR1+lb1988UU+pXv77beb Me559E5HfMtr0aJFW7bxPcvWvBNwpj/VuHHjriJ4EpzbtWvX5fTp06n79+//NQJ8sVtvvfXO c7WlSqXvtWrV6tymTZt5y5Yte+/++++f+9JLL80gnsgbzz333KQHHnigzZo1a7zgg3///XeG ++677+YpU6akIhhiUVeGrrHVTyDFjJTRPVeuXAdo25f0Lz+bAnTwzav7YO106UMt7+uvv45i u+J2kIi1bI88mXEo07Nnz1quHLsaAoaAIWAIGALJFQEjEcl1ZOPoV+7cuU8i0C3Yv39/9Coy Qt1NvO+nE0EvWggizkSOYsWKPURwuJe1Yvy///3PE061Ai1thrQcUVFRfYhA7a1+T5w4MW/Z smXbayW4UKFCPdUM4keUZAvZ3pxPvPPOO2XjaNp5nxCAt1999dUbtm3b5rU1tnohGwVKly7d 0RXw3//+tyCr0u3VHu4bI0AX1iq4vkMo8tO2R9AUDCJORlutkLt8WkVXHvcc25UAfuk7depU ffjw4UXeeOONouR7kG1wX9SKtBOGu3Tp0hz8rlAa8G6qlXvVqVV8iFF0pPBAdaqtEmRd/QQN LMcK+6qRI0fOUdRxxmsaRKKivkOSKiJczyAo4CqC/i1iRXw541RG3xDmI/fu3ZuFWCB79OyO +JS3fPnyLOvXry+KdmUChOHv8ePHf7Nv377cWtlHq3Ajc+QoAQvHMfabaON0TJaqQQQ9bUTb tm1vRxPyo9pevXr1Fv/5z3+qE0ekLlqmDlu2bMlCkMNF4HSj2rd169aM9D0KrFxzvWtc9dPf wnny5Nkxbdq0L1U/pHkSbb3uzz//zOJbSLB2urShljd9+vSCzKH5Y8aMmQnx+bt27doLOLzA iyJvlOP9Xly5djUEDAFDwBAwBJILAkYikstIBukHpiHpEc4idErARtiqWqlSpaXKhmlJKQTC Bqxwf/7WW299wApwDVa3PQEVs5SO+fPn3076IVx3kqaN8jRt2rQjAey2IKT1R3iagkDYaf78 +dkQKiNYaS6NAFkGIfv7FStWZMbcowNC8XxWaicgdFVR/jiO1K6dWi2nbaVZPS7I9rFe4Lo4 6s1AvnyuXNqRAeKRF6Fu1+233/4jBGbz0KFDp4owdOjQoYeidUMWZOJ1Gm1BO5eP55Np06bV ftUBD5ljybwKYjOIvlQsUKDA4eeff/4eVsGnTZo06RVMjFIjzNdU5k2bNhUUHjt27MiC6Vgt hOKjrFwPzZcv3w5wbOwqCFQnZjvl8BdI79IgjKdRW93zwYMHIyAHUdICsPqfFjIX/Q0tU4aN Gzd6WKCVWPbjjz9+AbFY6fLqGp/yTpw4IUKQ2sUMOXz4cFrqTgexywdxylOwYMFNrg6inu8i dkgW5oInxP/111/XoiFYrDmyevXqwpCNTzGnmkY7i4DdOojoQXDyWIMipqvNkFFXnHeNq36I 7zrG812XAaJYDK3ENsyhDrt3ugZrp0sbanmvv/76PLQP40VwRKQnTJhQj7m+UOVIY9OxY8fu 4PIImrSyF2OS59plV0PAEDAEDAFDIKkgYE6NSWUkErgdjz/+eE/O6Frwi9iPEDdTL1gtrdmw YcNZmMss1/PkyZNnYqNenhXmjQjChRctWjQ8MjLyFILZtwhFxxGW82ByUgTh6W1W9I+xqr3w 008/rc3qcsmbb75506lTp9J9++237yO4HpbwhA/EBlavp6tsiMGMUaNGeQK0HGsRhj1BuUmT Jlv0HbKTE7IyVPfuwM5/TqtWrTZTZqz1oiXZ6dL7XhUdGwH1AEL2CUjTAQTW6qzK76IvM5Tu /fffn4gGY4iIC0TjhExtfPO7e/kPEOG7NivkRRFy59GfYYqhQXvTELE7G2Qq74MPPriaNo6G 9ERrEFx+8D5Af6cgWMrE6Au0CgO1Sg8xOBtbnS6vrpjILIL4NH7iiSfKsfK9nfbLJyINJCWd tEo81wHvPZCk7BC3GyF4a3zz+9/Hp7wyZcoc0ljif9EIEvQzQnM1jTWO8hnQJkTSx2OunqpV q+7j/iwamwxcD4noqK9oAsqBtzfPELivKVq06AqRkrlz5xaDMP7g8ge6xlW/5qFO5ZP/B+Zb 96D1+NS/nGDtdOlDLc+lZ25cj/bjHsYkPcTFM2FjmL9jfGZg3lWW31gd2tQUAjqb6O8/+5Mb V45dDQFDwBAwBAyBcEHANBHhMlIX2U4i/w5F2O2hc8aMGf1xYD7TrVu3Bip29+7deb766quG CHMv6MQ04w6E+2yLFy+OzJEjx24RCKWTGRSrvVMwkWGRN9d2J7TpG6YkyIu7vJVk8uwRgdB7 Vpyvu+GGG9bqXsdtt9223rvhHwT6+zGL6a0TQdrLi0/EXtdO2qUV3PcwD6kicyXITJz1unJ1 ZdU64NzGxCU3K975XV8rVqzYj0jfqSE3McxefMtq1qxZfdrxEOZRqxDSn0GrMN4F4aO9ZxCo x4BLXXB6BU1JM1acz9t9iobvEoHQIbKiVWq0EjHMphB6q4Lj0zrBIAv+DY/oXpoP6j7I6vhE hNU7SNe5SpUqS6h7v8p64YUX5kKUdj788MNd33333VsgG79Ie+TbB//7+JZHXeMhKUXQUPVC E5IdTcw6hPsd+EecgExEY7hz58709PE0pkteIEPmm6fdgcAdUToRKDArj0ZnB6v5xdAa5UFj tMO/nf7PsdWvdCJUcsT+6KOPbqPMkZzz/fMHa6dv+lDKc+khmQsYsz7MlUlofzo6p3c2BjgF cZoH6R6GKd/IefPmlQCvweq/y2tXQ8AQMAQMAUMgHBEIKGiFY0eszXEjwO5MZ7TiqxPb/D2c P2FK4u0chC37Mez3P0P4fUonq/J9IRojsVPfjmCUDbMUT+DRqjuCaiXybuU+h68ghBAYhRnH Ov9WsHK9C6E9p3uPEBXt3IugOQQBvodOmbC4NK6dIi843y6EvGzGATd/sHpFBlwZOORewbN7 jL5iUnQMH4S/XF91xW/hGTQonrAbndDnpmXLlksQTheycn4LQuKd0qC4z9quFi3JOgTqgWhY XoO8pPc1VXLpwFAr8t4BGcoKrtkp84B7pytk6q9+/fqN1YnmRGMyUfeYlv0qszBI11LVg3A7 ABLxNwTDIwoiYJDAzxiTvmhBXqUNEWg64iQR8SkPrNIwV04jEA/FlKnvr7/+OpoxjKpXr942 SMse7qP9PCCPuRi/HRpL9Q2/mjWYM5VAk7KYx9T4jjyA2dd0xqkABLchZnRjlS6uI6769Q3t R0fG9xDaoiHyvQhUVrB2ujyhlodWph4O7ZWVTyQRs77fGevMzi9G70VGunfvXon+tsIPKQda t0nSyuibHYaAIWAIGAKGQLgiYCQiXEfuItuNAHrICbaYAq3AfKmC9uzXiR9BW8xd6rET0F5W Undj5lRO1fXq1asqtuqlENb2//PeM1rXnv9oDaJw9o3WOLjmseXl0pUrV16vLTwlmCHsXvAu SwiGBxGQM8RVL6u7exDQIuWwLHKDs3F0PQhsZyTcq02Yba1EwLvWbW8r0xfe9XRaAp4ryL7d tV9XiMM2tDIf0s/nWUk/jOPuw5gL9ZBpkYRxBPo+coKGbGxp1KjRAgTszL75dY+AfSV+J56f Aj4UldFMbLv++uuP6Jurk1X7feC+Riek7zRajbW6l9YD/4u8aCR6y6FbJxqHOnXr1vVW2tnd qDZp71ZZpMuFaVUJzM7+1HNsR3zKo01n6Xt3iN31KhdBvTqakE2QsqPUt1QmbnKy3r59e3p2 LGqAqVL0fIAkTMbc7Vb8bfJhujQaH4l30Kxsxj/i39pNifEI6oAcV/2Y1N0ALnkwq/tSpFdt 0CmNgDYHYA57juZxtdM3XajlQdZ2QSpr4uSeU3VpbHn3lzDRWDBmd0JcBk2dOrUSJHAqbRw4 btw4z7QvtrGx94aAIWAIGAKGQDggYD4R4TBKCdBGVvcPI2Tll/MyttpTEXa64gD6HIJQahx/ NyHweSvDCIpfs+NPB3wHGsuvADv4UWqOnKkx4WjP6ntDTJ9yIGhPlv+Bf1NlosIq9Cq2+3xG 5jclS5aMU7j1z69n8h1ZuHBhMW5nxVavtCsIrSvr16//jEyw2DlqNYK9RwYwodqAvXo+fCLa 4AQ8Go3Cj6R/Vr4RWrVH4P3I1ctOSx0wxXrVmWO597rii3AQE5zJkKGp2LmXwS+iFrb+aejT UuobgmnOeshOFhzIP/fNp3uw2Q2W96NdSIMfQXqczT90aeKq06XB32Idgvha/AkeoY5s7PC0 FvOYX/QdovEz39tp1yc0QlciKE9AsyKfhFiP+JbHyvuUV199tRltPgEOmcByuCpBG7EbjcyX rLI/yTw5Lh8QhPLXXQPkz4CvzdsQrVbMoTPMtW3gkEZmTNrVifk2yaWN7arV+9jqp64iENkr IXev+uaHvD4LQclPnS3BfFFc7YQAFXTpQi0PYr2M7XTlTD1A85u5t5fxn6g2MFfbMffX4xuh rX53+bbL7g0BQ8AQMAQMgXBHINr8I9w7kszbL9OHoGOF+Y7MKirFBwutokpboLz+Ao9Mdlg5 zuprcqR0ckZGM5EbAWoXZksn9C62QxoCtBcnZYsfW5pQ38dVr4KRsQp8GIHOM6NxZSJ4p4Hs pJMPgd5p60+0CzkhOdsCkR+XL9hVq97Y2Z9V/9CEpNeWtP55FOjuk08+qYNGZji7O0VKkHWa D/+0wZ6l+cAUKm0gHNG+5IIoSUvk+bAEK0vf41OeNEqMe6T/PFF5aCMyaK5A5nbrOdAh8x4I RV78OI5B5mLFAhMgLJ1GdPcvI676/dPG9hxKO2PL6/9evx3GPxcas1O+vxE3N/zTh/Hz7/i2 zA3j9odL00P6ex8unbF2GgIhImDzPkSgklKyoIJpUmpsCm5LSD+uiyERKRjbBO+6IxFoRt5M 8MqSUQWxkYhk1MVw64qRiMszYiH9vb88TbFaDIHLhoDN+8sG9aWryMyZLh2WVpIhEBABVqe3 Y2ozJ+BHe2kIGAKGgCFgCBgChkAYImAkIgwHzZocXgg0btx4h87warW11hAwBAwBQ8AQMAQM gdgRsN2ZYsfGviQQAvKxSKCirdgkioDGXFvjalcs362Bk2hzrVmGgCFgCBgChoAhEAQBIxFB AEoOn9kt5xW2xxzG7jav6WTnnCHsJtTVbXN6OfuIY/EVOGEPCFQnu+cUx3FzuGunrjgJP6tg a3KmDZQnlHfadlR+CaGkvZg07HJVmK1bn7mYMnzzSthmN6K6bBnanajd7RQ1232XAzlB5Vpq Ryack5uw61R2981d2RK3JZGSo7dOjW95qldB3Jgz3Vq3bq1I2a6KVESZLsWOUR057yMQ3A3R H/65IZJ2fna66ozz/b3gU4ndjG7HobofO2bdJgdr//TJ/Zn5PIDdnKLHJLn31/pnCBgChoAh kHwRiLdglnwhSZ49Y4vTNxAiH9NJ1OVnjx07lrFz5873JLXesqvSPtdOXYlU/TY739QiYnR0 3IcLbTO7FhVAmK1xofkuND3bl/5NFGpvy9MLzRsoPUHmKs+eDs+6rwAAIABJREFUPbsCwcym Er16EZGQ2zsBtEWLFm3Z4eksMRYmsDvUKcylujqixfazJSEQrQjQdzPb+GZyZcenPG0BTIyF B4gZsoQgelOIh1CaHagaqkxFmmar11aQmWVsK/sTJLAN29AWdvURa+G6QYMG3cZWuGPY+Ws0 +f5kLMZy/wZRzLfDI5q6tHY1BAwBQ8AQMAQMgfBCwEhEeI3XJWktMSJO1qpVawFbkkavXhMo 7ibe99NJELBariIF4GKv+4fYy/9lgtJ1civbWvmWNkNaDlaW+7C/vrdKThyFvGXLlm1PULJa hQoV6qlyBgwYUJKtVXtzPkFsAy9AnSs/2FVbphJ/YQPxBLy2xlYvZKOAVsRdef/9738Lsg1q e7WH+8YQp8KshjfXd62O07ZH2JJzELEf2vIto8vH9rDdlMc9+16lRVHwMMhNaghDHQL2PU1c gIGKWqx0CMh5unXrdpfuCRB3K4H2aqg8iNHz4N3UCflvvvlmUeq9V+ncIW0JeTzh3L2jvIqQ hRlEOl5FrI5FrOgvB/8yCoa3fv36ogjnE4hy/TdB7L5hVT+3ylBetq7ND7E4jibnmCtL1/iU BxEohyZk1ciRI+coCjTzZBpEoqLK++CDD2pCBKYR4+E3AuatBv/FjENVfVNfIRl3guVoBYlj TvQiinUBcLuNrWF7EGtiPtG18ym4odJDRoqC1YNEuH6RaNYdXcTn2N5rbil6uuYe8T76E5sh 4LzSdsA4trfWWCtA4HvvvVdI9TVv3ryexl73Opgr7YidUUX3EJ8bVT5b/w7SHNJ2wHpP2+sq n9onjQKxUf6lQIHU/wzteEpzTuniGnt9d0dc89Cl0VWRvqXhUh+Yw80UbFDvpfnRHNRvUJoi aaf0PpR2ai7ffffd9f0DKyq/HYaAIWAIGAKGQCgIGIkIBaVkkIY4CeklUOmUsDNt2rSqxBRY qq7JJAVBtAErzZ+zkvwBUYVrsGrtCYoITR2JuLud9EO47iRNG+UhQnJHhLItCFj9FQDuqaee 6jR//vxsCLMRy5YtK0105zKdOnX6XnEIWKHugPAzH0FvAlF8PUFNZcRypHbt1Co4bSuNsFkQ gecvpY+j3gzk8yJCKx3tyADxyEv07V3EgvgRArN56NChU0UYOnTo0IPV88UIuDLxOo1Q2055 dPB8Mm3atNpqLvqQOY8IFNqAvuCYWcI6/aiG1mEEAucoYh7U1jt2YMq4adOmAspIHIIohMQ7 0CJ8j2A9HJyKg0MJfUOoPkM9MWI5IDRnI6DejfruDgLZpUVAPO2e0R5l2LhxYz4C5Glr5tQI 3J5dERGy05I2HQTL6z++B98Rx+ELvnsRsV3++JQHYUojjFwZxNqI2Lt3b5RIAlG4c1esWHGT +1agQIFdaD48IgMmUXnz5t1OAMCjEKAKzLUlH3/88SzGYR/zZr3iZGBWd5iI1Z6ATqTne4jo PG3SpEmvKOAhxKmmyo3tPTgXBvOqBDt8j3n2NYSldSBfG0hOK9qchbpHMId+ZtvYhzQnIba/ MSYlFcmaOV1h7dq1RdD0LJCpFiSvCXNkOlqgl9SGxx9/vI6uzK+czJmGxMBYxLh+8fnnn9/J WfOVV14ZBQFaw/jernRxjb2+6wg2D8+lSpVKwj7BEDtS3wT1gXYWgszVVpR4+tARnD6HPAyA 8ByCzHqkKJR2Mg7HiVtSkCCAAyFZbZyGy9VrV0PAEDAEDAFDIBgCKc4mORggyfU7glBPzuju IcDtRzieqResbtds2LDhLASq5XpGAJyJyUl5hLSNEtYWLVo0PDIy8hRC8beYrRxH0MuDoFQE IettVmyPsVq98NNPP63NinRJIiVvIhJxum+//fZ9RX3GDKksPhAbWDWfrrIhBjMQ/BrrXo62 CHjeqiqRjrfoHUJ6TsjKUN27A3+AOURD3kyZsdaLkL/Tpfe9KpAcq8QHEMZPIMgeQFCtrkjV 9GWG0hGJeyIr6EMQvCIQrE5AgN7Te4Th9OBRGaGxFvE30hBxezZ4fIIPwjFW0a9DcM+G4J8V srUGQfo1+ngMTDyBWPl1VKlSZY5W6HWPSdZ3aAJKQDqWKFq0Tr2P65C2iHbWAcc9CJ3ZEX5v RABfo+jPwhShsREC8M9ogaoJc4ToDJe6PKJhL4JwNX7iiSfKsXK/nfbIJyKN/BkgE5GshB9z dRKFei/kxWsDgm0eIp/v0TcE4XKspn+h+6VLlxaiX8skrMukTsHZFAiQAHrZEOrzgstqxnk0 xDEjQnPjQO9Vjg4E6G8U8E4n41QZbUkxiOqKc1+9uZaJuVsBwjcAv5E90moRYfsmAtiVGD58 +O8QhQmY+TVV1HHI6ieQnpMad/xnxmpcRUrAeSfB865xZYL9QsjofD2jJTnIvJ0Nidmg6Nt9 +vSJJqOxjb0rB2JQPq556NJBjiqjCVzx3HPPeYQfzMehPYhkDlYG73XU6ZFryP83/E5ecFq1 YO28/vrrjzAW70uzx5y8CWLSlYWA3Wi+fqSuRY6gunbY1RAwBAwBQ8AQ8EfANBH+iCTTZwSn oQhkPXTOmDGjPw7MZzC9aaDusoKe56uvvmqI4PCCzjFjxtyBcJ8Ns5hIzHV2i0AoncygENam LFmyBOuKXNtFIPReB8IkVha7PHMK8uwRgdB7TFiuw/59re51sDK83rvhHwT6+zHH6a0T4d3L i+nPXtdO2vUIJOS9BQsWVJG5EgJhnPW6cnVltT7g3MYMKPeOHTvyu75CAPpBElJDbmIQAISw Xl988cW/ENLG0a/BCLQ/ikCobMjYSnwO5iCE9pJZCyvt1SA+x/XN9wCf6G1dEdp2QzqK+n7X PQSmg0xSEFzvhcgU0L1O+RNgrjIXArQTs52u77777i0I879QjxcRm2/jIRVF0BT1QrDMjhZg HW2Ors+/Hj3HpzxFxsa8bSJmQHcgZ3ZGOF7CGO0X4YKYnUTYj8YNMpCBtntkjpX5feCWQ/Vm zpz5yJYtW7JiBpVTGGB6sxOtQIOSJUuu0nfKOwMZGsPcqstcewVtUzM0HSiE0qYK9F55dEBY o/sLTnsgtUXOfTn3L3Mvt8aWOfeEG29I8TUQBW+uyUSL76kQ5vcgQHvCOO0/STsLMtGeAetB 8+bNK+lbJvXsc89oU05BTLfpWdoljuhFmWBjH+o8BLdIxtarQ/Uw5zaKtPM+F3Nqg97p0DjR huPMiax6DrWdItbgPpmx6s9c+hFy1YJ5dq/KsMMQMAQMAUPAEIgLgYCCVlwZ7Ft4IiAhB0HK O7Uqy/kTpjH51Rv8HY516dLlMwS3p3QizPaFaIy86aabtmsl+Pjx4zKfkZYgjezQybuV+xzy DdB7HZgORWGydN7qOiu5uxDac55LlSoVQlked485zBCEuB46tSLt3rt2iry89NJLCyEvm3ES zh+sXgmMrgzMPq6QgOh/YFd+DAH3L9dXXfH7eAaBdK9vWgTnaeByBBOVltqRCOE32kGZyNMZ 0d58Q7/6sBr+GcJrZUxhSvvm1z3aimhfC0y98iMsH/BPwwr/9/369RuLHf0MCMlO3evEUXqz iBXk7jOw7ouw/irEKAL/hO20OQ1tO43mYyh19P31119Hg2VUvXr1ooVN/3r0HJ/yEEozQ/aW QlQGon0YAIn4G0HbIzIii+Ac6epiPkWiKfHawKr/FgT2/FoZRzswBf+JOvS1PjiNhjC1gCBm h6x+r7xa8UfTtE51oKV6jX6mhzw0RkOQKtB7Vx/zNBpfzWUE5xj4ogk5iqB/hjY+68YbDJ5G UJ6tMhi78pBpaZ3yo5HwCAjfimKmVp/xHSncITQzlcYdcmZ393Fdg419qPNQ4y2sXF3Sxsmn Bu3ENt/flXyXMDs7gc/OLqUNtZ1KO3fu3Bz081b8lZpCDjcz33/VezsMAUPAEDAEDIG4EDAS ERc6yfgbguAhyIFneoIp0ArMlyrIyVUnfgRtMWOpx448exFsd2PWU05QsD1nVcxVSrEKv/+f 954zq+yzEXSicLqN1jg46HAuXort9fWUn1vCL0LxBe+yhMB1EIEuQ1z1sgq/B0fxSMyGIkVu MB2Krgfh6owEU7UJs62VEIJr3fa2mBtV5F1PhC6vyXKUlbMppl4LEFJfgcSMwpylIKvnsh1v hZBbAGJRHj+LFpiEnUYgXsZK8QZWcjO7Prsrwn0Z9RkCEEF9ZdHOrNE31S0/FN3jgL4JrNew IrwZ8nRM9zqlycGspDbC3d1Kh0lOLsx9SmBO9ieE8Cz5utO26/UNDUF1hL9NkKOjeo7tiE95 1JsXwbQ3/UuvE41Inbp1685XHfIrmTp1alXhLeGWlf/KEE9vDsiMrG3bttMwA2vLu134PrzF 93HMoVWQi1fQQvyNKY1HLiFDGSEnfUTOcAre0qhRowUI4ZkZM5mEnffe9Y8tY8vrHqE/ipX5 QviseCQWclAOrVVWSOduiNs+xsjz79E8ZcW+H3Mxr/xtyN+M9nwG4ZkMufF8KtC+5ZMgTVm7 NHaaR4HIqGtDbNfYxt6lj2seihDIV0NpGWfv9yPfCJF55kYz8MuG9m4J8/IGvVc6+lKKjQ7+ cvNY74IdMstjXt/P77wvvx35jQxnDIaj/VsZLK99NwQMAUPAEDAEotXvBkXKQoDV/cNagf1H mJqKoNgVG+vnMMlIzQruJvwbxgoRBNSvMdfpgO9AY/kVYH8/Su/lTI2g3R6huiGmTznYqWay BEd98z0QtnewaroKYfIZmcEgPP7p+z2Ue/Idwem4GGlnxVYvAuMenHhX4vT6jEywEKhWIxB5 pjaYs2xgpTkfgnobBNfR2MX/SPpnZZOu1X3s0z9y7cDOvQMC/KvOHEv27pyjMOHKiqBZHcfc B1i5fQFC0wAMB6pPCPWnsfmfD0GKsf+/dkgCy/6sqEdA2rbi0O6tvJPuGlZ978ZpeImrN9AV gfFnfATaYUbVA03PlRCICWhMPHMa/CGmIAQ2o70nEHYz0afhgcrwfRef8uS7gb39WsyuHoHI ZaMta2n7LyoXE6eZ+ElcD46DEHAzo4ma7euTgMPxH5gEHWJudaH/u5hfO5hzOdGa5IIcLKte vbqn/UGQPcy8WMqYDWEnrvXUk4VyPsfk58ZA712fIFXFKLcimowrmF/fiYDoG34E7SF2IyCW q9nu9hMI2/3439RVOubCdyJucibWrl84Jy8Fv2W0rTIr8A2Y3zMxY6vLuPWGHGXAf+M3Nhqo 60ifqzvYNbaxd/nQ/K2PbR7ie1OQdrSErC7S74fdoJaCYX/5MYHnFnwYFlH+WcwEV6B9epa2 /g1m2SES77jyg13ZSCEfJLS5Nh2AVH2MxvBEsDz23RAwBAwBQ8AQ8EXg//X0vm/tPqkhIBOK oGPFimll0lWKT+Pl6CptgfLKUdW3DJmbsOqZ1dfkSN9ZqY9AM5Eb4XFXMCFEGgK0Fydlu+1b dnzu46pX21yyIn8Y4f6Mb9kIWWkgO+lky6/3CKBZWHXOiRC1LRD58c3re6/VYAlwwoRV+CgI 0qFAfeJde4TYNfJDYKU9kz92vmUGu2c1PBcESNofzzfFpddKOfhH+o+X+x7bNT7lyawJ07a0 gfoqzQq4ykwsVk2I8uNrkBvisEtOvYHapjnCinh6OUDrO4QNV54R3f3f6xv+Eq8zfk+jsUgH YTjqxlXf/A85gUMEohDG94uw+H8P9KzfAvN6j0zrZJKFNuyU8w0KlN733YWMfajzUPhB4s84 vxxXnxyj0XRlgkTt0Lx074Nd3TwOls7v+++Yds31e2ePlx6BkP7eX/pqrURDIFERsHmfqPDH r/Kggmn8irVclxiBkH5cF0MiLnF7U3xxTpDEIfynFA9GPAFwJCJQdkciQiUFgcpIqHfJeOyN RCTUpIlZbkh/72NmsSdDIOwRsHkfhkNo5kxhOGjW5KSPADbvC1lxj+GsnfRbHT4tRIM0BXOy JGmCY2MfPvPIWmoIGAKGgCEQfwRMExF/7C5nzpAYumkiLueQWF0JjUBcmoiErtvKD4iAaSIC wnLJX4b09/6S12oFGgKJi4DN+8TFP1612+5M8YItPDNpd51x48ZdKTvs8OxB8m+1tpIlMF9+ 2cAn/95aDw0BQ8AQMAQMAUMgXBEwEhGuI3cB7dbWmeyucx+70QwmzkM77gfjBPugnJAvoJgY SeWIzS43teSwHONDiA8Xmz+uatilprCChcWVxv8bW3rewdlY73GiHSxB3j/NxT5rO1nFnAhU DrsgVdGYEBfhbvwoymGucx+77jwZ265A7A7VklgGMXaDUlrGtqPGGofuGwLVo3fsDFQVU6su Skue0m4M5YBMELj6agfbsjbXVqOBylBcAdVPDIOHcehtRLCyvC4dOwtFsWVoM8roRvCyer6x RFwa32ugfrj24bieyrVPW8jK18D/VARy3/Ls3hAwBAwBQ8AQMAQuDwLxEgAvT9OslkuFANue dlTALPaX78dWoS+xp35vxSQgBkH7+NYh4fCTTz5pzm468fKrudj8cbWbrT7/JnZA0C1PYysD Qfg1djzydgiKLc2FvGfL0HzsONRQcQnY6Sc62J4rg12AmiPAZyIQ2kgCiU0i0N1CtpR9e+zY se+wq1AZX0LAlqUlEbxbEXzvZrZLjQ6Ax7amxdjutRWxG5axFexPbA/ahq1ZC7s63FUB1iAf txHrYSFb1/5I3Ifbe/ToUU3fCXB3FwShFGZEU9nxaBcEoacjGC6/rgTG68IlNfEXvsLB+TRC vzePFA+D+AVd2NI2Ne38mj4Uo4w7ffO6+9j64ds+dlNK5drHrkRH2OZ0se9JELkibHuaJP0i XD/taggYAoaAIWAIJFcEjEQk15H9p18KjsZ++9cSHXgcjqgn9Tpv3rwniVkwrnz58iskzOtE aG7EtqjPcw5GSGwoTYEOrUprNZgtNHsTf2Eg2oeaes/2pZ11pYxHEWbTa3VaK+DKzwr1Qy+/ /PJ1+q6DGAolpBlghX8QAnMzmVX551cUXmIO3HsuR9z/KsAWwuSdajeEoQ6xAp5W24idUE85 2cI0T7du3e7SPX25lYB3NbQyrv6x739TbY2qb7HViVCsVfgrEOLzV6xYsS0xMOpT/gDFDvBd /Se43k1g2k8ngn8tlRnoQJiOJBpzFuIp7PH/Lq0JW89mZnxmEo+jOH3oyPaiRYkH0QYhvR7f JxIE7GaXj21N8ysGAQH0jrl3uhIRuiYxEKYR3+M3NB6rGYvFaDSq+qbRPdG1byCY2w8jR46c A3lYgxPwL2yhWl5bfrIFaw36/IGC3XH94dixY5nYYjV6HJVfWi3SZqKcsR06dNhIrIFZjP/V Mr8CzxuJpH1UQeUUi4EYI9MJ8FZN46S8vkds/fBtHzERFBzQa5/idijuhDshNxEESVwOeZon guY7Lr712L0hYAgYAoaAIWAIJAwCRiISBtckUyor1lcivO703woTgf0gAae+Rxg9y8p1DSL8 FmfV+xWEsTcRAis99NBDVdQJNBf5IRwNWOX+BGFtOtqHZiINBG8br++8H4UQf7Jfv3412Uf/ AELgS5jizEW4vEdERAI/wdw6Ut4EhOERrB4XQris7Z+fgG1naEuMOAgq3/cguN21CI6dMDvq ixCZWaYzRFSuhtZhBAG4Rk2ePLm23hE9OyNalwLKS4yGKATiO6j/e4Tq4fiDFGeVvoS+xVYn eQuiGYjgzLBgwYJKO3bsyIGQ/xb920NwskbKK9Mh8Gvw6KOPfs6K/wdgVwOh3IuMrO++B0Hq lhHP4QsE4ZW+73U/adKk4mgAFuie4G31EdrHfPTRR7MgWrkgSssgP0eIhZBV33UQNO07lYUm KUasBQK45YbwbDqXKlUqaRIYpyj37K6U/w04/uyeCeJXlLmxBmE/EvyPu2B2+g7x20n07hhl KE4BhGjgqVOnUjMvCqJ5aEKgttWK/YA/Rx7uo9tAbIxdEI4saFjO88GJrR+xtc+1V1eZWTEP GxH0bpKeidKsOdyduh8h2nJZRxL1zQ5DwBAwBAwBQ8AQSBgEjEQkDK5JplSComXS6nBcDcL2 vPqdd945WwIkAu0OVrRnsZofLRAjHE9ihXyLhFvMRw7MmDEjirTeqroCzSHEpSL/n6NHj56E huEg5jZb9uzZkw/zlgysFFcmINuK5557bqmCiEEoxqGp2OmfX5GREQ7/599OERat+ENU+mLW 0wLys4pV72eUdvXq1TkQsLMhvGbVqjr9eI0Ixwf8yyA68hytzqNR2NaiRYvv6JtHImKr0zc/ Ab6Okv5ziNEOzHymQyg8+3/IVk1WyWf17dt3ubBB4zETDUJ5+p0OsnS1ThEa37IC3YNRbsx2 ds+fPz8bpmE5KWe7tAL0Ox9kaxWRwgvjB7A8UF7fdwj2kWAUrZ1AoN5LNO4Mvml0r6B3Cswm XDF9aol51TV9+vT5BTIRiYYjxjyBfO4D3wj/MvS8cePGjL169eoAyarK+G6QtgEzuUjmR3Qb mAeKrn0WQnReOwKVqXe+7YOApnLt801PNOt/4bMxB9wO6T3mYt8RgPAZ5tdPjEsdNG0D8e1o YBsI+KJm94aAIWAIGAKGwKVFIF727Je2CVZaQiKAgLcLwaqAnGZ9Ix7L1h3Bu9qrr746B+E1 F6v76107lAfBOXr1m2cJg96h1WqISXr37K4IkWkgFF0QJK9GiNvq3kuwZFV8m3uWCQz3GyUo u3dxXSElvWQ+g6ZjDPbyq3zTPv744ytxuJ1Dmb3QNBzCoXfO559/PsU3je4LFSq0w71jxXw3 TtP13XOwKyZQB10kYDQRx1mB9/qOtiPPV199VQiNwL9UBlqXtJg1bUfwzc3qfG+9o9/rELaH 6T62A8F/38qVK3MgFO/ClyCdxgl/gbJE0d5H3kxobBpAxDytT2xl6D1k5ySEJHrFn/HNQNk7 A+VBg5IPYtaN9m0k4vGL0iIgcOdkBT86v/KBe0TRokV3BSpDeWjrQEV2xu+hHxqp5eB0grkR XQbakfQQzNNEqb6geBmufbQ/lWufawOapQwQyCpooIa4d7pqbmNONU+nzNDQSLRg7txKnx6V ts03rd0bAoaAIWAIGAKGwMUjYJqIi8cwKZVwnrDEiv82hNP0mJ7EcLKFPNyI+U91BONTUVFR W1ndz+k6gglLXoTHde4Zs5/zynXfdBUhQMi/D2FyDvb9fdj1aYT7jtZhOwJ3dvesXXbki+Ce g13xNZiGJuUIJkgttbORtkB1eWSfD0H6Bu1AHwjGZ5hSVcZ0qLT77q6spmd096z454cYnKet cN/9rzikB+w7bTqG78RnCKlP6WQlvC8ampGsgG8jXkcPncEIhOpC67NswoQJFa+66qoT7GY0 BR+TbhCytAjef6Dd6YJm4jdpJ/zb5f+Mz8YeTMUi3XvqjrzmmmuiyZt7j9lVbhyqu9L2CUuX Ln1fZEDf0Hbspd6MvlvLolXJBbmJJoRKh0lYAfmJ6F4H5HMXu36tgwjlwodhD8Qhug2YxeVi fu2AaJ1zsDmXJc5/fduHn04q1z6XCf+aCvimbJbWzL1zVxEwtEWVmAutIMY5mjRpMskIhEPn klwD/hYuSclWiCFgCBgChkDYIWAkIuyGLM4GewKhb4p69ertrlSp0q9Dhw5thIOvp13AgTYn tud3Ybr0k9LyfSmr85VliiM/BvwoStauXfsv33L872XCxHEGU5UIzIoyaxUbzcZSCW2sAld2 6XGwXYqAeb18I0Q2cNpths9BNt/8Sjtr1qwr5Gfg8rkr9vsLENBfwcdi1F9//VUQ+/2BmLy0 ksM4xKI8ZkYtMKE5jRPyMlbWN9Ce8+Ir/Prrr2VoXxrtHkQ9ZfFNWBNXna7uuK74ZqxgFb6C MNMJXm3pm+fYHVc+/28ys0K7kVaO2fhE/AwRGC6nZ3wGpkKKRuCTEk3A/PP6PmOatBhzrqoy KxJRQ4CvDAFYqzRy3pb/gu4he7eA33wE7T9l0qRT7f/HjGgDOHo7NfG93JEjR7Kys5enzdAz fjNZITRbmUeltRuUylNdjE8BTJsW45ewFE1BEZlxqVxM1xpARr02yI8B068yyhPX4ds++pLK tc/lwYH/Bubrn+5ZV7QS8h+5ExIzCAwqse3rVObBQGKiTPdNZ/cXjcB5f18uukQrwBAwBAwB QyBsETBzprAduoANP2/lWamwz/+SVdnW7NgzhB2S9rMyn51din6AWMzRd8yC5iIcdsfsZwBm McflUItQGKcdvsgCZk7LEVSfWrVqlQT7OQh3feTwy/u12N1vYGW9CcLjWGzXlyLk9UfY34+g twUn6EX++TENugZH2buff/75JWqT/8Hq+QbOUSJCaBuqs+L8AALlC9jdN8CMaCDahf1oTE6z Uj2fsmLET9BuRqxe90cjE4GJzFYE6u9VfrA6/dvg+4xgPpU+dcX34DmIV2rK38TOSGN904R6 P2/evI/YbrchuD3Mqv5WVu8PyCGcccpCXA+vrcHKgoDMxF/kevwYBkHWMmNaNhvfgRXKR7tq Zs6c+ahMydDeFEYbk5f2NnRlYn62EbLyMsTyY0hfD7QaNdiZKQvj9K7TIkAa2kPSRoj04Asy nfnREydzmTqlRvvyrXZP0kmcC821JzWP5D/D+L+ueiAWBYcNG9YS4rfI1Rvo6t8+5sQw1z6l RxNVDFOsH33z3nfffe3Abj2+EdqaN6D5lW96u483AgH/vsS7NMtoCBgChoAhENYIhGSXHtY9 TB6NlxlBSGOFGU0T0gYMlCZTFVaTcyL87pAZky800hKwihuFcHlMq9K+3+K6l3kRq82eQy72 69kxjToBGTmm8lhVzyzBUvlVN4LlGe3u41ueb37f98HuVb58FbDBT6t2I0QewiTnoH8+BSfD Nn4NTtlzEcwzXUjf/Mvyf5bWRj4Ben8phFeVx3aruTDPyohp2HZfHxb/umN7lkYHAneMXZ1i OEnHlt7/vZsH0kA4AuGfRs+YvGVhTLPKWd7/u/wW0BoncmB1AAAgAElEQVRJi7Hb/9uFPEMU 4TUjugfL4+ZCsHT2/aIQ2IJp34SLKsEyh4pAyH/vQy3Q0hkCYYCAzfswGCT/JoYkmPpnsufL jkDIPy5IRA5a15LTtEyA4EgEtvye6dZlHzmrMN4IhEoi4l2BZQwVAS04jIVEhLy4EGrBli4g AiH/vQ+Y214aAuGJgM37MBw3EzTDcNDiarL+o4dIzCBNXc4UP76Y3izEOfeCdgeKC1/7Zgik MAREIGYYgUhho27dNQQMAUMgBARSvJAZAkZhl4T/8FdBJLStqYhEQNOmsOtUPBtMFOg4bfDj WaxlMwRSAgJb6KQRiJQw0tZHQ8AQMATigYCRiHiAFg5Z/lk5nACZyEV783Fq1yIzXwuHwbM2 egjgY6Or949BctkQkEmBdmHaxt+Qi/JpuWwttooMAUPAEDAEDAFDIFYE9B+7HYZASkPA5n1K G3HrrxCweW/zICUiYPM+DEfd4kSE4aBZkw0BQ8AQMAQMAUPAEDAEDIHERMBIRGKif2nqjqCY wpemKCvFEDAEDAFDwBAwBAwBQ8AQMASSCwKB1Hzl6dw7nLJfPp5cOmr9MAR8EAg0730+260h kCwRsHmfLIfVOhUEAZv3QQCyz4ZAfBFwPy45ST/OuY5TgdVOcurbPk47DIHkhoCb98mtX9Yf QyAuBGzex4WOfUuuCNi8D8ORtd16wmPQ9OPSWOl6iDMrpx2GQEpAwP5GpYRRtj76IuD+3vu+ s3tDILkjYPM+uY+w9S/RENCPS4c0EY9xruU0TQQg2JGsEXDzPll30jpnCPghYPPeDxB7TBEI 2LxPEcNsnUwMBAL9uOQT8R/OM5wnEqNRVqchkMAIBJr3CVylFW8IJDoCNu8TfQisAYmAgM37 RADdqkwZCMT140oPBNekDBislykMgbjmfQqDwrqbghCweZ+CBtu6Go2AzftoKOzGELi0CNiP 69LiaaWFBwI278NjnKyVlxYBm/eXFk8rLTwQsHkfHuMUo5UWJyIGHPZgCBgChoAhYAgYAoaA IWAIGALBEDASEQwh+24IGAKGgCFgCBgChoAhYAgYAjEQMBIRAw57MAQMAUPAEDAEDAFDwBAw BAyBYAgYiQiGkH03BAwBQ8AQMAQMAUPAEDAEDIEYCBiJiAGHPRgChoAhYAgYAoaAIWAIGAKG QDAEjEQEQ8i+GwKGgCFgCBgChoAhYAgYAoZADASMRMSAwx4MAUPAEDAEDAFDwBAwBAwBQyAY AkYigiFk3w0BQ8AQMAQMAUPAEDAEDAFDIAYCRiJiwGEPhoAhYAgYAoaAIWAIGAKGgCEQDAEj EcEQsu+GgCFgCBgChoAhYAgYAoaAIRADASMRMeCwB0PAEDAEDAFDwBAwBAwBQ8AQCIaAkYhg CNl3Q8AQMAQMAUPAEDAEDAFDwBCIgYCRiBhw2IMhYAgYAoaAIWAIGAKGgCFgCARDwEhEMITs uyFgCBgChoAhYAgYAoaAIWAIxEDASEQMOOzBEDAEDAFDwBAwBAwBQ8AQMASCIWAkIhhC9t0Q MAQMAUPAEDAEDAFDwBAwBGIgYCQiBhz2YAgYAoaAIWAIGAKGgCFgCBgCwRAwEhEMIftuCBgC hoAhYAgYAoaAIWAIGAIxEDASEQMOezAEDAFDwBAwBAwBQ8AQMAQMgWAIGIkIhpB9NwQMAUPA EDAEDAFDwBAwBAyBGAgYiYgBhz0YAoaAIWAIGAKGgCFgCBgChkAwBIxEBEPIvhsChoAhYAgY AoaAIWAIGAKGQAwEjETEgMMeDAFDwBAwBAwBQ8AQMAQMAUMgGAJGIoIhZN8NAUPAEDAEDAFD wBAwBAwBQyAGAkYiYsBhD4aAIWAIGAKGgCFgCBgChoAhEAwBIxHBELLvhoAhYAgYAoaAIWAI GAKGgCEQAwEjETHgsAdDwBAwBAwBQ8AQMAQMAUPAEAiGQLpgCex7eCNw9uzZXPQgH2dmztTh 3RtrfUpCoEqVKqnmzJlTOZn0+Sz9OMK5LXXq1LuTSZ+sG4aAIWAIGAIpGAEjEcl08CEPOeha Xc78ybSL1q1kjkClSpXUQ++f5NRVfptb6M8MyMT+5NQv64shYAgYAoZAykLAzJmS4XgjpFxL t1pyXhCB2LVrV/px48Zd+eeff2ZJhrDEu0tr1qzJ9Nlnn+VfsWKFtDl2GAIXi4B+ly3/+Z1e bFmW3xAwBAwBQ8AQSBQEjEQkCuwJV6mPBuI8LVPBggV7Zc2adfDJkydjmDWtW7cuY+nSpe+7 +uqrBz/88MPtuB987bXXPvjHH39kU0vbt29fU8++rb7pppua58iRY+D06dNlLhX0ePvttwvn ypXrmaAJfRI0aNDgDs7GepUtW7bBEuR9Pl+S20ceeaRi69atawcq7MEHH6yifrdq1eruDz/8 sNztt99+X758+Z58+umnSwVKX7Vq1Zb/+9//rvL9prTg2VH4vvDCCzf4fvO979KlS9Xrr7++ i9KSp/ShQ4e83+a+ffvS3X333fXVDmH+22+/ScN03jF37twcqr9IkSIP33rrrY0mTpyY1yX6 5ptvomrWrNmMMro1b968nv/4u3TuGqgfgdr37bff5ilXrlx7//OBBx6o7sqya6wI6PdZ95/f a6yJ7IMhYAgYAoaAIZBUETASkVRHJv7tqkvW8wiEhP09e/bkSZs27Zk333yzmG/x9evX74hp RapNmzb127Zt20tbtmzpnSlTpmNNmzZt75vO3deoUaPZsmXLbpg8efKwevXqhWTf3bJly7+/ /vrr4a6MC70iCL92yy23bL/QfLGl/+KLL/LdddddDSE3zTZs2JDHPx19bI4An4l+jgSvSW3a tFm4ZMmSt8eOHfvOlClTyvgSgv79+5dE8G6F/f7N27dvz+TKev3114u98cYbrapVq7asY8eO Pw0ZMqTNW2+9Vdh9d9fHHnusPOTjtrp16y7s1KnTj+++++7tPXr0qKbvjRs3vguCUKp79+5T CxQosAuC0NMRDJdf1zvuuKMLl9TPPPPMV4zxaYR+b+w2b94c0a5duy6nT59OTTu/pg/FKONO 37zuPrZ+xNa+woULH/nXv/612Pdcu3ZtkSxZspxwZdo1TgQ8IhFnCvtoCBgChoAhYAgkUQSM RCTRgYlPs1jVlFYg4Go9wmxFVoz/KF++/B+YLFV05Y8aNarA+vXrrx0zZsy43Llzn9T7vHnz nvzvf/87jrQr/Feta9Wq1fSvv/66btq0aa9Xr159nyvH9wphqJMnT56npam455576unb999/ n6dbt2536R6B91a0GzW0Mo5m5HmVefToUW8uIrAXrVChwr1K53sgFGsV/gqE+PwVK1Zs26xZ s/qUPwDNQG/f1f/777//JvrRTyeCfy3fMnzvEaYj9+7dm+WKK67Y4/te99KaHDx4MDOYzHzx xReL04eO3333XdGbb765DUJ6Pb5P/Pjjj292+RYvXpw/Q4YMx9OnT3/MvdP1gw8+qHnbbbdN +89//vMbGo/VaBkWo9Go6ptG97Nnz76hUaNGP4wcOXIO5GFNw4YNf/nhhx/KHz9+PPUvv/xS gz5/0LNnzzVcfzh27FimESNGXOdbhjRJpM1EOWM7dOiw8aWXXpoFmbla5lfgeWPGjBmP/vzz z+PuvffeTV27dp3+008/VfMfV5UXWz9ia1/x4sUPv/LKK3+4E3ITceONNy6HPM3zbZ/dx4lA /n9+t3Emso+GgCFgCBgChkBSQ8BIRFIbkYtrT77YsiNEVsIsZ16LFi0WcpR1q9msnl+JIL2z RIkSh33zIsgfHD9+/PcIxtpVxjtq165996xZs2ojHL+n7+6971VmNGg9qqF1GDFo0KBRaCtq y5xm9+7dGdF0FFDav//+OwqB+I6HHnroe4Tq4fhgFGeVvoS+pUuX7gx1ntK970HegmgGIjgz LFiwoNKOHTtyIOS/FRkZuWfAgAGNlFamQ7S5waOPPvo5K/4foDGogVAeTZh8y3v22WeX/fjj j18gCK/0fa/7SZMmFUcDsED37733Xn2E9jEfffTRLHxGcrHqvgzyc+Tw4cNZ9V3Hl19++Z3K Qnuj3Xeij507d+aG8GxyL6RJQLiPcs/uSvnfvPbaaz+7Z8anKOOxBmE/EiyOQ16iyRomYTuX L18eoww0AscgRANPnTqVGvJXEM1DE0zXVmMedQR/jjzcR7ehcuXKuyAcWdCwnOf3Els/Ymuf a6+uMrP65JNPGr3zzjuTfN/bfUgIxPq7DSm3JTIEDAFDwBAwBBIBASMRiQB6AlYZ0PFXgiUC ZgSr0Os6d+68DsH0JEJrcbXjwIEDmbRSHaxNmKlcx+p9CVb+/2Y1/tbY0q9cuTIHAnY2hNes WlWfOnXqayVLljzgn57tO+dodR6NwjaIzXdoKjwSgR/COgTS//mn932OiIg4SvrP8VHYgZnP dAiFZ/+PRqImq/iz+vbtuxztwRY0HjPRIJTHjCsdmoOrdYrQ+JYV6B4ToNylSpXaPX/+/Gz7 9+/PSTnbpRWAAOQDw1Xvv/9+YbQ6ywPl9X2HYB+JRiZaO4Ewv/fEiRMZfNPoHsF+/5VXXnmC 8tNj+tQS86pr+vTp8wtkIhINR4yxgfDtA98I/zL0vHHjxoy9evXqAMmqWqxYsQ3SNmCaFol5 UXQbMLsSITkLITqvHYHK1LvY2ueb/sknn/wXPhtzwO2Q73u7DwmBgL/bkHJaIkPAEDAEDAFD IJEQMBKRSMAnULUxHKZdHaz2V8IMJmP+/Pl765Qgy6qzt0KPsLlr69atBeTA69LrKk0Fdvw3 SQDXc+bMmQ8hgGMd8+bHkInyEImAzsWPP/74SgTVOZjV9MqZM+cAzIGqUedxleF7FCpUaId7 ZsV8N6SjqHsOdsUE6iDCtachQRNxHIKUXnnQduT56quvGqIReEEnmoo7MEvKNnPmzNyszvfW iUlVm2DlI/jvExmCMB3HlyCdsHniiScqZM+efR+CeqZ///vfDcBmYbByIDsnISTRK/5gmoGy dwbKhwYl33XXXdeP9mb5/fffX5T2gX6exMwrOr/yQWYiihYtuitQGdI80NaBELcBmEPVwYTt WnA6AVGMLgPtSPo0adKcxhRtb6AyYnsXqH0uLZqlDBC/Kv369fvJvbPrBSEQ8Hd7QSVYYkPA EDAEDAFD4DIjYCTiMgN+uavTCvq8efMqsGPOOAT/8Tq5/wwTotLa0hVhdRuCcnq0FTEcfl99 9dUbMUWqjpDumRYhUG+BHOxnd5+trPZPHTZsWMtVq1ZFOxG7fsk+H43AN2gH+uCQ+xn29JUx HSrtvrsrq+kZ3T0r/vkRmM/TVrjv/lecwKNNrHy/oVE5hu/EZwjeT+mEHPWdMWPGSHY32obd eQ+dkIBhvnkC3ePHsGzChAkVr7rqqhP0dwq+Id1Y1U+L4P3HnXfe2QXNxG/STgTK6/sOn409 aHAi3Tvqjrzmmmu2uWd3xewqNw7VXWn7hKVLl74vMqBvaDv2Um9G361lIXW5WPHf6vLqCkks ID8R944drXax09Y6iFAuCNweiEN0GzBry8WY7oBknXHpg11ja5/LN3DgwArMj82+Zlfum10N AUPAEDAEDAFDIHkiYCQieY5rdK9wer0BP4OT2LX/jg/CWp1oE35nhfoIOwyV1O5KBPX6dejQ oY3QMHh2/jjz5iT9XfgFBFxZxp9hKgL7ERyom0VX9M8Nvg3lMTNqgQnNaQjLMvwANkBWzjPX +PXXX8vImVq7B+FnURbfhDUqgvsrYttC1b8u/2eceldgvlRB2hOd+HC0xSHZc+z2TxvXs8ys 0G6klWM2PhE/QwSGy+kZ7c1USNEIdrDKHld+9w3TpMVoBarKrEjboSLAV4YArNV3OW/LzEz3 rODfgsnQfEjXnzJp0qn2/2NGtAEcvZ2a+F7uyJEjWdlNy9Nm6HnRokVZITRbGbvS2g1K5aku aZcwbVqMxmQpmoIiMuNSuYMHD26AJsNrg/wYMP0qozxxHbG1z+Vh96gbmEN/ume7GgKGgCFg CBgChkDyR8BIRDIf488//7wyAt4fvt3EnCVV2bJlFyNseiZN+Ap8SRyGg+weNASTnUFsbzqQ +6UQizm++dw9aU4jjI6RgzOr0CXce10RShesXr26GLsjDWQl/zH5FJBmvm8a3UNijrN63Z9V 9wF6RqD+XlfMka6B5Nyj+ws9EMynouHIgu/Bc6zED8J8KAs7I3nlXmhZaG8+wrQoE+ZeDyvG AtvBNsCZvC0EqR34bAilPAjITMzAjuLHMAgNxlNoFhbjO7BCeWlXTb5X1T3am8L4eDQEj2Hu hBA9qm+QuY8hAPW0ExX3rXEi/6/TIkAa2mO2lE/aIrRD0yENPTEhe5a4Fw+hfflWuyeJJOJQ /2WTJk2ehDwMhLTlR1P0pcqm3ILSKOk+riOu9ikfpmjFwGRdXGXYN0PAEDAEDAFDwBBIXgiY LW54jKfMd4KOFeY6lUlXKb5dktkMK9s52YFohzNjik9Z2OCnZQU+CgH8EILzebs48a59mTJl 1qAJmcsqeSatuMennkB5zpw5kwptRG59I65EQN+BQPlie6fyENRzYZ6VkfgK2xHSz9s5Kra8 7r20KzhOH2NXpxhO0u57sKtM0oSnNBCOQATKw65NWRjDrBCe80yt5LfA1rzSYoQU1yNQ+Zf7 HU7z8KYR3S93vYlQ3++Y6M1NhHqtyqSJQEh/75Nm061VhkC8EbB5H2/oEi9jUME08ZpmNfsg ENKP62JJhE99CXrrSAS2/AHNpRK0cis8bBAwEhE2Q2UNvbQIhPT3/tJWaaUZAomOgM37RB+C C29AugvPYjkMgYtDANObhZgxXdDuQBdXo+U2BAwBQ8AQMAQMAUPAELiUCBiJuJRoWlkhIcC2 r4tCSmiJDAFDwBAwBAwBQ8AQMASSJALmWJ0kh8UaZQiEhgBRrXOya1Re7eYUWg5LZQgYAoaA IWAIGAKGwMUjYCTi4jFM8iUQ9OwVtnkdRqTq13Sy/eoQApt1lcNvfBsvh+N77723loLSxbeM UPOxc9Tgzz77LH+o6YOlI1r3tSVKlOgEBt3Yyai2+qJDW7ES6bpukSJFuhMbop3S+ZfF9q8V lcf3fXzK++OPP7IpOnXhwoV71KlTpwkB5qK3jdV2rNoRCkfsbsSpqKd2+dZHROuM7IbUnB2c OrEdbj12s6rG/WN6dk7lvumT+z1xMe7gbJzc+2n9MwQMAUPAEDAEkhICCS4AJqXOpuS2EGX5 DYTRx3QihD6rCNadO3eO11aqwlGC7SeffNKcLVwTfAUcofo1dlo6b8eh+IynAuSxDe0DCOlL Hn300SnExCjNbkYNVVaPHj0qEweiArE0piKULiJIXvvRo0dfpW9ffPFFPqVjG9lm4JdH73TE t7wWLVq0Zavds2x/O4Htbk8Rk6Ori5tBZO0uBABM3b9//6+J/1CMXaHuPFdbqlSKq1GrVq3O xLCYt2zZsvfuv//+uS+99NKMOXPmvPHcc89NIpBgG7ZczeTS29UQMAQMAUPAEDAEDIGEQMBI REKgmsTLJIbDSQTRBRAAb/VbhAAhvRFRo5/nHEzwsoZudZ5V+YenT5+ey3VJzwpSxhatnfWO FftHFcSM4GYRbNXaGq3BIKIy9yAGQiGXRzEWiMhc3T37XhU1W9+GDx9e5I033ijK6vuDbGP6 YqlSpTo6YZhIzs2p8wqlod1NtXKverSKz/ar0dGYtXI/ceLEvL7la8VeUbTdu5dffrkcfVil 4HFdu3ZdhxA+DSLhxcsgVkNFhPsZBHFbJb8N4iwsJ6aCF4wNYT5y7969WYj5sMeVpWt8ytNW rOvXry+KdmUChOHv8ePHf7Nv377c0kCgVbiRQH5HCUw3Dk3PJto4HZOlahoj1de2bdvb0YT8 qLYTQbsF8SaqP/XUU3XZlrfDli1bshDMbhE43ai0RCXPQpTxlozpEOJP9H7nnXe8MYntPeN+ a/v27WsIR80FYS1io7L8D3C7iXnUT6eC8uk78UauJkL24wSfy6HnBx98sIo0OrrXO2KP3Kf5 Bf4Pgdt1ek/gwvx6T1yLBopxgYbofjC/qlChQo989NFHqaQZUrpgY680OuKah+dSnPtXc5gt iB8C65elwVGd+iKNkLR00t5FRUX1IY6Gp42Kq53ETXnOtVNE05XlW5/dGwKGgCFgCBgCyQ2B gAJCcuuk9SdVKsyOPEFfQpYiJU+bNq0qQeiWChuiGtcgPkTxKVOmvIIA9CYCbCVW46voG+nz E3QtWtvA81V6RrMxXt8R/EflyZPn5G233daK91kQJEcgEP7M9pwPKe6E0iCQncaM6rTu3TFz 5swrEHzvUlA4SEpFIlsffv755+9hJX3apEmTXoHEpEaYr6n0mzZtKoiQHUGshiyYYNWCQBz9 +uuvhyIY70CbEG3GQh0n06ZNq23iog/MhsrhL5DevUAYT+PbFtocATmIkrDM6n9atdWlRVuT YePGjfn0jFZi2Y8//vgFxGKl+65rfMo7ceKECEFqF/OBAHlpqTsdAmw+iFMeguVtcnVAzHYR JyILWocsekesh2vRXiyeP39+NoL6FWasPsWcahrtLAJ26xB8D4JTNqWFXNyMluME0cGHsCPW b0Sebh3Xe2JJRCEs38HYf8/2u8MhG8WJQB4jmKDyK6I4xKcB2H/+1ltvfcC8qYEWp6JIDyRr L6SwCaQr6wcffHA3JOkX5aHumsQeOYCm5yUC9kl7co+IKuOaYenSpeV3796d7dVXX/2QtueD yDxCgLwfIDGpxo0b10QxLoKNverQEdc8PJfi3L+YiXWE8GzndzCE60760kZfmjZt2hESvIW+ 97/vvvumgGEnYR1XO5mnn7p2SrvE76k7Y/hI7969y8ZGwnzbYveGgCFgCBgChkA4IhAtHIZj 463NoSPw+OOP9+SMzoBfxH6Ez5l6QSCz6gj+M2+++eZ9ekYQm6VVeW4DRqxWGtJ6K/Ks9O+S xgASUgEyMAAtwR5WY7dPmDDhJgKFlWAF+XdW3Kcrjw75D6ClqI12oCgC8jy+DWMFfLt8K44c OZIN4S0vK9iriaY9GtOdaA3CudypUtHuAzgST1HUbUyMvmBVe6BW6SEGZ2Xe49LFdu3Zs+ci fBEaP/HEE+WIQL0doVk+EWkQEtMhtC7guQ5EYQ8mS9khQTciUK6JrSy9j095aHEOEc17A6vX jRBef2a1u9qpU6fSEaQvA9qESPp4zNWJJkFjchaNTQauh0R01Fc0FuVYwV+udGB9DdGoV4iU sOJfDCH/B70nT04IkqdtYlV/FnB5BCi298pTpUqVOfh9rNY9Wp7vmAclBg0atETP7oBo1oSU zMIszKt/8uTJM/HFKM/3eRDU8cyJfmi2chEVfaEri4jdfzIvNhF07wR92sLcyMf4qk+p6M8x hPkv1C/auWLnzp2R0gRBRFOhudhPO6KULrax1zcdMi2Lax6eS+VF6o6CmBYm7XAFVWTMv0Xw Pw55zQNhKQLReRtNyDG0JQs//fTT2mh7SqJR2RZbO1UuBMhrJxh/x1yagSlaWXCqg/lbU8jy bDD8GS3LYdcGuxoChoAhYAgYAuGOgGkiwn0EQ2w/QttQhPQeOmfMmNGfCLlnunXr1kDZMWvK hQ/AelcUZh67EOqzumffKwHtzpszrIbn5n1qyMcTCLIv6ERIuwYzJ29F3OVv1qxZfVZnHyLY 3CqE9GfQKowXgdB3hMUzCNRjMEeqi2D3CivCzVjFTevyumuuXLl2iUDokECqlV+0EjFMmDD1 qYp25Gmd9DcLfXtE99J8KII25jcTITJ3kK4zQvMSCaoqSxG0Wcnf+fDDD3d99913b4Fs/KLV ald3oGt8y6Ou8ZCUIqyI95KgjyZmHeRihzQHkAlP66D6EKjT08fTmC55cTUYN0/Twor/EaUT gQKz8mh0drz++uvFtm3bloeV/h3KO3To0CloMSIodwhCcU+0A55ZWmzvlYd0Xl7dE8tjNwSx qO59D7QGeb766quGbqzHjBlzBxodb6wVfZy2/gIZuob2fOvySWMDueiSOXPmlyAfzd17XdEs HRCB0D3XU6zib9W9Dvp+Bo2QN+DBxj7Uebh48eLIHDly7HZR2WXeB4ZThA/HdhGIc7WnSsW8 gXPt8voWajsV1RySNw9CMgwTspHz5s0rwRgM1li5cu1qCBgChoAhYAiEOwLnCYTh3iFrf2AE 2J3pjFaqdUpbwPkTJjD5lRrBeSsCbU6XE5v9vKxsr3PPMi3SvcxKEEo9EyX3TVfMio5K2Fu7 du2zCP5P6UQr8DRaiNm+6Vq2bLmE1diFrJzfAqG4U1uTuu8IxGkxYVmHQD1w1KhRr2Hykx5S 0dh9d1fq91av9cxKclZIQnbKPOC+64oJzV+Yz4zViXnSMXwqJuoek5tfZWKF2c9S1cOK8QBI xN8Iih5RoM3ZEI4/g0D1ZZX8VdoQgaYjThIRn/Jk4oIt/mnwHIopU1/MjUZDFqLq1au3DdKy Ryvxrj8IxrkQdndo3PQOgrcGc6YSaFIW85ga35EHMKeZDvYFIIoNMS8a6/IikJ+hfW9h0tUX R/KFEJd29CsitvfKR3uitT+Y8eSHYMXAVmlouzD9zI01Jm59IaYj9U1mTPgbVJEw3qdPn3p6 x5ilBv/7cBCfA9noQ3tG6L07RGjdfVzXYGMf6jzEb2Q78yab2qX6pAWDOFbiN7GV+xy+wj6k LAry4/0WQm2nypRmC01KJcamFSQ9R5MmTSY5oqTvdhgChoAhYAgYAuGOgJGIcB/BeLYfwfmQ E8rkG4FZUWXFGpCdOjv9lKxdu/ZfKppV1T0I1p5zKX4BMnHyDkiDrmdYpY1A+NqNsLnvmWee 8b4rdgEr9P0wcfFIAv4TReR0C3HYxirwh3x/npX0w9jQPywnbJkWSRhHoO8jJ2jIxpZGjRot QKA9j7AgYF+JPb7np4APRWWE1W2smB9RYzCdqSYabZUAACAASURBVCCnZVbC92FmtEYn5Ok0 Wo21upfWA5OrvGgketPu9DrRONSpW7fufOVnd6PapL1b93Imx7SqBGYuf+o5tiM+5dGms/S9 O34B16tcNCLV0YRswqH5KPUtlUmNnKzlsD548OAGELq1rn5IwmTMa27FDyEfpkuj8ZF4B83K Zvwj/g25+BLtjucgrPQ4ibcDI62CH8I86FcRPYTb9LG9Vx4ITRmRHJENyiqLaZdnzoVZTmH5 0igNjsgrGNsKmi86mSttwdcjDPSrKd//xCzpHQjQze+//35B2paZMrNA4pZKkEYbVVnlXOgR 19irrGDzEIG+nIgnhGov83o3GpFyyterV6+q+LuUwsxq/z/vy+q95jFalyicyKPx1/u4Ds0b 5tedkMFBmAlWgrBOZZ4NxGci2qQvrvz2zRAwBAwBQ8AQCBcEzCciXEbqErcTE47DCKn5ZUeO r8RcBOzumHEMYOX+OIL5TgSr5aoSW/bZmGS0hkjUw8xkIzvReL4QEgZZFV/Oqu5TlDEQG/BP sMW/H+1CXbQKV2Da9J0cbVUGOyHVgbTscc/4IhzEfGQyguVU8pWBwNTC1j9NyZIll7IzzhBM c9azIpzlySef/Fz5fQ/q343QfT8r4WnwI0iP4++H7jtO3h0Qel/ljNX2HH+LdQjia/EneIQ6 srHD01r65zn/Igj/zPd22vWJFegrEegnOD8RV4f/Nb7l4Q8xBTv6ZrT5BDhkQjszXGWjjdiN RuZLVq6f1FjID4CV/dddvSIE+CC8DdFqhS/FGcZkGzikkRmTdnWCYExyacF7Jrb490OUNqNV yYjPh2eXH9t75cOc6jgr+v0ZjwjGbCvE4Xu9p9yamCId7dChw0YIxVQE5a7U/Zy0VKTfxPex EJ7ikLiStPc5mXnVr19/Go7JrTFdexkzpzmQ1T5oVI4wb9ZCmjZgytUE5+U5Kj+UI66xV37a fjaueYh5VXvMxkaA4Wrm0NcQqw6QnMbgfAIsR6kMOVPjt9MebVhDtCY5IL6Tqfe0voVykL8d /VuPb4S2Jd4VSh5LYwgYAoaAIWAIhCMCZqMbHqMme/GgY4VfglZ4K8WnSzLtYOU0CoHwmOza fcvAXCUCgTutVsp93+teTtWslHvvZcLBCnkUJjb7L9SJVPVLCNSWrZh/pJdztn9daDpKEZui zsqVK4ezu1OkBO5/NCL+SYM+S/OBSUtaCbv+iXEmzoXAq1XpU/7fYnuOT3mQhzSsgEcGEjZl OoaWISuC+O7Y6hTeEIq8mKMd0yp8ICxEEhHqcxGHYptvfwK9B4v2CNhr5BtC/Zn854FvO6Sx coHtArXfN6271/aptPWEfA403phgZY6L8GEOhIXWiO7KfyFjH+o8lAmdMPbvp+Y745Jbmwbg AH/CtT+Uq5vHoaT1SfM7plJzfZ7tNmUjENLf+5QNkfU+GSJg8z4MBzWoYBqGfUqOTQ7px3Ux JCIcQHOCJCZPb4ZDe8OtjY5EsL3rT0mh7YFIRDIdeyMRSWHCJZ02hPT3Puk011piCFwSBGze XxIYL28hZs50efG22i4CAVaMt2OjHrL5y0VUlSKzsm3rQvxLvF2gkhoANvZJbUSsPYaAIWAI GAIpHQHTRITHDAiJoSd3TUR4DJW18lIh4KuJuFRlJtFyTBORRAcmkZoV0t/7RGqbVWsIJBQC Nu8TCtkELNd2Z0pAcK1oQ+ByIiD/FJzU88s/43LWa3UZAoaAIWAIGAKGQMpDwEhEChhzdp95 hW1Fh7Gj0ms62fFnCLsgdWULzyvi23051rLLTy0cri/rHGKHobuJN9Aovu32z0fMgmwElWup HZlwTm4i51+XRtG1cRDvBFbdWrdurcjW7pN3xWE5h777voxPeYpLwG5NdYlJ0Z3IyO1UrytT TsJEE6+PU/uD7ITVXHW6b+7KDlFV9J1dne7Gn6Ecwebuw0H+SXbLKuXS+F7ZyrQl0ZSjt4KN q345GbMFbhNtxcv1rtGjR0fn8y0zlHYqfajlsX1tDpzsU4HJwxpvdvPytgv2rdPuDQFDwBAw BAwBQyDxELisAmDiddNqJlbDGwiLj+lky81niQKcsXPnzvfEFxkJnuyU1JydlC6rXw3bsU4h GvAl23OfmAlt2dXoLDEWJrA71Cl2MeqqXZO0exFxBB4gpsASgt5N+eWXX0qzY1RD4aWdk9jK 82a2/7yfHYaK+mIYn/KIn1B59uzZFR566KGpRNdeRDyO9k5Ypz13IVCXwrRnKtuT7kKg7ulL 3NhBqDkCfCYC5Y0El0nEjFhIwLe3x44d+w47ZZVhp6UbXPvY/rQkBKIVcUBuZnvfTO59XPWz leu969evzw8G30CYNrdv3/5xESWX112DtdOlC7U8thzuojw403+VNm3a02zp296VYVdDwBAw BAwBQ8AQSHwEjEQk/hhc9hYQI+IkK/oLIADeqrsIAdt0NiJg3POcgxHgGrpVd60EK4CWa6Se tRrOVqCd9Y6V80cVFE0rzDi/ts6WLdsgrVq/9957hVwehO8GnTp1qu6e47qyX/+1CKo1CPSW RSvmtGcIq+q9IQ9eeQSEq/Tyyy97QcLYKrSnIg2zbWgfgtf1J66EFyRM5QeqE0G8ErEBooVq BaZDQC6KCdAEolz/TRC7bxDIcyvQm+qgr6uIcTGHmALrCDg2DSLhBdOjrxnZJSiKSNJezAzX n/iWx5ayFSEfMwiGtor2LWLb0+VoCspou1DqrAEh+EDB8rj+APnLxLan16lOBYAjlkHmMWPG zCRfcbQZHdl2tSixLdogfNfj+0SC/N3s2kegv/yKA4E26ph7p2ts9WsOECjuBsr/BKKxhgjk vxNEbQNkpYxv/mDtdGlDLU8BBykzE0HsUikuBUH5ZjHHrpaZloicrxbFlW1XQ8AQMAQMAUPA ELi8CBiJuLx4J1ptrF57gr6EfUUenjZtWlVFqlaDCKpWg0i+xVm5fgUB7U0iDVdiVbyKvpE+ P4JqtLaB56v0jGZjvL4TLG0UQclOElyuFe+zILSOwPzmZwT2h5xtPuZUpxFcYw3YJRIikkE5 Tw0YMKANROQYQcpuRuA9QQTlIewa9Fu/fv1aq75Nmzbl4oz8574wAn9VAoO9R/6vCSbWWnv/ 61ugOuljIchJtFkMAdi0sUBqAqB5dkpEyE5LkLV0mDTlg1il8W0zfYvYu3dvlLQUiitAHIEv EOxnqC53xLc86kyr9rpyIAoZNm7cmI+IyZG04bhvwDsFAoSsRCntpEmTiqMBWKB7SFt9yMUY IkXPIkKyoiYvw8TpCH3Kqu86CAT4ndqtgG/n3pz7N7b6eZ/666+/fkmRnJVSGhiC2l2NudRq 3/zB2unShloepmXHwHogGwWk0lyF4DUhsN1qRSaX1oj52p3nR4h8XVbj4cq3qyFgCBgChoAh YAhcPgSihcPLV6XVlBgIEJW6J2d01fhF7Mf2fqZeEGSuOoL/TCesQghmaXWaT7Fup0pabxVe Abnk0IuAXgGNxQD8CvawWrydCMw3IdSW0Oo1K/0BzY8UWO7555+vCWmpiqnOeojHV5gQLUdw Plu9evUWCJKepkSCMRGAV6qt/ger998o2JlO7OYrozkohkZiRWx1+uZHm3KIYGIbWMFvhLnO z2hBqhH9OR1EJAMEYRG+Eo2feOKJckTY3o4WQD4RaWT7jxAeMABZfMuTVojy66CB2IOpWXbI 141oc9YsXLgwEiLlBfJz7Ubjsg9iEKHnzZs350bAXjh//vxsaJVyokHaLq0ApCwf2pNVRGMu TOyH5S5vbNfY6tc4YF61S/kgE1FoY+6/4YYblmHGtc23rGDtdGlDLc+lh5SlInJ6B/qWh8CC 30tjxjz4jjGYgWlWWQhvHbQtTSFMs4nM7UXjdnntaggYAoaAIWAIGAIJi4Ct4iUsvkmmdAT6 oURo7qFzxowZ/YmQe6Zbt24N1ECEtFwIi+tdY4sVK7YLzUX0CrZ7ryurw+fNGUhAbt6nhnw8 gYD9gk60BdcgzJ5nO+/K+vbbb/PgqDtgx44dV3D/MlGo38YXYJkETaUZOnToFATiCATzITJb ws4/2qTKlaErZGaHe8asaQ++BUXcs64yvULD8bRONAyVIDcNdC8TKH3HZ2A8QnuR5s2b9xJp gcyso84dimSNf8FEVvjvQCDvXKVKlSWYVu2/8sorAxIIlaUjPuUpQjTt2YlpVtd33333FsjL L5gNbae+k6y0ZzlX8rl/hQkRwj3Bnn7sA7ccmHsdZ5U/nQgOpKdC9uzZ96HJyIS2qAGr9gt9 8we6j61+l5YybgKfxxmv3yAMH7j37hqsnS6duwYrz6XLmDFjKvo0EJI7AMJZB62X53CuyNuY VM1DMzIMM7eR8+bNK8GYDRbJcHntaggYAoaAIWAIGAIJi8B5AmHCVmelJzACngAeqA52ZzqD cO+d0hZw/oSgmV9pEWC3IkjndPkwl8mLoLrOPbMC7wlnMmdBiD1v+1CE2KOYmZzByfhZhN6n dOLo+zRaiNmuDP8rQvp+tAffkacYTrMtMGMq6SsEQibO0Ka3cOLti3PzQgTddqy8eyvwvmXJ P8E9qz/05YB71pWdlQ5jCjVWJ31ahQ/HH/88j5MpDILqafo1lNX9vphOjd65c2cUq97bqDvz Aw88sFRmNQiyAyARfyO0b/ct2/8+vuWBVbavvvrqM4hbX/r4KivwEfhjbAejvWCSUW1xde3Z sycXuzRt1TOkbRmkqCLalBMI+VPoWzfSp0WL88edd97ZBc3Eb9JOuLyxXWOrX+kZm6qYTdVE y/OyfDIY5/OKCdZO3wyhlMcOUwUqVqzY1uWTNuTqq69eB2GKJpIiTPJxQRPVChKco0mTJpMc AXX5wuga6+82jPpgTTUEDAFDwBBIYQicLxGkMACSWXdj2LrH1TcE4kMQggxKI98IzH8qI6Cm k/Mru/eUxKn1L31j1XcPAq63AoymwHMs1vt/hMkz2N9HQEh2sxq9D2de7zs28jkRLPvh5Ov5 H7AiXgRfiauVzx1a0Z88efKkLVu29EcY/p0V/wY4fA/QdqZoHbLiaNwOUyetMB/CafhXkRQE x/Quv7tizlJe9zK3oaxCCJwe+XF14vx8Sk7JOrnfh1Zjp+7lKAyxOss2td1x3L1eZaBxqE67 NuFLcBTTrLyYyfSmf+l1oiGow0r8fKWL7YhveTiL127atOndKldO7PhtlGC1/k/5XtCeDeBa Td8QmMuhScpav379nXp+5JFHVmN+lRaNSS3w+xlCNlyO4Pg+TEUjMwL/Bc8cTGnjOmKrX6QO gf7uwYMHj2Ec9st3RafIkspTezBjyxqsnS5dqOVBfLYyB0pDqP6vvTuBs6n+/zhOGDOWaAZp oqxFsu+yRWhRIUop2lFo3yV+tP1atGjT9mv5qwfJksoSSVRCpCJ7JPuanfB/f27OPI47987c mTvjzJn7uo/H6dzlnO/3e57fM/p+zvf7PSdQbOu1UrBYVkObFpqP6uVy9dQMVg9FfQV6k1Q/ g0aNGhVyyFxax52Dfov47zYHlZmiIIAAAgjEuABzInLXCXDcWPW0Dk0N9j1qECbbrUw1V+JH Ndz6qIE9UBN8D9jkXTXYAmPpdUX7Ww0ZuUaBRGtNZl2joTKBuRB21VfDnhbrqvhDSmOQxqh/ qOcS3KQGbCvNKThFgcFkNdDXWhnUsD1fQcs257O7XErvsCZEz7XFAg31XrTQOP8rtO10jXO/ SY33v3RlPl7j9kOOeVeDu5LSrmd56vank7t27bouvTyd/O0YNB9i4rPPPttZQ2UOqnGcoCv7 L9vvevbCqldffXVljRo17lQPQVFN9l0ph++cfUOtM5uegppZyq+7PatCDf/TFECMceanaBja B7LoV6xYsWaacF1YJm9aj5KTv4byvKcApJ3qoq+u1q9XoPS3elZKqWelsIZHTXG2S2sdLn/1 PCTLvpB6D+7TkpKE8hunO1lNUZ310PCvYQowlqdVTmc79XDtjSQ9C440mX6qzqVLFcQ+pozz Krj8QnNG9ihIvFXH+ofmRjxn82BSCuXvNxH/3fr7MCk9AggggEBuEmAMsT9q04Y7RFRXmpvQ UdsGhill5NDUK5FXV3ZLaWjSfruy7N5XV4Hj1JDOZ1fo3d/be5tUrWFCge9tiInu8FSqevXq O/VMgT3B20b62cqiCcVHLcDRnIYk3YFog42DD95fzw94QbctfUQN5vxqzO5Lb75C8P7OZ7uy rrsWJYZqlNpQIl39z6eelV3O9umtM5ueJrMnqVdoZ/CxOnVjPRDuAMJdDutB0ryBJM0xiVcw tTE4Dfe24d6Hyz/c9sHfR1LO4H3S+qw7bg1r3779YJuo72znnBvO51ywXqf5SWNywXFwCFkn EPG/91mXJSkh4LkA573nVZDxAkTUMM14suyRxQIR/3EpiLAnGnfVkut7mZwgIpqAJYvrieSy UEBzHtTBMaxPFiaZ05KywPhjBRHHBe05rZCU54QLRPzv/QkvGRkikH0CnPfZZ5ttKTMnItto vUn4WIPEnl+Q6sq9NyXKvlz1vIKJGpaV5t2Ssi93UkYgKgH7+5xGABGVITsjgAACCHgokOuv Vnto61nWapgsU4+E3fq0lZYMD23yrOAZzFh3DJqYwV3YHIGcIGDzdgggckJNUAYEEEAAgUwL EERkmi5n73jsCucYBRN2W8zSWuw2oQxfy9nVRulcAnquh30K/Mf1tV/fWle93YVpg/42t/r1 ICg3AggggAACCPhLwBogvBDIbQLldEBxaRwU530aOPyUawU473Nt1XJgaQhw3qeBw08IRCPA H1c0euybUwUOqGB2bg/XEnjeR1BBOe+DQPgYEwKc9zFRzRxkkADnfRAIHxHIKgH+uLJKknRy ksAOFcbO7UNa7Ba6q7Tcq8WG4NmL8/5fB/4bWwKc97FV3xztvwKc9z48Exgj749K44/LH/VE KaMX2K0kimixf5vsvOffKCHwiikBzvuYqm4O9pgA5z2nAgLZJEAQkU2wJOupQHBPxEqV5h4t 9ER4Wi1k7rEA/957XAFk74kA570n7GQaCwL8ccVCLcfeMdqcCLtj0RtamBMRe/XPEYcW4N/7 0C58m7sFOO9zd/1ydB4K8MflIT5ZZ5tAOaXM3ZmyjZeEfSrAv/c+rTiKHZUA531UfOyMQHgB /rjC2/BL7hXgvM+9dcuRhRfgvA9vwy+5V4Dz3od1e5IPy0yREUAAAQQQQAABBBBAwEMBgggP 8ckaAQQQQAABBBBAAAE/ChBE+LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCAAAIIIIAAAgj4 UYAgwo+1RpkRQAABBBBAAAEEEPBQgCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqMAAIIIIAA AggggICHAgQRHuKTNQIIIIAAAggggAACfhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCfrBFA AAEEEEAAAQQQ8KMAQYQfa40yI4AAAggggAACCCDgoQBBhIf4ZI0AAggggAACCCCAgB8FCCL8 WGuUGQEEEEAAAQQQQAABDwUIIjzEJ2sEEEAAAQQQQAABBPwoQBDhx1qjzAgggAACCCCAAAII eChAEOEhPlkjgAACCCCAAAIIIOBHAYIIP9YaZUYAAQQQQAABBBBAwEMBgggP8ckaAQQQQAAB BBBAAAE/ChBE+LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCAAAIIIIAAAgj4UYAgwo+1RpkR QAABBBBAAAEEEPBQgCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqMAAIIIIAAAggggICHAgQR HuKTNQIIIIAAAggggAACfhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCfrBFAAAEEEEAAAQQQ 8KMAQYQfa40yI4AAAggggAACCCDgoQBBhIf4ZI0AAggggAACCCCAgB8FCCL8WGuUGQEEEEAA AQQQQAABDwUIIjzEJ2sEEEAAAQQQQAABBPwoQBDhx1qjzAgggAACCCCAAAIIeChAEOEhPlkj gAACCCCAAAIIIOBHAYIIP9YaZUYAAQQQQAABBBBAwEMBgggP8ckaAQQQQAABBBBAAAE/ChBE +LHWKDMCCCCAAAIIIIAAAh4KEER4iE/WCCCAAAIIIIAAAgj4UYAgwo+1RpkRQAABBBBAAAEE EPBQgCDCQ3yyRgABBBBAAAEEEEDAjwIEEX6sNcqMAAIIIIAAAggggICHAgQRHuKTNQIIIIAA AggggAACfhQgiPBjrVFmBBBAAAEEEEAAAQQ8FCCI8BCfrBFAAAEEEEAAAQQQ8KMAQYQfa40y I4AAAggggAACCCDgoUB+D/MmawQQQCBbBI4ePZqkhEtrKaQlb7ZkQqIIZINAw4YN88yePbtB hEkf1XZ7tWzImzfv1gj3YTMEEEAgSwQIIrKEkUQQQCAnCCh4KKZytNKSnBPKQxkQyKhA/fr1 bZfAfzKyr879ddp+moKJnRnZj20RQACBzAownCmzcuyHAAI5SkCNqMoqUFctGQogtmzZUmDU qFGn/fbbb4Vz1AF5XJgVK1YkjBw5MnnJkiXWm8Mr5wvYed/12N9Bzi8tJUQAAd8LEET4vgo5 AAQQcPVApOpdPeOMM+4qUqTIkEOHDh03rGnVqlXxNWrUuL5MmTJD+vbt213vh1SuXPm2+fPn FzXRHj16NLfPbt3zzjuvS7FixQZNnTrVhkul+3r99dfLJyUlPZruhq4N2rZte5mWS+2rokWL DrGGvOvnLHl755131rvmmmtahkrstttua2jHffXVV3f63//+V/uSSy65vnTp0g888sgj1UNt 36hRo64fffTR6e7fbFt53mi+Tz75ZBX3b+73PXv2bHT22Wf3tG21T43du3cH/p+0Y8eO/J06 dWpj5TDzH374wXqYUr1+/PHHYpZ/hQoV+l500UXtx48ff6qz0eeff16qefPmnZVG7y5durQO rn9nO2cd6jhCle+LL74oWbt27R7Byy233NLEScvDtZ3/rY79PXhYDLJGAIFYECCIiIVa5hgR yP0CrXSIqQIIa+xv27atZL58+Y689NJLldwMbdq0uVFDP/KsXbu2/4YNG55et27d/QkJCfuv uOKKHu7tnPfNmjXrvGjRoipffvnl0NatW0c0/rxr165/fvbZZy87aWR0rYbwcxdeeOHGjO4X bvtPP/20dIcOHdopuOm8evXqksHb6Ri7qAGfoON8TV4TunXrtuCXX355/eOPPx4+ceLEmu6A YMCAAeeq4X21xu833bhxY4KT1gsvvFDpxRdfvLpx48aLbrzxxplPPPFEt1dffbW887uzvuee e+oo+Li4VatWC26++eZv3nzzzUv69evX2H6/9NJLOyhAqN6nT59JZcuW3aIA4Q4nwHD2t/Vl l13WU6u8jz766DjV8WE1+gN199dff8V179695+HDh/OqnJ/pGCopjcvd+zrvwx1HuPKVL19+ 7wUXXLDQvaxcubJC4cKFDzpperwOBBIel4HsEUAgBgQIImKgkjlEBHKzgK66Wq9AyKv1aszW 0xXj+XXq1JmvIUv1HIf333+/7B9//FF5xIgRo0qUKHHIvj/11FMPvfvuu6O07ZLgq9YtWrS4 4vfffz/rq6++eqFJkyY7nHTcawUM55csWfIR66m48sorW9tvU6ZMKdm7d+8O9l4N3ovUu9HM royrZ+RxS3Pfvn2Bf4PVYK9Yt27d62w790uNYrsKf4oa8cn16tW7tnPnzm2U/kD1DNzvvvp/ 0003nafj6G+LGv4t3Gm436sxnbh9+/bCp5xyyjb39/beek127dpVSCbTn3rqqao6hhsnT55c sWnTpt3USG+t38d/8MEHTZ39Fi5cmFywYMEDBQoU2O98Z+t33nmn+cUXX/zVG2+88YN6PJar l2GhejQaubex999++22V9u3bf/3aa6/NVvCwol27dt99/fXXdQ4cOJD3u+++a6ZjfueOO+5Y ofXX+/fvTxg2bNhZ7jSsJ0nbJiidj2+44YY1Tz/99AwFM2Vs+JU8z4mPj983a9asUdddd93a Xr16TZ05c2bj4Hq19MIdR7jyVa1adc8zzzwz31kU3MSdc845ixU8zXWXz+P3ycf+LjwuBtkj gEBuFiCIyM21y7EhEBsCpcMdphqR9TUsZ+5VV121QK9aztVsXT0/TQ3pzdWqVdvj3lcN+V2f fPLJFDWM7a43gVfLli07zZgxo6Uax2/Z78737rUNo1GvR2P1OgwbPHjw++qtaGnDabZu3Rqv no6ytu2ff/5ZSg3iy26//fYpalS/rDkYVXWVvpr9lj9//iPK8x97735p3zPUMxCnpeBPP/1U f9OmTcXUyH81MTFx28CBA9vbtjZ0SGVue/fdd4/WFf931GPQTI3ylIDJnd5jjz226JtvvvlU DeGl7u/t/YQJE6qqB+Ane//WW2+1UaN9xHvvvTdDc0aSdNV9kYKfvXv27Cliv9tr7Nixky0t 9d7Y3YFSXps3by6hgGet84X1JKhxX8r57KyV/ufPPffcLOez6qei6mOFGvuJsjig4CUlWNOQ sM2LFy8+Lg31COxXQDTon3/+yavg7wz1PHTU0LXlGh61V/M5Sup9ShkaNGiwRQFHYfWwpJr3 Eu44wpXPKa+tbZjVhx9+2H748OET3N/nkPdh/y5ySPkoBgII+FyAIMLnFUjxEUAgcBvXVAzW sFQDM05XoVfdeuutq9QwPaRGa1Xb8O+//06wK9Wpdgr6QsNUztLV+2q68v+nrsZfFPRzysel S5cWUwO7qBqvReyq+qRJk54799xz/07Z4Ngb3b5ztl2dV4/CBgU2k9VTEQgiNA9hlRqkHwVv 7/4cFxe3T9uP1hyFTRrmM1UBRWD8v3okmusq/oyHH354sXoP1qnHY7p6EOpoGFd+9RyUscUC Gndaod5rCFCJ6tWrb503b17RnTt3Flc6geUCJwAAIABJREFUG61XQAFAaRkue/vtt8urV2dx qH3d36lhn6gemZTeCTXmtx88eLCgext7r4b9ztNOO+2g0i+goU9dNbyq3IMPPvidgolE9XAc VzcK+HbINy44Dfu8Zs2a+LvuuusGBVmNKlWqtNp6GzQ0LVHDi1LKoGFXFpAcVUCUqhyh0rTv wpXPvf0DDzxwgeZszJbbbvf3OeQ9E+JzSEVQDARyqwBBRG6tWY4LgdgROG7CtHPYutpfX8Ng 4pOTk++3xRqyuuocuEKvxuaW9evXl7UJvM72traeCo3jP88a4Pa5UKFCu9UA1+iYlz5QMFFH gUTIycX33nvvUjVUZ2tYzV3FixcfqOFAjZXnAUvD/TrzzDM3OZ91xXyrgo6Kzuf01hoCtUuN 60APiXoiDihAKmD7qLej5Lhx49qpR+BJW9RTcZmGJRWdPn16CV2dv98WDanqll76avjvsGBI AdMBzSXIbzb33Xdf3ZNPPnmHGuoJr7zySlvZLEgvHQU7hxSQpFzxl2lBpb051H7qQSl91lln 9Vd5C8+ZM+cp633QcR7SMK+U/W0/BTNxFStW3BIqDet5UFkHKXAbqOFQ52sIW2U5HVSgmJKG ekcKnHTSSYc1FG17qDTCfReqfM626lkqqMCvYf/+/Wc63+Wwdci/ixxWRoqDAAI+FiCI8HHl UXQEEAgtYFfQ586dW1d3zBmlhv8ntuj9SA0hqmG3dFVjdYMaygXUW3HchN9nn332HA1FaqJG emBokRrU6xQc7NTdfdbrav+koUOHdl22bFnKJGIndxufrx6Bz9U78KAm5I7UePoGGjpUw/nd WetqerzzXlf8k9VgTtVb4fwevNYk8JQhVu7f1KOyX3MnRqrh/ZAtCo4enjZt2mu6u9EGjYvv Z4uCgKHufUK91zyGRWPGjKl3+umnH9TxTtTckN66qp9PDe/5l19+eU/1TPxgvROh9nV/pzkb 29SDk+h8p7wTy5Urt8H57Kw17KqEJlT3UtnH/Prrr29bMGC/qbdju/KNd99aVkFdkq74r3f2 tbWCxLI2T8T5Tne02qI7ba1SIJSkAG6bAoeUMmhYW5LqdJOCrCPO9umtw5XP2W/QoEF1dX78 5R525fzGGgEEEIgFAYKIWKhljhGBGBPQpNcqmmdwSOPa52gOwkpb1JswR1eo9+oOQ+fa3ZX0 UK/vn3/++fbqYQiM89dk3uLavoPmBYS8sqz5DJPUYN+rCdSdgzk1t6GOhhldpSE0hxWwLNI8 gNUKVlINJ/n+++9r2mRqu3uQ5lnU0tyEFZaW3p8S7haqwXkFf9ak3iUavlTXek9s0RyOazUh OTCxO3jbtD7bMCv1buSzidmaEzFLgcDLNulZvTeTFBQN0x2sTk5rf+c3DU1aqF6BRjasyG6H qgZ8AwUAK+13m7xtw8zsva7gX6ghQ/MUdP1mQ5pssfIfG0a0Wo6BOzXp99p79+4tortpBXoz 7PPPP/9cRAHNetVdDbsblKVneVnvkoY2LVSPya/qKahgw7gs3SFDhrRVT0agDDaPQUO/ato+ ab3Clc/ZR3ePqqJz6DfnM2sEEEAg1gQIImKtxjleBGJAYPTo0Q3UwJvvPlQNZ8lTq1athWps BoY0aa7AWD2HYZfuHvSEhuwM1u1NB+n9rwosZrv3c95rm8NqjI6wCc66Cl3N+d7WapT+tHz5 8kq6O9IgXcm/x+YUaJt57m3svYKYA7p6PUBX3QfaZzWop9haw5HKKci50t5n9KWG+ST1cBTW 3IP/6Er8YA0fKqw7IwXSzWha6r15T0OLEjTcq689Y0G3g22ryeTXKkDqLp/VkaSnAGS6hoHt 0zyGwerBeEg9Cws1d2CJ7atyNdfvjey9em/Ka45HO3kMdRYFRHfbbwrmPlAA0NruRKX312gS +btOL4KChh4atlTaeovUOzRVQcMdGkL2mJ57cbt6X76wuydZkKgJ9WM7duz4gIKHQQraktVT NNbSVrpnWI+SvU/rlVb5bD8NRaskk1VppcFvCCCAQG4WYMykP2rXhjFQV/6oK0qZdQIRnfca rtNAWdbPbLY2bEZXtovrDkSbnGFMmUlLY/Dz6Qp8KTXAd6vhnOouTvquR82aNVeoJ+RHXSVP sCvumckn1D5HjhzJo96IEvabnisRcu5AqP3CfWfpqaGepOFZ8Xq+wkY10lPdOSrcvs731rui idP7dVen4yZJO7+nt7YhaeZpPRBOABFqH921qbDqsIgCnlRDrWzegm7Na70YET3XI1T6J/o7 TZpX3DSsTxbkO0dD4H7MgnRIAoETIRDRv/cnoiDkEbkADdPIrbzckj8uL/XJ2yuBiM77aIOI E3VwThChsfwhh0udqHKQT84WIIjI2fVD6bJNIKJ/77MtdxLOlED+TO3FTggggAACGRLQ0JsF GsaUobsDZSgDNkYAAQQQQOAEChBEnEBsskIAgdgV0G1ff47do+fIEUAAAQRymwATq3NbjXI8 CCCAQAwJaIJzwsiRI5Pdt4SNocPnUBFAAAHPBAgiPKMnYwQQyE4BPfTsGd3mdaieVP2cLbr9 6hN6sFkvm/Cb2XxtwvF1113Xwh5Kl9k0MrNfixYtOmmCc/vM7Btqn/nz5xe1p0SXL1++3/nn n99RD3pLuX2rnupduVq1ajfLqrfueNTSjtn9sluk2u/u7zKTnt0CVk/YblWhQoU+eiZFd8vX SdMedKc7LbXRpOzbdHvYLpan85uz1lO+G9rvugtTJ80zqa07SF2vuzw9EO5WuXreR1fdoel0 Z/+08tetYuNatWrVUc+36Kd1h//7v/9L2c/Z39aRlNO2izQ93Ta2mCa055FJX6vv8ePHB55K bmnwQgABBHKawAn9H2FOO3jKgwACuVtAT1l+UY3Fe2xZvXr1Y/YE61tvvTVTt1I1KWt4fvjh h110C9cTOhR0+PDhE3UL2KlZVVtXXXXVtbrl7VHdhnaMbjv7j56N0cueX2EP0tPtam/R7V1/ ufvuuyfq2Rk1dNejdpav3eno+uuvb9q5c+eb9AyJ4560nZn0+vXr10DPn6irZ3hM0oPiftbD +Xo4jXWVp4Ma1NU1yXiSnrmxRQ3qO9yBm26t2kUN+IRFixa9JpcJerbFAj0z4nU9y2O4HhJX U3fAquJYDRgw4FwFEFfPnj27qZ4ZkfKgwLTy1526rvvjjz+SZfC5Aqa/evToca8FSk6azjq9 cjrbRZqenn3R0/bRMzLG5cuX77AexNfDSYM1AgggkNMECCJyWo1QHgQQyBYBPcPhkK7o/6QA IHDV3QIC3Q61vZ4a/biWIWrAtXOuutuV4KlTpyY5BbHPdjVct2i91b7TlfO77SFmdoVZt2q9 Rs+bGGxXrfUMhDOdfewZC3oicxPnc1prPbegshqqzfRE7cJ2xVzleUJX1e9X8BBI7z//+U/9 //73v7UtjTPPPPOOvn371i9VqtSDehbDAD2DoZaTdqg81RCvr/kYKY1quyWqGsgVNQRoTPfu 3f/85JNPPleDvIQ9mM3y0LEus4fM9erVa9VNN930lQKJwHM1dKzxenZCKd0Gd5uTn60zm56e EVFPwcc0PTxumc0X0fMdFqunoKbd2lV5NlNA8I4emrdC668V/CXotqdnWX72wDo9y6LQiBEj pmu/qurNuFG3t62oJ0d3U+O7tX4fr2eANLVt7bVw4cJkez6HeqP2//vNv/8Nl7+dA3rmRxWl /6ECjRUvv/zyHD0Be7WCleMeUJdeOZ28Ik3PnnquNBP0sMA8N9xww5qnn356hs6xMjZMywI5 dy+KkzZrBBBAwEsBgggv9ckbAQSyVUBXrwMNfWvs25OSv/rqq0Z6CN2vlqmeatxMz4eoqivX z6iB9pKerFxfV8Ub2m/aPlkN1ZTeBn0+3T6rZ+MT+/3FF198v2TJkocuvvjiq/V9YTVah2n4 zSw12G93xuZrONVhNVwP2/ahXhaEWJChdB7Sw9S6KRDZ/9BDDzVVg/egnmz9hO7m9IOemnyN 7bt27dokLYnH3pdXg7/R+++//5b2/0wPX7vGnlFhv4XKU8d4poKTlGExBw8etFt753WevaAH 1eU7fPhwfg1pKq3A6iR3mXVscdu3by9lvRT2XItvvvnmUzXsp1leziuz6SnPfFZeJx0FCgXX rFlTeubMmYkqwwEFBTuc35KSkjYrWCllnydMmFBVPQA/2XsFbW0UXIx47733ZugJ4Um64r9I Q5z26piK2O/20hO3J1u5dbx7//3m3/+Gy1/f5/3ss8+eVjAXeI6H9cDoad1lNFxquXv/9Mrp bBtpehpatl/Wg3TLYnsI4RkK8DrqAYLLdUevvdZrpPO1jz7fef/999ey+nDSZ40AAgh4JZDy P0mvCkC+CCCAQHYJ3HvvvXdoSUle8yJ2auz9dPtCDzJroob/dKexqoBghl2d1k8hn1ht+2jb wFV4DafZYhN61UCvqx6LgZpXsE1XizeOGTPmPDVqq9nVa13pDzn8SGPeEx9//PHmCloaaajO Hwo8xmkI0WI1nI82adLkKjUkAz0l1jD+9NNPl1q+wS9dvf/cHipni8bNN1DPQSV7KnS4PN37 qzdlt56qvVpX8NtruM4s9YI0/ueff/IrECmoAOFnzZW49L777qutJ1VvVC+AzYk4ycb+qxF+ 0J2O8z6z6VmvkNI/Xz0Q2zTU7GQFX+eoN2fFggULEhVIHfeAOvW47FBgEGd56unTJdTAXjBv 3ryi9mRw9SBttF4BBWWl1Xuy7O233y6vZ3IsdsoXbh0uf6sHDa/aYvspmCil3pibqlSpskjD uDa400qvnM62kabnbK+gLI+ewn2Djq2knrw9xXrMdB5MVh1M09CsWgp4z1dvyxUKmL4dPHjw LA232uPsyxoBBBA4kQJczTiR2uSFAAInVEAN+uf37t3bz5Zp06YN0BN8j/Tu3butFUKNtCQ1 Fv9wCqQnTW9Rz0XKFWzne1vr6nCqfysVBJTQ93kVfNynBvaTtqi3oJwas6nGzjtpffHFFyU1 UXegngR9it7/d+nSpa9rLsAia2jaNs8///xENYjj1DB/woYtaZx/ypAqJw1bK5jZ5HzWsKZt mltQwflsaxt6pR6OR2xRD0N9BTdt7b0NgbLfNWfgEzXaK3Tp0uUuC1oUzKxSnpvsSduaXzBe V/gvU4P81oYNG/6ioVU79eTpkAGEpWWvzKRnT+5WeTZraFavN99880IFL99p2NBG5XdIV9oL /5vyv/81k4oVKwYa9jqOHXIrpuFeB3SVP78FOAp66p588sk71JORoN6itrpqv8C9f6j34fJ3 tlUa58nnXtXXDwoY3nG+d9bpldPZzlmnl56zXXx8vE3YHqQgd6ACzvPV6xWYcG5PDdeQqrnq GRmqYW6vzZ07t5rqbIgFGc6+rBFAAIETKZDqf4wnMnPyQgABBLJAINAAD5WO7s50RI37wGK9 BVpmqqGZbNuqAbteDenizn4aLnOqGqqrnM+6Ah9onNlwFjViCznfO2s1YvdpmMkRTTJ+TI3e h2zRRN9H1AvxrbNN8FqN9J3qPZisfSpp0uxVGsZ0rrsRqGDiiMr0qibxPqzJzQvU0O2uK++B K/DutGx+gvPZjkfH8rfz2da6s9IeDYX62BYd0zLN4Zh/7PMoGwqjhuphHdfzurr/sIZO/d/m zZtL6ar3BuVd6JZbbvnVhtWoITtQQcSfarRvdKcd/D6z6cmq6Lhx40YqcHtYx/isrsDHaT7G Rhltl0m8lcXJa9u2bUm6S9N6+6ygbZGConrqTTmoRv5EHVtvbZ9PvTjzL7/88p7qmfjBeiec fcOtw+Vv26tuGmnYVHP18vzX5mSonlMlk1453TtEkp7uMFW2Xr161zr7WW9ImTJlVilgSgkk LWCyOS7qibpaQXCxjh07TnACUGc/1zrs34VrG94igAACmRZI/S9jppNiRwQQQMATgePGuqdV AjWIdysgKGjb2NwIDf9poAZqfpv8qrv3nKtJrb/bb7rqu00N3MAVYPUUBCYW2/fHGpNHNP4+ TgHJVl2N3qHJvIHfNUa+uBqW/TXJNzD/QFfEK2iuRBnbz3nZFf0vv/xywrp16waoMTxHV/zb asL3QLudqXodimiicXcNdbIrzLs1afh7C1LUcCzg7O+sNZyljr234TZK60w1OAPBj5OnJj// Y5OSbdH7HerV2GzvbaKwAqujuk1tH03cPdvSUI9DE5VrreYS7NPQrFM1TOZ+HV8BW9RDcL6u xM+z7cK9MpueJou3vOKKKzpZujaJXfM2qulq/W8290LlWS3XxvabGsy11ZNUpE2bNpvt8513 3rlcw6/yqcekhfxmKSB72SaCa+7DJPXIDNP8hcBwMNs2rVe4/C2oU4O+05AhQ0aoHnba3BVb LFiy9Kw8GsZWJL1yOttFmp4Cn/U6B2oooAoU23qtFCyW1dCmheajerlcPTWD1UNRX4HeJNXP oFGjRoUcMnfsuCP+uzi2PSsEEEAAgVwowBWlXFipHFK6AhGd9xpSlKTl9uBFV2j3qrH9jPt7 TUp9U+Pt9+jq7r0ajvSIJuyuVyCwXQ3tDWpE/6Ir8nfa9rpy/IGGPh0uVqzY5urVq8/TUJmt Cg4G2G8a9vSr5lbsUOP9rmefffYFpbfL0lF++3UlfLyTn8aq/6Sg5Cvnc7i1Jkg/qYDmu1q1 av2onolXdWvPA2osrlRwsU69Fl/afuqVmOq8V2BxSGX4Tb//pYnJezXJ+DMn7VB5aujT19de e+1IZxtbq7E+wtJXY/0PBUwbNWymv/O7pWHfa6L31ho1aszRkKHjbNVwf1o9GX8722c2vdGj Rw8+9dRTV2sexBJLT899eM9J034rVKjQTrlvtmNUwPOi85ut1WvRx45bk5F/1/yUr+U+Tj0S 32sS8kINYXvOva3z3upQ8z+GOp/D5a85B4/rzLRz77hFAc9Y29f8nXTSKqezXUbS0zGNt3x1 3m2yc09B5WjLUz0Sy+1cUgD6mFP+CNYpPRjp/qWxAQLeC0T07733xaQEbgHGUro1cu57++Oi rnJu/VCy7BGI+LxXg6qjihAYppSRoqhXIq+u7JbS0KT9dmXZva+uAsdpqE0+u0Lv/t7e26Rq DRMKfG9DTHSHp1IKNnZGM8nVyqKA5Kg9q0FzGpLUoNxg4+CD81aQ8YJuW/qIhiLl11yGfWrw pzlfIXh/57NdWdddixJtcrbznbO2oUS6+p9PPSu7nO/SW2c2PU1mT1IQtTP4WJ26sR4IG5IW Kn/rQVIAlKQ5JvF6lsTG4DRC7RP8Xbj8g7cL9zmScobbN9T3uuPWsPbt2w+2ifrO78654XyO YL1OQfCYCLZjEwRyikDE/97nlAJTDhqmfjkH+OPyS01RzqwUiPi8VxBhTzTuqiXX33HOCSKi CViyspJIK2sFNOdBnSnD+kSRqgWeHyuIOC4ojiI9dkXgRAhE/O/9iSgMeUQmwJyIyJzYCgEE crDAsQaTPb8g1ZX7HFzsTBVNzyuYqKFImep9yFSG7OQnATv/pxFA+KnKKCsC/hXI9Vft/Fs1 lBwBBDIioIbTMvVI2K1PW2nJ8NCmjOTl5ba6Y9BEL/Mn7+gENFwtUQ+N26mhaykP2osuxZS9 1+kdAUQKB28QQCC7BQgisluY9BFA4IQJHLsCO0bBhE0qLa3FbhPKfKITVgNklJ6A7ow1U+dn Ac1lGav5Hp/qKelL3PvouR72MfAf9/dh3tsQELsL0wad+1vDbMPXCCCAAAIxLGD/o+CFQKwJ cN7HWo3HxvHu0GHauX1Ii01cX6XFHqvu3E2J814YvGJOgPPeh1XOFTp/VJr9cVFX/qgrSpl1 AvxPJessSSlnC+xW8exp6fbvPP/e5+y6onTZI8B5nz2upIpA4H8qMCAQawIEEbFW47FxvME9 ESt12PdooSciNuqfowwtwL/3oV34FoGoBfjjipqQBHwowHnvw0qjyOkKHNAWNo/hDS2BJ48H 7cF5HwTCx5gQ4LyPiWrmIL0Q4I/LC3Xy9FqA897rGiD/7BAop0Tj0kiY8z4NHH7KtQKc97m2 ajkwrwX44/K6BsjfCwHOey/UydNrAc57r2uA/L0Q4Lz3Qj3KPHnYXJSA7I4AAggggAACCCCA QKwJEETEWo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCA AAIIIIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKy OwIIIIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJ EETEWo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAII IIAAAlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwII IIAAAggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETE Wo1zvAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAA AlEKEERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAA AggggAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1z vAgggAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEK EERECcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggg gAACsSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgg gAACCCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERE CcjuCCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAAC sSZAEBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAAC CCCAAAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcju CCCAAAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAACsSZA EBFrNc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCA AAIIRClAEBElILsjgAACCCCAAAIIIBBrAgQRsVbjHC8CCCCAAAIIIIAAAlEKEERECcjuCCCA AAIIIIAAAgjEmgBBRKzVOMeLAAIIIIAAAggggECUAgQRUQKyOwIIIIAAAggggAACsSZAEBFr Nc7xIoAAAggggAACCCAQpQBBRJSA7I4AAggggAACCCCAQKwJEETEWo1zvAgggAACCCCAAAII RClAEBElILsjgAACCCCAAAIIIBBrAvlj7YA5XgQQQAABBHKjwNGjR5N0XKW1FNKSNzceI8eU 4wSOqkR7tWzImzfv1hxXOgqUrQIEEdnKS+IIIIAAAghkr4CCh2LKoZWW5OzNidQRCC+g83Cd fp2mYGJn+K34JTcJMJwpN9Umx4IAAgggEFMCarhV1gF31ZKhAGLLli0FRo0addpvv/1WOKbA 0jnYFStWJIwcOTJ5yZIl1pvDK2MCdg52PXZOZmxPtvalAEGEL6uNQiOAAAIIxLqAqwci1aiC M844464iRYoMOXTo0HHDmlatWhVfo0aN68uUKTOkb9++3fV+SOXKlW+bP39+UfPs0aNHc/vs tj3vvPO6FCtWbNDUqVNtuFS6r9dff718UlLSo+lu6Nqgbdu2l2m51L4qWrToEGvIu37Okrd3 3nlnvWuuuaZlqMRuu+22hnbcV199daf//e9/tS+55JLrS5cu/cAjjzxSPdT2jRo16vrRRx+d 7v7NtpXnjeb75JNPVnH/5n7fs2fPRmeffXZP21b71Ni9e3egLbZjx478nTp1amPlMPMffvjB ephSvX788cdiln+FChX6XnTRRe3Hjx9/qrPR559/Xqp58+adlUbvLl26tA6uf2c7Zx3qOEKV 74svvihZu3btHsHLLbfc0sRJ69jazsVWx87NoJ/4mNsECCJyW41yPAgggAACsSLQSgeaKoCw xv62bdtK5suX78hLL71UyY3Rpk2bGzXcJM/atWv7b9iw4el169bdn5CQsP+KK67o4d7Oed+s WbPOixYtqvLll18Obd26dURj3rt27frnZ5999rKTRkbXagg/d+GFF27M6H7htv/0009Ld+jQ oZ2Cm86rV68uGbydjrGLGvAJOs7X5DWhW7duC3755ZfXP/744+ETJ06s6Q4IBgwYcK4a3lfP nj276caNGxOctF544YVKL7744tWNGzdedOONN8584oknur366qvlnd+d9T333FNHwcfFrVq1 WnDzzTd/8+abb17Sr1+/xvb7pZde2kEBQvU+ffpMKlu27BYFCHc4AYazv60vu+yynlrlffTR R8epjg+r0R+ou7/++iuue/fuPQ8fPpxX5fxMx1BJaVzu3td5H+44wpWvfPnyey+44IKF7mXl ypUVChcufNBJ07UOBBKuz7zNpQIEEbm0YjksBBBAAIHcK6ArvdYrEPJqvRqz9XTFeH6dOnXm a8hSPUfh/fffL/vHH39UHjFixKgSJUocsu9PPfXUQ+++++4obbsk+Kp1ixYtrvj999/P+uqr r15o0qTJDicd91oBw/klS5Z8xHqYqeZRAAAS90lEQVQqrrzyytb225QpU0r27t27g71Xg/ci 9W40syvj6hl53NLct29foO2hBnvFunXrXmfbuV9qFNtV+FPUiE+uV6/etZ07d26j9AeqZ+B+ 99X/m2666TwdR39b1PBv4U7D/V6N6cTt27cXPuWUU7a5v7f31muya9euQjKZ/tRTT1XVMdw4 efLkik2bNu2mRnpr/T7+gw8+aOrst3DhwuSCBQseKFCgwH7nO1u/8847zS+++OKv3njjjR/U 47FcvQwL1aPRyL2Nvf/222+rtG/f/uvXXntttoKHFe3atfvu66+/rnPgwIG83333XTMd8zt3 3HHHCq2/3r9/f8KwYcPOcqdhPUnaNkHpfHzDDTesefrpp2comCljw6/keU58fPy+WbNmjbru uuvW9urVa+rMmTMbB9erpRfuOMKVr2rVqnueeeaZ+c6i4CbunHPOWazgaa67fK73ycfOUddX vM1tAgQRua1GOR4EEEAAgVgQKB3uINWIrK9hOXOvuuqqBXrVcq5m6+r5aWpIb65Wrdoe975q yO/65JNPpqhhbHfaCbxatmzZacaMGS3VOH7Lfne+d69tGI16PRqr12HY4MGD31dvRUsbTrN1 69Z49XSUtW3//PPPUmoQX3b77bdPUaP6Zc3BqKqr9NXst/z58x9Rnv/Ye/dL+56hnoE4LQV/ +umn+ps2bSqmRv6riYmJ2wYOHNjetrWhQypz27vvvnu0rvi/ox6DZmqUpwRM7vQee+yxRd98 882naggvdX9v7ydMmFBVPQA/2fu33nqrjRrtI957770ZmjOSpKvuixT87N2zZ08R+91eY8eO nWxpqffG7kiU8tq8eXMJBTxrnS+sJ0GN+1LOZ2et9D9/7rnnZjmfVT8VVR8r1NhPlMUBBS8p wZqGhG1evHjxcWmoR2C/AqJB//zzT14Ff2eo56Gjhq4t1/CovZrPUVLvU8rQoEGDLQo4CquH JdW8l3DHEa58TnltbcOsPvzww/bDhw+f4P4+xPuw52iIbfnKhwIEET6sNIqMAAIIIBDzAiEn /lrDUg3MOF2FXnXrrbeuUsP0kBqtVU3r77//TrAr1enJaZjKWbp6X01X/v/U1fiLwm2/dOnS YmpgF1XjtYhdVZ80adJz55577t/B2zds2HC2XZ1Xj8IGBTaT1VMRCCI0D2GVGqQfBW/v/hwX F7dP24/WHIVNGuYzVQFFYPy/eiSa6yr+jIcffnixeg/WqcdjunoQ6mgYV371HJSxxQIad1qh 3msIUInq1atvnTdvXtGdO3cWVzobrVdAAUBpGS57++23y6tXZ3Gofd3fqWGfqB6ZlN4JNea3 Hzx4sKB7G3uvhv3O00477aDSL6ChT101vKrcgw8++J2CiUT1cBxXNwr4dsg3LjgN+7xmzZr4 u+666wYFWY0qVaq02nobNDQtUcOLUsqgYVcWkBxVQJSqHKHStO/Clc+9/QMPPHCB5mzMlttu 9/ch3oc8R0Nsx1c+FSCI8GnFUWwEEEAAgZgWOG7CtCOhq/31NQwmPjk5+X5brCGrq86BK/Rq bG5Zv359WZvA62xva+up0Dj+86wBbp8LFSq0Ww1wjY556QMFE3UUSIScXHzvvfcuVUN1tobV 3FW8ePGBGg7UWHkesDTcrzPPPHOT81lXzLcq6KjofE5vrSFQu9S4DvSQqCfigAKkAraPejtK jhs3rp16BJ60RT0Vl2lYUtHp06eX0NX5+23RkKpu6aWvhv8OC4YUMB3QXIL8ZnPffffVPfnk k3eooZ7wyiuvtJXNgvTSUbBzSAFJyhV/mRZU2ptD7acelNJnnXVWf5W38Jw5c56y3gcd5yEN 80rZ3/ZTMBNXsWLFLaHSsJ4HlXWQAreBGg51voawVZbTQQWKKWmod6TASSeddFhD0baHSiPc d6HK52yrnqWCCvwa9u/ff6bzXRrrkOdoGtvzk88ECCJ8VmEUFwEEEEAAAQmkDD1yNOwK+ty5 c+vqjjmj1PD/xBa9H6khRDXslq5qrG5QQ7mAeiuOm/D77LPPnqOhSE3USA8MLVKDep2Cg526 u896Xe2fNHTo0K7Lli1LmUTs5Gfj89Uj8Ll6Bx7UhNyRGk/fQEOHaji/O2tdTY933uuKf7Ia zKl6K5zfg9eaBJ7qOG0b9ajs19yJkWp4P2SLgqOHp02b9prubrRBY/H72aIgYGhwesGfNY9h 0ZgxY+qdfvrpB3W8EzU3pLeu6udTw3v+5Zdf3lM9Ez9Y70TwfsGfNWdjm3pwEp3vlXdiuXLl NjifnbWGXZXQhOpeKvuYX3/99W0LBuw39XZsV77x7lvLKqhL0hX/9c6+tlaQWNbmiTjf6Y5W W3SnrVUKhJIUwG1T4JBSBg1rS1KdblKQdcTZPr11uPI5+w0aNKiuzo+/3MOunN9CrEPWXYjt +MqnAgQRPq04io0AAgggENMCgcanW0CTXqtonsEhjWufozkIK21Rb8IcXaHeqzsMnWt3V6pf v/73zz//fHv1MATG+Wsyb3Ft30HzAkJeWdZ8hklqsO/VBOrO7rzsveY21NEwo6s0hOawApZF mgewWsFKqiEs33//fU2bTG13D9I8i1qam7DC9tf7U8LdQtV+T+ulSb1LNHyprvWe2KI5HNdq QnJgYnda+wX/ZsOs1LuRzyZma07ELAUCL9ukZ/XeTFJQNEx3sDo5eJ9QnzU0aaF6BRrZsCK7 Haoa8A0UAKy0bW3ytg0zs/e6gn+hhgzNU9D1mw1pssXKf2wY0Wo5Bu7UpN9r7927t4juphXo zbDPP//8cxEFNOtVdzXsblCWnuVlvUsa2rRQPSa/qqeggg3jsnSHDBnSVj0ZgTLYPAYN/app +6T1Clc+Zx/dPaqKzqHfnM/prFOdo+lsz88+EyCI8FmFUVwEEEAAAQQkkOoq9+jRoxuogTff raPhLHlq1aq1UI3NwJAmzRUYq+cw7NLdg57QkJ3Bur3pIL3/VYHFbPd+znttc1iN0RE2wVlX oas539tajdKfli9fXkl3RxqkK/n32JwCbTPPvY29VxBzQFevB+iq+0D7rAb1FFtrOFI5BTlX 2vuMvtQwn6QejsKae/AfXYkfrOFDhXVnpEC6GU1LvTfvaWhRgoZ79bVnLOh2sG01mfxaBUjd 5bM6kvQUgEzXMLB9mscwWD0YD6lnYaHmDiyxfVWu5vq9kb1X7015zfFoJ4+hzqKA6G77TcHc BwoAWtudqPT+Gk0if9fpRVDQ0EPDlkpbb5F6h6YqaLhDQ8ge03Mvblfvyxd29yQLEjWhfmzH jh0fUPAwSEFbsnqKxlraSvcM61Gy92m90iqf7aehaJVksiqtNFy/pTpHXb/xNhcIMF7NH5Vo XYLUlT/qilJmnQDnfdZZkpJ/BCI+7zVkp6MOK+RtXtM7XBs2oyvbxXUHok3OMKb09gn1u8bg 59MV+FJqgO9WwznVXZz0XY+aNWuuUE/Ij7pKnmBX3EOlk5nvjhw5kke9ESVsXz1XIuTcgYyk a+mpoZ6k4Vnxer7CRjXSU905Kr30rHdFE6f3665Ox02STm8/53cbkmae1gPhBBDOb+617tpU WHVYRAFPqqFWNm9Bt+a1XoyInuvhTjcL36/TULQxGUgv4vM+A2myaTYL0DDNZuAsSp4/riyC JBlfCXDe+6q6KGwWCUR83iuIKKY87epyYEJ0FuWfpck4QYTG8occLpWlmZFYThGw4OtjBRHu gLGcvlunJdTD6fR1YI4PbVKT8NGL4Uw+qiyKigACCCCAgCNwrJE2TZ8zfMXcSSO71xp6s0AP mFuT3fmQfo4RsHNxWlAAYYWzoV12567hWupo4ZULBIj6/FGJEV+Z8sfhUEoEIhLgvI+IiY1y mUCGz/tjPRKt5JCpoU25zI/D8U7AehpCBRBWIntmhfWcWZBhz7Kw4WevaHlXiw27yvB5r314 eSxAEOFxBUSYPX9cEUKxWa4S4LzPVdXJwUQoYOd9pl56wnEeTda15zzk0ZXgTKXBTghkREAB bB7dRSqP7mJlz+7IyK627W4tdpcwO1n5914IvBDIDoFM/08lOwpDmgicIAHO+xMETTY5SoDz PkdVB4XJIoHA07OV1iEtNgHfbj17j5YkLfbivP/Xgf8ikOUC/HFlOSkJ+kCA894HlUQRs1yA 8z7LSUkwBwjYfAh7bsQbWkLNieC8zwGVRBFypwB/XLmzXjmqtAU479P24dfcKcB5nzvrNdaP qpwA4tJA4LxPA4efEIhGgD+uaPTY168CnPd+rTnKHY0A5300euzrVwHOex/WHLd49WGlUWQE EEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGE l/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEE fChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBA AAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQRHipT94I IIAAAggggAACCPhQgCDCh5VGkRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQR Pqw0iowAAggggAACCCCAgJcCBBFe6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAAB BLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCA AAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPI CCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGC CC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQRHipT94IIIAAAggggAAC CPhQgCDCh5VGkRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQRPqw0iowAAggg gAACCCCAgJcCBBFe6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAABBLwUIIjwUp+8 EUAAAQQQQAABBBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUI InxYaRQZAQQQQAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAA Agh4KUAQ4aU+eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBA AAEEEEAAAR8KEET4sNIoMgIIIIAAAggggAACXgoQRHipT94IIIAAAggggAACCPhQgCDCh5VG kRFAAAEEEEAAAQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQRPqw0iowAAggggAACCCCAgJcC BBFe6pM3AggggAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAAB BBDwoQBBhA8rjSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQ QAABBBBAAAEvBQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+ eSOAAAIIIIAAAggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8K EET4sNIoMgIIIIAAAggggAACXgoQRHipT94IIIAAAggggAACCPhQgCDCh5VGkRFAAAEEEEAA AQQQ8FKAIMJLffJGAAEEEEAAAQQQQMCHAgQRPqw0iowAAggggAACCCCAgJcCBBFe6pM3Aggg gAACCCCAAAI+FCCI8GGlUWQEEEAAAQQQQAABBLwUIIjwUp+8EUAAAQQQQAABBBDwoQBBhA8r jSIjgAACCCCAAAIIIOClAEGEl/rkjQACCCCAAAIIIICADwUIInxYaRQZAQQQQAABBBBAAAEv BQgivNQnbwQQQAABBBBAAAEEfChAEOHDSqPICCCAAAIIIIAAAgh4KUAQ4aU+eSOAAAIIIIAA Aggg4EMBgggfVhpFRgABBBBAAAEEEEDASwGCCC/1yRsBBBBAAAEEEEAAAR8KEET4sNIoMgII IIAAAggggAACXgoQRHipT94IIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAII IIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAAC CCCAAAIIIIAAAggggAACCCCAwAkX+H+rpIIgkpqmDQAAAABJRU5ErkJggg== --------------080709070900090001070203-- --------------080803080501010004050609-- From adam@nostrum.com Wed Feb 3 11:26: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 DA5A83A6826 for ; Wed, 3 Feb 2010 11:26:12 -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.067, 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 5j+2LJNHu7Bi for ; Wed, 3 Feb 2010 11:26: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 4FE8A3A68AC for ; Wed, 3 Feb 2010 11:26:09 -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 o13JQoRU057824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Feb 2010 13:26:50 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B69CDFA.5060606@nostrum.com> Date: Wed, 03 Feb 2010 13:26: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: <4B6767A4.8000008@nostrum.com> <4B68A66C.50108@cisco.com> <4B69A3D2.6060309@nostrum.com> In-Reply-To: <4B69A3D2.6060309@nostrum.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) Subject: Re: [martini] Further details around use case 3 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 19:26:13 -0000 On 2/3/10 10:26 AM, Adam Roach wrote: > The PBX can either Record-Route, or it can act as a B2BUA and mint a > new contact with a state cookie that gives it a handle back to the > correct device. I prefer the latter... Yikes. That was a bad typo. I meant "I prefer the former." In other words, I think the Record-Routing approach is far cleaner. But both work, and I see no reason to prohibit one or the other. /a From adam@nostrum.com Wed Feb 3 11:36: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 9D23828C107 for ; Wed, 3 Feb 2010 11:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 69reebxSaHPK for ; Wed, 3 Feb 2010 11:36: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 7BAE928C0E2 for ; Wed, 3 Feb 2010 11:36: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 o13JbCnj058605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 13:37:12 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B69D068.6050508@nostrum.com> Date: Wed, 03 Feb 2010 13:37:12 -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] New draft-elwell-martini-reqs-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, 03 Feb 2010 19:36:32 -0000 John: This looks like a well-written and fair summary of the requirements we have discussed to date. The clarifications (which I don't think appeared on the mailing list) are very helpful in teasing out intended meaning. I don't see anything in here that appears harmful, nor can I think of a requirement (or a desirement) that is obviously missing. Thanks for putting it together. /a P.S. I notice that you've made the same mistake as I almost always do: the short title for this draft is "Secure Caller ID Requirements." :) On 2/3/10 8:51 AM, Elwell, John wrote: > I have attempted to capture the requirements more formally in a draft: > http://tools.ietf.org/id/draft-elwell-martini-reqs-00.txt > > Basically the requirements are derived from the list we debated on the mailing list prior to the last virtual meeting. I have reworded it in terms of telephone numbers, and also for the time being limited to E.164 (without necessarily precluding a system that would support other forms of telephone numbers or even AORs that are not based on telephone numbers). The first few requirements have been reworded substantially, and a few requirements have been added (e.g., concerning security). Some of the requirements were debated without real conclusion, and likewise there were a couple of requirements proposed for which we didn't have consensus, so feel free to raise these again if you are concerned about what I have written. > > John > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From ankriste@cisco.com Wed Feb 3 12:37: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 E078728C1BB for ; Wed, 3 Feb 2010 12:37:08 -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 94DQkOIivU77 for ; Wed, 3 Feb 2010 12:37:06 -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 A825028C18D for ; Wed, 3 Feb 2010 12:37:06 -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: ApoEADttaUurRN+K/2dsb2JhbADAfoofB41uglQLgWcE X-IronPort-AV: E=Sophos;i="4.49,400,1262563200"; d="scan'208";a="477697852" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2010 20:37:49 +0000 Received: from [128.107.147.3] (dhcp-128-107-147-3.cisco.com [128.107.147.3]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o13Kbnuf018039 for ; Wed, 3 Feb 2010 20:37:50 GMT Message-ID: <4B69DE9E.1040807@cisco.com> Date: Wed, 03 Feb 2010 12:37:50 -0800 From: Anders Kristensen 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: <4B6767A4.8000008@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Feb 2010 12:47:23 -0800 Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 20:37:09 -0000 Regarding the difference between use cases 1/3 and 2/4, if there's a chance that people start passing these URIs around, presumably customers would have a strong preference for 2 and 4 where they get to advertise their own domain names. In other words, if I run pan-am.com I'd rather put sip:+12145550105@pan-am.com on my business card than sip:+12145550105@centricvoice.com. Anders On 2/2/2010 12:32 AM, Elwell, John wrote: > Adam, > That's great that you have taken the trouble to enumerate these > different cases. Talking from a PBX perspective, I think you are correct > in saying that all would get the job done. Inevitably there are some I > dislike. > I dislike 5/5a because of the implications of making REGISTER work with > tel URIs (and also tel URIs tend not to be used so much today on PBXs, > in my opinion). > I dislike 6, because the PBX can't do anything with the received > Request-URI - strictly speaking it would have to route it back to the SP. > I dislike 7, for the same reason, plus the known difficulties with > extracting information from History-Info (I have my doubts whether the > present effort to revise History-Info will really solve its problems). > I suppose you could have a use case 8, which is a kind of combination of > 2 and 6. So you start of with sip:+12145550105@pan-am.com and deliver > the same Request-URI, together with Route: sip:pbx@192.168.17.25. This > was what I had in mind pre-MARTINI. It solves the problem of 6, but > still has the issues of 2. > Ignoring use case 8, this leaves use cases 1 to 4. From a PBX point of > view, cases 1 and 2 are the same. The difference is how the request > reaches the SP. Is this an issue for MARTINI? Or put it another way, if > we provide a solution for case 1, does this stop people implementing > case 2? Similarly for cases 3 and 4: if we provide a solution for case > 3, does this stop people implementing case 4? > So this narrows it down to cases 1 and 3. The recent "Implications" > thread seemed to be homing in on a solution that would give both 1 and > 3, which sounds reasonable to me. I am not convinced that there is a > problem with case 1's by-passing RFC 3263 procedures. > John > > ------------------------------------------------------------------------ > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] > *On Behalf Of *Adam Roach > *Sent:* 01 February 2010 23:46 > *To:* martini@ietf.org > *Subject:* [martini] Use Cases: what's important, what's not > > The more we talk about this, the further apart opinions seem to get. > There appears to be a lot of ocean boiling going on right now, such > that even when we can decide on a fairly narrow scope ("phone > numbers only"), the system behavior that people expect appears to > vary literally from person to person. > > I'm going to try to do something like I did before with the > diagrams, this time focusing on just what happens for E.164 numbers. > I'll continue with using the same dead companies as before > (CentricVoice as the SSP, and Pan-Am as the PBX). > > In particular, I'm assuming that the tentative (albeit far from > unanimous) agreement to do an initial batch of work towards E.164 > numbers means that these kinds of use cases are not under discussion > at the moment: > > > > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:not-a-number@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:some-other-string@pan-am.com | > | |--------------------------------->| > > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:not-a-number@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:some-other-string@pan-am.com | > | |--------------------------------->| > > > > So, ignoring those, we seem to still have a huge disconnect on what > the SSP needs to be able to do as a result of the MARTINI > operations. Now, one of the nice things we get from E.164 numbers is > that usernames now become unique. We can specify transformations > such that the username that arrives at the SSP stays the same as it > passes through the SSP. Unlike my earlier examples, I'm going to > assume that limiting to E.164 enables this kind of trivial > transformation. Not in the *general* case, of course -- only for > MARTINI-routed E.164 numbers. > > As you read through these, try to place each use case in one of the > following categories: > > 1. This use case by itself is sufficient for the architecture {I > am/my customers are} trying to deploy > > 2. This use case is necessary for the architecture {I am/my > customers are} trying to deploy, but requires other use cases > also. > > 3. This use case is neither necessary nor sufficient for the > architecture {I am/my customers are} trying to deploy. > > > Frankly, I would expect almost everyone will be able to place each > use case in category #1. All of these solutions certainly allow the > PBX to figure out who the call is supposed to be sent to, and that > appears to be the key criteria for the inbound messages. > > ------------------------------------------------------------------------ > > ================ > Use Case 1 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > RFC3263 for "pan-am.com" is not relevant. > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@pan-am.com | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating its own domain. > The SSP is provisioned to know that +12145550105 belongs to Pan-Am. > Having received information from Pan-Am about its PBX's IP address, > it changes the domain to "pan-am.com," keeps the user ID, ignores > RFC 3263 procedures, and sends the request to the MARTINI-registered > IP address it has for Pan-Am. > > The key drawback for this use case is the disregard for RFC3263 > procedures. > > ------------------------------------------------------------------------ > > ================ > Use Case 2 > ================ > > RFC3263 for "pan-am.com" resolves to the CentricVoice servers. > > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:+12145550105@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@pan-am.com | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating the domain for > pan-am.com. Having received information from Pan-Am about its PBX's > IP address, it leaves the Request-URI alone, ignores RFC 3263 > procedures, and sends the request to the MARTINI-registered IP > address it has for Pan-Am. > > Note that this use case is predicated on an external entity -- > something on the other side of the "Internet" cloud -- being able to > take the E.164 number "+12145550105" and figure out that it needs to > go to the domain "pan-am.com". I emphasize this because I know some > people are interested in models in which is tenable to track "phone > number to SSP" mapping, while the relatively larger number of "phone > number to end customer" mappings might be unpalatable. > > The key drawbacks for this use case are: > > 1. The disregard for RFC3263 procedures > 2. Ambiguity around which SIP nodes are "responsible for" > pan-am.com (in the RFC 3261 sense of that word). Cullen had a > litmus test for this: is CentricVoice allowed to redirect > calls for pan-am.com to a voicemail server or answering service? > > > Given that 3261 lacks a formal description of "responsible for," we > can potentially define the problem of "responsible for" away (as > Keith has proposed) -- but I'm pretty certain it's not within > MARTINI's scope to clarify the terms appearing in RFC 3261. I think > that would need to go back to DISPATCH, and I doubt we want to wait > for such an effort to complete. > > ------------------------------------------------------------------------ > > ================ > Use Case 3 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@192.168.17.25 | > | |--------------------------------->| > > > In this use case, the SSP receives a request for its own domain. The > SSP is provisioned to know that +12145550105 belongs to Pan-Am. > Having received information from Pan-Am about its PBX's IP address, > it changes the domain to that registered IP address (192.168.17.25), > keeps the user ID, correctly invokes RFC 3263 procedures, and sends > the request to the resulting host (192.168.17.25). > > This use case does not suffer from any of the drawbacks discussed to > date, other than differing from the model that is currently deployed > for bulk registrations (even though it is functionally identical to > the model deployed for single registrations). > > ------------------------------------------------------------------------ > > ================ > Use Case 4 > ================ > > RFC3263 for "pan-am.com" resolves to the CentricVoice servers. > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:+12145550105@pan-am.com | | > |--------------------------------->| | > | |INVITE | > | |sip:+12145550105@192.168.17.25 | > | |--------------------------------->| > > In this use case, the SSP receives a URI indicating the domain for > pan-am.com. Having received information from Pan-Am about its PBX's > IP address, it changes the domain to that registered IP address > (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 > procedures, and sends the request to the resulting host (192.168.17.25). > > Like use case 3, this use case does not suffer from any of the > drawbacks discussed to date, other than differing from the model > that is currently deployed for bulk registrations (even though it is > functionally identical to the model deployed for single > registrations). However, it is predicated on an external entity -- > something on the other side of the "Internet" cloud -- being able to > take the E.164 number "+12145550105" and figure out that it needs to > go to the domain "pan-am.com". > > ------------------------------------------------------------------------ > > ================ > Use Case 5 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |tel:+12145550105 | > | |--------------------------------->| > > > In this use case, the SSP receives a URI indicating its own domain. > The SSP is provisioned to know that +12145550105 belongs to Pan-Am. > It changes the R-URI to a tel: URI containing only the E.164 number > in question. Having received information from Pan-Am about its PBX's > IP address, it sends the request to the resulting host > (192.168.17.25). Since the URI in question is a TEL URI, RFC3263 > issues are avoided altogether, eliminating any alt-root considerations. > > The major drawback to this use case is that it (likely) requires the > ability to register TEL URIs, which is currently normatively > forbidden by RFC 3261. While this is tractable, it would require > companion work in SIPCORE to relax this normative requirement. It > also would likely require more mechanism than other approaches, > since we're effectively adding on a new URI-to-host address > resolution procedure. > > ================ > Use Case 5a > ================ > > A variation on Use Case 5, this use case ends up with a R-URI of the > PBX's lead number, with an extension parameter that indicates the > desired extension on the PBX: > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->| | > | |INVITE | > | |tel:+12145550100;extension=1214555| > | | 0105| > | |--------------------------------->| > > > This is effectively the exact same procedure as Use Case 5; however, > it may make contact registration somewhat easier (depending on the > exact mechanism used to communicate domain IP addresses). > > ------------------------------------------------------------------------ > > ================ > Use Case 6 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->|INVITE | > | |sip:+12145550105@centricvoice.com | > | |Route: | > | |--------------------------------->| > > In this example, In this use case, the SSP receives a URI indicating > its own domain. The SSP is provisioned to know that +12145550105 > belongs to Pan-Am. It pushes the MARTINI-registered contact into the > route set, leaves the Request-URI unmodified, invokes RFC 3263 > procedures (on the Route) and sends the request to the resulting host. > > A key drawback to this use case is that it cannot be effected using > REGISTER without radically changing the semantics of REGISTER (i.e., > registering a path towards an AOR instead of a contact for an AOR). > These changes necessarily require intermediaries who are a party to > the REGISTER transaction (e.g., using Path and/or Service-Route) to > understand these changed semantics, and would require the use of a > Proxy-Require to avoid the ensuing problems. Using a method other > than REGISTER eliminates this class of problems. > > A second major drawback to this approach pertains to domain > responsibility: unless the Pan-Am PBX is "responsible for" > centricvoice.com, it is in violation of SIP routing procedures if it > fails to route it back to CentricVoice: "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." In practice, I imagine it wants to route it to one of > its internal extensions. > > ------------------------------------------------------------------------ > > ================ > Use Case 7 > ================ > > RFC3263 for "centricvoice.com" resolves to the CentricVoice servers. > > Internet CentricVoice Pan-Am > |INVITE | | > |sip:+12145550105@centricvoice.com | | > |--------------------------------->|INVITE sip:pbx@192.168.17.25 | > | |History-Info: sip:+12145550105@cen| > | | tricvoice.com| > | |--------------------------------->| > > > Similar to use case 6, except the SSP swaps out the registered > Contact URI for the Request-URI, and squirrels the incoming R-URI > (containing the phone number) away in a History-Info header field. > > On the plus side, this looks a lot like normal proxy/registrar > behavior. Drawbacks include defining concrete procedures around > which History-Info entry to use (which is a problem the 4244bis > draft is currently struggling with), especially in the case that > there are intermediaries between the SSP and the PBX. We would also > be creating a normative dependency on the 4244bis document, which > may delay a final delivery of MARTINI work substantially. > > > ------------------------------------------------------------------------ > ====================================================================== > > Now, I've heard and read things that imply that each these use cases > are under consideration by at least one person. I think we need to > focus. Clearly just saying "phone numbers" is not sufficient. Look > back over how you rated each of the use cases relative to the > "sufficient," "necessary but not sufficient," and "neither necessary > nor sufficient" criteria. I think you'll find that, if you were > honest with yourself, all or most of these use cases fall into the > first category. I'm not saying you *like* them all -- merely that > they will get the job done, if push were to come to shove. > > So, I think we need to pick one and work on the mechanism required > to enable it. And I think we need to be vigilant against scope > creep. As we get into mechanism, it will be overwhelmingly tempting > to say, "oh, but we can add on Use Case X if we just do *this* small > thing!" But those small things can spiral out of control. > > All other things being equal, I have a strong preference for Use > Case 3, as its only real drawback is that it varies from the > demonstrably flawed ^[1] mechanism that showed up on the IETF's > doorstep. Any other approach is going to require interested parties > coming to consensus on the issues associated with the other use > cases, and I think we've seen that won't be a very fast process. > > /a > > [1] Lest this offend anyone as being too general a criticism, I > refer to the set of shortcomings enumerated here: > http://www.ietf.org/mail-archive/web/martini/current/msg00412.html > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Wed Feb 3 12:56: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 3ED963A6868 for ; Wed, 3 Feb 2010 12:56:41 -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, 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 vXGuHC80AZnc for ; Wed, 3 Feb 2010 12:56:40 -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 AE5BD3A67A3 for ; Wed, 3 Feb 2010 12:56: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 o13KvJJ0065007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 14:57:20 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B69E32F.6030602@nostrum.com> Date: Wed, 03 Feb 2010 14:57: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: Anders Kristensen References: <4B6767A4.8000008@nostrum.com> <4B69DE9E.1040807@cisco.com> In-Reply-To: <4B69DE9E.1040807@cisco.com> Content-Type: multipart/alternative; boundary="------------080606040002010602050301" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 20:56:41 -0000 This is a multi-part message in MIME format. --------------080606040002010602050301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/3/10 2:37 PM, Anders Kristensen wrote: > Regarding the difference between use cases 1/3 and 2/4, if there's a > chance that people start passing these URIs around, presumably > customers would have a strong preference for 2 and 4 where they get to > advertise their own domain names. In other words, if I run pan-am.com > I'd rather put sip:+12145550105@pan-am.com on my business card than > sip:+12145550105@centricvoice.com. I would be /mortified/ to put either on my business card. What goes on my business card would be "sip:adam.roach@pan-am.com" or something similar. But that's a different kettle of fish. /a --------------080606040002010602050301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/3/10 2:37 PM, Anders Kristensen wrote:
Regarding the difference between use cases 1/3 and 2/4, if there's a chance that people start passing these URIs around, presumably customers would have a strong preference for 2 and 4 where they get to advertise their own domain names. In other words, if I run pan-am.com I'd rather put sip:+12145550105@pan-am.com on my business card than sip:+12145550105@centricvoice.com.

I would be mortified to put either on my business card. What goes on my business card would be "sip:adam.roach@pan-am.com" or something similar. But that's a different kettle of fish.

/a
--------------080606040002010602050301-- From pkyzivat@cisco.com Wed Feb 3 13:49: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 03CA63A69C5 for ; Wed, 3 Feb 2010 13:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 w5SnwHCggLWO for ; Wed, 3 Feb 2010 13:49:52 -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 BCBCD3A6970 for ; Wed, 3 Feb 2010 13:49:52 -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: ApoEAFd+aUurRN+K/2dsb2JhbADBMYoeCY1sglOBcwQ X-IronPort-AV: E=Sophos;i="4.49,400,1262563200"; d="scan'208";a="145248858" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2010 21:50:36 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o13Loa3h014543; Wed, 3 Feb 2010 21:50:36 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); Wed, 3 Feb 2010 15:50: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); Wed, 3 Feb 2010 15:50:35 -0600 Message-ID: <4B69EFE3.7000203@cisco.com> Date: Wed, 03 Feb 2010 16:51:31 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B6767A4.8000008@nostrum.com> <4B69DE9E.1040807@cisco.com> <4B69E32F.6030602@nostrum.com> In-Reply-To: <4B69E32F.6030602@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2010 21:50:35.0722 (UTC) FILETIME=[EA9AB2A0:01CAA51A] Cc: Anders Kristensen , martini@ietf.org Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 21:49:54 -0000 Adam Roach wrote: > On 2/3/10 2:37 PM, Anders Kristensen wrote: >> Regarding the difference between use cases 1/3 and 2/4, if there's a >> chance that people start passing these URIs around, presumably >> customers would have a strong preference for 2 and 4 where they get to >> advertise their own domain names. In other words, if I run pan-am.com >> I'd rather put sip:+12145550105@pan-am.com on my business card than >> sip:+12145550105@centricvoice.com. > > I would be /mortified/ to put either on my business card. What goes on > my business card would be "sip:adam.roach@pan-am.com" or something > similar. But that's a different kettle of fish. I don't know why you should be *mortified*. IMO it would make much more sense to put: tel:+1-214-555-0105 email:john.smith@pan-am.com sip:john.smith@pan-am.com And yes, I would put the punctuation in the tel:, and I would expect that to work too. And it might be inferred that sip:+1-214-555-0105@pan-am.com might work too. That might also be listed on the card, but would be a tad geeky. This is also my obsession with From values. (Substitute PAID if that is what you use in your environment.) Namely, if you call me, I will hope my phone will capture your URI in its call history, and that I will then be able to use it to call you back. So whatever I get there ought to work for that purpose. I realize that it may be a lie, just as callerid might be a lie. But if I want to call you back, and that is what you gave me, it still seems like the most appropriate thing to use. Thanks, Paul From christer.holmberg@ericsson.com Wed Feb 3 14:03: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 0D3E13A6A28 for ; Wed, 3 Feb 2010 14:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 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 PD0VSUAt9W82 for ; Wed, 3 Feb 2010 14:03:15 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0CFC73A6950 for ; Wed, 3 Feb 2010 14:03:14 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-db-4b69f2cca7c5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BC.1F.02429.CC2F96B4; Wed, 3 Feb 2010 23:03:57 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 3 Feb 2010 23:03:56 +0100 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Wed, 3 Feb 2010 23:03:12 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-number registrationfirst Thread-Index: AcqkZMy9xd7SXas3SRCq+qFbKAIwWAAt+D4y 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> , <4B68BDC5.9060106@cisco.com> In-Reply-To: <4B68BDC5.9060106@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" 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, 03 Feb 2010 22:03:16 -0000 >The purpose of standards is to get people to do things in a consistent >way. The need for a mapping function is evidence that standards are >lacking or not being used. Or both :) Regards, Christer= From bernard_aboba@hotmail.com Wed Feb 3 14:34: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 91D613A67A6 for ; Wed, 3 Feb 2010 14:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, 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 32u+dtvbqd5r for ; Wed, 3 Feb 2010 14:34:01 -0800 (PST) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by core3.amsl.com (Postfix) with ESMTP id 5937E3A65A6 for ; Wed, 3 Feb 2010 14:34:01 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.73]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 14:34:45 -0800 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 3 Feb 2010 14:34:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01CAA4DE.07524E90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcqlIFTzxLVHyk68QKCJcfDdosrTpw== Content-Language: en-us X-OriginalArrivalTime: 03 Feb 2010 22:34:45.0065 (UTC) FILETIME=[15BC5B90:01CAA521] Subject: [martini] Martini Virtual Interim III 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: Wed, 03 Feb 2010 22:34:05 -0000 ------=_NextPart_000_0011_01CAA4DE.07524E90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim III February 9, 2010 8 AM - 10 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00238.html Agenda 8 AM - 8:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements & Usage Scenarios (30 minutes) 8:10 AM - 8:20 AM PT MARTINI Requirements Update, John Elwell (10 minutes) 8:20 AM - 8:30 AM PT Service Provider Perspective, Martin Dolly (10 minutes) 8:30 AM - 8:40 AM PT MARTINI Usage Scenarios, TBD (10 minutes) Solution Updates (30 minutes) 8:40 AM - 9:00 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (20 minutes) http://tools.ietf.org/html/draft-roach-martini-gin 9:00 AM - 9:10 AM PT, MARTINI Shaken & Stirred Update, Hadriel Kaplan (10 minutes) http://tools.ietf.org/html/draft-kaplan-martini-stirred-domain-registration http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s Discussion (30 minutes) 9:10 AM - 9:40 AM PT Discussion: Participants (30 minutes) Wrap-up (20 minutes) 9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes) 9:55 AM - 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_0011_01CAA4DE.07524E90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI = Virtual Interim III

February 9, = 2010

8 AM – 10 AM Pacific = Time

Conferencing Details:

 

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

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

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

Agenda

=

8 AM - 8:10 AM PT:  = Preliminaries

     Conference = issues/debugging

     Agenda bash

Requirements = & Usage Scenarios (30 minutes)

=

8:10 AM - 8:20 AM  PT MARTINI = Requirements Update, John Elwell (10 minutes)

8:20 AM – 8:30 AM  PT Service Provider = Perspective, Martin Dolly (10 minutes)

8:30 AM – 8:40 AM  PT MARTINI Usage = Scenarios, TBD (10 minutes)

=

Solution Updates (30 = minutes)

8:40 AM – 9:00 AM PT, MARTINI with Globally = Identifiable Numbers, Adam Roach (20 minutes)

http://tools.ietf.org/html/draft-roach-martini-gin =

 

9:00 AM – 9:10 AM PT, MARTINI Shaken & = Stirred Update, Hadriel Kaplan (10 minutes)

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

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

=

Discussion (30 = minutes)

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

=

Wrap-up (20 = minutes)

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

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

------=_NextPart_000_0011_01CAA4DE.07524E90-- From pkyzivat@cisco.com Wed Feb 3 14:49: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 6B77D3A67FB for ; Wed, 3 Feb 2010 14:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 zeZoVKdqiGIg for ; Wed, 3 Feb 2010 14:49:48 -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 70CE13A65A6 for ; Wed, 3 Feb 2010 14:49:48 -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: ApoEAN+MaUurR7Ht/2dsb2JhbADBcJgIhEYE X-IronPort-AV: E=Sophos;i="4.49,400,1262563200"; d="scan'208";a="295615362" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 03 Feb 2010 22:50:32 +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 o13MoVcK023787; Wed, 3 Feb 2010 22:50:32 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); Wed, 3 Feb 2010 16:50:31 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 16:50:31 -0600 Message-ID: <4B69FDF6.6010509@cisco.com> Date: Wed, 03 Feb 2010 17:51:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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 X-OriginalArrivalTime: 03 Feb 2010 22:50:31.0510 (UTC) FILETIME=[49DC6760:01CAA523] Cc: "martini@ietf.org" Subject: Re: [martini] Numbers and private networks X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 22:49:49 -0000 DRAGE, Keith (Keith) wrote: > I just want to assert a couple of things that I have not seen in the ongoing discussions so far. > > 1) PBXs already have a custom and practice on assigning URIs to their extensions already. Some of that conforms to what RFCs say, and some of it is questionable. Any solution we come up with to a Martini problem is not going to change the set of URIs that are used within the PBX. So I would point out that for private numbers we can see all of the following: > > sip:XXXX@subregion.region.enterprise.com Totally ambiguous. There is no way to distinguish if this is a number or a (numeric) name. Perhaps it doesn't matter, as long as it is treated as a numeric name. But you will need the "stirred" approach to route this I think. That assumes that subregion.region.enterprise.com resolves vis 3263 to a reachable server. > sip:XXXX@subregion.region.enterprise.com;user=phone This is just plain wrong! From the user=phone it is to conform with tel format. But it has neither a leading + nor a phone context. > tel:XXXX;phone-context=subregion.region.enterprise.com This is syntactically correct. But AFAIK there are no standard rules for routing such a thing. You must have configured information about how to deal with this phone context. If this gets to an SSP other than one servicing enterprise.com, it probably will get no further. Once it gets to the Martini SSP for the target pbx, do you want the phone context to be delivered to the pbx? Will it know what to do with it? I'm thinking Adam's wildcard mapping for the user part into the contact might barf on this. > sip:XXXX;phone-context=subregion.region.enterprise.com@enterprise.com/user=phone Pretty much the same as the tel case. But if this URI falls in the hands of somebody outside enterprise.com's SSP then presumably 3263 routing will deal with it. > sip:XXXX;phone-context=subregion.region.enterprise.com@ngn-operator.com/user=phone The new issue presented by this one is that ngn-operator.com had better have information about the phone context. > sip:XXXX;phone-context=+XXXX@enterprise.com/user=phone This is just like the case two up. The server identified by enterprise.com had better know what to do with this phone context. > where XXXX are digits. Ignore the subdomains, I pulled these from a document I drafted some time ago. The one you will probably not see is tel:... > > The first one is probably one of the most common! > > E.164 numbers are just a subset of the above usages. > > For support of private numbers within VPN type scenarios, PBXs are not going to map these numbers, just because the trunking is provided by a SSP. Nor are they going to suddenly define a whole new set of identities in their DNS. > > 2) Business trunking is in some ways a replacement for direct PBX connections or tie lines between those PBXs. Yes there is a certain quantity of traffic destined for, or received from, users outside the private network, but we also need to deal with the case of replacing existing direct connections with support from the SSP. That means that what may originally have been configured as a SIP peering link between two PBXs has to be easily replaced by whatever solution the SSP provides, and therefore with minimal reconfiguration. And remember that historically, different countries have had significant differences in the customs and practice of private networking, based on tariff structures and regulatory restrictions. Therefore consider the deployments in a couple of other countries rather than just your own. Do you assume that the SSP knows the phone contexts, and the valid values for XXXX? If not, then you are mostly talking about stirred. Thanks, Paul From bernard_aboba@hotmail.com Wed Feb 3 15:05: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 528D93A69A9 for ; Wed, 3 Feb 2010 15:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.165, 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 JOD3kfEyDzHY for ; Wed, 3 Feb 2010 15:04:56 -0800 (PST) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by core3.amsl.com (Postfix) with ESMTP id 1EEC23A699E for ; Wed, 3 Feb 2010 15:04:56 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.73]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 15:05:39 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 3 Feb 2010 15:05:39 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01CAA4E2.591011F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlIjuP8MU3h68LTRupLCAC1b16yQAAq08w Content-Language: en-us X-OriginalArrivalTime: 03 Feb 2010 23:05:39.0908 (UTC) FILETIME=[674EF040:01CAA525] Subject: [martini] Martini Virtual Interim III Agenda - Take Four X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 03 Feb 2010 23:05:00 -0000 ------=_NextPart_000_004A_01CAA4E2.591011F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim III February 9, 2010 8 AM - 10 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00238.html Agenda 8 AM - 8:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements & Usage Scenarios (30 minutes) 8:10 AM - 8:20 AM PT MARTINI Requirements Update, John Elwell (10 minutes) http://tools.ietf.org/html/draft-elwell-martini-reqs 8:20 AM - 8:30 AM PT Service Provider Perspective, Martin Dolly (10 minutes) 8:30 AM - 8:40 AM PT MARTINI Usage Scenarios, TBD (10 minutes) http://www.ietf.org/mail-archive/web/martini/current/msg00450.html http://www.ietf.org/mail-archive/web/martini/current/msg00531.html Solution Updates (30 minutes) 8:40 AM - 9:00 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (20 minutes) http://tools.ietf.org/html/draft-roach-martini-gin 9:00 AM - 9:10 AM PT, MARTINI Shaken & Stirred Update, Hadriel Kaplan (10 minutes) http://tools.ietf.org/html/draft-kaplan-martini-stirred-domain-registration http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s Discussion (30 minutes) 9:10 AM - 9:40 AM PT Discussion: Participants (30 minutes) Wrap-up (20 minutes) 9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes) 9:55 AM - 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_004A_01CAA4E2.591011F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim III

February 9, 2010

8 AM – 10 AM Pacific Time

 

Conferencing Details:

 

Slide Presentations:  http://ww= w.drizzle.com/~aboba/MARTINI/Jan-Interim-III/

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

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

 

Agenda

 

8 AM - 8:10 AM PT:  = Preliminaries

     Conference = issues/debugging

     Agenda bash

 

Requirements & Usage Scenarios (30 = minutes)

 

8:10 AM - 8:20 AM  PT MARTINI Requirements = Update, John Elwell (10 minutes)

http://tool= s.ietf.org/html/draft-elwell-martini-reqs

8:20 AM – 8:30 AM  PT Service Provider = Perspective, Martin Dolly (10 minutes)

8:30 AM – 8:40 AM  PT MARTINI Usage Scenarios, TBD (10 minutes)

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

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

 

Solution Updates (30 minutes)

 

8:40 AM – 9:00 AM PT, MARTINI with Globally = Identifiable Numbers, Adam Roach (20 minutes)

http://tools.= ietf.org/html/draft-roach-martini-gin

 

9:00 AM – 9:10 AM PT, MARTINI Shaken & = Stirred Update, Hadriel Kaplan (10 minutes)

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

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

 

Discussion (30 minutes)

 

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

 

Wrap-up (20 minutes)

 

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

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

------=_NextPart_000_004A_01CAA4E2.591011F0-- From bernard_aboba@hotmail.com Wed Feb 3 17:42: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 04A7328C0DC for ; Wed, 3 Feb 2010 17:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.255, 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 1nHoqSTfZso2 for ; Wed, 3 Feb 2010 17:41:57 -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 3CB973A69B7 for ; Wed, 3 Feb 2010 17:41:57 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.72]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 17:42:41 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 3 Feb 2010 17:42:40 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01CAA4F8.489CCA00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlIjuP8MU3h68LTRupLCAC1b16yQAGQaOA Content-Language: en-us X-OriginalArrivalTime: 04 Feb 2010 01:42:41.0138 (UTC) FILETIME=[56CC8D20:01CAA53B] Subject: [martini] Martini Virtual Interim III Agenda - Take Four X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 01:42:01 -0000 ------=_NextPart_000_00AF_01CAA4F8.489CCA00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim III February 9, 2010 8 AM - 10 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00238.html Agenda 8 AM - 8:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements & Usage Scenarios (30 minutes) 8:10 AM - 8:20 AM PT MARTINI Requirements Update, John Elwell (10 minutes) http://tools.ietf.org/html/draft-elwell-martini-reqs 8:20 AM - 8:30 AM PT Service Provider Perspective, Martin Dolly (10 minutes) 8:30 AM - 8:40 AM PT MARTINI Usage Scenarios, Adam Roach (10 minutes) Solution Updates (30 minutes) 8:40 AM - 9:00 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (20 minutes) http://tools.ietf.org/html/draft-roach-martini-gin 9:00 AM - 9:10 AM PT, MARTINI Shaken & Stirred Update, Hadriel Kaplan (10 minutes) http://tools.ietf.org/html/draft-kaplan-martini-stirred-domain-registration http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s Discussion (30 minutes) 9:10 AM - 9:40 AM PT Discussion: Participants (30 minutes) Wrap-up (20 minutes) 9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes) 9:55 AM - 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_00AF_01CAA4F8.489CCA00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim III

February 9, 2010

8 AM – 10 AM Pacific Time

 

Conferencing Details:

 

Slide Presentations:  http://ww= w.drizzle.com/~aboba/MARTINI/Jan-Interim-III/

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

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

 

Agenda

 

8 AM - 8:10 AM PT:  = Preliminaries

     Conference = issues/debugging

     Agenda bash

 

Requirements & Usage Scenarios (30 = minutes)

 

8:10 AM - 8:20 AM  PT MARTINI Requirements = Update, John Elwell (10 minutes)

http://tool= s.ietf.org/html/draft-elwell-martini-reqs

8:20 AM – 8:30 AM  PT Service Provider = Perspective, Martin Dolly (10 minutes)

8:30 AM – 8:40 AM  PT MARTINI Usage Scenarios, Adam Roach (10 minutes)

 

Solution Updates (30 minutes)

 

8:40 AM – 9:00 AM PT, MARTINI with Globally = Identifiable Numbers, Adam Roach (20 minutes)

http://tools.= ietf.org/html/draft-roach-martini-gin

 

9:00 AM – 9:10 AM PT, MARTINI Shaken & = Stirred Update, Hadriel Kaplan (10 minutes)

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

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

 

Discussion (30 minutes)

 

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

 

Wrap-up (20 minutes)

 

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

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

------=_NextPart_000_00AF_01CAA4F8.489CCA00-- From bernard_aboba@hotmail.com Wed Feb 3 17:42: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 4FC2B28C0DC for ; Wed, 3 Feb 2010 17:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=-0.771, 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 j6jkuWqzDdRl for ; Wed, 3 Feb 2010 17:42:44 -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 773613A69B8 for ; Wed, 3 Feb 2010 17:42:44 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.72]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 17:43:28 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 3 Feb 2010 17:43:27 -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: AcqTtgDNJhhnr6gOQwy26APUGVMGAgRhXHHw Content-Language: en-us X-OriginalArrivalTime: 04 Feb 2010 01:43:28.0570 (UTC) FILETIME=[731219A0:01CAA53B] 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: Thu, 04 Feb 2010 01:42:45 -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:20100204T014327Z DESCRIPTION:When: Tuesday\, February 09\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: https://workgreen.webex.com/workgreen /j.php?ED=131322887&UID=1112097932&PW=NZjNiMTY2ODYx&RT=MiM0\n\nNote: The G MT offset above does not reflect daylight saving time adjustments.\n\n*~*~ *~*~*~*~*~*~*~*\n\nMARTINI Virtual Interim III\nFebruary 9\, 2010\n8 AM – 10 AM Pacific Time\n\nConferencing Details: \n \nSlide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/\nJabber room: mar tini at jabber.ietf.org (Please join)\nDial in Audioconference and WebEx d etails: http://www.ietf.org/mail-archive/web/martini/current/msg00238.ht ml\n\nAgenda\n\n8 AM - 8:10 AM PT: Preliminaries\n Conference issues/ debugging\n Agenda bash\n\nRequirements & Usage Scenarios (30 minutes) \n\n8:10 AM - 8:20 AM PT MARTINI Requirements Update\, John Elwell (10 mi nutes)\nhttp://tools.ietf.org/html/draft-elwell-martini-reqs\n8:20 AM – 8:30 AM PT Service Provider Perspective\, Martin Dolly (10 minutes)\n8:30 AM – 8:40 AM PT MARTINI Usage Scenarios\, Adam Roach (10 minutes)\n\nS olution Updates (30 minutes)\n\n8:40 AM – 9:00 AM PT\, MARTINI with Glob ally Identifiable Numbers\, Adam Roach (20 minutes)\nhttp://tools.ietf.org /html/draft-roach-martini-gin \n \n9:00 AM – 9:10 AM PT\, MARTINI Shaken & Stirred Update\, Hadriel Kaplan (10 minutes)\nhttp://tools.ietf.org/htm l/draft-kaplan-martini-stirred-domain-registration\nhttp://tools.ietf.org/ html/draft-kaplan-martini-shaken-implicit-registrations\n\nDiscussion (30 minutes)\n\n9:10 AM – 9:40 AM PT Discussion: Participants (30 minutes) \n\nWrap-up (20 minutes)\n\n9:40 AM - 9:55 AM PT Hums: WG Chairs (15 min utes)\n9:55 AM – 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes)\ n\n======================================================================= =================\nTopic: MARTINI WG Virtual Meeting \nDate: Tuesday\, Feb ruary 9\, 2010 \nTime: 8:00 am\, Pacific Standard Time (San Francisco\, GM T-08:00) \nMeeting Number: 969 465 025 \nMeeting Password: martini \n\n\n- ------------------------------------------------------ \nTo join the onlin e meeting (Now from iPhones too!) \n-------------------------------------- ----------------- \n1. Go to https://workgreen.webex.com/workgreen/j.php?E D=131322887&UID=1112097932&PW=NZjNiMTY2ODYx&RT=MiM0 \n2. Enter your name a nd email address. \n3. Enter the meeting password: martini \n4. Click "Joi n Now". \n\nTo view in other time zones or languages\, please click the li nk: \nhttps://workgreen.webex.com/workgreen/j.php?ED=131322887&UID=1112097 932&PW=NZjNiMTY2ODYx&ORT=MiM0 \n\n---------------------------------------- --------------- \nTo join the audio conference only \n-------------------- ----------------------------------- \nTo receive a call back\, provide you r phone number when you join the meeting\, or call the number below and en ter the access code. \nCall-in toll number (US/Canada): 1-408-792-6300 1 -408-792-6300 \nGlobal call-in numbers: https://workgreen.webex.com/workgr een/globalcallin.php?serviceType=MC&ED=131322887&tollFree=0 \n\nAccess cod e:969 465 025 \n\n------------------------------------------------------- \nFor assistance \n------------------------------------------------------- \n1. Go to https://workgreen.webex.com/workgreen/mc \n2. On the left navi gation bar\, click "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/VXl6V1pDv1V 4vEfINO/rCHPTwZP3yrb0IWfUc=&RT=MiM0 \n\n\nWebEx will automatically setup M eeting Manager for Windows the first time you join a meeting. To save time \, you can setup prior to the meeting by clicking this link: \nhttps://wor kgreen.webex.com/workgreen/meetingcenter/mcsetup.php \n\n\nThe playback of UCF (Universal Communications Format) rich media files requires appropria te 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 \n\nSign up for a free trial of WebEx \nhttp://www.webex.com/go/mcemfreetrial \n\nhttp://w ww.webex.com\n\n DTEND:20100209T180000Z DTSTAMP:20100204T014327Z DTSTART:20100209T160000Z LAST-MODIFIED:20100204T014327Z LOCATION:https://workgreen.webex.com/workgreen/j.php?ED=131322887&UID=11120 97932&PW=NZjNiMTY2ODYx&RT=MiM0 ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:3 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: https://w orkgreen.webex.com/workgreen/j.php?ED=131322887&UID=1112097932&PW=NZjNiMTY 2ODYx&RT=MiM0

\n\n

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

\n\n\n\n

MARTINI Virtual Interim III

\n\n

February 9\, 2010

\n\n

8 AM – 10 AM Pacific Time

\n\n

Conferencing Details:

\n\n

 

\n\ n

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

\n\n

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

\n\n

Dial in Audioconference and WebEx deta ils:   http://www.ietf.org/mail-archive/web/ martini/current/msg00238.html< /A>

\n\n

Agenda

\n\n

8 AM - 8:10 AM PT:  Preliminaries

\n\ n

     Conference is sues/debugging

\n\n

     Agenda bash

\n\n

Requirements &\; Usage Scenarios (30 mi nutes)

\n\n

8:10 AM - 8:20 AM  PT MARTINI Requirements Update\, John Elwell (10 minutes)

\n\n

http://tools.ietf.org/html/draft- elwell-martini-reqs

\n\n

8:20 AM – 8:30 AM  PT Service Provider Perspective\, Martin Dolly ( 10 minutes)

\n\n

8:30 AM – 8:40 AM  PT MARTINI Usage Scenarios\, Adam Roach (10 mi nutes)

\n\n

\n\n< P DIR=LTR>Solution Updates (30 min utes)

\n\n

8:40 AM – 9:00 AM PT\, MARTINI with Globally Identifiable Numbers\, Adam Roach (20 minutes)

\n\n

http://tools.ietf.or g/html/draft-roach-martini-gin

\n\n

 

\n\n

9:00 AM – 9:10 AM PT\, MART INI Shaken &\; Stirred Update\, Hadriel Kaplan (10 minutes)

\n\n

http://tools.ietf.org/html/dra ft-kaplan-martini-stirred-domain-registration

\n\n

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

\n\n

Discussion (30 minutes)

\n\n

9:10 AM – 9:40 AM  PT Discussion:  Participan ts (30 minutes)

\n\n

Wrap-up (20 minutes)

\n\n

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

\n\n

9:55 AM – 10:00 AM PT   Next Steps:  WG Chairs &\; ADs (5 minutes)

\n\n

\n\n

=================== =====================================================================

\n\n

< /SPAN>Topic: MARTINI WG Virt ual Meeting
\nDate: Tuesday\, February 9\, 2010
\nTime: 8:00 am\, Pa cific Standard Time (San Francisco\, GMT-08:00)
\nMeeting Number: 969 4 65 025
\nMeeting Password: martini
\n
\n
\n------------------- ------------------------------------
\nTo join the online meeting (Now from iPhones too!)
\n-------------------------------------------------- -----
\n1. Go to https://workgreen.webex.com/workgreen/j.php?ED=131322887&\;UID=11120 97932&\;PW=NZjNiMTY2ODYx&\;RT=MiM0
\n2. Enter your name and email a ddress.
\n3. Enter the meeting password: martini
\n4. Click "\;J oin Now"\;.
\n
\nTo view in other time zones or languages\, plea se click the link:
\nhttps://workgreen.webex.com/workgreen/j.php?ED=131322887&\;UID= 1112097932&\;PW=NZjNiMTY2ODYx&\;ORT=MiM0
\n
\n------------------ -------------------------------------
\nTo join the audio conference on ly
\n-------------------------------------------------------
\nTo re ceive 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 numb er (US/Canada):  1-408-792-6300  1-408-792-6300
\nGlobal call-in numb ers: https://workgreen.we bex.com/workgreen/globalcallin.php?serviceType=MC&\;ED=131322887&\;t ollFree=0
\n
\nAccess code:969 465 025
\n
\n-------------------- -----------------------------------
\nFor assistance
\n------------- ------------------------------------------
\n1. Go to https://workgreen.webex.com/wor kgreen/mc
\n2. On the left navigation bar\, click "\;Support"\;.< BR>\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 Micr osoft Outlook)\, click this link:
\nhttps://workgreen.webex.com/workgreen/j.php?ED=13 1322887&\;UID=1112097932&\;ICS=MRS3&\;LD=1&\;RD=2&\;ST=1&am p\;SHA2=FKFrM/VXl6V1pDv1V4vEfINO/rCHPTwZP3yrb0IWfUc=&\;RT=MiM0
\n
\ n
\nWebEx will automatically setup Meeting Manager for Windows the firs t time you join a meeting. To save time\, you can setup prior to the meeti ng by clicking this link:
\nhttps://workgreen.webex.com/workgr een/meetingcenter/mcsetup.php< /A>
\n
\n
\nThe playback of UCF (Universa l 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< SPAN LANG="en-us"> https://wor kgreen.webex.com/workgreen/systemdiagnosis.php
\n
\nSign up for a free trial of WebEx
\nhttp://www.webex.com/go/mcemfreetrial
\n
\n http://www.webex.com

\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:2 X-MS-OLK-APPTSEQTIME:20100202T042217Z 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 Feb 3 17:47: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 84C6D28C135 for ; Wed, 3 Feb 2010 17:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=-0.663, 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 YcIKEWfi-q5o for ; Wed, 3 Feb 2010 17:47:58 -0800 (PST) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by core3.amsl.com (Postfix) with ESMTP id 8734428C122 for ; Wed, 3 Feb 2010 17:47:58 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.72]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 17:48:42 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 3 Feb 2010 17:48:42 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01CAA4F9.1FF9B170" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlPC3jj7RDUzmeQWySIotFVogfxg== Content-Language: en-us X-OriginalArrivalTime: 04 Feb 2010 01:48:42.0745 (UTC) FILETIME=[2E556690:01CAA53C] Subject: [martini] REQUEST: MARTINI Virtual Interim III Agenda and Slides X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 01:47:59 -0000 ------=_NextPart_000_00D3_01CAA4F9.1FF9B170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you are on the agenda for MARTINI Virtual Interim III (see http://www.ietf.org/mail-archive/web/martini/current/msg00543.html ) on Tuesday, February 9, please send me slides to myself and Spencer no later than close of business on Monday, February 8, 2010 so we can get them uploaded in time. Thanks in advance! ------=_NextPart_000_00D3_01CAA4F9.1FF9B170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are on the agenda for MARTINI Virtual = Interim III (see http://www.ietf.org/mail-archive/web/martini/current/msg00543.html ) on Tuesday, February 9, please send me slides to myself and Spencer no = later than close of business on Monday,  February 8, 2010 so we can get them = uploaded in time. 

 

Thanks in advance!

------=_NextPart_000_00D3_01CAA4F9.1FF9B170-- From HKaplan@acmepacket.com Thu Feb 4 09:26: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 8686228C0ED for ; Thu, 4 Feb 2010 09:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 x4YikHhgo8fS for ; Thu, 4 Feb 2010 09:26:56 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B40C83A6C7F for ; Thu, 4 Feb 2010 09:26:56 -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, 4 Feb 2010 12:27:42 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 4 Feb 2010 12:27:42 -0500 From: Hadriel Kaplan To: "martini@ietf.org" Date: Thu, 4 Feb 2010 12:27:39 -0500 Thread-Topic: Can we remove draft-stirred? Thread-Index: Acqlv1mEbjP3s+W2ThG+tSmeE+bWAA== Message-ID: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> 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] Can we remove draft-stirred? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 17:26:57 -0000 Howdy, I proposed removing draft-stirred from consideration at the last virtual me= eting, but got shot down. Since then no one has advocated it over the othe= rs (in fact, most of the arguments have been against it, afaict, and have b= een confusing it with draft-shaken). So can we please remove that draft now, so we can focus on the others? -hadriel From HKaplan@acmepacket.com Thu Feb 4 09:53: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 B80B03A6C6E for ; Thu, 4 Feb 2010 09:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 gV1zC6dWugN9 for ; Thu, 4 Feb 2010 09:53:18 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9913E3A6B85 for ; Thu, 4 Feb 2010 09:53: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; Thu, 4 Feb 2010 12:54:04 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 4 Feb 2010 12:54:04 -0500 From: Hadriel Kaplan To: "martini@ietf.org" Date: Thu, 4 Feb 2010 12:53:46 -0500 Thread-Topic: comments on draft-roach-martini-gin-00 Thread-Index: Acqlwv/iE0rGOHK6S4ubDUi+/RIThA== Message-ID: <430FC6BDED356B4C8498F634416644A917E5E0E11A@mail> 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] comments on draft-roach-martini-gin-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, 04 Feb 2010 17:53:19 -0000 Hi Adam,=20 Thanks for taking the time to write up the draft! I have a few comments/questions: 1) Why bother having the "()" indicator in the Contact-URI username? This = implies that the Contact-URI could be "sip:foo()bar@192.0.2.1", or somethin= g similar, such that a placeholder is needed. But why do we need to compli= cate the mechanism to handle that? The PBX can already use URI params if i= t needs extra cookies, or it can even insert itself as a Path header. I do= , though, think the explicitly Registered contact-URI could be of the form = "sip:foobar@192.0.2.1", and have a username - but it would be replaced for = the expanded entries.=20 2) Why bother having the "*" indicator for GRUU? We've talked about doing = the GRUU manip that way (by having the pbx add on to the one the SSP gives = it), but by either adding the pbx-specifics as a new param, or simple appen= ding. Again I don't see a need to support something like "uuid:foo*bar" (i= n fact it would be really bad to do that), so if it's always appending to t= he end then you don't need a star. 3) Why does the Contact-URI have a 'bnc' param, instead of in the AoR being= Registered? ISTM the expansion of the location service entries is actuall= y a property of the AoR, not its location/contact. And if we have it in th= e contact-uri, why remove it for the req-uri replacement? 4) Wrt the open issue of proxy-require, yes I think we should have that too= , for the reasons we've discussed before on this list. -hadriel From richard@shockey.us Thu Feb 4 10:01: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 BAEC128C117 for ; Thu, 4 Feb 2010 10:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, 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 3Dh8-oqAD38B for ; Thu, 4 Feb 2010 10:01:11 -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 AFE9228C14B for ; Thu, 4 Feb 2010 10:01:11 -0800 (PST) Received: (qmail 8245 invoked by uid 0); 4 Feb 2010 18:01:56 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy8.bluehost.com.bluehost.com with SMTP; 4 Feb 2010 18:01:56 -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=NA+tdTMkrVFhGK3p+UZs03TuJO60Fc73Kl4VMw7lYuvLZyZvvPuQecLMT5AkIS6EqokD5Wv0GKzrmOJGlWUF/MlhHTFkedWOchTJGbEJpOC+z9N7O/1T+NyXuFPqF+Vs; 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 1Nd61V-0003na-My; Thu, 04 Feb 2010 11:01:55 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , References: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> Date: Thu, 4 Feb 2010 13:01:46 -0500 Message-ID: <007801caa5c4$1e9c4010$5bd4c030$@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: Acqlv1mEbjP3s+W2ThG+tSmeE+bWAAABMDqg 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] Can we remove draft-stirred? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 18:01:12 -0000 +1 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, February 04, 2010 12:28 PM To: martini@ietf.org Subject: [martini] Can we remove draft-stirred? Howdy, I proposed removing draft-stirred from consideration at the last virtual meeting, but got shot down. Since then no one has advocated it over the others (in fact, most of the arguments have been against it, afaict, and have been confusing it with draft-shaken). So can we please remove that draft now, so we can focus on the others? -hadriel _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From drage@alcatel-lucent.com Thu Feb 4 10: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 A91B53A6C86 for ; Thu, 4 Feb 2010 10:07:48 -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 4jvo5faxTj83 for ; Thu, 4 Feb 2010 10:07:47 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 9F4783A6D5B for ; Thu, 4 Feb 2010 10:07:47 -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 o14I8U1G003915 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Feb 2010 19:08:30 +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; Thu, 4 Feb 2010 19:08:30 +0100 From: "DRAGE, Keith (Keith)" To: Hadriel Kaplan , "martini@ietf.org" Date: Thu, 4 Feb 2010 19:08:29 +0100 Thread-Topic: Can we remove draft-stirred? Thread-Index: Acqlv1mEbjP3s+W2ThG+tSmeE+bWAAABXhdw Message-ID: References: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> 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 Subject: Re: [martini] Can we remove draft-stirred? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 18:07:48 -0000 Yes. We need more flexibility than it provides. Assuming we are talking about the draft. I'm still setting up the test bed for the Martini's to see which one is bet= ter. Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Thursday, February 04, 2010 5:28 PM > To: martini@ietf.org > Subject: [martini] Can we remove draft-stirred? >=20 > Howdy, > I proposed removing draft-stirred from consideration at the=20 > last virtual meeting, but got shot down. Since then no one=20 > has advocated it over the others (in fact, most of the=20 > arguments have been against it, afaict, and have been=20 > confusing it with draft-shaken). > So can we please remove that draft now, so we can focus on the others? >=20 > -hadriel > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From HKaplan@acmepacket.com Thu Feb 4 10:20: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 EC3833A6C98 for ; Thu, 4 Feb 2010 10:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 EDqsbT4oDTeU for ; Thu, 4 Feb 2010 10:20:08 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8BC283A6E02 for ; Thu, 4 Feb 2010 10:20:07 -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, 4 Feb 2010 13:20:53 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 4 Feb 2010 13:20:53 -0500 From: Hadriel Kaplan To: Adam Roach , "Elwell, John" Date: Thu, 4 Feb 2010 13:20:29 -0500 Thread-Topic: [martini] GIN Draft Thread-Index: Acqk4xCOCTQo5455TEe0QUp3rWgMKwA4XlCg Message-ID: <430FC6BDED356B4C8498F634416644A917E5E0E121@mail> References: <4B68BEB4.2020207@nostrum.com> <4B6991B1.1040806@nostrum.com> In-Reply-To: <4B6991B1.1040806@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 Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 18:20:09 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Adam Roach > Sent: Wednesday, February 03, 2010 10:10 AM >=20 > On 2/3/10 4:12 AM, Elwell, John wrote: > > 3. I have a concern about the public GRUU solution. Suppose a UA > registered with the PBX uses one of these permanent GRUUs, and some other > on-PBX UA ends up making an out-of-dialog request back to that GRUU. It > seems the PBX would be required to route via the SSP, resulting in a > hairpin. > > >=20 > Yes, a na=EFve implementation would do that, and the signaling (but not > the media) would end up going through the SSP. Everything would work > okay, although the SSP would have to suffer through one (!) additional > SIP message and its responses. >=20 > But this hairpinning isn't necessary. I'm assuming that all of those > terminals will send outgoing requests through the PBX. This would give > the PBX the opportunity, if it wanted, to optimize this hairpin: it > would trivially be able to recognize the R-URI as matching the public > GRUU it received from the SSP (there will be only one, so it's not an > expensive comparison), and process it locally without sending it to the > SSP. I think we should mandate that behavior, because hair-pinning it through th= e SSP would be bad. One of the definitions of a "PBX" is that it handles l= ocal calls locally, and the SSP is not going to expect or want the extra si= gnaling. (and arguably the Enterprise shouldn't want the SSP involved in th= em either) =20 > It's pretty much the same behavior as recognizing a normal, non-GRUU URI > as one of its own extensions and handling it locally instead of routing > to the SSP. You mean if a phone off the pbx sends a request to number@SSP.com and the P= BX says "hey, I have that number", then it's ok for it to route the request= locally and not send it to the SSP? I didn't see that in the draft. =20 -hadriel From bernard_aboba@hotmail.com Thu Feb 4 10:38: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 8400F28C162 for ; Thu, 4 Feb 2010 10:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-1.030, 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 Pi7ChjGO3vqq for ; Thu, 4 Feb 2010 10:38:00 -0800 (PST) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by core3.amsl.com (Postfix) with ESMTP id 4C70828C120 for ; Thu, 4 Feb 2010 10:38:00 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.72]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 10:38:47 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Thu, 4 Feb 2010 10:39:25 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01CAA586.52433F60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlyWAeCbS2MWqURHu4T0ET6RZbyg== Content-Language: en-us X-OriginalArrivalTime: 04 Feb 2010 18:38:47.0356 (UTC) FILETIME=[497F27C0:01CAA5C9] Subject: [martini] MARTINI Virtual Interim IV date: March 2, 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: Thu, 04 Feb 2010 18:38:02 -0000 ------=_NextPart_000_00DD_01CAA586.52433F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Based on the Doodle Poll, we have selected Tuesday, March 2, 2010 from 10 AM - noon PT as the date/time for Virtual Interim IV. Details will be forthcoming. ------=_NextPart_000_00DD_01CAA586.52433F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on the Doodle Poll, we have selected Tuesday, = March 2, 2010 from 10 AM – noon PT as the date/time for Virtual Interim IV. =

 

Details will be forthcoming.

------=_NextPart_000_00DD_01CAA586.52433F60-- From bernard_aboba@hotmail.com Thu Feb 4 11: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 C8C273A6B38 for ; Thu, 4 Feb 2010 11:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.291, 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 4UUVl2cBYzED for ; Thu, 4 Feb 2010 11:39:29 -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 8E3E328C111 for ; Thu, 4 Feb 2010 11:39:29 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.72]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 11:40:16 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Thu, 4 Feb 2010 11:40:22 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01CAA58E.D619BAF0" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-index: AcqlIjuP8MU3h68LTRupLCAC1b16yQAGQaOAACWSKTA= X-OriginalArrivalTime: 04 Feb 2010 19:40:16.0727 (UTC) FILETIME=[E0887E70:01CAA5D1] Subject: [martini] Martini Virtual Interim III Agenda - Take Five X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 19:39:33 -0000 ------=_NextPart_000_00DB_01CAA58E.D619BAF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim III February 9, 2010 8 AM - 10 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00238.html Agenda 8 AM - 8:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements & Usage Scenarios (30 minutes) 8:10 AM - 8:20 AM PT MARTINI Requirements Update, John Elwell (10 minutes) http://tools.ietf.org/html/draft-elwell-martini-reqs 8:20 AM - 8:30 AM PT Service Provider Perspective, Martin Dolly (10 minutes) 8:30 AM - 8:40 AM PT MARTINI Usage Scenarios, Adam Roach (10 minutes) Solution Updates (30 minutes) 8:40 AM - 9:00 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (20 minutes) http://tools.ietf.org/html/draft-roach-martini-gin 9:00 AM - 9:10 AM PT, MARTINI Shaken Update, Hadriel Kaplan (10 minutes) http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s Discussion (30 minutes) 9:10 AM - 9:40 AM PT Discussion: Participants (30 minutes) Wrap-up (20 minutes) 9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes) 9:55 AM - 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_00DB_01CAA58E.D619BAF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim III

February 9, 2010

8 AM – 10 AM Pacific Time

 

Conferencing Details:

 

Slide Presentations:  http://ww= w.drizzle.com/~aboba/MARTINI/Jan-Interim-III/

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

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

 

Agenda

 

8 AM - 8:10 AM PT:  = Preliminaries

     Conference = issues/debugging

     Agenda bash

 

Requirements & Usage Scenarios (30 = minutes)

 

8:10 AM - 8:20 AM  PT MARTINI Requirements = Update, John Elwell (10 minutes)

http://tool= s.ietf.org/html/draft-elwell-martini-reqs

8:20 AM – 8:30 AM  PT Service Provider = Perspective, Martin Dolly (10 minutes)

8:30 AM – 8:40 AM  PT MARTINI Usage Scenarios, Adam Roach (10 minutes)

 

Solution Updates (30 minutes)

 

8:40 AM – 9:00 AM PT, MARTINI with Globally = Identifiable Numbers, Adam Roach (20 minutes)

http://tools.= ietf.org/html/draft-roach-martini-gin

 

9:00 AM – 9:10 AM PT, MARTINI Shaken =  Update, Hadriel Kaplan (10 minutes)

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

 

Discussion (30 minutes)

 

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

 

Wrap-up (20 minutes)

 

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

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

------=_NextPart_000_00DB_01CAA58E.D619BAF0-- From adam@nostrum.com Thu Feb 4 11:41: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 D280F28C174 for ; Thu, 4 Feb 2010 11:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 kARLuJxUvTz4 for ; Thu, 4 Feb 2010 11:41: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 6F5BE28C1AA for ; Thu, 4 Feb 2010 11:41:58 -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 o14Jgfoo036126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Feb 2010 13:42:42 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6B2331.6050209@nostrum.com> Date: Thu, 04 Feb 2010 13:42:41 -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: <4B68BEB4.2020207@nostrum.com> <4B6991B1.1040806@nostrum.com> <430FC6BDED356B4C8498F634416644A917E5E0E121@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5E0E121@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 19:42:00 -0000 On 2/4/10 12:20 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of Adam Roach >> Sent: Wednesday, February 03, 2010 10:10 AM >> >> On 2/3/10 4:12 AM, Elwell, John wrote: >> >>> 3. I have a concern about the public GRUU solution. Suppose a UA >>> >> registered with the PBX uses one of these permanent GRUUs, and some other >> on-PBX UA ends up making an out-of-dialog request back to that GRUU. It >> seems the PBX would be required to route via the SSP, resulting in a >> hairpin. >> >>> >> Yes, a naïve implementation would do that, and the signaling (but not >> the media) would end up going through the SSP. Everything would work >> okay, although the SSP would have to suffer through one (!) additional >> SIP message and its responses. >> >> But this hairpinning isn't necessary. I'm assuming that all of those >> terminals will send outgoing requests through the PBX. This would give >> the PBX the opportunity, if it wanted, to optimize this hairpin: it >> would trivially be able to recognize the R-URI as matching the public >> GRUU it received from the SSP (there will be only one, so it's not an >> expensive comparison), and process it locally without sending it to the >> SSP. >> > I think we should mandate that behavior... I think we should ensure that the MARTINI mechanism doesn't preclude that behavior. And none of the proposals so far have precluded that behavior. Mandating that behavior is more architectural. It's the kind of thing you might see come out of a body that defines concrete architectures -- like 3GPP, ETSI, PacketCable, SIPForum, etc. > ...because hair-pinning it through the SSP would be bad. One of the definitions of a "PBX" is that it handles local calls locally, and the SSP is not going to expect or want the extra signaling. (and arguably the Enterprise shouldn't want the SSP involved in them either) > I agree. It's a good implementation choice to make. > >> It's pretty much the same behavior as recognizing a normal, non-GRUU URI >> as one of its own extensions and handling it locally instead of routing >> to the SSP. >> > You mean if a phone off the pbx sends a request to number@SSP.com and the PBX says "hey, I have that number", then it's ok for it to route the request locally and not send it to the SSP? I didn't see that in the draft. As with the other (related) issue, I don't think that's in scope for either the mechanism or for MARTINI. /a From bernard_aboba@hotmail.com Thu Feb 4 11: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 25F6428C1CE for ; Thu, 4 Feb 2010 11:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 bop2VrzlxCqR for ; Thu, 4 Feb 2010 11:42:32 -0800 (PST) Received: from blu0-omc4-s11.blu0.hotmail.com (blu0-omc4-s11.blu0.hotmail.com [65.55.111.150]) by core3.amsl.com (Postfix) with ESMTP id 5FE2D28C1CA for ; Thu, 4 Feb 2010 11:42:32 -0800 (PST) Received: from BLU137-DS5 ([65.55.111.136]) by blu0-omc4-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 11:43:19 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Hadriel Kaplan'" , References: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> Date: Thu, 4 Feb 2010 11:43:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-index: Acqlv1lb1gvPYgWpSLGpdYpyRbcanwAEul0g X-OriginalArrivalTime: 04 Feb 2010 19:43:19.0598 (UTC) FILETIME=[4D8864E0:01CAA5D2] Subject: Re: [martini] Can we remove draft-stirred? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 19:42:33 -0000 +1. No interest in stirred here. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Thursday, February 04, 2010 9:28 AM To: martini@ietf.org Subject: [martini] Can we remove draft-stirred? Howdy, I proposed removing draft-stirred from consideration at the last virtual meeting, but got shot down. Since then no one has advocated it over the others (in fact, most of the arguments have been against it, afaict, and have been confusing it with draft-shaken). So can we please remove that draft now, so we can focus on the others? -hadriel From adam@nostrum.com Thu Feb 4 11:44: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 49CE728C128 for ; Thu, 4 Feb 2010 11:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 b2KkZilcOaDU for ; Thu, 4 Feb 2010 11:44: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 1C8813A67AC for ; Thu, 4 Feb 2010 11:44:43 -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 o14JjSDB036395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Feb 2010 13:45:28 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6B23D8.5010402@nostrum.com> Date: Thu, 04 Feb 2010 13:45:28 -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: Bernard Aboba References: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> 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] Can we remove draft-stirred? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 19:44:45 -0000 +1 /a On 2/4/10 1:43 PM, Bernard Aboba wrote: > +1. No interest in stirred here. > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Thursday, February 04, 2010 9:28 AM > To: martini@ietf.org > Subject: [martini] Can we remove draft-stirred? > > Howdy, > I proposed removing draft-stirred from consideration at the last virtual > meeting, but got shot down. Since then no one has advocated it over the > others (in fact, most of the arguments have been against it, afaict, and > have been confusing it with draft-shaken). > So can we please remove that draft now, so we can focus on the others? > > -hadriel > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From bernard_aboba@hotmail.com Thu Feb 4 11:45: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 C2CA43A67AC for ; Thu, 4 Feb 2010 11:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-0.927, 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 k+0qD4Cr-dDe for ; Thu, 4 Feb 2010 11:45:42 -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 BD0A43A6812 for ; Thu, 4 Feb 2010 11:45:42 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.72]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 11:46:30 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Thu, 4 Feb 2010 11:46:35 -0800 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-index: Acql0pu2ZlMdDPubTEO2m66tPhtQXwAACa1Q X-OriginalArrivalTime: 04 Feb 2010 19:46:30.0001 (UTC) FILETIME=[BF059610:01CAA5D2] Subject: [martini] MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 19:45:43 -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:20100204T194635Z DESCRIPTION:When: Tuesday\, March 02\, 2010 10:00 AM-12:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: Cyberspace\n\nNote: The GMT offset abov e does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~ *\n\nDetails TBD. \n DTEND:20100302T200000Z DTSTAMP:20100204T194635Z DTSTART:20100302T180000Z LAST-MODIFIED:20100204T194635Z LOCATION:Cyberspace ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:0 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim IV TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E008000000009007938D8FA5CA01000000000000000 0100000001F815CB7E59A144492451C2E670E961A X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Tuesday\, March 02\, 2010 10:00 AM-12:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Cyberspace

\n\n

< SPAN LANG="en-us">Note: The GMT offset above does not reflect daylight saving time adjustments.

\n\n

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

\n\n

Details TBD.

\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 adam@nostrum.com Thu Feb 4 12:08: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 EC1693A6E1A for ; Thu, 4 Feb 2010 12:08:14 -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 iMcn2AXIZ9Qi for ; Thu, 4 Feb 2010 12:08: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 A48733A6CD5 for ; Thu, 4 Feb 2010 12:08:13 -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 o14K8t1M038151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Feb 2010 14:08:55 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6B2957.4000209@nostrum.com> Date: Thu, 04 Feb 2010 14:08:55 -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: <430FC6BDED356B4C8498F634416644A917E5E0E11A@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5E0E11A@mail> 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-roach-martini-gin-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, 04 Feb 2010 20:08:15 -0000 On 2/4/10 11:53 AM, Hadriel Kaplan wrote: > Hi Adam, > Thanks for taking the time to write up the draft! > > I have a few comments/questions: > 1) Why bother having the "()" indicator in the Contact-URI username? This implies that the Contact-URI could be "sip:foo()bar@192.0.2.1", or something similar, such that a placeholder is needed. But why do we need to complicate the mechanism to handle that? The PBX can already use URI params if it needs extra cookies, or it can even insert itself as a Path header. I do, though, think the explicitly Registered contact-URI could be of the form "sip:foobar@192.0.2.1", and have a username - but it would be replaced for the expanded entries. What would the username do in your example? If we get rid of the '()' syntax, then I'd propose heading directly for URIs of the form instead. But I think the ability for the PBX to specify the form of its own contact URIs (even if constrained by having the entire phone number inserted) is still a useful one. I had originally toyed around with the idea of the PBX expressing a number of digits it was interested in -- for example: would transform into , but this seemed to be getting a bit complicated for the short timeframes we're applying. > 2) Why bother having the "*" indicator for GRUU? We've talked about doing the GRUU manip that way (by having the pbx add on to the one the SSP gives it), but by either adding the pbx-specifics as a new param, or simple appending. Again I don't see a need to support something like "uuid:foo*bar" (in fact it would be really bad to do that), so if it's always appending to the end then you don't need a star. > That's a good point. I'll remove the "*" mechanism, and simply propose appending in all cases. > 3) Why does the Contact-URI have a 'bnc' param, instead of in the AoR being Registered? ISTM the expansion of the location service entries is actually a property of the AoR, not its location/contact. No, it's the Contact URI that's having something special done to it. We're saying "explode this URI into a bunch of different URIs according to this new procedure." It means "this is not the actual URI; it is a placeholder for the actual URI, and it must be modified to be the actual URI." > And if we have [a 'bnc' parameter] in the contact-uri, why remove it for the req-uri replacement? > As before: it means, "This is not the literal value of the URI to be used. You cannot use this URI as-is. You must transform this URI by putting a phone number in the correct place before you can use it." After the replacement takes place, this is no longer true. It's just a normal URI at that point. > 4) Wrt the open issue of proxy-require, yes I think we should have that too, for the reasons we've discussed before on this list. > I agree. But I didn't see a clear consensus on that point (and did see some pushback), so I wanted to leave it open for now. /a From bernard_aboba@hotmail.com Thu Feb 4 12:12: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 6037D3A6E27 for ; Thu, 4 Feb 2010 12:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=-0.909, 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 EuFUbPZ-CGf8 for ; Thu, 4 Feb 2010 12:12:55 -0800 (PST) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by core3.amsl.com (Postfix) with ESMTP id 26CD43A6E1D for ; Thu, 4 Feb 2010 12:12:52 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.73]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 12:13:39 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Thu, 4 Feb 2010 12:13:45 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F7_01CAA593.7FC9AF20" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-index: Acql1o2jdCNiINCQRs+ArPWshJOg8g== X-OriginalArrivalTime: 04 Feb 2010 20:13:39.0000 (UTC) FILETIME=[89FB1B80:01CAA5D6] Subject: [martini] Request for Review: New Drafts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 04 Feb 2010 20:12:56 -0000 ------=_NextPart_000_00F7_01CAA593.7FC9AF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As you may have noticed, MARTINI Virtual Interim III has a section of the agenda devoted to discussion of new drafts, including: http://tools.ietf.org/html/draft-elwell-martini-reqs-00 http://tools.ietf.org/html/draft-roach-martini-gin-00 To ensure that discussion is productive, we would like to strongly encourage attendees to read these documents, and post their comments to the list. ------=_NextPart_000_00F7_01CAA593.7FC9AF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As you may have noticed, MARTINI Virtual Interim = III has a section of the agenda devoted to discussion of new drafts, = including:

http://tools.ietf.org/html/draft-elwell-martini-reqs-00=

http://tools.ietf.org/html/draft-roach-martini-gin-00

 

To ensure that discussion is productive, we would = like to strongly encourage attendees to read these documents, and post their = comments to the list.

------=_NextPart_000_00F7_01CAA593.7FC9AF20-- From dean.willis@softarmor.com Thu Feb 4 21:17: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 4DB113A6B81 for ; Thu, 4 Feb 2010 21:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 DvSvXGJcri-r for ; Thu, 4 Feb 2010 21:17:17 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 635793A6A48 for ; Thu, 4 Feb 2010 21:17:17 -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 o155Hrvk028399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:18:00 -0600 Message-Id: From: Dean Willis To: Christer Holmberg 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, 4 Feb 2010 23:17:47 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <4B670F85.4030808@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" , Hadriel Kaplan 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, 05 Feb 2010 05:17:18 -0000 On Feb 2, 2010, at 12:12 AM, Christer Holmberg wrote: > > Hi, > >>> 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 beg to differ. The contact address is the ultimate target. >> There have been many documents pointing that out. >> And as long as you register each AOR independently it can be >> handled very cleanly. > > In my opinion Contact is not meant to be used for informing the UA > about what number was called etc in order to reach the UA. No, but it IS the mechanism that a proxy uses to select the UA to which the INVITE should be sent. In other words it doesn't inform the UA as to which number was used; rather it informs the UA as to which handset to alert. > >>> I also think it is a very "clumsy" solution, when you >>> mandate a 1-to-1 mapping of the R-URI/Contact userpart values >>> (maybe it could also have security impacts). >> >> Its clumsy precisely because of implicit registration. >> Adam's proposal provided a way to do that mapping under the >> control of the recipient so that only expected contact >> addresses are used. > > Again, as far as I understand, from a SIP network perspective the > PBX only has a single contact. That depends on the PBX, doesn't it? -- Dean From dean.willis@softarmor.com Thu Feb 4 21:19: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 B39413A6B69 for ; Thu, 4 Feb 2010 21:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 TAFd5dK4csNU for ; Thu, 4 Feb 2010 21:19:35 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B82023A6A48 for ; Thu, 4 Feb 2010 21:19:35 -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 o155KIk2028437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:20:20 -0600 Message-Id: <031B4639-7A63-434C-83EB-DE288E238A3D@softarmor.com> From: Dean Willis To: Christer Holmberg 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, 4 Feb 2010 23:20:13 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: Hadriel Kaplan , "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, 05 Feb 2010 05:19:36 -0000 On Feb 2, 2010, at 2:18 AM, Christer Holmberg wrote: > > > But, what if the PBX is using outbound? I assume the same instance > id and gr values are going to be used for all PBX users, eventhough > each PBX user has a unique Contact within the SSP? > I wouldn't think so: we should have a separate instance ID and gruu value for each "user" -- it's the only way I can see to make call transfers work right. -- Dean From dean.willis@softarmor.com Thu Feb 4 21: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 330EA3A6A48 for ; Thu, 4 Feb 2010 21:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 dnz9WR-Jbrlu for ; Thu, 4 Feb 2010 21:25:17 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5EA153A68FE for ; Thu, 4 Feb 2010 21:25:17 -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 o155Pu2d028470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:26:02 -0600 Message-Id: <96495901-30AA-4CE7-A59D-0D414D80E356@softarmor.com> From: Dean Willis To: Doug Sauder In-Reply-To: <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.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, 4 Feb 2010 23:25:51 -0600 References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> X-Mailer: Apple Mail (2.936) Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 05:25:18 -0000 On Feb 2, 2010, at 4:15 AM, Doug Sauder wrote: > Dean, > > I disagree with the PBX claiming its AORs at the SSP through a > registration. I think this kind of "provisioning" is backwards > compared to what real SSPs want. In my experience, subscribers are > provisioned at the SSP, and it's a goal to have the PBX provisioned > through some kind of auto-provisioning. For example, the PBX uses > HTTP or FTP to get its configuration information from a server > maintained by the SSP. This is how the PBX discovers its AORs, > extensions, and so forth. It might not be this way in every > deployment, but I believe it's where the SMB-market service > providers want to go. > > Your approach seems to suggest that provisioning happens at the PBX, > and it is then "pushed" to the SSP. > > I think the implicit registration is a better alternative, > especially when such auto-provisioning is deployed. > No, no, no, no no. Registration is NOT provisioning. Registration is the process by which a provisioned identity is mapped to an ephemeral IP address and port number, also known as a "contact". Provisioning tells the SSP's system about which phone numbers to accept and who is authorized to use those numbers and how they are authenticated. So, assume the SSP gets "provisioned", and the PBX might use some sort of autoconfiguration mechanism (like an HTTP GET) to pull the config file telling the PBX which phone numbers it should REGISTER for and how to map the phone numbers to contacts on the PBX. -- Dean From dean.willis@softarmor.com Thu Feb 4 21:28: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 A046E3A6B7E for ; Thu, 4 Feb 2010 21:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 zN+QcWSTnWkc for ; Thu, 4 Feb 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 DFB993A6B79 for ; Thu, 4 Feb 2010 21:28:43 -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 o155TPIw028506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:29:28 -0600 Message-Id: <0E006E68-093A-4D22-ADE2-A54F3AB4B93E@softarmor.com> From: Dean Willis To: Jack Burton In-Reply-To: <4B68270C.6D98.00CB.0@cablevision.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, 4 Feb 2010 23:29:20 -0600 References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> <4B68270C.6D98.00CB.0@cablevision.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 05:28:44 -0000 On Feb 2, 2010, at 7:22 AM, Jack Burton wrote: > How does the PBX learn its outbound numbers and DIDs when it > registers? It needs to know this for more than just registration. > I am not counting on registration as a configuration tool, just as a > way to authenticate and identify the IP-PBX to the SSP. > The PBX does NOT learn its numbers through registration. It has to know them already so it can register them and so the SSP knows what IP address and port to send calls to. The question of "How does the PBX learn its numbers" is entirely outside the current scope of MARTINI. -- Dean From dean.willis@softarmor.com Thu Feb 4 21:29: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 2C8FF28C0CE for ; Thu, 4 Feb 2010 21:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 H39oBRcyBe0B for ; Thu, 4 Feb 2010 21:29:22 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6CEDD3A6B67 for ; Thu, 4 Feb 2010 21:29:22 -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 o155TPIx028506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:30:05 -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: Thu, 4 Feb 2010 23:30:04 -0600 References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> <3DF106C5-3CAA-480C-9ACE-8909CA16E667@dsauder.com> <4B682BA2.6D98.00CB.0@cablevision.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 05:29:23 -0000 On Feb 2, 2010, at 9:04 AM, Elwell, John wrote: > > > [JRE] I agree. A single AOR in the REGISTER request should be > sufficient to cover the needs of MARTINI. > > And then how are you going to provide a discrete GRUU for each extension so that call-transfer stuff works? -- Dean From dean.willis@softarmor.com Thu Feb 4 21:34: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 E2B6D3A6B8F for ; Thu, 4 Feb 2010 21:34:35 -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.200, 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 KI3xVUTO33Rt for ; Thu, 4 Feb 2010 21:34:35 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0C44F3A6B88 for ; Thu, 4 Feb 2010 21:34:34 -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 o155Z6Mp028560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:35:22 -0600 From: Dean Willis To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> Message-Id: <636E316F-E670-4B2D-A578-E5C22B5B78CD@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: Thu, 4 Feb 2010 23:34:59 -0600 X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs (was: Re: 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, 05 Feb 2010 05:34:36 -0000 On Feb 2, 2010, at 11:24 AM, Spencer Dawkins wrote: > > > > So, just to check consensus here ... is anyone willing to argue > AGAINST dropping TEL URIs from consideration? I haven't seen support > for basing a solution on TEL URIs on-list, and I don't want us to > head down blind alleys if no one is following ... > > Thanks, > > Spencer > > I continue to support TEL as the cleanest solution. It's what people really want and don't know how to ask for, kind of like one of those Cosmo quiz things. If all you want is "a phone number" without the overhead of "domain ownership" then you really do want TEL. Yes, we don't have a history of doing it the right way. We could always start. -- Dean From dean.willis@softarmor.com Thu Feb 4 21:39: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 69F5B3A6B93 for ; Thu, 4 Feb 2010 21:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 77upqITeIeur for ; Thu, 4 Feb 2010 21:39:25 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3BE2F3A6B90 for ; Thu, 4 Feb 2010 21:39:25 -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 o155dpCe028611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:39:54 -0600 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <4B6870C1.8090502@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: Thu, 4 Feb 2010 23:39:45 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 05:39:27 -0000 On Feb 2, 2010, at 12:36 PM, Adam Roach wrote: > On 2/2/10 11:24, Feb 2, Spencer Dawkins wrote: >> >> So, just to check consensus here ... is anyone willing to argue >> AGAINST dropping TEL URIs from consideration? > > Although I was originally thinking this was the best way forward, I > have concluded that we can achieve the same effect using SIP URIs, > if *and* *only* *if* we use the PBX's IP address as the host > portion. I think we can all agree that the PBX is uniquely > responsible for URIs addressed to the PBX's IP address. I'm still not sure I but this. For example, the PBX might have a valid DNS name, that just isn't interesting from a "company name" perspective. For example, my "PBX" is currently using cpe-66-25-30-183.tx.res.rr.com, which it discovers by doing a PTR lookup on its IP address. It's a perfectly valid thing to use to populate a Contact, even though it has only an ephemeral relationship with "softarmor.mine.nu". -- Dean From dean.willis@softarmor.com Thu Feb 4 21:42: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 4B0703A6B9C for ; Thu, 4 Feb 2010 21:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 L6oilNgILVho for ; Thu, 4 Feb 2010 21:42:35 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 80CBF3A6B8F for ; Thu, 4 Feb 2010 21:42:35 -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 o155hCkx028665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:43:18 -0600 Message-Id: From: Dean Willis To: Richard Shockey In-Reply-To: <003201caa443$5c12f1f0$1438d5d0$@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: Thu, 4 Feb 2010 23:43:06 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> <14C85D6CCBE92743AF33663BF5D24EBA0582965C@gaalpa1msgusr7e.ugd.att.com> <003201caa443$5c12f1f0$1438d5d0$@us> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org, 'Hadriel Kaplan' 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, 05 Feb 2010 05:42:36 -0000 On Feb 2, 2010, at 2:07 PM, Richard Shockey wrote: > +1 Thank you Marty ..that is the central problem. > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf > Of DOLLY, MARTIN C (ATTLABS) > Sent: Monday, February 01, 2010 8:50 PM > To: Dean Willis; Christer Holmberg > Cc: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] Proposed work split: > tackletelephone-numberregistration first > > Every user registering is not implementable. > Dangit Richard! I never suggested that every user register. As far as I know, NOBODY has suggested that. I suggested (based on Adam's work) that the PBX send a single registration that creates multiple AOR/Contact/GRUU bindings in the SSP proxy, and that the SSP proxy work just exactly like an ordinary proxy when handling requests following the registration. -- Dean From dean.willis@softarmor.com Thu Feb 4 21: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 AF4FF3A6CAE for ; Thu, 4 Feb 2010 21:46:10 -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 kZ6ZXgVQqTQv for ; Thu, 4 Feb 2010 21:46:09 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A1F693A6CAA for ; Thu, 4 Feb 2010 21:46:05 -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 o155knb9028720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:46:52 -0600 Message-Id: <7A1ECB82-1B00-4F8D-A3B0-1DCB1D0EC195@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B6891D8.8030801@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, 4 Feb 2010 23:46:43 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> <4B6891D8.8030801@cisco.com> X-Mailer: Apple Mail (2.936) Cc: 'Hadriel Kaplan' , martini@ietf.org Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 05:46:10 -0000 On Feb 2, 2010, at 2:58 PM, Paul Kyzivat wrote: > Adam, > > I just posted a reply to david that is a different spin, but getting > at the same point. Specifically, if a domain name is used, the SSP > needs a way to know, legally, that the pbx customer is entitled to > that domain name, and that can be a problem. > If a domain name is used in a Contact, then no, the SSP doesn't need to know that a PBX customer is entitled to use that domain. We don't have any way in SIP to check for authorization at the Contact level based on DNS name or IP address. If a user PBX installed at an IP address having an associated A record for "cisco.com" sends a REGISTER request with a "To:" of "baynetworks.com", and that PBX has the authentication credentials for baynetworks.com, then it can register! -- Dean From dean.willis@softarmor.com Thu Feb 4 21:50: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 9969F3A680A for ; Thu, 4 Feb 2010 21:50:53 -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.096, 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 tB-J82MXwsqW for ; Thu, 4 Feb 2010 21:50:53 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E1CBA3A67F2 for ; Thu, 4 Feb 2010 21:50:52 -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 o155pciE028753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:51:40 -0600 Message-Id: From: Dean Willis To: Bernard Aboba 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, 4 Feb 2010 23:51:33 -0600 References: <4B6767A4.8000008@nostrum.com> <76AC5FEF83F1E64491446437EA81A61F7CD4B2A867@srvxchg> <4B689107.9060301@cisco.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Use Cases: what's important, what's not X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 05:50:53 -0000 On Feb 2, 2010, at 4:23 PM, Bernard Aboba wrote: > [BA] I think we're conflating multiple distinct things here. > > One thing is the use of a domain name in the Contact URI. > This is already legal in a single AOR registration; however > before doing "Contact routing", the SSP should check that the > A/AAAA RR corresponding to the domain name corresponds to the > address from which the PBX registration arrived. Of course, the > same check needs to be made if the PBX used an address within > the domain portion of the Contact URI, so the domain name case > only adds a name resolution step. > Not necessarily true. Third party registration is perfectly valid (although somewhat useless with Outbound). It's also possible that an intervening proxy will cause the request to reach the registrar in a packet sourced from a different IP address, so in general requiring that the name used in the Contact resolve to the address from which the request was received is not a feasible solution. -- Dean From dean.willis@softarmor.com Thu Feb 4 21:56: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 0003A3A63D3 for ; Thu, 4 Feb 2010 21:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 FGYb4Jth6-y0 for ; Thu, 4 Feb 2010 21:56:37 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 48F4F3A62C1 for ; Thu, 4 Feb 2010 21:56:37 -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 o155vMi0028809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2010 23:57:25 -0600 Message-Id: <4B75C0E0-7BEB-4591-8F73-932B26E57E5D@softarmor.com> 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: Thu, 4 Feb 2010 23:57:16 -0600 References: <4B68BEB4.2020207@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 05:56:38 -0000 On Feb 3, 2010, at 4:12 AM, Elwell, John wrote: > 3. I have a concern about the public GRUU solution. Suppose a UA > registered with the PBX uses one of these permanent GRUUs, and some > other on-PBX UA ends up making an out-of-dialog request back to that > GRUU. It seems the PBX would be required to route via the SSP, > resulting in a hairpin. > The PBX needs a table for mapping SSP-minted GRUUs to local contacts so that it can handle local routing without hairpinning. -- Dean From dean.willis@softarmor.com Thu Feb 4 22:07: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 5D4F53A679C for ; Thu, 4 Feb 2010 22:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 5H4nlFgHbYZB for ; Thu, 4 Feb 2010 22:07:02 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2B3593A63D3 for ; Thu, 4 Feb 2010 22:07:02 -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 o1567fuL028901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Feb 2010 00:07:46 -0600 Message-Id: From: Dean Willis To: Dean Willis 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, 5 Feb 2010 00:07:35 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: 'Hadriel Kaplan' , martini@ietf.org Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 06:07:03 -0000 On Feb 4, 2010, at 11:39 PM, Dean Willis wrote: > > On Feb 2, 2010, at 12:36 PM, Adam Roach wrote: > >> On 2/2/10 11:24, Feb 2, Spencer Dawkins wrote: >>> >>> So, just to check consensus here ... is anyone willing to argue >>> AGAINST dropping TEL URIs from consideration? >> >> Although I was originally thinking this was the best way forward, I >> have concluded that we can achieve the same effect using SIP URIs, >> if *and* *only* *if* we use the PBX's IP address as the host >> portion. I think we can all agree that the PBX is uniquely >> responsible for URIs addressed to the PBX's IP address. > > I'm still not sure I but Buy, not but ! mean I'm not sure I BUY this (aka, I think it's not true). > this. For example, the PBX might have a valid DNS name, that just > isn't interesting from a "company name" perspective. For example, my > "PBX" is currently using cpe-66-25-30-183.tx.res.rr.com, which it > discovers by doing a PTR lookup on its IP address. It's a perfectly > valid thing to use to populate a Contact, even though it has only an > ephemeral relationship with "softarmor.mine.nu". -- Dean, the typing impaired. From john.elwell@siemens-enterprise.com Thu Feb 4 23:15: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 4E8BB3A6EB5 for ; Thu, 4 Feb 2010 23:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 XaVzeSgkB8ch for ; Thu, 4 Feb 2010 23:15:28 -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 1340A3A6EAC for ; Thu, 4 Feb 2010 23:15:27 -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-786741; Fri, 5 Feb 2010 08:16:15 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 8B90223F028E; Fri, 5 Feb 2010 08:16:15 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Feb 2010 08:16:15 +0100 From: "Elwell, John" To: Adam Roach , Hadriel Kaplan Date: Fri, 5 Feb 2010 08:16:14 +0100 Thread-Topic: [martini] GIN Draft Thread-Index: Acql0jtq5FQVg2m3RqaManC+oQPf+gAYL40g Message-ID: References: <4B68BEB4.2020207@nostrum.com> <4B6991B1.1040806@nostrum.com> <430FC6BDED356B4C8498F634416644A917E5E0E121@mail> <4B6B2331.6050209@nostrum.com> In-Reply-To: <4B6B2331.6050209@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 Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 07:15:29 -0000 Yes, I think as long as these things are possible and reasonable, they can = be left out of scope of MARTINI and perhaps specified in SIPconnect 1.1. John=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 04 February 2010 19:43 > To: Hadriel Kaplan > Cc: Elwell, John; MARTINI > Subject: Re: [martini] GIN Draft >=20 > On 2/4/10 12:20 PM, Hadriel Kaplan wrote: > > > > =20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf > >> Of Adam Roach > >> Sent: Wednesday, February 03, 2010 10:10 AM > >> > >> On 2/3/10 4:12 AM, Elwell, John wrote: > >> =20 > >>> 3. I have a concern about the public GRUU solution. Suppose a UA > >>> =20 > >> registered with the PBX uses one of these permanent GRUUs,=20 > and some other > >> on-PBX UA ends up making an out-of-dialog request back to=20 > that GRUU. It > >> seems the PBX would be required to route via the SSP,=20 > resulting in a > >> hairpin. > >> =20 > >>> =20 > >> Yes, a na=EFve implementation would do that, and the=20 > signaling (but not > >> the media) would end up going through the SSP. Everything=20 > would work > >> okay, although the SSP would have to suffer through one=20 > (!) additional > >> SIP message and its responses. > >> > >> But this hairpinning isn't necessary. I'm assuming that=20 > all of those > >> terminals will send outgoing requests through the PBX.=20 > This would give > >> the PBX the opportunity, if it wanted, to optimize this hairpin: it > >> would trivially be able to recognize the R-URI as matching=20 > the public > >> GRUU it received from the SSP (there will be only one, so=20 > it's not an > >> expensive comparison), and process it locally without=20 > sending it to the > >> SSP. > >> =20 > > I think we should mandate that behavior... >=20 > I think we should ensure that the MARTINI mechanism doesn't preclude=20 > that behavior. And none of the proposals so far have precluded that=20 > behavior. >=20 > Mandating that behavior is more architectural. It's the kind of thing=20 > you might see come out of a body that defines concrete=20 > architectures --=20 > like 3GPP, ETSI, PacketCable, SIPForum, etc. >=20 > > ...because hair-pinning it through the SSP would be bad. =20 > One of the definitions of a "PBX" is that it handles local=20 > calls locally, and the SSP is not going to expect or want the=20 > extra signaling. (and arguably the Enterprise shouldn't want=20 > the SSP involved in them either) > > =20 >=20 > I agree. It's a good implementation choice to make. >=20 > > =20 > >> It's pretty much the same behavior as recognizing a=20 > normal, non-GRUU URI > >> as one of its own extensions and handling it locally=20 > instead of routing > >> to the SSP. > >> =20 > > You mean if a phone off the pbx sends a request to=20 > number@SSP.com and the PBX says "hey, I have that number",=20 > then it's ok for it to route the request locally and not send=20 > it to the SSP? I didn't see that in the draft. >=20 >=20 > As with the other (related) issue, I don't think that's in scope for=20 > either the mechanism or for MARTINI. >=20 > /a > = From john.elwell@siemens-enterprise.com Thu Feb 4 23:31: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 67BD13A6CFB for ; Thu, 4 Feb 2010 23:31:21 -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 4cW9u7fGAhTj for ; Thu, 4 Feb 2010 23:31:20 -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 52D6D3A6835 for ; Thu, 4 Feb 2010 23:31:19 -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-786838; Fri, 5 Feb 2010 08:32:08 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8663D1EB82AB; Fri, 5 Feb 2010 08:32:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 5 Feb 2010 08:32:08 +0100 From: "Elwell, John" To: Dean Willis , Christer Holmberg Date: Fri, 5 Feb 2010 08:32:06 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqmIu0iLOS4cM8JQdyk2QrG8VYUngAEiFlQ Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> <031B4639-7A63-434C-83EB-DE288E238A3D@softarmor.com> In-Reply-To: <031B4639-7A63-434C-83EB-DE288E238A3D@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] 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, 05 Feb 2010 07:31:21 -0000 There is a discussion of gr values in the gin draft. I don't see a need for= multiple instance IDs. John=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 05 February 2010 05:20 > To: Christer Holmberg > Cc: Elwell, John; martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 >=20 > On Feb 2, 2010, at 2:18 AM, Christer Holmberg wrote: >=20 > > > > > > But, what if the PBX is using outbound? I assume the same instance =20 > > id and gr values are going to be used for all PBX users,=20 > eventhough =20 > > each PBX user has a unique Contact within the SSP? > > >=20 > I wouldn't think so: we should have a separate instance ID and gruu =20 > value for each "user" -- it's the only way I can see to make call =20 > transfers work right. >=20 > -- > Dean >=20 > = From john.elwell@siemens-enterprise.com Thu Feb 4 23:43: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 83CBC3A6885 for ; Thu, 4 Feb 2010 23:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 i4pe56uz1CuS for ; Thu, 4 Feb 2010 23:43:44 -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 C30763A6C76 for ; Thu, 4 Feb 2010 23:43: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-786998; Fri, 5 Feb 2010 08:44:16 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 822C01EB82AB; Fri, 5 Feb 2010 08:44:16 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 5 Feb 2010 08:44:16 +0100 From: "Elwell, John" To: Bernard Aboba , "martini@ietf.org" Date: Fri, 5 Feb 2010 08:44:15 +0100 Thread-Topic: Requirements (RE: [martini] Martini Virtual Interim III Agenda - Take Five) Thread-Index: AcqlIjuP8MU3h68LTRupLCAC1b16yQAGQaOAACWSKTAAGUZX0A== 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_A444A0F8084434499206E78C106220CAB9210815MCHP058Aglobala_" MIME-Version: 1.0 Subject: [martini] Requirements (RE: Martini Virtual Interim III Agenda - Take Five) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 07:43:50 -0000 --_000_A444A0F8084434499206E78C106220CAB9210815MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't want to spend too long on the Requirements draft - just check wheth= er it can be adopted as work item. So if you have any issues you want to di= scuss in that 10 minute slot, please raise them on the list. John ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: 04 February 2010 19:40 To: martini@ietf.org Subject: [martini] Martini Virtual Interim III Agenda - Take Five MARTINI Virtual Interim III February 9, 2010 8 AM - 10 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III= / Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archi= ve/web/martini/current/msg00238.html Agenda 8 AM - 8:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements & Usage Scenarios (30 minutes) 8:10 AM - 8:20 AM PT MARTINI Requirements Update, John Elwell (10 minutes) http://tools.ietf.org/html/draft-elwell-martini-reqs 8:20 AM - 8:30 AM PT Service Provider Perspective, Martin Dolly (10 minute= s) 8:30 AM - 8:40 AM PT MARTINI Usage Scenarios, Adam Roach (10 minutes) Solution Updates (30 minutes) 8:40 AM - 9:00 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roac= h (20 minutes) http://tools.ietf.org/html/draft-roach-martini-gin 9:00 AM - 9:10 AM PT, MARTINI Shaken Update, Hadriel Kaplan (10 minutes) http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registratio= ns Discussion (30 minutes) 9:10 AM - 9:40 AM PT Discussion: Participants (30 minutes) Wrap-up (20 minutes) 9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes) 9:55 AM - 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) --_000_A444A0F8084434499206E78C106220CAB9210815MCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't want to spend too long on the Requiremen= ts=20 draft - just check whether it can be adopted as work item. So if you have a= ny=20 issues you want to discuss in that 10 minute slot, please raise them on the= =20 list.
 
John

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 04 February 2010 19:40
To:=20 martini@ietf.org
Subject: [martini] Martini Virtual Interim III= =20 Agenda - Take Five

MARTINI Virtual Interim III

February 9, 2010

8 AM – 10 AM Pacific Time

 

Conferencing Details:

 

Slide Presentations:  http://ww= w.drizzle.com/~aboba/MARTINI/Jan-Interim-III/

Jabber room:  martini at jabber.ietf.org (Pleas= e=20 join)

Dial in Audioconference and WebEx details: &nbs= p; http://www.ietf.org/mail-archive/web/martini/current/msg00238.html

 

Agenda

 

8 AM - 8:10 AM PT:  Preliminaries

     Conference=20 issues/debugging

     Agenda bash

 

Requirements & Usage Scenarios (30=20 minutes)

 

8:10 AM - 8:20 AM  PT MARTINI Requirements Upda= te,=20 John Elwell (10 minutes)

http://tool= s.ietf.org/html/draft-elwell-martini-reqs

8:20 AM – 8:30 AM  PT Service Provider Pe= rspective,=20 Martin Dolly (10 minutes)

8:30 AM – 8:40 AM  PT MARTINI Usage Scenarios, Adam Roach (10=20 minutes)

 

Solution Updates (30 minutes)

 

8:40 AM – 9:00 AM PT, MARTINI with Globally Id= entifiable=20 Numbers, Adam Roach (20 minutes)

http://tools.= ietf.org/html/draft-roach-martini-gin=20

 

9:00 AM – 9:10 AM PT, MARTINI Shaken  Upd= ate, Hadriel=20 Kaplan (10 minutes)

http://tools.ietf.org/html/draft-kaplan-martini-shaken-implic= it-registrations

 

Discussion (30 minutes)

 

9:10 AM – 9:40 AM  PT Discussion:  P= articipants=20 (30 minutes)

 

Wrap-up (20 minutes)

 

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

9:55 AM – 10:00 AM PT   Next Steps:&= nbsp; WG=20 Chairs & ADs (5 minutes)

--_000_A444A0F8084434499206E78C106220CAB9210815MCHP058Aglobala_-- From john.elwell@siemens-enterprise.com Fri Feb 5 00:03: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 D88BB28C0FB for ; Fri, 5 Feb 2010 00:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 aJlqhMDaDE-t for ; Fri, 5 Feb 2010 00:03:54 -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 538DE28C116 for ; Fri, 5 Feb 2010 00:03:54 -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-787236; Fri, 5 Feb 2010 09:04:42 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 9B1B31EB82AB; Fri, 5 Feb 2010 09:04:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 5 Feb 2010 09:04:42 +0100 From: "Elwell, John" To: Adam Roach , Hadriel Kaplan Date: Fri, 5 Feb 2010 09:04:41 +0100 Thread-Topic: [martini] comments on draft-roach-martini-gin-00 Thread-Index: Acql1eciuAOr99uxQKmRA2/i/E5jYQAYmf4Q Message-ID: References: <430FC6BDED356B4C8498F634416644A917E5E0E11A@mail> <4B6B2957.4000209@nostrum.com> In-Reply-To: <4B6B2957.4000209@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] comments on draft-roach-martini-gin-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, 05 Feb 2010 08:03:56 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 04 February 2010 20:09 > To: Hadriel Kaplan > Cc: martini@ietf.org > Subject: Re: [martini] comments on draft-roach-martini-gin-00 >=20 > On 2/4/10 11:53 AM, Hadriel Kaplan wrote: > > Hi Adam, > > Thanks for taking the time to write up the draft! > > > > I have a few comments/questions: > > 1) Why bother having the "()" indicator in the Contact-URI=20 > username? This implies that the Contact-URI could be=20 > "sip:foo()bar@192.0.2.1", or something similar, such that a=20 > placeholder is needed. But why do we need to complicate the=20 > mechanism to handle that? The PBX can already use URI params=20 > if it needs extra cookies, or it can even insert itself as a=20 > Path header. I do, though, think the explicitly Registered=20 > contact-URI could be of the form "sip:foobar@192.0.2.1", and=20 > have a username - but it would be replaced for the expanded entries. >=20 > What would the username do in your example? If we get rid of the '()'=20 > syntax, then I'd propose heading directly for URIs of the form=20 > instead. But I think the ability for the PBX to=20 > specify the form of its own contact URIs (even if constrained=20 > by having=20 > the entire phone number inserted) is still a useful one. [JRE] Can we have some examples of why it would be useful? If useful, I wou= ld go for always appending the number to the user name, rather than having = special characters to denote the position of insertion. If not useful, then= the simple form above (no user name) would suffice. John >=20 > I had originally toyed around with the idea of the PBX expressing a=20 > number of digits it was interested in -- for example:=20 > would transform=20 > into=20 > , but this seemed to be getting a bit complicated=20 > for the short timeframes we're applying. >=20 > > 2) Why bother having the "*" indicator for GRUU? We've=20 > talked about doing the GRUU manip that way (by having the pbx=20 > add on to the one the SSP gives it), but by either adding the=20 > pbx-specifics as a new param, or simple appending. Again I=20 > don't see a need to support something like "uuid:foo*bar" (in=20 > fact it would be really bad to do that), so if it's always=20 > appending to the end then you don't need a star. > > =20 >=20 > That's a good point. I'll remove the "*" mechanism, and=20 > simply propose=20 > appending in all cases. >=20 > > 3) Why does the Contact-URI have a 'bnc' param, instead of=20 > in the AoR being Registered? ISTM the expansion of the=20 > location service entries is actually a property of the AoR,=20 > not its location/contact. >=20 > No, it's the Contact URI that's having something special done to it.=20 > We're saying "explode this URI into a bunch of different URIs=20 > according=20 > to this new procedure." It means "this is not the actual URI; it is a=20 > placeholder for the actual URI, and it must be modified to be=20 > the actual=20 > URI." >=20 > > And if we have [a 'bnc' parameter] in the contact-uri, why=20 > remove it for the req-uri replacement? > > =20 >=20 > As before: it means, "This is not the literal value of the URI to be=20 > used. You cannot use this URI as-is. You must transform this URI by=20 > putting a phone number in the correct place before you can use it." >=20 > After the replacement takes place, this is no longer true.=20 > It's just a=20 > normal URI at that point. >=20 > > 4) Wrt the open issue of proxy-require, yes I think we=20 > should have that too, for the reasons we've discussed before=20 > on this list. > > =20 >=20 > I agree. But I didn't see a clear consensus on that point=20 > (and did see=20 > some pushback), so I wanted to leave it open for now. >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Fri Feb 5 01:17: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 15F9A3A6D26 for ; Fri, 5 Feb 2010 01:17:17 -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 ocAvxQpWNobB for ; Fri, 5 Feb 2010 01:17: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 09D743A6C94 for ; Fri, 5 Feb 2010 01:17:15 -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-788722; Fri, 5 Feb 2010 10:18:04 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A5FEB1EB82AE; Fri, 5 Feb 2010 10:18:04 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Feb 2010 10:18:04 +0100 From: "Elwell, John" To: Dean Willis Date: Fri, 5 Feb 2010 10:18:03 +0100 Thread-Topic: [martini] Implications of multiple AOR/contact mapping Thread-Index: AcqmJEsDFXYC50W4QI+8AsklfIbewwAH8nLQ Message-ID: References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com> <0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com> <4B680653.6D98.00CB.0@cablevision.com> <3DF106C5-3CAA-480C-9ACE-8909CA16E667@dsauder.com> <4B682BA2.6D98.00CB.0@cablevision.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] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 09:17:17 -0000 See gin-00. John=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 05 February 2010 05:30 > To: Elwell, John > Cc: Jack Burton; Doug Sauder; martini@ietf.org > Subject: Re: [martini] Implications of multiple AOR/contact mapping >=20 >=20 > On Feb 2, 2010, at 9:04 AM, Elwell, John wrote: >=20 > > > > > > [JRE] I agree. A single AOR in the REGISTER request should be =20 > > sufficient to cover the needs of MARTINI. > > > > >=20 > And then how are you going to provide a discrete GRUU for each =20 > extension so that call-transfer stuff works? >=20 > -- > Dean >=20 > = From spencer@wonderhamster.org Fri Feb 5 03:45: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 5704E3A6BDA for ; Fri, 5 Feb 2010 03:45:25 -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.117, 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 iTA6fGjJpJ4H for ; Fri, 5 Feb 2010 03:45:24 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 3E6013A6880 for ; Fri, 5 Feb 2010 03:45:24 -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 0MEnze-1NXNPL0DbG-00Fzy0; Fri, 05 Feb 2010 06:46:09 -0500 Message-ID: From: "Spencer Dawkins" To: "Elwell, John" , "Adam Roach" , "Hadriel Kaplan" References: <4B68BEB4.2020207@nostrum.com><4B6991B1.1040806@nostrum.com><430FC6BDED356B4C8498F634416644A917E5E0E121@mail><4B6B2331.6050209@nostrum.com> Date: Fri, 5 Feb 2010 05:46:03 -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: V01U2FsdGVkX1+OVhg/x1HKhOdIacpwlKsmIXGTDUa0OtoL/mY SYSdZCGPCSLkk7sOZaYeVw8Ke3gpgGxwx59ZsWH+09dPLXJuq6 qiTRWumGG67a2AJLfU2fIhQpEs6Rt5Ra+F5efUEVAE= Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 11:45:25 -0000 Adam, I appreciate the nudge in the direction of "does not preclude", and agree with your reasoning ("more architectural than we usually get in the IETF"). Just to be clear - are you suggesting that we can say "does not preclude" in a MARTINI specification? I would like to see that level of discussion captured, so we don't spend the next few years answering the question "did you guys think about hairpinning?" :-) Thanks, Spencer ----- Original Message ----- From: "Elwell, John" To: "Adam Roach" ; "Hadriel Kaplan" Cc: "MARTINI" Sent: Friday, February 05, 2010 1:16 AM Subject: Re: [martini] GIN Draft Yes, I think as long as these things are possible and reasonable, they can be left out of scope of MARTINI and perhaps specified in SIPconnect 1.1. John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 04 February 2010 19:43 > To: Hadriel Kaplan > Cc: Elwell, John; MARTINI > Subject: Re: [martini] GIN Draft > > On 2/4/10 12:20 PM, Hadriel Kaplan wrote: > > > > > >> -----Original Message----- > >> From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf > >> Of Adam Roach > >> Sent: Wednesday, February 03, 2010 10:10 AM > >> > >> On 2/3/10 4:12 AM, Elwell, John wrote: > >> > >>> 3. I have a concern about the public GRUU solution. Suppose a UA > >>> > >> registered with the PBX uses one of these permanent GRUUs, > and some other > >> on-PBX UA ends up making an out-of-dialog request back to > that GRUU. It > >> seems the PBX would be required to route via the SSP, > resulting in a > >> hairpin. > >> > >>> > >> Yes, a naïve implementation would do that, and the > signaling (but not > >> the media) would end up going through the SSP. Everything > would work > >> okay, although the SSP would have to suffer through one > (!) additional > >> SIP message and its responses. > >> > >> But this hairpinning isn't necessary. I'm assuming that > all of those > >> terminals will send outgoing requests through the PBX. > This would give > >> the PBX the opportunity, if it wanted, to optimize this hairpin: it > >> would trivially be able to recognize the R-URI as matching > the public > >> GRUU it received from the SSP (there will be only one, so > it's not an > >> expensive comparison), and process it locally without > sending it to the > >> SSP. > >> > > I think we should mandate that behavior... > > I think we should ensure that the MARTINI mechanism doesn't preclude > that behavior. And none of the proposals so far have precluded that > behavior. > > Mandating that behavior is more architectural. It's the kind of thing > you might see come out of a body that defines concrete > architectures -- > like 3GPP, ETSI, PacketCable, SIPForum, etc. > > > ...because hair-pinning it through the SSP would be bad. > One of the definitions of a "PBX" is that it handles local > calls locally, and the SSP is not going to expect or want the > extra signaling. (and arguably the Enterprise shouldn't want > the SSP involved in them either) > > > > I agree. It's a good implementation choice to make. > > > > >> It's pretty much the same behavior as recognizing a > normal, non-GRUU URI > >> as one of its own extensions and handling it locally > instead of routing > >> to the SSP. > >> > > You mean if a phone off the pbx sends a request to > number@SSP.com and the PBX says "hey, I have that number", > then it's ok for it to route the request locally and not send > it to the SSP? I didn't see that in the draft. > > > As with the other (related) issue, I don't think that's in scope for > either the mechanism or for MARTINI. > > /a > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Fri Feb 5 03:48: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 E792A3A6D3E for ; Fri, 5 Feb 2010 03:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 jWniopmIdtHQ for ; Fri, 5 Feb 2010 03:48:03 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 0AF4B3A6C03 for ; Fri, 5 Feb 2010 03:48:03 -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 0LngZT-1OEeAX2AZD-00hmgH; Fri, 05 Feb 2010 06:48:24 -0500 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" , "Bernard Aboba" References: <430FC6BDED356B4C8498F634416644A917E5E0E113@mail> <4B6B23D8.5010402@nostrum.com> Date: Fri, 5 Feb 2010 05:48:16 -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: V01U2FsdGVkX18e9qJ4Iq/GrB1IEAJIHgwxL9LvX6jPW4OqI5+ 3h62hE2x51b6YIFZLlV1LCl6xKTl0YTpcPimhK6gqRbd84O6eo d5vNKoZa080CmtYWtxbHPTCy4aTCLJ1HmhooVNMQNY= Cc: 'Hadriel Kaplan' , martini@ietf.org Subject: Re: [martini] Can we remove draft-stirred? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 11:48:04 -0000 My impression is that stirred seemed like a good idea at the time, but we don't need to consider it further. Thanks, Spencer ----- Original Message ----- From: "Adam Roach" To: "Bernard Aboba" Cc: ; "'Hadriel Kaplan'" Sent: Thursday, February 04, 2010 1:45 PM Subject: Re: [martini] Can we remove draft-stirred? > +1 > > /a > > On 2/4/10 1:43 PM, Bernard Aboba wrote: >> +1. No interest in stirred here. >> >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: Thursday, February 04, 2010 9:28 AM >> To: martini@ietf.org >> Subject: [martini] Can we remove draft-stirred? >> >> Howdy, >> I proposed removing draft-stirred from consideration at the last virtual >> meeting, but got shot down. Since then no one has advocated it over the >> others (in fact, most of the arguments have been against it, afaict, and >> have been confusing it with draft-shaken). >> So can we please remove that draft now, so we can focus on the others? >> >> -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 spencer@wonderhamster.org Fri Feb 5 03:56: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 740483A6C0D for ; Fri, 5 Feb 2010 03:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, 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 VIG9IyGqk9La for ; Fri, 5 Feb 2010 03:56:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 892B83A6AAE for ; Fri, 5 Feb 2010 03:56:09 -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 0MAxmW-1NTUuo3KvU-00A2fO; Fri, 05 Feb 2010 06:56:58 -0500 Message-ID: <631611B37C93408A8AC2D7F26851A52E@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , References: Date: Fri, 5 Feb 2010 05:56:52 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0277_01CAA628.03F4ADB0" 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+TsowOKWUoxLymxr+dvzD2uGAcfZS3xK2J0i1 qZXOrmXn73rGt9Eh9eePKChf9RtJ/PH3FBwIPjQRfe/3Fv2wp1 C5KPP8EVkUZKwQvNpSZQLAoQHbULmyTpWWdY45TbAU= Subject: Re: [martini] Request for Review: New Drafts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 11:56:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0277_01CAA628.03F4ADB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ] ... and to be even more precise, we would like to strongly encourage = people to look at the requirements draft, and then look at gin to see if = you think gin meets the stated requirements, as part of your review of = gin. Adam says he thinks it does - that's good, the rest of us just need to = agree. Thanks, Spencer ----- Original Message -----=20 From: Bernard Aboba=20 To: martini@ietf.org=20 Sent: Thursday, February 04, 2010 2:13 PM Subject: [martini] Request for Review: New Drafts As you may have noticed, MARTINI Virtual Interim III has a section of = the agenda devoted to discussion of new drafts, including: http://tools.ietf.org/html/draft-elwell-martini-reqs-00 http://tools.ietf.org/html/draft-roach-martini-gin-00 =20 To ensure that discussion is productive, we would like to strongly = encourage attendees to read these documents, and post their comments to = the list.=20 -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_0277_01CAA628.03F4ADB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<speaking-as-co-chair>]
 
... and to be even more precise, we would like to = strongly=20 encourage people to look at the requirements draft, and then look at gin = to see=20 if you think gin meets the stated requirements, as part of your review = of=20 gin.
 
Adam says he thinks it does - that's good, the rest = of us just=20 need to agree.
 
</speaking-as-co-chair>
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Bernard Aboba

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

Sent: Thursday, February 04, = 2010 2:13=20 PM
Subject: [martini] Request for = Review:=20 New Drafts

As you may have noticed, MARTINI Virtual Interim = III has a=20 section of the agenda devoted to discussion of new drafts,=20 including:

http://t= ools.ietf.org/html/draft-elwell-martini-reqs-00

http://too= ls.ietf.org/html/draft-roach-martini-gin-00

 

To ensure that discussion is productive, we would = like to=20 strongly encourage attendees to read these documents, and post their = comments=20 to the list.

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_0277_01CAA628.03F4ADB0-- From spencer@wonderhamster.org Fri Feb 5 04:15: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 8CC7B3A6D58 for ; Fri, 5 Feb 2010 04:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, 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 EjcH4Ows-xS5 for ; Fri, 5 Feb 2010 04:15:33 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 372363A6EDA for ; Fri, 5 Feb 2010 04:15: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 0MEG1o-1NWoba0s1Y-00FSD2; Fri, 05 Feb 2010 07:16:15 -0500 Message-ID: <4A1C806F295E434FB87C6DE706166302@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <636E316F-E670-4B2D-A578-E5C22B5B78CD@softarmor.com> Date: Fri, 5 Feb 2010 06:16:08 -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+e3lqN0qfyguvpyqcxCQfQMHTYVzFpFOu9QlD BgLfPcxXVe0jHuCnZxZzIHbomFlYCV7d6T8hlh+brTmyVrxzhc hTbBGIOI6xj9Rq+gdtY6Ce80p3FZsvgDRjGUyb89IM= Cc: martini@ietf.org, 'Hadriel Kaplan' Subject: Re: [martini] Culling tel URIs (was: Re: 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, 05 Feb 2010 12:15:34 -0000 Hi, Dean, >> So, just to check consensus here ... is anyone willing to argue AGAINST >> dropping TEL URIs from consideration? I haven't seen support for basing >> a solution on TEL URIs on-list, and I don't want us to head down blind >> alleys if no one is following ... >> >> Thanks, >> >> Spencer >> >> > > I continue to support TEL as the cleanest solution. It's what people > really want and don't know how to ask for, kind of like one of those > Cosmo quiz things. > > If all you want is "a phone number" without the overhead of "domain > ownership" then you really do want TEL. Yes, we don't have a history of > doing it the right way. We could always start. TEL URIs would really need to appear in a draft, for us to move in this direction. I thought that was where we were headed sometime around the V-I II timeframe, but then I had some e-mail exchanges with Adam and he produced GIN instead. So I'm thinking that we might not be CULLING the TEL URI concept, but if we don't have a draft that proposes TEL URIs, we're not going to end up adopting a solution that uses them. Thanks, Spencer From drage@alcatel-lucent.com Fri Feb 5 04:45: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 00A893A6EDA for ; Fri, 5 Feb 2010 04:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.158 X-Spam-Level: X-Spam-Status: No, score=-5.158 tagged_above=-999 required=5 tests=[AWL=1.091, 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 pJBxh6WyWOef for ; Fri, 5 Feb 2010 04:45:45 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id C5CD53A6EAE for ; Fri, 5 Feb 2010 04:45:44 -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.14.3/8.14.3/ICT) with ESMTP id o15CjFS5005477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 5 Feb 2010 13:46:28 +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; Fri, 5 Feb 2010 13:46:01 +0100 From: "DRAGE, Keith (Keith)" To: Dean Willis , Christer Holmberg Date: Fri, 5 Feb 2010 13:45:58 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqmIp45lkH/XHydQ6a2R18/6B+Y6QAPZmww Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <4B670F85.4030808@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 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Hadriel Kaplan , "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, 05 Feb 2010 12:45:46 -0000 Just picking up on this one. > > Again, as far as I understand, from a SIP network=20 > perspective the PBX=20 > > only has a single contact. >=20 >=20 > That depends on the PBX, doesn't it? > =20 If I have a scenario for what used to be called a multi-tenant PBX, i.e. wh= ere the physical resources are being shared, including the ADSL link, it ma= y well be that you need a separate key identifier for each tenant.=20 Certainly in the TISPAN work we said that the registered contact should rep= resent an endpoint that is able to act on behalf of all the other URIs that= implicitly registered as part of that registration. Thus a URI that repres= ents the attendent of tenant 1 can be used to register all the public URIs = of users of tenant 1, but not should be responsible for those of tenant 2 (= excluding a shared attendant of course). How much this impacts the SSP depends on other things. To the SSP it may lo= ok like a set of independent PBXs, but in IMS land they could all share the= same private user identity and use the same security association. regards Keith > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Friday, February 05, 2010 5:18 AM > To: Christer Holmberg > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 >=20 > On Feb 2, 2010, at 12:12 AM, Christer Holmberg wrote: >=20 > > > > Hi, > > > >>> I think that is wrong usage of the Contact header. You=20 > more or less=20 > >>> use it for carrying target information. We have other=20 > mechanisms for=20 > >>> that. > >> > >> I beg to differ. The contact address is the ultimate target. > >> There have been many documents pointing that out. > >> And as long as you register each AOR independently it can=20 > be handled=20 > >> very cleanly. > > > > In my opinion Contact is not meant to be used for informing the UA=20 > > about what number was called etc in order to reach the UA. >=20 > No, but it IS the mechanism that a proxy uses to select the=20 > UA to which the INVITE should be sent. In other words it=20 > doesn't inform the UA as to which number was used; rather it=20 > informs the UA as to which handset to alert. >=20 > > > >>> I also think it is a very "clumsy" solution, when you mandate a=20 > >>> 1-to-1 mapping of the R-URI/Contact userpart values=20 > (maybe it could=20 > >>> also have security impacts). > >> > >> Its clumsy precisely because of implicit registration. > >> Adam's proposal provided a way to do that mapping under=20 > the control=20 > >> of the recipient so that only expected contact addresses are used. > > > > Again, as far as I understand, from a SIP network=20 > perspective the PBX=20 > > only has a single contact. >=20 >=20 > That depends on the PBX, doesn't it? >=20 > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From tyler@foxfam.com Fri Feb 5 05:46: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 AA7B528C154 for ; Fri, 5 Feb 2010 05:46:39 -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.651, 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 bxpuEvuwBKpT for ; Fri, 5 Feb 2010 05:46:38 -0800 (PST) Received: from smtp02.atlngahp.sys.nuvox.net (smtp-out2.atlngahp.sys.nuvox.net [70.43.63.19]) by core3.amsl.com (Postfix) with ESMTP id ABAFC28C12E for ; Fri, 5 Feb 2010 05:46:38 -0800 (PST) Received: from LT6KW7CD1 (fw-nat.it.nuvox.net [216.215.144.201]) by smtp02.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o15DlMdX022037; Fri, 5 Feb 2010 08:47:22 -0500 Message-ID: <00cf01caa669$be167480$150610ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: "Dean Willis" , "Jack Burton" References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com><0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com><4B680653.6D98.00CB.0@cablevision.com><4B68270C.6D98.00CB.0@cablevision.com> <0E006E68-093A-4D22-ADE2-A54F3AB4B93E@softarmor.com> Date: Fri, 5 Feb 2010 08:47:21 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 13:46:39 -0000 New to the list so if I'm missing something, sorry about that. If I understand correctly, the assertion is that with draft-roach-martini-gin-00/imlicit reg, the PBX sends a single AoR to the SSP which (because of it's provisioning) automatically activates all the associated records in it's location database and just replies to the PBX with a generic ();bnc to indicate success. Provisioning aside, I tend to agree that the PBX needs to be informed of which numbers the SSP considers to be implicitly registered for that AoR. I'd hate to lose functionality by moving to implicit/bulk reg. For example, if I register 100 numbers individually and 10 of them fail, then I stop subsequent subscribes/notifies for those numbers and, in the case of some PBX's, even present to the end user that their line isn't working. Provisioning disconnects happen all the time between PBX's and SSP's as a result of MACD's. I'm not proposing MARTINI resolve procedural issues, but a lack of two way acknowledgement of which numbers both parties consider active is a loss of functionality. I realize draft-roach-martini-gin-00 suggests a NOTIFY request to communicate status. To me there's a difference between a negative/failed registration state vs. relying on a PBX to interrogate the SSP after the fact. Regards, Tyler ----- Original Message ----- From: "Dean Willis" To: "Jack Burton" Cc: Sent: Friday, February 05, 2010 12:29 AM Subject: Re: [martini] Implications of multiple AOR/contact mapping > > On Feb 2, 2010, at 7:22 AM, Jack Burton wrote: > >> How does the PBX learn its outbound numbers and DIDs when it registers? >> It needs to know this for more than just registration. I am not >> counting on registration as a configuration tool, just as a way to >> authenticate and identify the IP-PBX to the SSP. >> > > The PBX does NOT learn its numbers through registration. It has to know > them already so it can register them and so the SSP knows what IP address > and port to send calls to. The question of "How does the PBX learn its > numbers" is entirely outside the current scope of MARTINI. > > -- > Dean > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Fri Feb 5 06:14: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 9502C3A6F05 for ; Fri, 5 Feb 2010 06:14:07 -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 H2Exp6MASmfT for ; Fri, 5 Feb 2010 06:14:02 -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 4CAC93A6852 for ; Fri, 5 Feb 2010 06:14:00 -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: ApoEADu2a0utJV2Y/2dsb2JhbAC/KZgDhFIE X-IronPort-AV: E=Sophos;i="4.49,413,1262563200"; d="scan'208";a="238021002" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 05 Feb 2010 14:14:50 +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 o15EEo4d029717; Fri, 5 Feb 2010 14:14:50 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, 5 Feb 2010 08:14:49 -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, 5 Feb 2010 08:14:49 -0600 Message-ID: <4B6C27DD.7070107@cisco.com> Date: Fri, 05 Feb 2010 09:14:53 -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> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <4B6870C1.8090502@nostrum.com> <4B6891D8.8030801@cisco.com> <7A1ECB82-1B00-4F8D-A3B0-1DCB1D0EC195@softarmor.com> In-Reply-To: <7A1ECB82-1B00-4F8D-A3B0-1DCB1D0EC195@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2010 14:14:49.0791 (UTC) FILETIME=[93FC44F0:01CAA66D] Cc: 'Hadriel Kaplan' , martini@ietf.org Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 14:14:08 -0000 Dean Willis wrote: > > On Feb 2, 2010, at 2:58 PM, Paul Kyzivat wrote: > >> Adam, >> >> I just posted a reply to david that is a different spin, but getting >> at the same point. Specifically, if a domain name is used, the SSP >> needs a way to know, legally, that the pbx customer is entitled to >> that domain name, and that can be a problem. >> > > If a domain name is used in a Contact, then no, the SSP doesn't need to > know that a PBX customer is entitled to use that domain. We don't have > any way in SIP to check for authorization at the Contact level based on > DNS name or IP address. > > If a user PBX installed at an IP address having an associated A record > for "cisco.com" sends a REGISTER request with a "To:" of > "baynetworks.com", and that PBX has the authentication credentials for > baynetworks.com, then it can register! My comment was in the context of doing something like the stirred approach. People seem to be taking that draft off the table, but I'm not certain that corresponding concept is off the table. If it is entirely off the table, then you can ignore my comment. Thanks, Paul From adam@nostrum.com Fri Feb 5 07:13: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 5C7C23A690A for ; Fri, 5 Feb 2010 07:13:35 -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.056, 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 sgjCVv08nPj6 for ; Fri, 5 Feb 2010 07:13: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 4F6703A6DC8 for ; Fri, 5 Feb 2010 07:13: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 o15FDwS2027331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 09:13:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C35B6.7050101@nostrum.com> Date: Fri, 05 Feb 2010 09: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.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Tyler Parkin References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com><0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com><4B680653.6D98.00CB.0@cablevision.com><4B68270C.6D98.00CB.0@cablevision.com> <0E006E68-093A-4D22-ADE2-A54F3AB4B93E@softarmor.com> <00cf01caa669$be167480$150610ac@CORPORATE.VOX.NET> In-Reply-To: <00cf01caa669$be167480$150610ac@CORPORATE.VOX.NET> 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] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 15:13:35 -0000 Tyler: For the record, I agree with you: explicitly including this information in the protocol messages is useful. I didn't include a mechanism for doing so in my draft (even though it would be trivial to do so) because there appears to be adamant opposition to including this information. I don't understand the pushback. But given the more important issues with the solutions in this space, I'm willing to let this one go. /a On 2/5/10 7:47 AM, Tyler Parkin wrote: > New to the list so if I'm missing something, sorry about that. If I > understand correctly, the assertion is that with > draft-roach-martini-gin-00/imlicit reg, the PBX sends a single AoR to > the SSP which (because of it's provisioning) automatically activates > all the associated records in it's location database and just replies > to the PBX with a generic ();bnc to indicate success. > > Provisioning aside, I tend to agree that the PBX needs to be informed > of which numbers the SSP considers to be implicitly registered for > that AoR. I'd hate to lose functionality by moving to implicit/bulk > reg. For example, if I register 100 numbers individually and 10 of > them fail, then I stop subsequent subscribes/notifies for those > numbers and, in the case of some PBX's, even present to the end user > that their line isn't working. > > Provisioning disconnects happen all the time between PBX's and SSP's > as a result of MACD's. I'm not proposing MARTINI resolve procedural > issues, but a lack of two way acknowledgement of which numbers both > parties consider active is a loss of functionality. > > I realize draft-roach-martini-gin-00 suggests a NOTIFY request to > communicate status. To me there's a difference between a > negative/failed registration state vs. relying on a PBX to interrogate > the SSP after the fact. > > Regards, > > Tyler > > ----- Original Message ----- From: "Dean Willis" > > To: "Jack Burton" > Cc: > Sent: Friday, February 05, 2010 12:29 AM > Subject: Re: [martini] Implications of multiple AOR/contact mapping > > >> >> On Feb 2, 2010, at 7:22 AM, Jack Burton wrote: >> >>> How does the PBX learn its outbound numbers and DIDs when it >>> registers? It needs to know this for more than just registration. >>> I am not counting on registration as a configuration tool, just as >>> a way to authenticate and identify the IP-PBX to the SSP. >>> >> >> The PBX does NOT learn its numbers through registration. It has to >> know them already so it can register them and so the SSP knows what >> IP address and port to send calls to. The question of "How does the >> PBX learn its numbers" is entirely outside the current scope of >> MARTINI. >> >> -- >> 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 pkyzivat@cisco.com Fri Feb 5 07:40: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 C5B2E3A6F19 for ; Fri, 5 Feb 2010 07:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 4XUBIpIlArgL for ; Fri, 5 Feb 2010 07:40:20 -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 895813A6F18 for ; Fri, 5 Feb 2010 07:40:18 -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: ApoEAJ7Ka0urRN+K/2dsb2JhbAC/ZZd+gkiCCgQ X-IronPort-AV: E=Sophos;i="4.49,413,1262563200"; d="scan'208";a="146435424" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 05 Feb 2010 15:41:09 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o15Ff8Pq017305; Fri, 5 Feb 2010 15:41:09 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); Fri, 5 Feb 2010 09:41:08 -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, 5 Feb 2010 09:41:08 -0600 Message-ID: <4B6C3C26.80908@cisco.com> Date: Fri, 05 Feb 2010 10:41:26 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B68BEB4.2020207@nostrum.com> In-Reply-To: <4B68BEB4.2020207@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2010 15:41:08.0543 (UTC) FILETIME=[A2C31CF0:01CAA679] Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 15:40:20 -0000 Adam, This is good!!! A few comments: * Use of () to mark insertion of number: Why not just place the phone number in a uri-parameter? * Need for Proxy-Require You say we need because we are altering the semantics of REGISTER. But which semantics of register *that pertain to proxies* are we altering? * Temp GRUUs One possibility would be for the pbx to use the public GRUU seed of some single number (the attendant number?) of the pbx to mint its own temporary GRUUs. Their anonymity would be limited since they can all be traced to the same pbx, but that may be acceptable in some cases. * Aggregate reg state You say the () syntax and bnc can't appear. But reg event notifications should contain information on GRUUs too. (RFC 5628) And those gruus would have that syntax in them. * Individual reg state I think you neglected to mention something - perhaps because you assumed it was obvious: If a subscription is received addressed to the a phone number the pbx services, then presumably it will first be mapped to the corresponding contact for the pbx, and *then* proxied on that basis. Thanks, Paul From adam@nostrum.com Fri Feb 5 07:49: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 0A54228C0F5 for ; Fri, 5 Feb 2010 07:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.061, 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 jr+JLUIutoQo for ; Fri, 5 Feb 2010 07:49:53 -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 DB3ED28B56A for ; Fri, 5 Feb 2010 07:49: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 o15Foda3030306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 09:50:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C3E4F.603@nostrum.com> Date: Fri, 05 Feb 2010 09:50: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: Spencer Dawkins References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <636E316F-E670-4B2D-A578-E5C22B5B78CD@softarmor.com> <4A1C806F295E434FB87C6DE706166302@china.huawei.com> In-Reply-To: <4A1C806F295E434FB87C6DE706166302@china.huawei.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: 'Hadriel Kaplan' , martini@ietf.org Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 15:49:54 -0000 On 2/5/10 6:16 AM, Spencer Dawkins wrote: > TEL URIs would really need to appear in a draft, for us to move in > this direction. I thought that was where we were headed sometime > around the V-I II timeframe, but then I had some e-mail exchanges with > Adam and he produced GIN instead. My original plan for the GIN draft was actually to use TEL instead of SIP. I took it the other direction for two reasons: (1) the temperature of the working group on TEL gave me the impression that a TEL-based proposal had less chance of satisfying everyone's desires; and (2) the mechanism for doing this with TEL became a bit more fiddly, since we had to clarify how TEL routing is performed in a MARTINI context. /a From adam@nostrum.com Fri Feb 5 07:55: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 C696F3A6D54 for ; Fri, 5 Feb 2010 07:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Jx-HsKetEMz9 for ; Fri, 5 Feb 2010 07:55: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 A7B803A6919 for ; Fri, 5 Feb 2010 07:55: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 o15FuN2S030713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 09:56:23 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C3FA7.2090404@nostrum.com> Date: Fri, 05 Feb 2010 09:56: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: Spencer Dawkins References: <4B68BEB4.2020207@nostrum.com><4B6991B1.1040806@nostrum.com><430FC6BDED356B4C8498F634416644A917E5E0E121@mail><4B6B2331.6050209@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 , Hadriel Kaplan Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 15:55:36 -0000 On 2/5/10 5:46 AM, Spencer Dawkins wrote: > > > Adam, I appreciate the nudge in the direction of "does not preclude", > and agree with your reasoning ("more architectural than we usually get > in the IETF"). > > Just to be clear - are you suggesting that we can say "does not > preclude" in a MARTINI specification? I would like to see that level > of discussion captured, so we don't spend the next few years answering > the question "did you guys think about hairpinning?" :-) If we want to capture this, I would argue it goes in the requirements document. /a From adam@nostrum.com Fri Feb 5 07: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 62C653A6F0B for ; Fri, 5 Feb 2010 07:59:59 -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 I957juqQYTea for ; Fri, 5 Feb 2010 07:59:58 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0CEF83A6A0B for ; Fri, 5 Feb 2010 07:59:57 -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 o15G0jfK031065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 10:00:45 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C40AD.7020108@nostrum.com> Date: Fri, 05 Feb 2010 10:00:45 -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: <430FC6BDED356B4C8498F634416644A917E5E0E11A@mail> <4B6B2957.4000209@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" , Hadriel Kaplan Subject: Re: [martini] comments on draft-roach-martini-gin-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, 05 Feb 2010 15:59:59 -0000 On 2/5/10 2:04 AM, Elwell, John wrote: > >> What would the username do in your example? If we get rid of the '()' >> syntax, then I'd propose heading directly for URIs of the form >> instead. But I think the ability for the PBX to >> specify the form of its own contact URIs (even if constrained >> by having >> the entire phone number inserted) is still a useful one. >> > [JRE] Can we have some examples of why it would be useful? If useful, I would go for always appending the number to the user name, rather than having special characters to denote the position of insertion. If not useful, then the simple form above (no user name) would suffice. > After giving it some additional thought in the context of "we need a fast solution for phone numbers," I realized that the ability to perform these kinds of manipulations on the user portions isn't likely to be useful for the target market for GIN. We certainly want something like this (but much more flexible) for the general solution, but for the numbers-only solution, I think the time spent engineering this feature won't be warranted by its utility. So, yeah, I now agree that we just want to simplify this to the no-user-name variant. /a From spencer@wonderhamster.org Fri Feb 5 08:04: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 64E2A28C0F5 for ; Fri, 5 Feb 2010 08:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 3GHAhCz188go for ; Fri, 5 Feb 2010 08:04:07 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 765A63A6A0B for ; Fri, 5 Feb 2010 08:04:07 -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 0MEnze-1NXRSh36wk-00G0LP; Fri, 05 Feb 2010 11:04:50 -0500 Message-ID: <3FE085361E444628AD6A7BA163ACEBFA@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <012901caa41c$014921d0$03db6570$@us> <636E316F-E670-4B2D-A578-E5C22B5B78CD@softarmor.com> <4A1C806F295E434FB87C6DE706166302@china.huawei.com> <4B6C3E4F.603@nostrum.com> Date: Fri, 5 Feb 2010 10:04:43 -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: V01U2FsdGVkX19zt8cRK7uw0qrOARDhuYgk4hAvE+g6ocvvTEl IIAzDsmR1SKH8EAeWQNyQXcj2CeDKjlCHl8eTMVDrPApfywYme /EKMxZRZD7PQxfgIwWLH2rXRuNiQPdb+Oi3EhUca78= Cc: 'Hadriel Kaplan' , martini@ietf.org Subject: Re: [martini] Culling tel URIs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 16:04:08 -0000 Hi, Adam, >> TEL URIs would really need to appear in a draft, for us to move in this >> direction. I thought that was where we were headed sometime around the >> V-I II timeframe, but then I had some e-mail exchanges with Adam and he >> produced GIN instead. > > My original plan for the GIN draft was actually to use TEL instead of SIP. > I took it the other direction for two reasons: (1) the temperature of the > working group on TEL gave me the impression that a TEL-based proposal had > less chance of satisfying everyone's desires; and (2) the mechanism for > doing this with TEL became a bit more fiddly, since we had to clarify how > TEL routing is performed in a MARTINI context. Speaking as a participant, I agree with your change of course, for reasons that people raised almost immediately when a TEL draft loomed just over the horizon. Speaking as co-chair, my intention was to let people who think TEL would be awesome that they might have been expecting a TEL-ish draft to automagically appear, but it doesn't look that's going to happen unless THEY write one :D Thanks, Spencer From spencer@wonderhamster.org Fri Feb 5 08:04: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 DC8BF28C194 for ; Fri, 5 Feb 2010 08:04:57 -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 knh74p98ePay for ; Fri, 5 Feb 2010 08:04:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 091A528C0F5 for ; Fri, 5 Feb 2010 08:04:57 -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 0MA9Uv-1NSkO50iAD-00BQ4m; Fri, 05 Feb 2010 11:05:45 -0500 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" References: <4B68BEB4.2020207@nostrum.com><4B6991B1.1040806@nostrum.com><430FC6BDED356B4C8498F634416644A917E5E0E121@mail><4B6B2331.6050209@nostrum.com> <4B6C3FA7.2090404@nostrum.com> Date: Fri, 5 Feb 2010 10:05:37 -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/LHukV7RQEK6ynHi/EXkMHhWpXXiH0lBxj7Nv fCTE5aSdEasWIC9Z5H5Foesw15j9epbqPHl9vtuZr7yLfEh5BT 3K9uwk24fw8rDKhSoTIrVhXd4VKs0uW2eyyRffFg6w= Cc: MARTINI , Hadriel Kaplan Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 16:04:58 -0000 Hi, Adam, > On 2/5/10 5:46 AM, Spencer Dawkins wrote: >> >> >> Adam, I appreciate the nudge in the direction of "does not preclude", and >> agree with your reasoning ("more architectural than we usually get in the >> IETF"). >> >> Just to be clear - are you suggesting that we can say "does not preclude" >> in a MARTINI specification? I would like to see that level of discussion >> captured, so we don't spend the next few years answering the question >> "did you guys think about hairpinning?" :-) > > If we want to capture this, I would argue it goes in the requirements > document. Thank you for clarifying... speaking as a participant, that would work for me. Spencer From tyler@foxfam.com Fri Feb 5 08:18: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 A4B1D28C18A for ; Fri, 5 Feb 2010 08:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, 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 d3ki5UYSHetf for ; Fri, 5 Feb 2010 08:17:59 -0800 (PST) Received: from smtp05.atlngahp.sys.nuvox.net (smtp-out5.atlngahp.sys.nuvox.net [70.43.63.23]) by core3.amsl.com (Postfix) with ESMTP id 838FF28C160 for ; Fri, 5 Feb 2010 08:17:59 -0800 (PST) Received: from LT6KW7CD1 (fw-nat.it.nuvox.net [216.215.144.201]) by smtp05.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o15GIjEI012923; Fri, 5 Feb 2010 11:18:45 -0500 Message-ID: <012601caa67e$e3c79b40$150610ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: "Adam Roach" References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com><0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com><4B680653.6D98.00CB.0@cablevision.com><4B68270C.6D98.00CB.0@cablevision.com> <0E006E68-093A-4D22-ADE2-A54F3AB4B93E@softarmor.com> <00cf01caa669$be167480$150610ac@CORPORATE.VOX.NET> <4B6C35B6.7050101@nostrum.com> Date: Fri, 5 Feb 2010 11:18:44 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 16:18:00 -0000 Thanks Adam. Out of curiosity, is there a process defined (or does there need to be) for an individual registration superceding a previously bulk-registered number? I think these are obvious, but... Example 1: PBX registers a number as part of bulk reg. User then enables a softphone which either uses a different PBX or comes directly to the SSP and registers the number again. Obviously, the most recent number should take precedence. Example 2: PBX sends an individual register expires:0 message for a specific number (what if it's the primary AoR #?). I would expect that if it's an associated number just that entry would be removed from the location database. If it's the AoR, do we force de-reg of all associated #'s? I assume we'd have to. Thanks, Tyler ----- Original Message ----- From: "Adam Roach" To: "Tyler Parkin" Cc: "Dean Willis" ; "Jack Burton" ; Sent: Friday, February 05, 2010 10:13 AM Subject: Re: [martini] Implications of multiple AOR/contact mapping > Tyler: > > For the record, I agree with you: explicitly including this information in > the protocol messages is useful. I didn't include a mechanism for doing so > in my draft (even though it would be trivial to do so) because there > appears to be adamant opposition to including this information. I don't > understand the pushback. But given the more important issues with the > solutions in this space, I'm willing to let this one go. > > /a > > On 2/5/10 7:47 AM, Tyler Parkin wrote: >> New to the list so if I'm missing something, sorry about that. If I >> understand correctly, the assertion is that with >> draft-roach-martini-gin-00/imlicit reg, the PBX sends a single AoR to the >> SSP which (because of it's provisioning) automatically activates all the >> associated records in it's location database and just replies to the PBX >> with a generic ();bnc to indicate success. >> >> Provisioning aside, I tend to agree that the PBX needs to be informed of >> which numbers the SSP considers to be implicitly registered for that AoR. >> I'd hate to lose functionality by moving to implicit/bulk reg. For >> example, if I register 100 numbers individually and 10 of them fail, then >> I stop subsequent subscribes/notifies for those numbers and, in the case >> of some PBX's, even present to the end user that their line isn't >> working. >> >> Provisioning disconnects happen all the time between PBX's and SSP's as a >> result of MACD's. I'm not proposing MARTINI resolve procedural issues, >> but a lack of two way acknowledgement of which numbers both parties >> consider active is a loss of functionality. >> >> I realize draft-roach-martini-gin-00 suggests a NOTIFY request to >> communicate status. To me there's a difference between a negative/failed >> registration state vs. relying on a PBX to interrogate the SSP after the >> fact. >> >> Regards, >> >> Tyler >> >> ----- Original Message ----- From: "Dean Willis" >> >> To: "Jack Burton" >> Cc: >> Sent: Friday, February 05, 2010 12:29 AM >> Subject: Re: [martini] Implications of multiple AOR/contact mapping >> >> >>> >>> On Feb 2, 2010, at 7:22 AM, Jack Burton wrote: >>> >>>> How does the PBX learn its outbound numbers and DIDs when it >>>> registers? It needs to know this for more than just registration. I >>>> am not counting on registration as a configuration tool, just as a way >>>> to authenticate and identify the IP-PBX to the SSP. >>>> >>> >>> The PBX does NOT learn its numbers through registration. It has to know >>> them already so it can register them and so the SSP knows what IP >>> address and port to send calls to. The question of "How does the PBX >>> learn its numbers" is entirely outside the current scope of MARTINI. >>> >>> -- >>> 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 john.elwell@siemens-enterprise.com Fri Feb 5 08:36: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 422E73A6AD0 for ; Fri, 5 Feb 2010 08:36:48 -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 sm29hU3Ug+MV for ; Fri, 5 Feb 2010 08:36:47 -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 095123A687B for ; Fri, 5 Feb 2010 08:36:46 -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-795933; Fri, 5 Feb 2010 17:37:37 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 0964C1EB82AB; Fri, 5 Feb 2010 17:37:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Feb 2010 17:37:37 +0100 From: "Elwell, John" To: Adam Roach , Spencer Dawkins Date: Fri, 5 Feb 2010 17:37:35 +0100 Thread-Topic: [martini] GIN Draft Thread-Index: Acqme8eHLNvwu6MXQ3mOxGQPjr7shAABQHkg Message-ID: References: <4B68BEB4.2020207@nostrum.com><4B6991B1.1040806@nostrum.com><430FC6BDED356B4C8498F634416644A917E5E0E121@mail><4B6B2331.6050209@nostrum.com> <4B6C3FA7.2090404@nostrum.com> In-Reply-To: <4B6C3FA7.2090404@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 , Hadriel Kaplan Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 16:36:48 -0000 In principle, yes, but I am not sure how. The original concern was with GRU= Us having xxxx.sp.com, where xxxx is recognised as being internal to the PB= X. First, perhaps we need a requirement that the mechanism must allow the P= BX to provide its UAs with public or temporary GRUUs. Second, and this is the harder part, we seem to be asking for something to = be said about not precluding direct on-PBX routing of requests to xxx@sp.co= m, where xxx is known to be on-PBX. The difficulty I have with this is that= it seems to assume a solution involving sp.com as the host part of a URI f= or an on-PBX entity. Any ideas what we should say? John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 05 February 2010 15:56 > To: Spencer Dawkins > Cc: Elwell, John; Hadriel Kaplan; MARTINI > Subject: Re: [martini] GIN Draft >=20 > On 2/5/10 5:46 AM, Spencer Dawkins wrote: > > > > > > Adam, I appreciate the nudge in the direction of "does not=20 > preclude",=20 > > and agree with your reasoning ("more architectural than we=20 > usually get=20 > > in the IETF"). > > > > Just to be clear - are you suggesting that we can say "does not=20 > > preclude" in a MARTINI specification? I would like to see=20 > that level=20 > > of discussion captured, so we don't spend the next few=20 > years answering=20 > > the question "did you guys think about hairpinning?" :-) >=20 > If we want to capture this, I would argue it goes in the requirements=20 > document. >=20 > /a > = From richard@shockey.us Fri Feb 5 08:47: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 B0B863A6A22 for ; Fri, 5 Feb 2010 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 Lsx2xzBaQL6x for ; Fri, 5 Feb 2010 08:47:11 -0800 (PST) Received: from outbound-mail-358.bluehost.com (outbound-mail-358.bluehost.com [66.147.249.252]) by core3.amsl.com (Postfix) with SMTP id 95D733A687B for ; Fri, 5 Feb 2010 08:47:11 -0800 (PST) Received: (qmail 2676 invoked by uid 0); 5 Feb 2010 16:48:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 5 Feb 2010 16:48:01 -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=NAsbT+36CF0qUZdKZpBrlhaCXr7eVJmX+mGFuvq4P9q3Fo+MOCv7uSRLfnsmj2kLdbDVyWfVJXcNka5VVNm9vwa77gJICPISQ/Qu1rMUgOize+jvXF2GxoBiTr6/XH8B; 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 1NdRLd-0001qW-HC; Fri, 05 Feb 2010 09:48:01 -0700 From: "Richard Shockey" To: "'Dean Willis'" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <82A960D0-7834-443A-883B-4EF0D25AE5C5@softarmor.com> <14C85D6CCBE92743AF33663BF5D24EBA0582965C@gaalpa1msgusr7e.ugd.att.com> <003201caa443$5c12f1f0$1438d5d0$@us> In-Reply-To: Date: Fri, 5 Feb 2010 11:47:57 -0500 Message-ID: <00dc01caa682$f9245e70$eb6d1b50$@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: AcqmJiMFtK0BAJMzQ+OmNgTAXvGxqQAW/uGg 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, 05 Feb 2010 16:47:12 -0000 Brother Dean.. my intention was to remind everyone what the meta problem really is problem and the consensus we have that it really is a two part solution we will need to address. First is the Implicit Registration issue in REGISTER and the second a long term problem to the provisioning of PBX's to SSP's. The list had gotten much bigger over the last few week. BTW IMHO using TEL: URI here is a non starter. Either the shaken or gin approach _could_ work and in fact already does. The issue we have always had is that there was no implicit indicator ( aka the option tag) in the register message that let the SSP understand exactly what the semantic meaning of the implicit registration actually was. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, February 05, 2010 12:43 AM To: Richard Shockey Cc: 'DOLLY, MARTIN C (ATTLABS)'; 'Christer Holmberg'; 'Hadriel Kaplan'; martini@ietf.org Subject: Re: [martini] Proposed work split: tackletelephone-numberregistration first On Feb 2, 2010, at 2:07 PM, Richard Shockey wrote: > +1 Thank you Marty ..that is the central problem. > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf > Of DOLLY, MARTIN C (ATTLABS) > Sent: Monday, February 01, 2010 8:50 PM > To: Dean Willis; Christer Holmberg > Cc: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] Proposed work split: > tackletelephone-numberregistration first > > Every user registering is not implementable. > Dangit Richard! I never suggested that every user register. As far as I know, NOBODY has suggested that. I suggested (based on Adam's work) that the PBX send a single registration that creates multiple AOR/Contact/GRUU bindings in the SSP proxy, and that the SSP proxy work just exactly like an ordinary proxy when handling requests following the registration. -- Dean From richard@shockey.us Fri Feb 5 08:58: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 85B8D3A6F4D for ; Fri, 5 Feb 2010 08:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 ah8Ldv2F54TB for ; Fri, 5 Feb 2010 08:58:42 -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 7AB1B3A6F4B for ; Fri, 5 Feb 2010 08:58:42 -0800 (PST) Received: (qmail 25616 invoked by uid 0); 5 Feb 2010 16:59:33 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy8.bluehost.com.bluehost.com with SMTP; 5 Feb 2010 16:59:33 -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=g94PubkAngxNJrgBNZeybJX/Vge0OQxc6kPvmLZSf+1ttDzN1jt8QlrhUN+kcAVt52V+eLh3SCdVAbzP2qpzDWU6395+U+3mBRpm7fiWiqYFPeqjyeWF5gIiXp72F+uU; 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 1NdRWn-0000bb-4m; Fri, 05 Feb 2010 09:59:33 -0700 From: "Richard Shockey" To: "'Adam Roach'" , "'Tyler Parkin'" References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com><0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com><4B680653.6D98.00CB.0@cablevision.com><4B68270C.6D98.00CB.0@cablevision.com> <0E006E68-093A-4D22-ADE2-A54F3AB4B93E@softarmor.com> <00cf01caa669$be167480$150610ac@CORPORATE.VOX.NET> <4B6C35B6.7050101@nostrum.com> In-Reply-To: <4B6C35B6.7050101@nostrum.com> Date: Fri, 5 Feb 2010 11:59:29 -0500 Message-ID: <00e901caa684$9561d0f0$c02572d0$@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: AcqmdeqN8bG/vnffTxiC4X6yM0e5mgADchNw 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] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 16:58:43 -0000 Thank you Adam. Tyler that is IMHO the general consensus of those of us involved in the SIP Forum work over the last 16 months, and nearly all of those folks are on this list. The issue at hand is a serious interoperability problem observed in an increasing number of deployments that needs a solution ASAP. The larger issue of provisioning between SSP and PBX's is going to take a very long time in the IETF and could run into serious resistance by vendors etc that will view provisioning/configuration standardization as somewhat threatening. Plus the IETF really doesn't do configuration very well. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Friday, February 05, 2010 10:14 AM To: Tyler Parkin Cc: martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping Tyler: For the record, I agree with you: explicitly including this information in the protocol messages is useful. I didn't include a mechanism for doing so in my draft (even though it would be trivial to do so) because there appears to be adamant opposition to including this information. I don't understand the pushback. But given the more important issues with the solutions in this space, I'm willing to let this one go. /a On 2/5/10 7:47 AM, Tyler Parkin wrote: > New to the list so if I'm missing something, sorry about that. If I > understand correctly, the assertion is that with > draft-roach-martini-gin-00/imlicit reg, the PBX sends a single AoR to > the SSP which (because of it's provisioning) automatically activates > all the associated records in it's location database and just replies > to the PBX with a generic ();bnc to indicate success. > > Provisioning aside, I tend to agree that the PBX needs to be informed > of which numbers the SSP considers to be implicitly registered for > that AoR. I'd hate to lose functionality by moving to implicit/bulk > reg. For example, if I register 100 numbers individually and 10 of > them fail, then I stop subsequent subscribes/notifies for those > numbers and, in the case of some PBX's, even present to the end user > that their line isn't working. > > Provisioning disconnects happen all the time between PBX's and SSP's > as a result of MACD's. I'm not proposing MARTINI resolve procedural > issues, but a lack of two way acknowledgement of which numbers both > parties consider active is a loss of functionality. > > I realize draft-roach-martini-gin-00 suggests a NOTIFY request to > communicate status. To me there's a difference between a > negative/failed registration state vs. relying on a PBX to interrogate > the SSP after the fact. > > Regards, > > Tyler > > ----- Original Message ----- From: "Dean Willis" > > To: "Jack Burton" > Cc: > Sent: Friday, February 05, 2010 12:29 AM > Subject: Re: [martini] Implications of multiple AOR/contact mapping > > >> >> On Feb 2, 2010, at 7:22 AM, Jack Burton wrote: >> >>> How does the PBX learn its outbound numbers and DIDs when it >>> registers? It needs to know this for more than just registration. >>> I am not counting on registration as a configuration tool, just as >>> a way to authenticate and identify the IP-PBX to the SSP. >>> >> >> The PBX does NOT learn its numbers through registration. It has to >> know them already so it can register them and so the SSP knows what >> IP address and port to send calls to. The question of "How does the >> PBX learn its numbers" is entirely outside the current scope of >> MARTINI. >> >> -- >> 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 adam@nostrum.com Fri Feb 5 09:01: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 118353A6F42 for ; Fri, 5 Feb 2010 09:01:34 -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.056, 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 ibk8VFGjfdTN for ; Fri, 5 Feb 2010 09:01: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 D63483A6F51 for ; Fri, 5 Feb 2010 09:01: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 o15H27x9063177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 11:02:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C4F0F.3000802@nostrum.com> Date: Fri, 05 Feb 2010 11:02: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: Tyler Parkin References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com><0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com><4B680653.6D98.00CB.0@cablevision.com><4B68270C.6D98.00CB.0@cablevision.com> <0E006E68-093A-4D22-ADE2-A54F3AB4B93E@softarmor.com> <00cf01caa669$be167480$150610ac@CORPORATE.VOX.NET> <4B6C35B6.7050101@nostrum.com> <012601caa67e$e3c79b40$150610ac@CORPORATE.VOX.NET> In-Reply-To: <012601caa67e$e3c79b40$150610ac@CORPORATE.VOX.NET> 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] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 17:01:34 -0000 On 2/5/10 10:18 AM, Tyler Parkin wrote: > Out of curiosity, is there a process defined (or does there need to > be) for an individual registration superceding a previously > bulk-registered number? > > I think these are obvious, but... > > Example 1: PBX registers a number as part of bulk reg. User then > enables a softphone which either uses a different PBX or comes > directly to the SSP and registers the number again. Obviously, the > most recent number should take precedence. SIP actually has a model for "what happens when you register two contacts for the same AOR." I don't think we're in a position to override that model, nor do I think it's a good idea to do so. > Example 2: PBX sends an individual register expires:0 message for a > specific number (what if it's the primary AoR #?). I would expect > that if it's an associated number just that entry would be removed > from the location database. If it's the AoR, do we force de-reg of > all associated #'s? I assume we'd have to. Deregistration is done to a Contact, not an AOR (with the exception of "Contact: *"). I would assume that deregistering the ";mnc" tagged contact would do the same thing as registering that contact, but in reverse. (That is, all the associated entries in the location server would be removed). Now, the question about what happens if the PBX tries to deregister a *single* phone number from the range is a good one. The semantics would be pretty clear (remove this one contact/AOR paid), but it would be un-removed when the bulk registration is renewed, making it a pretty useless operation. I would propose that we put a "don't do that, then" clause in. /a From adam@nostrum.com Fri Feb 5 09:18: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 64B6F28C1EA for ; Fri, 5 Feb 2010 09:18:19 -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 TBLHGlElMA8E for ; Fri, 5 Feb 2010 09:18: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 035A128C1DC for ; Fri, 5 Feb 2010 09:18: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 o15HJ0mq086776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 11:19:01 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C5304.9070605@nostrum.com> Date: Fri, 05 Feb 2010 11:19: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: Paul Kyzivat References: <4B68BEB4.2020207@nostrum.com> <4B6C3C26.80908@cisco.com> In-Reply-To: <4B6C3C26.80908@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 Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 17:18:19 -0000 On 2/5/10 9:41 AM, Paul Kyzivat wrote: > Adam, > > This is good!!! A few comments: > > * Use of () to mark insertion of number: > > Why not just place the phone number in a uri-parameter? That would work also. Right now, based on Hadriel's input, I'm thinking the fastest way forward is simply to limit the Contact URIs to have no userpart at all, and use the 'bnc' parameter to indicate that the user part should be filled in with the phone number. > * Need for Proxy-Require > > You say we need because we are altering the semantics of REGISTER. But > which semantics of register *that pertain to proxies* are we altering? Policy decisions that have historically applied to a single AOR will now be applied to REGISTER transactions that pertain to multiple AORs. That's a change. Really: why else are you going to have proxies between the PBX and the SSP? It pretty much comes down to NAT traversal and application of policy. > * Temp GRUUs > > One possibility would be for the pbx to use the public GRUU seed of > some single number (the attendant number?) of the pbx to mint its own > temporary GRUUs. Their anonymity would be limited since they can all > be traced to the same pbx, but that may be acceptable in some cases. I thought through this, and decided that doing the temp-GRUUs at the SSP introduced far more complication than was gained. Since public GRUUs get you the ability to do all the call-control state, I'm not sure it's as important to make the temp-GRUUs as universally available. I'm not really attached to this viewpoint, though. If someone wants to write up text about how to do temp-GRUUs through the SSP (including an analysis of why it works), then I'm happy to put it in. > * Aggregate reg state > > You say the () syntax and bnc can't appear. But reg event > notifications should contain information on GRUUs too. (RFC 5628) And > those gruus would have that syntax in them. Oh, good point. Interesting. The SSP won't actually know the mapping from public GRUU to AOR, since the substitution is done at the PBX. I think we probably won't be able to usefully put GRUU information into the aggregate registration state. I'll have to dig through some documents to determine whether this would be a valid thing to do. > * Individual reg state > > I think you neglected to mention something - perhaps because you > assumed it was obvious: > > If a subscription is received addressed to the a phone number the pbx > services, then presumably it will first be mapped to the corresponding > contact for the pbx, and *then* proxied on that basis. Right. Just like an INVITE. Or an UNKNOWN_METHOD. /a From adam@nostrum.com Fri Feb 5 09:20: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 3FD5D3A6F3C for ; Fri, 5 Feb 2010 09:20:46 -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.053, 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 IrwbezM6YqFo for ; Fri, 5 Feb 2010 09:20: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 863CE3A680C for ; Fri, 5 Feb 2010 09:20:41 -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 o15HLTrd087006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 11:21:29 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C5399.9070105@nostrum.com> Date: Fri, 05 Feb 2010 11:21: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: <4B68BEB4.2020207@nostrum.com><4B6991B1.1040806@nostrum.com><430FC6BDED356B4C8498F634416644A917E5E0E121@mail><4B6B2331.6050209@nostrum.com> <4B6C3FA7.2090404@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 Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 17:20:46 -0000 On 2/5/10 10:37 AM, Elwell, John wrote: > In principle, yes, but I am not sure how. The original concern was with GRUUs having xxxx.sp.com, where xxxx is recognised as being internal to the PBX. First, perhaps we need a requirement that the mechanism must allow the PBX to provide its UAs with public or temporary GRUUs. > Ah, yes. That would be a good thing to add. > Second, and this is the harder part, we seem to be asking for something to be said about not precluding direct on-PBX routing of requests to xxx@sp.com, where xxx is known to be on-PBX. The difficulty I have with this is that it seems to assume a solution involving sp.com as the host part of a URI for an on-PBX entity. Any ideas what we should say? > I don't think we need to get that far into mechanism. What I think we want to say is that the mechanism must not preclude the ability of the PBX to route on-PBX calls directly, without hair-pinning the signaling through the SSP. /a From pkyzivat@cisco.com Fri Feb 5 09:23: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 E29A43A6A22 for ; Fri, 5 Feb 2010 09:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 FJYJjeC67pzX for ; Fri, 5 Feb 2010 09:23:04 -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 648553A680C for ; Fri, 5 Feb 2010 09:23:03 -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: ApoEAHbja0tAZnwM/2dsb2JhbADAO5d8hFIE X-IronPort-AV: E=Sophos;i="4.49,414,1262563200"; d="scan'208";a="84270990" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2010 17:23:48 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o15HNmD8003528; Fri, 5 Feb 2010 17:23:48 GMT Message-ID: <4B6C5425.9000405@cisco.com> Date: Fri, 05 Feb 2010 12:23:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com><0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com><4B680653.6D98.00CB.0@cablevision.com><4B68270C.6D98.00CB.0@cablevision.com> <0E006E68-093A-4D22-ADE2-A54F3AB4B93E@softarmor.com> <00cf01caa669$be167480$150610ac@CORPORATE.VOX.NET> <4B6C35B6.7050101@nostrum.com> <012601caa67e$e3c79b40$150610ac@CORPORATE.VOX.NET> <4B6C4F0F.3000802@nostrum.com> In-Reply-To: <4B6C4F0F.3000802@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 17:23:07 -0000 Adam Roach wrote: > On 2/5/10 10:18 AM, Tyler Parkin wrote: >> Out of curiosity, is there a process defined (or does there need to >> be) for an individual registration superceding a previously >> bulk-registered number? >> >> I think these are obvious, but... >> >> Example 1: PBX registers a number as part of bulk reg. User then >> enables a softphone which either uses a different PBX or comes >> directly to the SSP and registers the number again. Obviously, the >> most recent number should take precedence. > > SIP actually has a model for "what happens when you register two > contacts for the same AOR." I don't think we're in a position to > override that model, nor do I think it's a good idea to do so. amen >> Example 2: PBX sends an individual register expires:0 message for a >> specific number (what if it's the primary AoR #?). I would expect >> that if it's an associated number just that entry would be removed >> from the location database. If it's the AoR, do we force de-reg of >> all associated #'s? I assume we'd have to. > > Deregistration is done to a Contact, not an AOR (with the exception of > "Contact: *"). I would assume that deregistering the ";mnc" tagged > contact would do the same thing as registering that contact, but in > reverse. (That is, all the associated entries in the location server > would be removed). > > Now, the question about what happens if the PBX tries to deregister a > *single* phone number from the range is a good one. The semantics would > be pretty clear (remove this one contact/AOR paid), but it would be > un-removed when the bulk registration is renewed, making it a pretty > useless operation. I would propose that we put a "don't do that, then" > clause in. Deregistration of a single number from the range would have implications on certain optimizations that might be done on the location database. While one could simply say "tough - your optimizations must conform to the spec, even if that is hard for you", it might lead to widespread nonconformance. So it might be better to simply ban it. Thanks, Paul From tyler@foxfam.com Fri Feb 5 09:29: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 10D7E3A68FC for ; Fri, 5 Feb 2010 09:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 OdCPcdtVdoOJ for ; Fri, 5 Feb 2010 09:29:43 -0800 (PST) Received: from smtp04.atlngahp.sys.nuvox.net (smtp-out4.atlngahp.sys.nuvox.net [70.43.63.22]) by core3.amsl.com (Postfix) with ESMTP id EA8693A6801 for ; Fri, 5 Feb 2010 09:29:42 -0800 (PST) Received: from LT6KW7CD1 (fw-nat.it.nuvox.net [216.215.144.201]) by smtp04.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o15HUSXm011842; Fri, 5 Feb 2010 12:30:29 -0500 Message-ID: <015501caa688$e9929020$150610ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: "Richard Shockey" , "'Adam Roach'" References: <77A7ADEB-FCA6-4702-B04B-F6F9DF69DC8B@softarmor.com><0AF054D1-2E3E-41F4-859F-4F340E666DB9@dsauder.com><4B680653.6D98.00CB.0@cablevision.com><4B68270C.6D98.00CB.0@cablevision.com> <0E006E68-093A-4D22-ADE2-A54F3AB4B93E@softarmor.com> <00cf01caa669$be167480$150610ac@CORPORATE.VOX.NET> <4B6C35B6.7050101@nostrum.com> <00e901caa684$9561d0f0$c02572d0$@us> Date: Fri, 5 Feb 2010 12:30:27 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: martini@ietf.org Subject: Re: [martini] Implications of multiple AOR/contact mapping X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 17:29:44 -0000 Got it. My concern was less with the (auto)configuration of customer/vendor equipment and more with preventing a customer who adds/removes a couple hundred numbers from hamming me with requests about them until the vendor updates his config... which the PBX in likely hood would not do if it knew the numbers weren't registered. I'll let it drop, just wanted to be clear provisioning wasn't my issue =). Thanks, Tyler ----- Original Message ----- From: "Richard Shockey" To: "'Adam Roach'" ; "'Tyler Parkin'" Cc: Sent: Friday, February 05, 2010 11:59 AM Subject: RE: [martini] Implications of multiple AOR/contact mapping > > Thank you Adam. Tyler that is IMHO the general consensus of those of us > involved in the SIP Forum work over the last 16 months, and nearly all of > those folks are on this list. The issue at hand is a serious > interoperability problem observed in an increasing number of deployments > that needs a solution ASAP. The larger issue of provisioning between SSP > and PBX's is going to take a very long time in the IETF and could run into > serious resistance by vendors etc that will view > provisioning/configuration > standardization as somewhat threatening. Plus the IETF really doesn't do > configuration very well. > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf > Of Adam Roach > Sent: Friday, February 05, 2010 10:14 AM > To: Tyler Parkin > Cc: martini@ietf.org > Subject: Re: [martini] Implications of multiple AOR/contact mapping > > Tyler: > > For the record, I agree with you: explicitly including this information > in the protocol messages is useful. I didn't include a mechanism for > doing so in my draft (even though it would be trivial to do so) because > there appears to be adamant opposition to including this information. I > don't understand the pushback. But given the more important issues with > the solutions in this space, I'm willing to let this one go. > > /a > > On 2/5/10 7:47 AM, Tyler Parkin wrote: >> New to the list so if I'm missing something, sorry about that. If I >> understand correctly, the assertion is that with >> draft-roach-martini-gin-00/imlicit reg, the PBX sends a single AoR to >> the SSP which (because of it's provisioning) automatically activates >> all the associated records in it's location database and just replies >> to the PBX with a generic ();bnc to indicate success. >> >> Provisioning aside, I tend to agree that the PBX needs to be informed >> of which numbers the SSP considers to be implicitly registered for >> that AoR. I'd hate to lose functionality by moving to implicit/bulk >> reg. For example, if I register 100 numbers individually and 10 of >> them fail, then I stop subsequent subscribes/notifies for those >> numbers and, in the case of some PBX's, even present to the end user >> that their line isn't working. >> >> Provisioning disconnects happen all the time between PBX's and SSP's >> as a result of MACD's. I'm not proposing MARTINI resolve procedural >> issues, but a lack of two way acknowledgement of which numbers both >> parties consider active is a loss of functionality. >> >> I realize draft-roach-martini-gin-00 suggests a NOTIFY request to >> communicate status. To me there's a difference between a >> negative/failed registration state vs. relying on a PBX to interrogate >> the SSP after the fact. >> >> Regards, >> >> Tyler >> >> ----- Original Message ----- From: "Dean Willis" >> >> To: "Jack Burton" >> Cc: >> Sent: Friday, February 05, 2010 12:29 AM >> Subject: Re: [martini] Implications of multiple AOR/contact mapping >> >> >>> >>> On Feb 2, 2010, at 7:22 AM, Jack Burton wrote: >>> >>>> How does the PBX learn its outbound numbers and DIDs when it >>>> registers? It needs to know this for more than just registration. >>>> I am not counting on registration as a configuration tool, just as >>>> a way to authenticate and identify the IP-PBX to the SSP. >>>> >>> >>> The PBX does NOT learn its numbers through registration. It has to >>> know them already so it can register them and so the SSP knows what >>> IP address and port to send calls to. The question of "How does the >>> PBX learn its numbers" is entirely outside the current scope of >>> MARTINI. >>> >>> -- >>> 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 Feb 5 09:47: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 0420A3A6C10 for ; Fri, 5 Feb 2010 09:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 nEbDboptzHiP for ; Fri, 5 Feb 2010 09:47:08 -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 CE0513A68E3 for ; Fri, 5 Feb 2010 09:47:07 -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: ApoEADHoa0tAZnwN/2dsb2JhbADAf5d4hFIE X-IronPort-AV: E=Sophos;i="4.49,414,1262563200"; d="scan'208";a="84274004" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2010 17:47:58 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o15HlwZm025196; Fri, 5 Feb 2010 17:47:58 GMT Message-ID: <4B6C59D1.20706@cisco.com> Date: Fri, 05 Feb 2010 12:48:01 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B68BEB4.2020207@nostrum.com> <4B6C3C26.80908@cisco.com> <4B6C5304.9070605@nostrum.com> In-Reply-To: <4B6C5304.9070605@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 17:47:09 -0000 Adam Roach wrote: > On 2/5/10 9:41 AM, Paul Kyzivat wrote: >> Adam, >> >> This is good!!! A few comments: >> >> * Use of () to mark insertion of number: >> >> Why not just place the phone number in a uri-parameter? > > That would work also. Right now, based on Hadriel's input, I'm thinking > the fastest way forward is simply to limit the Contact URIs to have no > userpart at all, and use the 'bnc' parameter to indicate that the user > part should be filled in with the phone number. I find that approach problematic. A pbx that only has one address may still have need to connect to multiple things, and to multiplex that one address other uses as well. I guess you can argue that as long as this is just E.164 numbers, they will be unique across multiple providers, and other uses of the user part can avoid anything that looks like an E.164 number. A URI parameter seems very straightforward, and one could be registered for the purpose. One of the arguments against URI parameters is that they don't survive address translation. But in this case the translation that would lose it is precisely the box that would consume this parameter. OTOH, I suppose there will be a bunch of folk who have code that works for the user part, and that won't work for a URI parameter. >> * Need for Proxy-Require >> >> You say we need because we are altering the semantics of REGISTER. But >> which semantics of register *that pertain to proxies* are we altering? > > Policy decisions that have historically applied to a single AOR will now > be applied to REGISTER transactions that pertain to multiple AORs. > That's a change. > > Really: why else are you going to have proxies between the PBX and the > SSP? It pretty much comes down to NAT traversal and application of policy. AFAIK all of these things are making leaps of faith that aren't supported by the standards. As far as the standards say, there is no relationship between registration and being able to originate requests, or between registration and the possible addresses of requests that are allowed to come your way. Registration is simply a way to tell somebody "please establish a mapping from specified AOR to this URI". The fact that others put other connotations on the register is *their* business, not ours. If we want to support those other connotations then we ought to codify them first. I guess the option tag can be defined, and the choice to use it in Proxy-Require can be a policy decision, based on whether you have devices that make such leaps of faith as require it. >> * Temp GRUUs >> >> One possibility would be for the pbx to use the public GRUU seed of >> some single number (the attendant number?) of the pbx to mint its own >> temporary GRUUs. Their anonymity would be limited since they can all >> be traced to the same pbx, but that may be acceptable in some cases. > > I thought through this, and decided that doing the temp-GRUUs at the SSP > introduced far more complication than was gained. Since public GRUUs get > you the ability to do all the call-control state, I'm not sure it's as > important to make the temp-GRUUs as universally available. > > I'm not really attached to this viewpoint, though. If someone wants to > write up text about how to do temp-GRUUs through the SSP (including an > analysis of why it works), then I'm happy to put it in. I think you missed my point. What I was suggesting does not require the SSP to do anything more. Its simply local behavior that the pbx could use to mint its own temp gruus using one of its public gruus from the SSP. >> * Aggregate reg state >> >> You say the () syntax and bnc can't appear. But reg event >> notifications should contain information on GRUUs too. (RFC 5628) And >> those gruus would have that syntax in them. > > Oh, good point. Interesting. The SSP won't actually know the mapping > from public GRUU to AOR, since the substitution is done at the PBX. I > think we probably won't be able to usefully put GRUU information into > the aggregate registration state. I'll have to dig through some > documents to determine whether this would be a valid thing to do. What the aggregate registration state can provide is the template public gruu returned in response to the register. It can't provide public gruus for all the associated AORs. Thanks, Paul From john.elwell@siemens-enterprise.com Fri Feb 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 DC6A23A6F63 for ; Fri, 5 Feb 2010 10:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-Ra6UE4dSwL for ; Fri, 5 Feb 2010 10:17:56 -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 763573A6F66 for ; Fri, 5 Feb 2010 10:17:56 -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-797281; Fri, 5 Feb 2010 19:18:46 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 66FC31EB82AB; Fri, 5 Feb 2010 19:18:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 5 Feb 2010 19:18:46 +0100 From: "Elwell, John" To: Adam Roach Date: Fri, 5 Feb 2010 19:18:44 +0100 Thread-Topic: [martini] GIN Draft Thread-Index: Acqmh6r2uUq7eNKmS++PPxN9Mf5CEgAB/VKw Message-ID: References: <4B68BEB4.2020207@nostrum.com><4B6991B1.1040806@nostrum.com><430FC6BDED356B4C8498F634416644A917E5E0E121@mail><4B6B2331.6050209@nostrum.com> <4B6C3FA7.2090404@nostrum.com> <4B6C5399.9070105@nostrum.com> In-Reply-To: <4B6C5399.9070105@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 Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 18:17:58 -0000 Sounds good. John=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 05 February 2010 17:21 > To: Elwell, John > Cc: Spencer Dawkins; Hadriel Kaplan; MARTINI > Subject: Re: [martini] GIN Draft >=20 > On 2/5/10 10:37 AM, Elwell, John wrote: > > In principle, yes, but I am not sure how. The original=20 > concern was with GRUUs having xxxx.sp.com, where xxxx is=20 > recognised as being internal to the PBX. First, perhaps we=20 > need a requirement that the mechanism must allow the PBX to=20 > provide its UAs with public or temporary GRUUs. > > =20 >=20 > Ah, yes. That would be a good thing to add. >=20 > > Second, and this is the harder part, we seem to be asking=20 > for something to be said about not precluding direct on-PBX=20 > routing of requests to xxx@sp.com, where xxx is known to be=20 > on-PBX. The difficulty I have with this is that it seems to=20 > assume a solution involving sp.com as the host part of a URI=20 > for an on-PBX entity. Any ideas what we should say? > > =20 >=20 > I don't think we need to get that far into mechanism. What I think we=20 > want to say is that the mechanism must not preclude the=20 > ability of the=20 > PBX to route on-PBX calls directly, without hair-pinning the=20 > signaling=20 > through the SSP. >=20 > /a > = From john.elwell@siemens-enterprise.com Fri Feb 5 10: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 2B3A13A6C14 for ; Fri, 5 Feb 2010 10:24:20 -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 U2RRCSJvDIuD for ; Fri, 5 Feb 2010 10:24:19 -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 B45173A6C8A for ; Fri, 5 Feb 2010 10:24:18 -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-797395; Fri, 5 Feb 2010 19:25:08 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 664611EB82AB; Fri, 5 Feb 2010 19:25:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Feb 2010 19:25:08 +0100 From: "Elwell, John" To: "DRAGE, Keith (Keith)" , Dean Willis , Christer Holmberg Date: Fri, 5 Feb 2010 19:25:07 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqmIp45lkH/XHydQ6a2R18/6B+Y6QAPZmwwAAwDsEA= Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> <4B670F85.4030808@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" , Hadriel Kaplan 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, 05 Feb 2010 18:24:20 -0000 Keith, I think the gin-00 solution could handle that, by treating each as a logica= l PBX (i.e., registering separately on behalf of each). Rather like a multi= -line UA would register separately on behalf of each of its lines. Anyway, = if you believe we should address requirements in this area, we should say s= o in the requirements draft. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: 05 February 2010 12:46 > To: Dean Willis; Christer Holmberg > Cc: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 > Just picking up on this one. >=20 >=20 > > > Again, as far as I understand, from a SIP network=20 > > perspective the PBX=20 > > > only has a single contact. > >=20 > >=20 > > That depends on the PBX, doesn't it? > > =20 > If I have a scenario for what used to be called a=20 > multi-tenant PBX, i.e. where the physical resources are being=20 > shared, including the ADSL link, it may well be that you need=20 > a separate key identifier for each tenant.=20 >=20 > Certainly in the TISPAN work we said that the registered=20 > contact should represent an endpoint that is able to act on=20 > behalf of all the other URIs that implicitly registered as=20 > part of that registration. Thus a URI that represents the=20 > attendent of tenant 1 can be used to register all the public=20 > URIs of users of tenant 1, but not should be responsible for=20 > those of tenant 2 (excluding a shared attendant of course). >=20 > How much this impacts the SSP depends on other things. To the=20 > SSP it may look like a set of independent PBXs, but in IMS=20 > land they could all share the same private user identity and=20 > use the same security association. >=20 > regards >=20 > Keith >=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > > Sent: Friday, February 05, 2010 5:18 AM > > To: Christer Holmberg > > Cc: martini@ietf.org; Hadriel Kaplan > > Subject: Re: [martini] Proposed work split: tackle=20 > > telephone-numberregistration first > >=20 > >=20 > > On Feb 2, 2010, at 12:12 AM, Christer Holmberg wrote: > >=20 > > > > > > Hi, > > > > > >>> I think that is wrong usage of the Contact header. You=20 > > more or less=20 > > >>> use it for carrying target information. We have other=20 > > mechanisms for=20 > > >>> that. > > >> > > >> I beg to differ. The contact address is the ultimate target. > > >> There have been many documents pointing that out. > > >> And as long as you register each AOR independently it can=20 > > be handled=20 > > >> very cleanly. > > > > > > In my opinion Contact is not meant to be used for=20 > informing the UA=20 > > > about what number was called etc in order to reach the UA. > >=20 > > No, but it IS the mechanism that a proxy uses to select the=20 > > UA to which the INVITE should be sent. In other words it=20 > > doesn't inform the UA as to which number was used; rather it=20 > > informs the UA as to which handset to alert. > >=20 > > > > > >>> I also think it is a very "clumsy" solution, when you mandate a=20 > > >>> 1-to-1 mapping of the R-URI/Contact userpart values=20 > > (maybe it could=20 > > >>> also have security impacts). > > >> > > >> Its clumsy precisely because of implicit registration. > > >> Adam's proposal provided a way to do that mapping under=20 > > the control=20 > > >> of the recipient so that only expected contact addresses=20 > are used. > > > > > > Again, as far as I understand, from a SIP network=20 > > perspective the PBX=20 > > > only has a single contact. > >=20 > >=20 > > That depends on the PBX, doesn't it? > >=20 > > -- > > 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 bernard_aboba@hotmail.com Fri Feb 5 10:39: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 01CF73A6D9C for ; Fri, 5 Feb 2010 10:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.353 X-Spam-Level: X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=-0.614, 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 4gB3psrVA6iy for ; Fri, 5 Feb 2010 10:39:44 -0800 (PST) Received: from blu0-omc2-s19.blu0.hotmail.com (blu0-omc2-s19.blu0.hotmail.com [65.55.111.94]) by core3.amsl.com (Postfix) with ESMTP id A704C3A6828 for ; Fri, 5 Feb 2010 10:39:44 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.71]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 10:40:35 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 5 Feb 2010 10:40:35 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0204_01CAA64F.A6B027B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqmkrSaUy4RFUS7TA+MohWChj+xMQ== Content-Language: en-us X-OriginalArrivalTime: 05 Feb 2010 18:40:35.0636 (UTC) FILETIME=[B4731F40:01CAA692] Subject: [martini] Conflict with MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 18:39:48 -0000 ------=_NextPart_000_0204_01CAA64F.A6B027B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It has been brought to our attention that the date of MARTINI Virtual Interim IV (March 2) conflicts with a joint 3GPP/IETF IPv6 transition meeting in San Francisco. Given this, we are likely to lose a number of people including Keith, our co-Chair (Spencer) and maybe even some Area Directors. Given this, it seems prudent to reconsider the date/time. Are there any obvious conflicts for the second week of March (March 8 - 12, 2010)? Given that IETF 77 is taking place on March 21-26, this is probably the latest date that could make sense before then. ------=_NextPart_000_0204_01CAA64F.A6B027B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It has been brought to our attention that the date = of MARTINI Virtual Interim IV (March 2) conflicts with a joint 3GPP/IETF = IPv6 transition meeting in San Francisco.   Given this, we are = likely to lose a number of people including Keith, our co-Chair (Spencer) and maybe even = some Area Directors.

 

Given this, it seems prudent to reconsider the = date/time. 

 

Are there any obvious conflicts for the second week = of March (March 8 – 12, 2010)?   Given that IETF 77 is taking = place on March 21-26, this is probably the latest date that could make sense before = then.

------=_NextPart_000_0204_01CAA64F.A6B027B0-- From adam@nostrum.com Fri Feb 5 11:31: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 EA04F28C0E3 for ; Fri, 5 Feb 2010 11:31:18 -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.052, 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 Wf0gtciHNa9k for ; Fri, 5 Feb 2010 11:31: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 E8B233A6C6C for ; Fri, 5 Feb 2010 11:31:15 -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 o15JW2lm098638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 13:32:03 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6C7232.4090009@nostrum.com> Date: Fri, 05 Feb 2010 13:32: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: Paul Kyzivat References: <4B68BEB4.2020207@nostrum.com> <4B6C3C26.80908@cisco.com> <4B6C5304.9070605@nostrum.com> <4B6C59D1.20706@cisco.com> In-Reply-To: <4B6C59D1.20706@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 Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 19:31:19 -0000 On 2/5/10 11:48 AM, Paul Kyzivat wrote: > > > Adam Roach wrote: >> On 2/5/10 9:41 AM, Paul Kyzivat wrote: >>> Adam, >>> >>> This is good!!! A few comments: >>> >>> * Use of () to mark insertion of number: >>> >>> Why not just place the phone number in a uri-parameter? >> >> That would work also. Right now, based on Hadriel's input, I'm >> thinking the fastest way forward is simply to limit the Contact URIs >> to have no userpart at all, and use the 'bnc' parameter to indicate >> that the user part should be filled in with the phone number. > > I find that approach problematic. A pbx that only has one address may > still have need to connect to multiple things, and to multiplex that > one address other uses as well. > > I guess you can argue that as long as this is just E.164 numbers, they > will be unique across multiple providers, and other uses of the user > part can avoid anything that looks like an E.164 number. > > A URI parameter seems very straightforward, and one could be > registered for the purpose. One of the arguments against URI > parameters is that they don't survive address translation. But in this > case the translation that would lose it is precisely the box that > would consume this parameter. > > OTOH, I suppose there will be a bunch of folk who have code that works > for the user part, and that won't work for a URI parameter. That was the major consideration I had in mind when I suggested putting it in the user portion. > > >>> * Need for Proxy-Require >>> >>> You say we need because we are altering the semantics of REGISTER. >>> But which semantics of register *that pertain to proxies* are we >>> altering? >> >> Policy decisions that have historically applied to a single AOR will >> now be applied to REGISTER transactions that pertain to multiple >> AORs. That's a change. >> >> Really: why else are you going to have proxies between the PBX and >> the SSP? It pretty much comes down to NAT traversal and application >> of policy. > > AFAIK all of these things are making leaps of faith that aren't > supported by the standards. I think RFCs 3327 and 3608 actually provide such support, after a fashion. They're designed explicitly to put proxies in the path at registration time. What are these proxies ostensibly used for? >>> * Temp GRUUs >>> >>> One possibility would be for the pbx to use the public GRUU seed of >>> some single number (the attendant number?) of the pbx to mint its >>> own temporary GRUUs. Their anonymity would be limited since they can >>> all be traced to the same pbx, but that may be acceptable in some >>> cases. >> >> I thought through this, and decided that doing the temp-GRUUs at the >> SSP introduced far more complication than was gained. Since public >> GRUUs get you the ability to do all the call-control state, I'm not >> sure it's as important to make the temp-GRUUs as universally available. >> >> I'm not really attached to this viewpoint, though. If someone wants >> to write up text about how to do temp-GRUUs through the SSP >> (including an analysis of why it works), then I'm happy to put it in. > > I think you missed my point. What I was suggesting does not require > the SSP to do anything more. Its simply local behavior that the pbx > could use to mint its own temp gruus using one of its public gruus > from the SSP. Ah, I see. You're saying that the PBX does something to get a *PUBLIC* GRUU from the SSP, and then hands it out (with tokens appended) as a *PRIVATE* GRUU for its internal extensions. I missed that you were doing this public-to-private crossover. Yes, that works, subject to the restrictions you placed on it. It does end up having the kind of bizarre property that they look like public URIs for one AOR, but are *actually* temp URIs for another. I would suggest, if we want to go down this path, we define it in addition to what I currently have the draft, instead of replacing it. That is: if the PBX can make its own temp-gruus (as described in the current GIN draft), it does; otherwise, it makes use of the mechanism you describe. > >>> * Aggregate reg state >>> >>> You say the () syntax and bnc can't appear. But reg event >>> notifications should contain information on GRUUs too. (RFC 5628) >>> And those gruus would have that syntax in them. >> >> Oh, good point. Interesting. The SSP won't actually know the mapping >> from public GRUU to AOR, since the substitution is done at the PBX. I >> think we probably won't be able to usefully put GRUU information into >> the aggregate registration state. I'll have to dig through some >> documents to determine whether this would be a valid thing to do. > > What the aggregate registration state can provide is the template > public gruu returned in response to the register. It can't provide > public gruus for all the associated AORs. I'm not sure I understand your proposal, then. Can you sketch out what such an XML document would look like? /a From richard@shockey.us Fri Feb 5 15:09: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 3DC4F3A6868 for ; Fri, 5 Feb 2010 15:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.273, 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 tpSarTYVQEPb for ; Fri, 5 Feb 2010 15:09:29 -0800 (PST) Received: from outbound-mail-342.bluehost.com (outbound-mail-342.bluehost.com [66.147.249.3]) by core3.amsl.com (Postfix) with SMTP id 6EA1B3A6D6A for ; Fri, 5 Feb 2010 15:09:29 -0800 (PST) Received: (qmail 16627 invoked by uid 0); 5 Feb 2010 23:10:21 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 5 Feb 2010 23:10:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=MBGl2xWzP57jWUQD6++J8EDlyfIx+ZvX7OcvQV+m3PeGC+NYoj01SbjkPGP0fUP4f2IQTW1GySIbmbm5zBpW/IqfcjFigEwn9kVmMl6zOel++Vt6ijWPNOPnp8bbMvxs; 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 1NdXJd-0004Ah-5I for martini@ietf.org; Fri, 05 Feb 2010 16:10:21 -0700 From: "Richard Shockey" To: Date: Fri, 5 Feb 2010 18:10:18 -0500 Message-ID: <017901caa6b8$6291b530$27b51f90$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017A_01CAA68E.79BBAD30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqmuGH+Py+ATF/pQfOh5O3bv0eWzg== 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: [martini] A modest proposal... X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 05 Feb 2010 23:09:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_017A_01CAA68E.79BBAD30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IMHO there is enough commonality in drafts gin and shaken that should be merged into a single co-authored draft and that the principal goal of next week's interim meeting should be to ratify the requirements and the combined draft as WG items and proceed with all deliberate speed. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ------=_NextPart_000_017A_01CAA68E.79BBAD30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMHO  there is enough commonality in drafts = gin and shaken that should be merged into a single co-authored  draft and that the = principal goal of next week’s interim meeting should be to ratify the = requirements and the combined draft as WG items and proceed with all deliberate = speed.

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype: rshockey101
LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org

 

------=_NextPart_000_017A_01CAA68E.79BBAD30-- From bernard_aboba@hotmail.com Fri Feb 5 20:38: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 4B71C3A6842 for ; Fri, 5 Feb 2010 20:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.880, 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 ksN0SOdKmqc0 for ; Fri, 5 Feb 2010 20:38:11 -0800 (PST) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by core3.amsl.com (Postfix) with ESMTP id D093F3A69D6 for ; Fri, 5 Feb 2010 20:38:10 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.72]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 20:39:03 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 5 Feb 2010 20:39:41 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0107_01CAA6A3.5831F6F0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acqm5mYTuKTozgGOT460/Jmgyo+MBQ== Content-Language: en-us X-OriginalArrivalTime: 06 Feb 2010 04:39:03.0644 (UTC) FILETIME=[4F4A51C0:01CAA6E6] Subject: [martini] Potential alternative Virtual Interim IV date: March 1, 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: Sat, 06 Feb 2010 04:38:14 -0000 ------=_NextPart_000_0107_01CAA6A3.5831F6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Due to the potential conflict with the IETF/3GPP IPv6 transition meeting, we are considering moving the date of MARTINI Virtual Interim IV to Monday, March 1, 2010 from 11 AM - 1 PM Pacific Time. To allow us to understand all the ramifications/issues with this potential date (we'll make a final decision at close of business Monday), please fill out the Doodle poll if you haven't already done so: http://www.doodle.com/gfd9ramt42v5cxbd ------=_NextPart_000_0107_01CAA6A3.5831F6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Due to the potential conflict with the IETF/3GPP = IPv6 transition meeting, we are considering moving the date of MARTINI = Virtual Interim IV to Monday, March 1, 2010 from 11 AM – 1 PM Pacific = Time.  To allow us to understand all the ramifications/issues with this = potential date (we’ll make a final decision at close of business Monday), please = fill out the Doodle poll if you haven’t already done so:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

------=_NextPart_000_0107_01CAA6A3.5831F6F0-- From bernard_aboba@hotmail.com Fri Feb 5 22:01: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 CF1F13A7007 for ; Fri, 5 Feb 2010 22:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=-0.586, 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 N+4b6th--uAT for ; Fri, 5 Feb 2010 22:01:16 -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 F36173A6FD6 for ; Fri, 5 Feb 2010 22:01:15 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.71]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 22:02:08 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 5 Feb 2010 22:02:07 -0800 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acql0pu2ZlMdDPubTEO2m66tPhtQXwBH012Q Content-Language: en-us X-OriginalArrivalTime: 06 Feb 2010 06:02:08.0926 (UTC) FILETIME=[EABFFBE0:01CAA6F1] Subject: [martini] MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 06 Feb 2010 06:01:16 -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:20100206T060206Z DESCRIPTION:When: Monday\, March 01\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pac ific Time (US & Canada).\nWhere: Cyberspace\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\ n\nDetails TBD. \n DTEND:20100301T210000Z DTSTAMP:20100206T060206Z DTSTART:20100301T190000Z LAST-MODIFIED:20100206T060206Z LOCATION:Cyberspace ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:1 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim IV TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E008000000009007938D8FA5CA01000000000000000 0100000001F815CB7E59A144492451C2E670E961A X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Monday\, March 01\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Ti me (US &\; Canada).

\n\n

Where: Cyberspace

\n\n

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

\n\n

< SPAN LANG="en-us">*~*~*~*~*~*~*~*~*~*\n\n

Details TBD.

\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-APPTSEQTIME:20100204T194635Z 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 HKaplan@acmepacket.com Sat Feb 6 07:56: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 F3E183A6C15 for ; Sat, 6 Feb 2010 07:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 6Dspm3p82RvB for ; Sat, 6 Feb 2010 07:56:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EF1C33A6C05 for ; Sat, 6 Feb 2010 07:56:30 -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; Sat, 6 Feb 2010 10:57:24 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 6 Feb 2010 10:57:24 -0500 From: Hadriel Kaplan To: Adam Roach Date: Sat, 6 Feb 2010 10:57:24 -0500 Thread-Topic: [martini] comments on draft-roach-martini-gin-00 Thread-Index: Acql1fASF+OY6bddTraC60cIad+omgAADyrw Message-ID: <430FC6BDED356B4C8498F634416644A917E5E0E38A@mail> References: <430FC6BDED356B4C8498F634416644A917E5E0E11A@mail> <4B6B2957.4000209@nostrum.com> In-Reply-To: <4B6B2957.4000209@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] comments on draft-roach-martini-gin-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, 06 Feb 2010 15:56:32 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, February 04, 2010 3:09 PM > To: Hadriel Kaplan >=20 > On 2/4/10 11:53 AM, Hadriel Kaplan wrote: > > Hi Adam, > > Thanks for taking the time to write up the draft! > > > > I have a few comments/questions: > > 1) Why bother having the "()" indicator in the Contact-URI username? > This implies that the Contact-URI could be "sip:foo()bar@192.0.2.1", or > something similar, such that a placeholder is needed. But why do we need > to complicate the mechanism to handle that? The PBX can already use URI > params if it needs extra cookies, or it can even insert itself as a Path > header. I do, though, think the explicitly Registered contact-URI could > be of the form "sip:foobar@192.0.2.1", and have a username - but it would > be replaced for the expanded entries. >=20 > What would the username do in your example? If we get rid of the '()' > syntax, then I'd propose heading directly for URIs of the form > instead. But I think the ability for the PBX to > specify the form of its own contact URIs (even if constrained by having > the entire phone number inserted) is still a useful one. The username would be replaced for the expanded set, but would be a real UR= I username - of the PBX itself. In other words, there is a real UA in the = PBX which is performing the Registration, and sip:foobar@192.0.2.1 is its c= ontact URI. > > 3) Why does the Contact-URI have a 'bnc' param, instead of in the AoR > being Registered? ISTM the expansion of the location service entries is > actually a property of the AoR, not its location/contact. >=20 > No, it's the Contact URI that's having something special done to it. > We're saying "explode this URI into a bunch of different URIs according > to this new procedure." It means "this is not the actual URI; it is a > placeholder for the actual URI, and it must be modified to be the actual > URI." Oh, but I'm thinking it *is* a real URI. For example, I can send an OPTION= S request to it. And the PBX can use it to send a SUBSCRIBE, for example t= o the reg-event package. -hadriel From adam@nostrum.com Sat Feb 6 08:29: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 C4A563A6C36 for ; Sat, 6 Feb 2010 08:29:17 -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 kzKf3XE2PCzw for ; Sat, 6 Feb 2010 08:29:16 -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 373663A6801 for ; Sat, 6 Feb 2010 08:29:15 -0800 (PST) Received: from [192.168.0.128] (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 o16GU4Df003933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2010 10:30:05 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6D990C.9020005@nostrum.com> Date: Sat, 06 Feb 2010 10:30:04 -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: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A917E5E0E11A@mail> <4B6B2957.4000209@nostrum.com> <430FC6BDED356B4C8498F634416644A917E5E0E38A@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A917E5E0E38A@mail> 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] comments on draft-roach-martini-gin-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, 06 Feb 2010 16:29:17 -0000 On 02/06/2010 09:57 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Thursday, February 04, 2010 3:09 PM >> To: Hadriel Kaplan >> >> On 2/4/10 11:53 AM, Hadriel Kaplan wrote: >> >>> Hi Adam, >>> Thanks for taking the time to write up the draft! >>> >>> I have a few comments/questions: >>> 1) Why bother having the "()" indicator in the Contact-URI username? >>> >> This implies that the Contact-URI could be "sip:foo()bar@192.0.2.1", or >> something similar, such that a placeholder is needed. But why do we need >> to complicate the mechanism to handle that? The PBX can already use URI >> params if it needs extra cookies, or it can even insert itself as a Path >> header. I do, though, think the explicitly Registered contact-URI could >> be of the form "sip:foobar@192.0.2.1", and have a username - but it would >> be replaced for the expanded entries. >> >> What would the username do in your example? If we get rid of the '()' >> syntax, then I'd propose heading directly for URIs of the form >> instead. But I think the ability for the PBX to >> specify the form of its own contact URIs (even if constrained by having >> the entire phone number inserted) is still a useful one. >> > The username would be replaced for the expanded set, but would be a real URI username - of the PBX itself. In other words, there is a real UA in the PBX which is performing the Registration, and sip:foobar@192.0.2.1 is its contact URI. > No, that's a different thing, and there's a very real chance that you'll want different parameters on it. For example, I would wager that the phone number contacts will end up in the form: While this "main PBX contact" you're talking about would probably be of the form: So, I think for the circumstance that you'll want this latter thing (which is feeling very much like the "general case", not the "phone numbers only" case), you'll need to register it separately. But really, is this trying to pick up functionality for free, or is it driven by an actual use case? Remember, we're trying to keep this fast and simple. /a From adam@nostrum.com Sat Feb 6 09:04: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 1214E3A6F47 for ; Sat, 6 Feb 2010 09:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 vAY9dOHNLbAX for ; Sat, 6 Feb 2010 09:04: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 BF3033A6F48 for ; Sat, 6 Feb 2010 09:04:55 -0800 (PST) Received: from [192.168.0.128] (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 o16H5kPT006568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2010 11:05:46 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6DA16A.9080109@nostrum.com> Date: Sat, 06 Feb 2010 11:05:46 -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: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A917E5E0E11A@mail> <4B6B2957.4000209@nostrum.com> <430FC6BDED356B4C8498F634416644A917E5E0E38A@mail> <4B6D990C.9020005@nostrum.com> In-Reply-To: <4B6D990C.9020005@nostrum.com> Content-Type: text/html; charset=ISO-8859-1 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] comments on draft-roach-martini-gin-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, 06 Feb 2010 17:04:57 -0000 On 02/06/2010 10:30 AM, Adam Roach wrote:
On 02/06/2010 09:57 AM, Hadriel Kaplan wrote:
The username would be replaced for the expanded set, but would be a real URI username - of the PBX itself.  In other words, there is a real UA in the PBX which is performing the Registration, and sip:foobar@192.0.2.1 is its contact URI.   

No, that's a different thing, and there's a very real chance that you'll want different parameters on it.

For example, I would wager that the phone number contacts will end up in the form:

<sip:+12145550100@192.0.2.1;user=phone>

While this "main PBX contact" you're talking about would probably be of the form:

<sip:foobar@192.0.2.1>

So, I think for the circumstance that you'll want this latter thing (which is feeling very much like the "general case", not the "phone numbers only" case), you'll need to register it separately.


Reply to myself; sorry...

I realized that this could be read as "send two REGISTER requests," which is not what I mean (although it would work). What I mean is that you could send a single REGISTER request with two contacts (which is explicitly allowed by 3261). One Contact would be tagged "bnc" (and therefore expand into the associated phone numbers), while the other wouldn't (and would therefore be a literal URI).

That is, if you really want to do what you propose, you would send a REGISTER that looks something like:

   REGISTER sip:ssp.example.com SIP/2.0
   Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
   Max-Forwards: 70
   To: <sip:pbx@ssp.example.com>
   From: <sip:pbx@ssp.example.com>;tag=a23589
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Require: bulk-number-contact
   Contact: <sip:198.51.100.3:5060;user=phone;bnc>
   Contact: <sip:foobar@192.51.100.3:5060>
   Expires: 7200
   Content-Length: 0
/a
From bernard_aboba@hotmail.com Sat Feb 6 17:50: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 90BF73A7147 for ; Sat, 6 Feb 2010 17:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.524, 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 OkWDhh7pr25f for ; Sat, 6 Feb 2010 17:50:47 -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 C02293A7142 for ; Sat, 6 Feb 2010 17:50:46 -0800 (PST) Received: from BLU137-W17 ([65.55.111.73]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Feb 2010 17:51:42 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_56b4e0f3-aca1-4f69-a629-0c6ad54cc811_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: Date: Sat, 6 Feb 2010 17:51:43 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2010 01:51:42.0953 (UTC) FILETIME=[18FC3590:01CAA798] Subject: [martini] Draft Minutes from 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: Sun, 07 Feb 2010 01:50:50 -0000 --_56b4e0f3-aca1-4f69-a629-0c6ad54cc811_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 MARTINI WG Virtual Interim Meeting #2 =20 Date: Tuesday Jan 26th=2C 2009 Time: 10:00 AM: 12:30 PM PST=20 Minute takers:=20 David Hancock=2C John Elwell =20 Attendees: =20 Adam Roach Roach Adam Roach Uzelac Alan John Elwellston Andy Hutton Bernard Aboba Aboba Brian Lindsay Lindsay Rich Shockey Christain Schmidt Cullen Jennings Jennings Dan Romascanu Dean Willis Willis Doug Sauders Ernst Horvath Hadriel Kaplan Kaplan James Swan John Elwell Elwell Keith Drage Drage Krisztian Kiss Mary Barnes Paul Kyzivat Kyzivat David Hancock Spencer Dawkins Dawkins =20 =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= =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 =20 1. Agenda bashing No comments. =20 2. John Elwells Requirement List =20 Requirement-1: The mechanism MUST allow the PBX to be responsible for its AORs and to handle requests to those AORs according to = its rules. =20 Adam Roach: the term =93responsible for domain=94 is mentioned in RFC3261=2C and in general it doesn=92t allow a no= n-responsible proxy to retarget. =20 Paul Kyzivat: Agreed. But if the SSP network receives a request addressed to the SSP=92s domain and identifying = an enterprise user=2C and the PBX is not reachable=2C the SSP should be allowe= d to retarget the request to voice mail. But if incoming request is addressed to= the enterprise domain then it shouldn=92t be allowed to retarget.=20 =20 Keith Drage: the SSP has a virtual PBX that is (or represents) the physical PBX. As such it (the SSP) is responsible fo= r the enterprise domain. =20 Adam Roach: The aspect of domain responsibility and how it might affect the MARTINI solutions is something n= ew that hasn=92t been fully considered yet. =20 Paul Kyzivat: From a SIP perspective it makes a difference whether we=92re considering only E.164 numbers=2C or not= . =20 Richard Shockey: emphasizes that we=92re really only concerned about telephone numbers. =20 Paul Kyzivat: Things get simplified greatly if we agree this is only about E.164 numbers. But if we make that simplification=2C then the RFC better explicitly state that the scope is li= mited to that. =20 Richard Shockey agrees. =20 Dean Willis: this scope issue affects the rest of our discussion. So this has got to be question number 1. =20 Cullen Jennings: we have to solve the phone number problem first=2C and if we do that it is enough for the consumers of= this specification work. =20 Spencer Dawkins: we need to make this decision on the list=2C but could we decide to limit it to E.164 numbers fo= r this call (at least)? =20 Adam Roach: OK with limiting to E.164 numbers=2C but you have to be able to tell it is an E.164 number by some st= andard mechanism.=20 =20 Spencer Dawkins and Richard Shockey agree. =20 Dean Willis: One way to indicate that URI contains an E.164 number is to use Tel URIs.=20 =20 Paul Kyzivat agrees. Tel URIs=2C solve problems with From: & To: headers as well. =20 Richard Shockey: what about SIP URI with =93user=3Dphone=94? =20 Keith Drage: Disagrees with limiting scope to E.164 number=2C since it excludes private numbers that may not be E.164 numbers.=20 =20 Paul Kyzivat: the problem with using a SIP URI with =93user=3Dphone=94 is that if you don=92t own the URI domain then = you can=92t look at the user part. =20 Dean Willis: RFC3261 doesn=92t allow registration of TEL URI. But since we=92re changing REGISTER: we can change= that too.=20 =20 Richard Shockey: Let=92s narrow the scope to something solvable. However=2C using TEL URIs is neither necessary nor helpful. Service providers won=92t deplo= y that.=20 =20 Hadriel Kaplan: if the SSP receives an E.164 at SSP domain then there=92s no problem. It=92s when the request arri= ves with the PBX domain that there is an issue. =20 Adam Roach: Richard Shockey (SIPconnect1.1) has a tight time requirement to solve specific problem=2C namely to standar= dize procedures for support of E.164 numbers. Others in the group have a less ti= me critical and more general requirement to standardize procedures for any typ= e of AOR.=20 =20 Requirements 2=2C3=2C4: no comments. =20 Requirement-5: The mechanism MUST observe SIP backwards compatibility principles.=20 =20 Keith Drage: This sounds like a good requirement=2C but unfortunately these principles aren=92t written down any= where.=20 =20 Requirement-6: 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)= =2C where those intermediate "proxies" need to be on the path of inbound requests to the PBX. =20 Someone: If we keep this requirement we need to nail down the term =93proxies=94.=20 =20 Keith Drage: what is the use-case that requires proxies in enterprise? =20 Paul Kyzivat: There are cases where an enterprise might want to put an SBC between the PBX and the SP network. =20 Dean Willis: there could be things (like proxies) between PBX and SP network=2C and things between enterprise UA and= the PBX. =20 Many responded: the 2nd case is definitely out-of-scope. =20 Keith Drage: the PBX registration with the PS network is independent and separate from the enterprise users registerin= g with the PBX. =20 Dean Willis: there may be some issues with Outbound. =20 Requirement-8: The mechanism MUST work without requiring the PBX to publish reachability information through the DNS. =20 Cullen Jennings: who is the PBX in this case? This doesn=92t sound like a real requirement=2C it limits solutions.= =20 =20 Bernard Aboba: I agree with Cullen.=20 Dynamic DNS is widely available and inexpensive. There are some cases (suc= h as putting an FQDN in a Contact URI) that require DNS resource records to be put in place. =20 =20 Hadriel Kaplan: the real issue here is that the PBX may not have a domain name. =20 Bernard Aboba: That=92s a different requirement.=20 =20 Requirement-9: The mechanism MUST work over any existing transport specified for SIP=2C including UDP =20 Someone: SIPconnect 1.1 requires TCP.=20 =20 Spencer Dawkins: Just to clarify=2C SIPconnect 1.1 does allow UDP. It just recommends TCP. =20 Keith Drage: Why is SIPconnect 1.1 content and timelines driving the solution? =20 Requirement-10: Do we need any requirement concerning ability to check the two sides have matching set of AORs? =20 Brian Lindsay: No=2C this should be out-of-scope. =20 Adam Roach: Do we have a requirement that provisioning mismatches can detected? =20 Spencer Dawkins: Question is that should this be in-scope for MARTINI=2C or can we use some other SIP mechanism like reg-event? =20 Brian Lindsay: Maybe there are non-SIP mechanisms that would be better suited to provide this capability. =20 Keith Drage: This is nice to have=2C but not necessarily a must-have MARTINI requirement.=20 =20 Adam Roach: There are really two separate problems here... a)=20 how do the SSP and PBX know they have the same set of enterprise AORs?=20 b)=20 how do intermediaries know which AORs are valid for the enterprise (say an SP network edge proxy needs to assert iden= tity on incoming requests).=20 These two could be solved by the same solution=2C but they are not the same problem.=20 =20 Question: are there any requirements missing? =20 Richard Shockey: Should there be a requirement for Proxy-Require? i.e. do we require intermediate proxies to understand this extension? =20 Someone: Pure proxies are somewhat involved in registration transactions=2C so we may need to have them understand this= .=20 =20 Keith Drage: Proxies in the path should not be impacted by the mechanism. =20 Hadriel Kaplan: Can=92t we decide this later? Once we=92ve settled on the mechanism=2C do the right thing so as not to br= eak things. =20 =20 Desirables: all accepted except for the following=85 =20 Desirable-2. The mechanism SHOULD scale to PBXs of several thousand AORs. =20 General comment: there is some ambiguity about how large a MARTINI-compliant IP-PBX should scale.=20 =20 Desirable-4. The mechanism SHOULD allow handling of inbound requests and outbound reques= ts between SSP and PBX to be as common as possible as with a normal peering arrangement (RFC 3263 based)=2C as far as the PBX is concerned.=20 =20 General comment: this last =93desirable=94 is questionable. =20 3.=20 Adam Roach=92s Presentation Slide-2: Contact Routing vs. Domain Routing Paul Kyzivat: if Jonathan=92s loose-routing proposal had been accepted=2C we wouldn=92t be worried about overloading RE= GISTER with domain routing now. =20 Hadriel Kaplan/Adam Roach/Paul Kyzivat: Does the reason for rejecting Jonathan=92s loose-routing proposal apply to this MARTINI =93shaken-implicit=94 draft proposal as well?=20 =20 Hadriel Kaplan: no=2C Jonathan=92s loose route proposal was rejected in favor of the History-Info solution.=20 =20 Paul Kyzivat: if we=92re going to resurrect the loose-route solution in MARTINI=2C then we should consider those issues= raised against Jonathan=92s L-R proposal again now. =20 Someone: If scope is limited to E.164 numbers then the usual case is that an incoming request to SSP will contain= the SSP domain. Does this avoid some of the concerns described here?=20 =20 Hadriel Kaplan: there is still the case where a remote user uses initiates a call to the enterprise user using the From: header or Refer-To: header which contains enterprise domain. =20 Slide-3: Domain Responsibility =20 Paul Kyzivat: The term =93responsible for AOR=94 is not well defined. =20 Adam Roach: Keith Drage is saying that this responsibility can span across networks. Anything you can let the PBX do=2C= you should be able to let the SSP do as well.=20 =20 Hadriel Kaplan: this is no different than email: sometimes your email provider is your service provider.=20 =20 Paul Kyzivat: this could get complicated if you have multi service providers and one domain name.=20 =20 Hadriel Kaplan/Paul Kyzivat: agree that maybe this =93multi service provider one domain name=94 case probably doesn=92t m= ake sense. =20 Slide-4: AORs: To Enumerate or Not to Enumerate =20 Someone: Does reg-event have a way to represent all the registered AORs? For example=2C reg-event has no way to say =93all = AORs in this domain=94. The syntax only supports enumerating each AOR. Keith Drage thought this case was either supported=2C or possible to add.Bottom line: i= f we choose reg-event as a solution=2C then we have to include the updates requi= red to reg-event to make it work.=20 =20 Brian Lindsay: do intermediaries really need to know the list of AORs? P-CSCFs need to know: but they have a way. I= f all intermediaries are on the SSP side=2C then whatever mechanism is used d= oesn=92t appear on the interface and is therefore out-of-scope w.r.t. MARTINI. =20 =20 Keith Drage: agrees. =20 =20 John Elwell: The concept that the P-CSCF knows the list of AORs assigned to the IP-PBX=2C and uses this information = to assert the identity of the calling enterprise user is flawed anyway=3B e.g.= =2C consider the case where a call from a user outside the enterprise arrives at the IP-= PBX via a =93tie-line=94 trunk?=20 =20 Slide-5: Multiple AORs : Implicit or Explicit? =20 =20 Someone: The issue around having the SIP-PBX sending the regular-expression up to the SS= P=2C -- isn=92t it too complex to expect to work? i.e. it=92s sufficiently compl= ex that there=92s a good chance the PBX vendor will not implement it well. =20 Hadriel Kaplan: point of there would only be one John.Elwell@sp.com =20 Slide-6: Contacts: To Map or Not To Map? =20 Slide-7: REGISTER Applied to Multiple Humans No comments recorded. =20 Slide-8: Transport: Is UDP a requirement? This topic already covered during review of John Elwell=92s requirement list. =20 Cullen Jennings: once we figure out the solution: thinks UDP won=92t be an issue.=20 =20 4.=20 Keith Drage=92s Presentation Slide-3: Relationship of identities Someone: What do the different boxes represent?=20 =20 Keith Drage: A Private User Identity is specific to your phone/CPE=2C while a Public User Identity your AOR.=20 =20 Slide-5: Business trunking (release 8) Cullen Jennings: Is it true=2C as some people have asserted=2C that there is a violation of SIP RFCs (e.g.=2C wildcard Pu= blic User Identity breaks URI syntax)?=20 =20 Keith Drage: there may be an issue=2C but haven=92t looked. =20 5.=20 Dean Willis=92s Presentation This presentation problem identifies a problem with connection re-use where there are multiple domains using a sin= gle route.=20 =20 Slide-3: Alternate Topology Paul Kyzivat: is this really a problem? Couldn=92t this be accomplished simply by establishing two flows? =20 Hadriel Kaplan: wasn=92t the problem with connection reuse that the SSP had no way to authenticate the PBX (connection-reuse was actually for proxy-to-proxy)? But we don=92t have tha= t problem because the SSP can authenticate the PBX using SIP Digest.=20 =20 Cullen Jennings: what is the shared secret? Is it something for a single user=2C or for a whole domain? What exactly is= authenticated by that shared-secret?=20 =20 Hadriel Kaplan: it would authenticate all the PBX AORs.=20 =20 Cullen Jennings: traditionally it would only authenticating the AOR being registered.=20 =20 Hadriel Kaplan: if the SP network receives a request addressed to the target enterprise domain=2C then the SP network = simply loose-routes the request and it should arrive at the correct enterprise use= r. If the SP network receives a request addressed to the SAP domain but destin= ed for an enterprise user=2C then the SP network must make a decision as to wh= ich enterprise domain to retarget to.=20 =20 Paul Kyzivat: this could all be driven by provisioning=2C where if one thing happens then provisioning says this othe= r thing happens=2C etc. So on the one hand there should be no problem=2C but = on the other hand=2C it=92s not clear. =20 Dean Willis: we just need to satisfy ourselves that the connection-reuse issues identified in section 9.3 of the re-use draft don=92t apply to this MARTINI case as well. =20 6.=20 Hums Bernard Aboba: should initial focus be to solve the E.164 problem first? I.e.=2C agree to deliver on a milestone to l= imit to E.164? Should we describe the HUM as restricting to tel URIs=2C which would also support private URIs.=20 =20 Brian Lindsay: should we limit scope to phone numbers?=20 =20 Adam Roach: no=2C since telephone numbers have are digit strings. For this to work the user part has to be a unique k= ey.=20 =20 Paul Kyzivat: one of the contexts for local tel URIs is domain name: and so if we allow local Tel URIs we still have th= e domain issue.=20 =20 Do we do a point solution for E.164=2C and then tackle the more general problem? =20 Paul Kyzivat: there are some common non-E.164 numbers like 911: would these be precluded if we limited the scop= e to =93E.164-only=94?=20 =20 Cullen Jennings: No=2C it wouldn=92t. The E.164-limitration applies to enterprise AORs=2C and =93911=94 would never b= e assigned to an IP-PBX.=20 =20 Cullen Jennings: should the hum be reworded to say that the PBX should only register E.164 public user IDs? Reason bein= g: call xfer=2C which requires support of some non-E.164 GRUU-like URI=2C still nee= ds to work. =20 Bernard Aboba: what are next-steps=2C to be completed by the next meeting?=20 =20 Action Item to Dean Willis & Adam Roach to bring the E.164 scope issue to the list. = --_56b4e0f3-aca1-4f69-a629-0c6ad54cc811_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

<= b> =3B=

<= b>MARTINI WG Virtual Interim Meeting #2

 =3B

Date: Tuesday Jan 26th=2C 2009
Time: 10:00 AM: 12:30 PM PST

Minute takers: =3B David Hancock=2C John Elwell

 =3B

Attendees:

 =3B

Adam Roach Roach
Adam Roach Uzelac
Alan John Elwellston
Andy Hutton
Bernard Aboba Aboba
Brian Lindsay Lindsay
Rich Shockey
Christain Schmidt
Cullen Jennings Jennings
Dan Romascanu
Dean Willis Willis
Doug Sauders
Ernst Horvath
Hadriel Kaplan Kaplan
James Swan
John Elwell Elwell
Keith Drage Drage
Krisztian Kiss
Mary Barnes
Paul Kyzivat Kyzivat
David Hancock

Spencer Dawkins Dawkins

 =3B

 =3B

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

 =3B

1. =3B Agenda bashing

No comments.

 =3B

2. =3B John Elwells Requirement List

 =3B

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

 =3B

Adam Roach: the term =93responsible for domain=94 is mentioned in RFC3261=2C and in general it doesn=92t allow a no= n-responsible proxy to retarget.

 =3B

Paul Kyzivat: Agreed. But if the SSP network receives a request addressed to the SSP=92s domain and identifying = an enterprise user=2C and the PBX is not reachable=2C the SSP should be allowe= d to retarget the request to voice mail. But if incoming request is addressed to= the enterprise domain then it shouldn=92t be allowed to retarget.

 =3B

Keith Drage: the SSP has a virtual PBX that is (or represents) the physical PBX. As such it (the SSP) is responsible fo= r the enterprise domain.

 =3B

Adam Roach: The aspect of domain responsibility and how it might affect the MARTINI solutions is something n= ew that hasn=92t been fully considered yet.

 =3B

Paul Kyzivat: From a SIP perspective it makes a difference whether we=92re considering only E.164 numbers=2C or not= .

 =3B

Richard Shockey: emphasizes that we=92re really only concerned about telephone numbers.

 =3B

Paul Kyzivat: Things get simplified greatly if we agree this is only about E.164 numbers. But if we make that simplification=2C then the RFC better explicitly state that the scope is li= mited to that.

 =3B

Richard Shockey agrees.

 =3B

Dean Willis: this scope issue affects the rest of our discussion. So this has got to be question number 1.

 =3B

Cullen Jennings: we have to solve the phone number problem first=2C and if we do that it is enough for the consumers of= this specification work.

 =3B

Spencer Dawkins: we need to make this decision on the list=2C but could we decide to limit it to E.164 numbers fo= r this call (at least)?

 =3B

Adam Roach: OK with limiting to E.164 numbers=2C but you have to be able to tell it is an E.164 number by some st= andard mechanism.

 =3B

Spencer Dawkins and Richard Shockey agree.<= /o:p>

 =3B

Dean Willis: One way to indicate that URI contains an E.164 number is to use Tel URIs.

 =3B

Paul Kyzivat agrees. Tel URIs=2C solve problems with From: &=3B To: headers as well.

 =3B

Richard Shockey: what about SIP URI with =93user= =3Dphone=94?

 =3B

Keith Drage: Disagrees with limiting scope to E.164 number=2C since it excludes private numbers that may not be E.164 numbers.

 =3B

Paul Kyzivat: the problem with using a SIP URI with =93user=3Dphone=94 is that if you don=92t own the URI domain then = you can=92t look at the user part.

 =3B

Dean Willis: RFC3261 doesn=92t allow registration of TEL URI. But since we=92re changing REGISTER: we can change= that too.

 =3B

Richard Shockey: Let=92s narrow the scope to something solvable. =3B However=2C using TEL URIs is neither necessary nor helpful. =3B = Service providers won=92t deploy that.

 =3B

Hadriel Kaplan: if the SSP receives an E.164 at SSP domain then there=92s no problem. It=92s when the request arri= ves with the PBX domain that there is an issue.

 =3B

Adam Roach: Richard Shockey (SIPconnect1.1) has a tight time requirement to solve specific problem=2C namely to standar= dize procedures for support of E.164 numbers. Others in the group have a less ti= me critical and more general requirement to standardize procedures for any typ= e of AOR.

 =3B

Requirements 2=2C3=2C4: no comments.

 =3B

Requirement-5: The mechanism MUST observe SIP backwards compatibility principles.

 =3B

Keith Drage: This sounds like a good requirement=2C but unfortunately these principles aren=92t written down any= where.

 =3B

Requirement-6: 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)= =2C where those intermediate "proxies" need to be on the path of inbound requests to the PBX.

 =3B

Someone: If we keep this requirement we need to nail down the term =93proxies=94.

 =3B

Keith Drage: what is the use-case that requires proxies in enterprise?

 =3B

Paul Kyzivat: There are cases where an enterprise might want to put an SBC between the PBX and the SP network.

 =3B

Dean Willis: there could be things (like proxies) between PBX and SP network=2C and things between enterprise UA and= the PBX.

 =3B

Many responded: the 2nd case is defin= itely out-of-scope.

 =3B

Keith Drage: the PBX registration with the PS network is independent and separate from the enterprise users registerin= g with the PBX.

 =3B

Dean Willis: there may be some issues with Outbound.

 =3B

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

 =3B

Cullen Jennings: who is the PBX in this case? This doesn=92t sound like a real requirement=2C it limits solutions. =

 =3B

Bernard Aboba: =3B I= agree with Cullen. =3B Dynamic DNS is widely available and inexpensive.&nb= sp=3B There are some cases (such as putting an FQDN in a Contact URI) that require DNS resource records to be put in place. =3B

 =3B

Hadriel Kaplan: the real issue here is that the PBX may not have a domain name.

 =3B

Bernard Aboba: =3B T= hat=92s a different requirement.

 =3B

Requirement-9: The mechanism MUST work over any existing transport specified for SIP=2C including UDP

 =3B

Someone: =3B SIPconn= ect 1.1 requires TCP.

 =3B

Spencer Dawkins: Just to clarify=2C SIPconnect 1.1 does allow UDP. It just recommends TCP.

 =3B

Keith Drage: Why is SIPconnect 1.1 content and timelines driving the solution?

 =3B

Requirement-10: Do we need any requirement concerning ability

to check the two sides have matching set of AORs?

 =3B

Brian Lindsay: No=2C this should be out-of-scope= .

 =3B

Adam Roach: Do we have a requirement that provisioning mismatches can detected?

 =3B

Spencer Dawkins: Question is that should this be in-scope for MARTINI=2C or can we use some other SIP mechanism like reg-event?

 =3B

Brian Lindsay: Maybe there are non-SIP mechanisms that would be better suited to provide this capability.

 =3B

Keith Drage: This is nice to have=2C but not necessarily a must-have MARTINI requirement.

 =3B

Adam Roach: There are really two separate problems here...

a) =3B how do the SSP and PBX know they hav= e the same set of enterprise AORs?

b) =3B how do intermediaries know which AOR= s are valid for the enterprise (say an SP network edge proxy needs to assert iden= tity on incoming requests).

These two could be solved by the same solution=2C but they are not the same problem.

 =3B

Question: are there any requirements missing?

 =3B

Richard Shockey: Should there be a requirement for Proxy-Require? i.e. do we require intermediate proxies to understand this extension?

 =3B

Someone: Pure proxies are somewhat involved in registration transactions=2C so we may need to have them understand this= .

 =3B

Keith Drage: Proxies in the path should not be impacted by the mechanism.

 =3B

Hadriel Kaplan: Can=92t we decide this later? Once we=92ve settled on the mechanism=2C do the right thing so as not to br= eak things.

 =3B

 =3B

Desirables: all accepted except for the following=85

 =3B

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

 =3B

General comment: there is some ambiguity about how large a MARTINI-compliant IP-PBX should scale. =

 =3B

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

 =3B

General comment: this last =93desirable=94 is questionable.

 =3B

3. =3B Adam Roach=92s Presentation

Slide-2: Contact Routing vs. Domain Routing

Paul Kyzivat: if Jonathan=92s loose-routing proposal had been accepted=2C we wouldn=92t be worried about overloading RE= GISTER with domain routing now.

 =3B

Hadriel Kaplan/Adam Roach/Paul Kyzivat: Does the reason for rejecting Jonathan=92s loose-routing proposal apply to this MARTINI =93shaken-implicit=94 draft proposal as well?

 =3B

Hadriel Kaplan: no=2C Jonathan=92s loose route p= roposal was rejected in favor of the History-Info solution.

 =3B

Paul Kyzivat: if we=92re going to resurrect the loose-route solution in MARTINI=2C then we should consider those issues= raised against Jonathan=92s L-R proposal again now.

 =3B

Someone: If scope is limited to E.164 numbers then the usual case is that an incoming request to SSP will contain= the SSP domain. Does this avoid some of the concerns described here?

 =3B

Hadriel Kaplan: there is still the case where a remote user uses initiates a call to the enterprise user using the From: header or Refer-To: header which contains enterprise domain.

 =3B

Slide-3: Domain Responsibility

 =3B

Paul Kyzivat: The term =93responsible for AOR=94 is not well defined.

 =3B

Adam Roach: Keith Drage is saying that this responsibility can span across networks. Anything you can let the PBX do=2C= you should be able to let the SSP do as well.

 =3B

Hadriel Kaplan: this is no different than email: sometimes your email provider is your service provider. <= /span>

 =3B

Paul Kyzivat: this could get complicated if you have multi service providers and one domain name.

 =3B

Hadriel Kaplan/Paul Kyzivat: agree that maybe this =93multi service provider one domain name=94 case probably doesn=92t m= ake sense.

 =3B

Slide-4: AORs: To Enumerate or Not to Enumerate

 =3B

Someone: Does reg-event have a way to represent all the registered AORs? For example=2C reg-event has no way to say =93all = AORs in this domain=94. The syntax only supports enumerating each AOR. Keith Drage thought this case was either supported=2C or possible to add.Bottom line: i= f we choose reg-event as a solution=2C then we have to include the updates requi= red to reg-event to make it work.

 =3B

Brian Lindsay: do intermediaries really need to know the list of AORs? P-CSCFs need to know: but they have a way. I= f all intermediaries are on the SSP side=2C then whatever mechanism is used d= oesn=92t appear on the interface and is therefore out-of-scope w.r.t. MARTINI.  =3B

 =3B

Keith Drage: agrees.  =3B

 =3B

John Elwell: The concept that the P-CSCF knows the list of AORs assigned to the IP-PBX=2C and uses this information = to assert the identity of the calling enterprise user is flawed anyway=3B e.g.= =2C consider the case where a call from a user outside the enterprise arrives at the IP-= PBX via a =93tie-line=94 trunk?

 =3B

Slide-5: Multiple AORs : Implicit or Explicit?

 =3B

 =3B

Someone: The issue around having the SIP-PBX sending the regular-expression up to the SS= P=2C -- isn=92t it too complex to expect to work? i.e. it=92s sufficiently compl= ex that there=92s a good chance the PBX vendor will not implement it well.

 =3B

Hadriel Kaplan: point of there would only be one John.Elwell@sp.com

 =3B

Slide-6: Contacts: To Map or Not To Map?

 =3B

Slide-7: REGISTER Applied to Multiple Humans

No comments recorded.

 =3B

Slide-8: Transport: Is UDP a requirement?

This topic already covered during review of John Elwell=92s requirement list.

 =3B

Cullen Jennings: once we figure out the solution: thinks UDP won=92t be an issue.

 =3B

4. =3B Keith Drage=92s Presentation

Slide-3: Relationship of identities

Someone: What do the different boxes represent?

 =3B

Keith Drage: A Private User Identity is specific to your phone/CPE=2C while a Public User Identity your AOR. <= /o:p>

 =3B

Slide-5: Business trunking (release 8)

Cullen Jennings: Is it true=2C as some people have asserted=2C that there is a violation of SIP RFCs (e.g.=2C wildcard Pu= blic User Identity breaks URI syntax)?

 =3B

Keith Drage: there may be an issue=2C but haven=92t looked.

 =3B

5. =3B Dean Willis=92s Presentation

This presentation problem identifies a problem with connection re-use where there are multiple domains using a sin= gle route.

 =3B

Slide-3: Alternate Topology

Paul Kyzivat: is this really a problem? Couldn=92t this be accomplished simply by establishing two flows?

 =3B

Hadriel Kaplan: wasn=92t the problem with connection reuse that the SSP had no way to authenticate the PBX (connection-reuse was actually for proxy-to-proxy)? But we don=92t have tha= t problem because the SSP can authenticate the PBX using SIP Digest.

 =3B

Cullen Jennings: what is the shared secret? Is it something for a single user=2C or for a whole domain? What exactly is= authenticated by that shared-secret?

 =3B

Hadriel Kaplan: it would authenticate all the PBX AORs.

 =3B

Cullen Jennings: traditionally it would only authenticating the AOR being registered.

 =3B

Hadriel Kaplan: if the SP network receives a request addressed to the target enterprise domain=2C then the SP network = simply loose-routes the request and it should arrive at the correct enterprise use= r. If the SP network receives a request addressed to the SAP domain but destin= ed for an enterprise user=2C then the SP network must make a decision as to wh= ich enterprise domain to retarget to.

 =3B

Paul Kyzivat: this could all be driven by provisioning=2C where if one thing happens then provisioning says this othe= r thing happens=2C etc. So on the one hand there should be no problem=2C but = on the other hand=2C it=92s not clear.

 =3B

Dean Willis: we just need to satisfy ourselves that the connection-reuse issues identified in section 9.3 of the re-use draft don=92t apply to this MARTINI case as well.<= /p>

 =3B

6. =3B Hums

Bernard Aboba: should initial focus be to solve the E.164 problem first? I.e.=2C agree to deliver on a milestone to l= imit to E.164? =3B Should we describe the HUM as restricting to tel URIs=2C which would also support private URIs.

 =3B

Brian Lindsay: should we limit scope to phone numbers?

 =3B

Adam Roach: no=2C since telephone numbers have are digit strings. For this to work the user part has to be a unique k= ey.

 =3B

Paul Kyzivat: one of the contexts for local tel URIs is domain name: and so if we allow local Tel URIs we still have th= e domain issue.

 =3B

Do we do a point solution for E.164=2C and then tackle the more general problem?

 =3B

Paul Kyzivat: there are some common non-E.164 numbers like 911: would these be precluded if we limited the scop= e to =93E.164-only=94?

 =3B

Cullen Jennings: No=2C it wouldn=92t. The E.164-limitration applies to enterprise AORs=2C and =93911=94 would never b= e assigned to an IP-PBX.

 =3B

Cullen Jennings: should the hum be reworded to say that the PBX should only register E.164 public user IDs? Reason bein= g: call xfer=2C which requires support of some non-E.164 GRUU-like URI=2C still nee= ds to work.

 =3B

Bernard Aboba: what are next-steps=2C to be completed by the next meeting?

 =3B

Action Item to Dean Willis &=3B Adam Roach to bring the E.164 scope issue to the list.

= --_56b4e0f3-aca1-4f69-a629-0c6ad54cc811_-- From adam@nostrum.com Sat Feb 6 19:46: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 6BD503A6768 for ; Sat, 6 Feb 2010 19:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 0oZ8QmakjqbJ for ; Sat, 6 Feb 2010 19:46:48 -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 05B923A6FF7 for ; Sat, 6 Feb 2010 19:46:46 -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 o173lecE050229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2010 21:47:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6E37DB.7080604@nostrum.com> Date: Sat, 06 Feb 2010 21:47: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: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090606020408000101030402" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Draft Minutes from 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: Sun, 07 Feb 2010 03:46:49 -0000 This is a multi-part message in MIME format. --------------090606020408000101030402 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2/6/10 19:51, Feb 6, Bernard Aboba wrote: > > * * > > *MARTINI WG Virtual Interim Meeting #2*** > > Date: Tuesday Jan 26^th , 2009 > Time: 10:00 AM: 12:30 PM PST > > Minute takers: David Hancock, John Elwell > > *_Attendees_*: > > Adam Roach Roach > Adam Roach Uzelac > Alan John Elwellston > Andy Hutton > Bernard Aboba Aboba > Brian Lindsay Lindsay > Rich Shockey > Christain Schmidt > Cullen Jennings Jennings > Dan Romascanu > Dean Willis Willis > Doug Sauders > Ernst Horvath > Hadriel Kaplan Kaplan > James Swan > John Elwell Elwell > Keith Drage Drage > Krisztian Kiss > Mary Barnes > Paul Kyzivat Kyzivat > David Hancock > > Spencer Dawkins Dawkins > I'm think we had some kind of search-and-replace-splosion in the roster. "Adam Roach Uzelac" and "Alan John Elwellston" are instant classics. /a --------------090606020408000101030402 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 2/6/10 19:51, Feb 6, Bernard Aboba wrote:

 

MARTINI WG Virtual Interim Meeting #2

 

Date: Tuesday Jan 26th, 2009
Time: 10:00 AM: 12:30 PM PST

Minute takers:  David Hancock, John Elwell

 

Attendees:

 

Adam Roach Roach
Adam Roach Uzelac
Alan John Elwellston
Andy Hutton
Bernard Aboba Aboba
Brian Lindsay Lindsay
Rich Shockey
Christain Schmidt
Cullen Jennings Jennings
Dan Romascanu
Dean Willis Willis
Doug Sauders
Ernst Horvath
Hadriel Kaplan Kaplan
James Swan
John Elwell Elwell
Keith Drage Drage
Krisztian Kiss
Mary Barnes
Paul Kyzivat Kyzivat
David Hancock

Spencer Dawkins Dawkins



I'm think we had some kind of search-and-replace-splosion in the roster.

"Adam Roach Uzelac" and "Alan John Elwellston" are instant classics.

/a
--------------090606020408000101030402-- From bernard_aboba@hotmail.com Sat Feb 6 21:01: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 5EAB23A69D6 for ; Sat, 6 Feb 2010 21:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.516, 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 uhokdZRhkVpD for ; Sat, 6 Feb 2010 21:01:18 -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 2BE8A3A68AF for ; Sat, 6 Feb 2010 21:01:18 -0800 (PST) Received: from BLU137-W31 ([65.55.111.73]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Feb 2010 21:02:14 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_9f731f24-dba7-47a0-9644-a29a7348fded_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Sat, 6 Feb 2010 21:02:14 -0800 Importance: Normal In-Reply-To: <4B6E37DB.7080604@nostrum.com> References: , <4B6E37DB.7080604@nostrum.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2010 05:02:14.0875 (UTC) FILETIME=[B6F112B0:01CAA7B2] Cc: martini@ietf.org Subject: Re: [martini] Draft Minutes from 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: Sun, 07 Feb 2010 05:01:19 -0000 --_9f731f24-dba7-47a0-9644-a29a7348fded_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oops (blushing). Revised version is here: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-II/ = --_9f731f24-dba7-47a0-9644-a29a7348fded_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oops (blushing). =3B Revised version is here:
http://www.drizzle.com= /~aboba/MARTINI/Jan-Interim-II/
= --_9f731f24-dba7-47a0-9644-a29a7348fded_-- From john.elwell@siemens-enterprise.com Mon Feb 8 03:39: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 B70D63A6D4A for ; Mon, 8 Feb 2010 03:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12idvb8KMzeW for ; Mon, 8 Feb 2010 03:39:18 -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 C95A23A6D48 for ; Mon, 8 Feb 2010 03:39:17 -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-810080 for martini@ietf.org; Mon, 8 Feb 2010 12:40:19 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id EEC0623F028E for ; Mon, 8 Feb 2010 12:40:18 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 8 Feb 2010 12:40:18 +0100 From: "Elwell, John" To: "martini@ietf.org" Date: Mon, 8 Feb 2010 12:40:16 +0100 Thread-Topic: draft-elwell-martini-reqs-01 posted Thread-Index: Acqos3wyX5nL+DG6T3+NR867VZntGg== 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] draft-elwell-martini-reqs-01 posted X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 08 Feb 2010 11:39:18 -0000 The 01 version just adds a couple of new requirements (REQ/16/REQ17) arisin= g from discussion last week. http://www.ietf.org/internet-drafts/draft-elwell-martini-reqs-01.txt John= From spencer@wonderhamster.org Mon Feb 8 08:50: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 AA3473A7404 for ; Mon, 8 Feb 2010 08:50:10 -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.014, 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 t0dFNH+3X-oj for ; Mon, 8 Feb 2010 08:50:08 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 984E93A67F6 for ; Mon, 8 Feb 2010 08:50:08 -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 0MCtWV-1NWajI0ddL-009IOf; Mon, 08 Feb 2010 11:51:10 -0500 Message-ID: <5D100A6D3EAA4844949B964F0A0359FB@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , References: Date: Mon, 8 Feb 2010 10:51:01 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09A5_01CAA8AC.9AB4EC70" 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: V01U2FsdGVkX19LumKUqnSyTk5Td0DEndGdv6wMIutDP7pnhtP yCIoiCnu2fqmMGpW8imjuM7JZ/gbm6a+oWmwgslugbBtIL5BlC kBcSXaEiWPT8ZtL2LfKlOdXtgSS1Cnf87z2NIDOtY8= Subject: Re: [martini] Potential alternative Virtual Interim IV date: March 1, 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, 08 Feb 2010 16:50:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_09A5_01CAA8AC.9AB4EC70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That actually doesn't work for the 3GPP weenies, either - the workshop = is scheduled for March 1-2, and then people will be traveling.=20 I liked your question about the next week more... Sorry to be difficult! on the bright side, I'm somewhat alive after = spending the weekend with 120 youth and adults in a pine forest (to = which I am allergic), so I should be more help than I was last week! Spencer ----- Original Message -----=20 From: Bernard Aboba=20 To: martini@ietf.org=20 Sent: Friday, February 05, 2010 10:39 PM Subject: [martini] Potential alternative Virtual Interim IV date: = March 1,2010 Due to the potential conflict with the IETF/3GPP IPv6 transition = meeting, we are considering moving the date of MARTINI Virtual Interim = IV to Monday, March 1, 2010 from 11 AM - 1 PM Pacific Time. To allow us = to understand all the ramifications/issues with this potential date = (we'll make a final decision at close of business Monday), please fill = out the Doodle poll if you haven't already done so: http://www.doodle.com/gfd9ramt42v5cxbd =20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_09A5_01CAA8AC.9AB4EC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That actually doesn't work for the 3GPP weenies, = either - the=20 workshop is scheduled for March 1-2, and then people will be traveling.=20
 
I liked your question about the next week = more...
 
Sorry to be difficult! on the bright side, I'm = somewhat alive=20 after spending the weekend with 120 youth and adults in a pine forest = (to which=20 I am allergic), so I should be more help than I was last = week!
 
Spencer
 
----- Original Message -----
From:=20 Bernard Aboba
Sent: Friday, February 05, 2010 = 10:39=20 PM
Subject: [martini] Potential = alternative=20 Virtual Interim IV date: March 1,2010

Due to the potential conflict with the IETF/3GPP = IPv6=20 transition meeting, we are considering moving the date of MARTINI = Virtual=20 Interim IV to Monday, March 1, 2010 from 11 AM =96 1 PM Pacific = Time.  To=20 allow us to understand all the ramifications/issues with this = potential date=20 (we=92ll make a final decision at close of business Monday), please = fill out the=20 Doodle poll if you haven=92t already done so:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_09A5_01CAA8AC.9AB4EC70-- From bernard_aboba@hotmail.com Mon Feb 8 09:59: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 172DE3A71DD for ; Mon, 8 Feb 2010 09:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.554, 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 ku+IzyDX-mp6 for ; Mon, 8 Feb 2010 09:59:52 -0800 (PST) Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by core3.amsl.com (Postfix) with ESMTP id 347AE28C131 for ; Mon, 8 Feb 2010 09:59:52 -0800 (PST) Received: from BLU137-DS7 ([65.55.116.72]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 10:00:54 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Spencer Dawkins'" , References: <5D100A6D3EAA4844949B964F0A0359FB@china.huawei.com> In-Reply-To: <5D100A6D3EAA4844949B964F0A0359FB@china.huawei.com> Date: Mon, 8 Feb 2010 10:00:52 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0102_01CAA8A5.998B64C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqo3ut1H2xK6aiwSZOGxlks/1vRvwACap0w Content-Language: en-us X-OriginalArrivalTime: 08 Feb 2010 18:00:54.0846 (UTC) FILETIME=[A8A0A5E0:01CAA8E8] Subject: Re: [martini] Potential alternative Virtual Interim IV date: March 1, 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, 08 Feb 2010 17:59:57 -0000 ------=_NextPart_000_0102_01CAA8A5.998B64C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for the info. We'll see what is available the next week. From: Spencer Dawkins [mailto:spencer@wonderhamster.org] Sent: Monday, February 08, 2010 8:51 AM To: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Potential alternative Virtual Interim IV date: March 1,2010 That actually doesn't work for the 3GPP weenies, either - the workshop is scheduled for March 1-2, and then people will be traveling. I liked your question about the next week more... Sorry to be difficult! on the bright side, I'm somewhat alive after spending the weekend with 120 youth and adults in a pine forest (to which I am allergic), so I should be more help than I was last week! Spencer ----- Original Message ----- From: Bernard Aboba To: martini@ietf.org Sent: Friday, February 05, 2010 10:39 PM Subject: [martini] Potential alternative Virtual Interim IV date: March 1,2010 Due to the potential conflict with the IETF/3GPP IPv6 transition meeting, we are considering moving the date of MARTINI Virtual Interim IV to Monday, March 1, 2010 from 11 AM - 1 PM Pacific Time. To allow us to understand all the ramifications/issues with this potential date (we'll make a final decision at close of business Monday), please fill out the Doodle poll if you haven't already done so: http://www.doodle.com/gfd9ramt42v5cxbd _____ _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_0102_01CAA8A5.998B64C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the = info.  We’ll see what is available the next week.

 

From:= Spencer = Dawkins [mailto:spencer@wonderhamster.org]
Sent: Monday, February 08, 2010 8:51 AM
To: Bernard Aboba; martini@ietf.org
Subject: Re: [martini] Potential alternative Virtual Interim IV = date: March 1,2010

 

That actually doesn't work for the 3GPP weenies, either - the workshop is = scheduled for March 1-2, and then people will be traveling.

 

I liked your question about the next week more...

 

Sorry to be difficult! on the bright side, I'm somewhat alive after spending = the weekend with 120 youth and adults in a pine forest (to which I am = allergic), so I should be more help than I was last week!

 

Spencer

 

----- Original Message -----

From: Bernard Aboba =

Sent:<= /b> Friday, = February 05, 2010 10:39 PM

Subject: [martini] = Potential alternative Virtual Interim IV date: March 1,2010

 

Due to the potential conflict with the IETF/3GPP = IPv6 transition meeting, we are considering moving the date of MARTINI = Virtual Interim IV to Monday, March 1, 2010 from 11 AM – 1 PM Pacific = Time.  To allow us to understand all the ramifications/issues with this potential = date (we’ll make a final decision at close of business Monday), please = fill out the Doodle poll if you haven’t already done so:

http://www.doodle.com/gfd= 9ramt42v5cxbd

 

 

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

------=_NextPart_000_0102_01CAA8A5.998B64C0-- From bernard_aboba@hotmail.com Mon Feb 8 11:09: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 AEE603A7247 for ; Mon, 8 Feb 2010 11:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_50=0.001, MISSING_MIMEOLE=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 QTp6wjvgAMRJ for ; Mon, 8 Feb 2010 11:09:20 -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 0305B3A71A9 for ; Mon, 8 Feb 2010 11:09:19 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 11:10:23 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 8 Feb 2010 11:10:21 -0800 MIME-Version: 1.0 Content-Type: text/calendar; method=CANCEL; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acql0pu2ZlMdDPubTEO2m66tPhtQXwDH8CCg Content-Language: en-us Importance: High X-OriginalArrivalTime: 08 Feb 2010 19:10:23.0240 (UTC) FILETIME=[5D2F1880:01CAA8F2] Subject: [martini] Canceled: MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 08 Feb 2010 19:09:20 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100208T191021Z DESCRIPTION:When: Monday\, March 01\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pac ific Time (US & Canada).\nWhere: Cyberspace\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\ n\nCancelled due to conflict with 3GPP/IETF IPv6 Transition meeting. \n DTEND:20100301T210000Z DTSTAMP:20100208T191021Z DTSTART:20100301T190000Z LAST-MODIFIED:20100208T191021Z LOCATION:Cyberspace ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:1 SEQUENCE:2 SUMMARY;LANGUAGE=en-us:Canceled: MARTINI Virtual Interim IV TRANSP:TRANSPARENT UID:040000008200E00074C5B7101A82E008000000009007938D8FA5CA01000000000000000 0100000001F815CB7E59A144492451C2E670E961A X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Monday\, March 01\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Ti me (US &\; Canada).

\n\n

Where: Cyberspace

\n\n

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

\n\n

< SPAN LANG="en-us">*~*~*~*~*~*~*~*~*~*\n\n

Cancelled due to conflict with 3GPP/IETF IPv6 Transition meeting. \;

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:FREE X-MICROSOFT-CDO-IMPORTANCE:2 X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:1 X-MS-OLK-APPTSEQTIME:20100206T060206Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 END:VEVENT END:VCALENDAR From bernard_aboba@hotmail.com Mon Feb 8 11:13: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 6FDBE3A71A9 for ; Mon, 8 Feb 2010 11:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=-0.372, 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 dDLuUKgaiQ37 for ; Mon, 8 Feb 2010 11:13:37 -0800 (PST) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by core3.amsl.com (Postfix) with ESMTP id 2152D3A6828 for ; Mon, 8 Feb 2010 11:13:37 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.72]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 11:14:40 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 8 Feb 2010 11:14:38 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011A_01CAA8AF.E76E5030" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqo8vVYFnkwR4FFSI2KaSHdERLJXw== Content-Language: en-us X-OriginalArrivalTime: 08 Feb 2010 19:14:40.0429 (UTC) FILETIME=[F67B05D0:01CAA8F2] Subject: [martini] New Doodle Poll for MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 08 Feb 2010 19:13:38 -0000 ------=_NextPart_000_011A_01CAA8AF.E76E5030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As Spencer noted, both of the dates with acceptable availability (March 1 & 2) appear to be in conflict with the IETF/3GPP IPv6 transition meeting. We therefore need to do another Doodle poll to find an acceptable date for MARTINI Virtual Interim IV. Please fill out the following poll for the week of March 8-12, 2010: http://www.doodle.com/hgndgicqw9ymesav ------=_NextPart_000_011A_01CAA8AF.E76E5030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As Spencer noted,  both of the dates with = acceptable availability (March 1 & 2) appear to be in conflict with the = IETF/3GPP IPv6 transition meeting.

 

We therefore need to do another Doodle poll to find = an acceptable date for MARTINI Virtual Interim IV.

 

Please fill out the following poll for the week of = March 8-12, 2010:

http://www.doodle.com/hgn= dgicqw9ymesav

 

 

------=_NextPart_000_011A_01CAA8AF.E76E5030-- From bernard_aboba@hotmail.com Mon Feb 8 11:53: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 3F82A3A7482 for ; Mon, 8 Feb 2010 11:53:08 -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.562, 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 LxLJA15EDFcF for ; Mon, 8 Feb 2010 11:53:04 -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 06D343A748A for ; Mon, 8 Feb 2010 11:51:19 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.73]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 11:52:23 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 8 Feb 2010 11:52:21 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0142_01CAA8B5.2C0C9710" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqo+Dn2rLFeq4sNRHGIs/Y1x0Mb9A== Content-Language: en-us X-OriginalArrivalTime: 08 Feb 2010 19:52:23.0446 (UTC) FILETIME=[3B580360:01CAA8F8] Subject: [martini] REMINDER: MARTINI Virtual Interim III -- February 9, 2010 (Tommorrow): 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: Mon, 08 Feb 2010 19:53:08 -0000 ------=_NextPart_000_0142_01CAA8B5.2C0C9710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim III February 9, 2010 8 AM - 10 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00238.html Agenda 8 AM - 8:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements & Usage Scenarios (30 minutes) 8:10 AM - 8:20 AM PT MARTINI Requirements Update, John Elwell (10 minutes) http://tools.ietf.org/html/draft-elwell-martini-reqs 8:20 AM - 8:30 AM PT Service Provider Perspective, Martin Dolly (10 minutes) 8:30 AM - 8:40 AM PT MARTINI Usage Scenarios, Adam Roach (10 minutes) Solution Updates (30 minutes) 8:40 AM - 9:00 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (20 minutes) http://tools.ietf.org/html/draft-roach-martini-gin 9:00 AM - 9:10 AM PT, MARTINI Shaken Update, Hadriel Kaplan (10 minutes) http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s Discussion (30 minutes) 9:10 AM - 9:40 AM PT Discussion: Participants (30 minutes) Wrap-up (20 minutes) 9:40 AM - 9:55 AM PT Hums: WG Chairs (15 minutes) 9:55 AM - 10:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_0142_01CAA8B5.2C0C9710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim III

February 9, 2010

8 AM – 10 AM Pacific Time

 

Conferencing Details:

 

Slide Presentations:  http://ww= w.drizzle.com/~aboba/MARTINI/Jan-Interim-III/

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

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

 

Agenda

 

8 AM - 8:10 AM PT:  = Preliminaries

     Conference = issues/debugging

     Agenda bash

 

Requirements & Usage Scenarios (30 = minutes)

 

8:10 AM - 8:20 AM  PT MARTINI Requirements = Update, John Elwell (10 minutes)

http://tool= s.ietf.org/html/draft-elwell-martini-reqs

8:20 AM – 8:30 AM  PT Service Provider Perspective, Martin Dolly (10 minutes)

8:30 AM – 8:40 AM  PT MARTINI Usage Scenarios, Adam Roach (10 = minutes)

 

Solution Updates (30 minutes)

 

8:40 AM – 9:00 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (20 minutes)

http://tools.= ietf.org/html/draft-roach-martini-gin

 

9:00 AM – 9:10 AM PT, MARTINI Shaken =  Update, Hadriel Kaplan (10 minutes)

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

 

Discussion (30 minutes)

 

9:10 AM – 9:40 AM  PT Discussion:  Participants (30 minutes)

 

Wrap-up (20 minutes)

 

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

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

 

------=_NextPart_000_0142_01CAA8B5.2C0C9710-- From bernard_aboba@hotmail.com Mon Feb 8 11:53: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 9F2D328C16A for ; Mon, 8 Feb 2010 11:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-0.653, 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 zqn4iM1g-TPm for ; Mon, 8 Feb 2010 11:53:10 -0800 (PST) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by core3.amsl.com (Postfix) with ESMTP id CCA0D28C191 for ; Mon, 8 Feb 2010 11:52:05 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.71]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 11:53:05 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 8 Feb 2010 11:53:02 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0147_01CAA8B5.44DE5990" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqo+FLGTSzl4YXSQTCAr747SgQr9A== Content-Language: en-us X-OriginalArrivalTime: 08 Feb 2010 19:53:05.0025 (UTC) FILETIME=[54207710:01CAA8F8] Subject: [martini] REMINDER: Slide Request X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 08 Feb 2010 19:53:11 -0000 ------=_NextPart_000_0147_01CAA8B5.44DE5990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you are on the agenda for the MARTINI Virtual Interim III tomorrow, please get your slides to myself and/or Spencer ASAP. Thanks in advance! ------=_NextPart_000_0147_01CAA8B5.44DE5990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are on the agenda for the MARTINI Virtual = Interim III tomorrow, please get your slides to myself and/or Spencer ASAP.  =

 

Thanks in advance!

------=_NextPart_000_0147_01CAA8B5.44DE5990-- From john.elwell@siemens-enterprise.com Mon Feb 8 12:33: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 6577D28C18E for ; Mon, 8 Feb 2010 12:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmJA20t-w3sW for ; Mon, 8 Feb 2010 12:33:06 -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 65CBB28C18B for ; Mon, 8 Feb 2010 12:33:06 -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-819116 for martini@ietf.org; Mon, 8 Feb 2010 21:34:08 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B42411EB82AB for ; Mon, 8 Feb 2010 21:34:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 8 Feb 2010 21:34:08 +0100 From: "Elwell, John" To: "martini@ietf.org" Date: Mon, 8 Feb 2010 21:34:07 +0100 Thread-Topic: draft-elwell-martini-reqs-01 posted Thread-Index: Acqos3wyX5nL+DG6T3+NR867VZntGgASjm9A Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] draft-elwell-martini-reqs-01 posted X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 08 Feb 2010 20:33:07 -0000 One point for consideration before the interim. The requirements draft info= rmatively references the problem statement draft. Should we progress both d= ocuments, or merge them (e.g., merge relevant parts of the problem statemen= t draft into the requirements draft)? John > -----Original Message----- > From: Elwell, John=20 > Sent: 08 February 2010 11:40 > To: martini@ietf.org > Subject: draft-elwell-martini-reqs-01 posted >=20 > The 01 version just adds a couple of new requirements=20 > (REQ/16/REQ17) arising from discussion last week. > http://www.ietf.org/internet-drafts/draft-elwell-martini-reqs-01.txt >=20 >=20 > John= From pkyzivat@cisco.com Mon Feb 8 17:56: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 18D333A74EF for ; Mon, 8 Feb 2010 17:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 Tz7wQNE+XUgf for ; Mon, 8 Feb 2010 17:56:38 -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 DDDD63A67A4 for ; Mon, 8 Feb 2010 17:56:37 -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: ApoEALpPcEtAZnwM/2dsb2JhbAC/ZZdrhFQE X-IronPort-AV: E=Sophos;i="4.49,433,1262563200"; d="scan'208";a="84785645" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2010 01:57:41 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o191vffT011413; Tue, 9 Feb 2010 01:57:41 GMT Message-ID: <4B70C117.4090900@cisco.com> Date: Mon, 08 Feb 2010 20:57:43 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B68BEB4.2020207@nostrum.com> <4B6C3C26.80908@cisco.com> <4B6C5304.9070605@nostrum.com> <4B6C59D1.20706@cisco.com> <4B6C7232.4090009@nostrum.com> In-Reply-To: <4B6C7232.4090009@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MARTINI Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 09 Feb 2010 01:56:39 -0000 Adam Roach wrote: >>>> * Need for Proxy-Require >>>> >>>> You say we need because we are altering the semantics of REGISTER. >>>> But which semantics of register *that pertain to proxies* are we >>>> altering? >>> >>> Policy decisions that have historically applied to a single AOR will >>> now be applied to REGISTER transactions that pertain to multiple >>> AORs. That's a change. >>> >>> Really: why else are you going to have proxies between the PBX and >>> the SSP? It pretty much comes down to NAT traversal and application >>> of policy. >> >> AFAIK all of these things are making leaps of faith that aren't >> supported by the standards. > > I think RFCs 3327 and 3608 actually provide such support, after a > fashion. They're designed explicitly to put proxies in the path at > registration time. What are these proxies ostensibly used for? Putting a proxy in the path doesn't say anything about why it is there. (Maybe just for data gathering/monitoring, ...) There is still nothing that justifies such a proxy making assumptions such as: "only the registered contact will validly appear in outgoing requests on this path". Of course there are deployments that make such an assumption. But that doesn't make them right. You are suggesting that now a UA must include a Proxy-Require to ensure it is permitted to do something that it was never forbidden to do. ISTM that in real life deployments where this might be an issue, it is the obligation of the proxy making the leap of faith to support the new behavior if it desires to permit anything on the side it is protecting/restricting to use the feature. IOW, if my P-CSCF has been making these kinds of restrictions, it needs to get smarter in tandem with the S-CSCF behind it supporting this feature. It isn't really the problem of the UA on the other side. >>>> * Temp GRUUs >>>> >>>> One possibility would be for the pbx to use the public GRUU seed of >>>> some single number (the attendant number?) of the pbx to mint its >>>> own temporary GRUUs. Their anonymity would be limited since they can >>>> all be traced to the same pbx, but that may be acceptable in some >>>> cases. >>> >>> I thought through this, and decided that doing the temp-GRUUs at the >>> SSP introduced far more complication than was gained. Since public >>> GRUUs get you the ability to do all the call-control state, I'm not >>> sure it's as important to make the temp-GRUUs as universally available. >>> >>> I'm not really attached to this viewpoint, though. If someone wants >>> to write up text about how to do temp-GRUUs through the SSP >>> (including an analysis of why it works), then I'm happy to put it in. >> >> I think you missed my point. What I was suggesting does not require >> the SSP to do anything more. Its simply local behavior that the pbx >> could use to mint its own temp gruus using one of its public gruus >> from the SSP. > > Ah, I see. You're saying that the PBX does something to get a *PUBLIC* > GRUU from the SSP, and then hands it out (with tokens appended) as a > *PRIVATE* GRUU for its internal extensions. I missed that you were doing > this public-to-private crossover. > > > Yes, that works, subject to the restrictions you placed on it. It does > end up having the kind of bizarre property that they look like public > URIs for one AOR, but are *actually* temp URIs for another. > > I would suggest, if we want to go down this path, we define it in > addition to what I currently have the draft, instead of replacing it. > That is: if the PBX can make its own temp-gruus (as described in the > current GIN draft), it does; otherwise, it makes use of the mechanism > you describe. Sure, I'm fine with both. Since what I suggest is a latent capability that can be implemented locally by the pbx, there is no need to even mention it. I just thought it might be a good note for those who might not think of it. While that mechanism isn't *very* anonymizing for really small pbx's, the more I think about it the more I like it. It has exactly the property that many companies desire - not giving out direct numbers to their employees - while still providing controlled direct callback. Having the "attendant number" in those temp gruus will often be a good thing: if somebody picks it apart and calls the base number directly they will get the company attendant. For your case, of the pbx minting its own private gruus - if it has a routable address that permits it to do so, it wouldn't need to use the martini mechanism. It could just give the SSP its publicly routable address and be done with it. Thanks, Paul From adam@nostrum.com Mon Feb 8 19:06: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 1059A28B797 for ; Mon, 8 Feb 2010 19:06:40 -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.025, 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 lKNfPIiUaL3s for ; Mon, 8 Feb 2010 19:06: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 9465028B56A for ; Mon, 8 Feb 2010 19:06:38 -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 o1937erH019963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 21:07:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B70D17C.7050601@nostrum.com> Date: Mon, 08 Feb 2010 21:07: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: Paul Kyzivat References: <4B68BEB4.2020207@nostrum.com> <4B6C3C26.80908@cisco.com> <4B6C5304.9070605@nostrum.com> <4B6C59D1.20706@cisco.com> <4B6C7232.4090009@nostrum.com> <4B70C117.4090900@cisco.com> In-Reply-To: <4B70C117.4090900@cisco.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 Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 09 Feb 2010 03:06:40 -0000 On 2/8/10 19:57, Feb 8, Paul Kyzivat wrote: > > > Adam Roach wrote: > >>>>> * Need for Proxy-Require >>>>> >>>>> You say we need because we are altering the semantics of REGISTER. >>>>> But which semantics of register *that pertain to proxies* are we >>>>> altering? >>>> >>>> Policy decisions that have historically applied to a single AOR >>>> will now be applied to REGISTER transactions that pertain to >>>> multiple AORs. That's a change. >>>> >>>> Really: why else are you going to have proxies between the PBX and >>>> the SSP? It pretty much comes down to NAT traversal and application >>>> of policy. >>> >>> AFAIK all of these things are making leaps of faith that aren't >>> supported by the standards. >> >> I think RFCs 3327 and 3608 actually provide such support, after a >> fashion. They're designed explicitly to put proxies in the path at >> registration time. What are these proxies ostensibly used for? > > Putting a proxy in the path doesn't say anything about why it is there. > (Maybe just for data gathering/monitoring, ...) > > There is still nothing that justifies such a proxy making assumptions > such as: "only the registered contact will validly appear in outgoing > requests on this path". Or something less broken (although admittedly more baroque) like: "I know AOR sip:+12145550107@foo.com needs to go through proxy Y, so I'll add it to the Path list." >> Ah, I see. You're saying that the PBX does something to get a >> *PUBLIC* GRUU from the SSP, and then hands it out (with tokens >> appended) as a *PRIVATE* GRUU for its internal extensions. I missed >> that you were doing this public-to-private crossover. >> >> >> Yes, that works, subject to the restrictions you placed on it. It >> does end up having the kind of bizarre property that they look like >> public URIs for one AOR, but are *actually* temp URIs for another. >> >> I would suggest, if we want to go down this path, we define it in >> addition to what I currently have the draft, instead of replacing it. >> That is: if the PBX can make its own temp-gruus (as described in the >> current GIN draft), it does; otherwise, it makes use of the mechanism >> you describe. > > > Sure, I'm fine with both. Since what I suggest is a latent capability > that can be implemented locally by the pbx, there is no need to even > mention it. I just thought it might be a good note for those who might > not think of it. We can do it that way, or we can make it slightly more anonymous by (a) having the PBX leave out the user portion for these private GRUUs, and (b) have the SSP route on "gr" instead of user if the user portion is missing. > While that mechanism isn't *very* anonymizing for really small pbx's, > the more I think about it the more I like it. It has exactly the > property that many companies desire - not giving out direct numbers to > their employees - while still providing controlled direct callback. > Having the "attendant number" in those temp gruus will often be a good > thing: if somebody picks it apart and calls the base number directly > they will get the company attendant. Actually, that's kind of an interesting property. Definitely something we should talk over on the call tomorrow (assuming my voice holds out -- I appear to be rapidly developing a cold). > For your case, of the pbx minting its own private gruus - if it has a > routable address that permits it to do so, it wouldn't need to use the > martini mechanism. It could just give the SSP its publicly routable > address and be done with it. There's a qualitative difference between the level of permanence required for the SSP-PBX routing to work versus temp-gruus. If the PBX is going to be installed on an arbitrary IP address that can't be reasonably provisioned into the SSP, and may potentially be reassigned on an infrequent basis, then we need some means for the PBX to update the SSP with its address. That's what MARTINI is doing. On the other hand, temp-gruus don't need the same level of permanence. Reassigning the IP address of a PBX in production would be highly disruptive: ongoing calls will fail, and there will likely be a short period of time before it has re-registered to the SSP, during which incoming calls will fail. In other words, while MARTINI makes allowances for this kind of thing to happen, it isn't *practical* for the PBX's address to change unless something quite exceptional has happened. Temp-gruus are formed around the concept of periodic invalidation anyway. So the prospect that one of these highly disruptive events will invalidate the currently issued temp-gruus is well within the realm of what is expected for temp-gruus. For what it's worth, I've had the same IP address at home for several months (it does change whenever the PPPoE link drops, but that is an infrequent event). My co-workers with cable modems report several years with the same IP address. /a From dean.willis@softarmor.com Tue Feb 9 07:49: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 9E1B53A7207 for ; Tue, 9 Feb 2010 07:49:55 -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 AI-MwUjrcUSt for ; Tue, 9 Feb 2010 07:49:54 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AD7863A708D for ; Tue, 9 Feb 2010 07:49:54 -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 o19FowSV004519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 9 Feb 2010 09:51:01 -0600 Message-Id: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> From: Dean Willis To: MARTINI 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, 9 Feb 2010 09:50:51 -0600 X-Mailer: Apple Mail (2.936) Subject: [martini] DID Number Mobility and 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, 09 Feb 2010 15:49:55 -0000 One of my understanding of goals for corporate VoIP systems was the ability to move a user from one PBX to another PBX without having to pay a service provider MACD (move, add, change, delete) fee. In fact, it was my demonstrating this very capability to MCI's chief engineering officer back in 1999 that got the first SIP project there funded. Let's talk through a use case: Assume Alice is working today in our building at #901 I-street, which has a PBX. Her DID number is routed to that PBX. Over lunch, her office gets moved down the street to the lab at #400 I-Street. Three cases might apply: 1) Alice moves her phone and plugs it in and it "just works", because the phone dynamically registers with the new PBX, which then dynamically registers with the SSP proxy for that DID number, effectively moving the binding from #901's PBX to #400's PBX. 2) Alice moves her phone to #400, waits until after lunch, then calls the phone support people, who manually reprovision her onto the #400 PBX. This PBX then re-registers with SSP, and her number starts working again. 3) Alice moves her pone to #400, and waits until after lunch to talk to the phone support people, who reprovision her on the PBXes and then call the SSP support people to move her DID number from #901's "trunk" to 400's "trunk". Sometime, tomorrow, her phone line starts working AND we get a $50 bill for the "change fee" from the SSP. Our original design goal favored #1, we might have accepted #2, and #3 was what we were most aggressively trying to avoid. Yet my understanding of the consensus of MARTINI is that #3 is the desired outcome. This is the difference, if I understand it, between draft-gin's "()" proposal for implicit registration and the "XXXX" proposal for explicit registration I made on-list. Why are we pushing ourselves ten years backwards in operational advances? And what happens when Alice has a WiFi phone and moves back and forth from #901 to #400 several times a day? Does she just go without a phone, or do we pay a $50 change fee each time? -- Dean From dean.willis@softarmor.com Tue Feb 9 10:07: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 842283A720D for ; Tue, 9 Feb 2010 10:07: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 owJ2bElq1rS3 for ; Tue, 9 Feb 2010 10:07:28 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B22CB3A68B4 for ; Tue, 9 Feb 2010 10:07:28 -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 o19I8YQx005894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 9 Feb 2010 12:08:35 -0600 Message-Id: From: Dean Willis To: MARTINI 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, 9 Feb 2010 12:08:28 -0600 X-Mailer: Apple Mail (2.936) Subject: [martini] Question on registration 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, 09 Feb 2010 18:07:29 -0000 A PBX is registering with an SSP expects the REGISTER transaction to result in a number of bindings between "phone number" AORs and the PBX's Contact. Do we expect that the response to the REGISTER request will indicate whether these bindings have in fact been produced, or do we expect it to convey no such information and instead rely on the PBX to execute a re-event subscription and thereby learn what happened? Historical use of REGISTER is consistent with the first approach; if the REGISTER request fails its authorization or authentication, it gets rejected. I propose a model: A PBX explicitly indicates which phone numbers it is binding in the REGISTER request. If SSP determines that PBX is not authorized for one or more of those phone numbers, it returns a 403 request letting the PBX know that the registration has failed. This at least lets us detect a configuration mismatch very early on. If a registration is later retracted by SSP, then we can either use reg-event to inform PBX, or simply reject further re-registrations made by PBX. -- Dean From tyler@foxfam.com Tue Feb 9 10:17: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 7F33528C268 for ; Tue, 9 Feb 2010 10:17:37 -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 t0TGzxpLbFpZ for ; Tue, 9 Feb 2010 10:17:36 -0800 (PST) Received: from smtp05.atlngahp.sys.nuvox.net (smtp-out5.atlngahp.sys.nuvox.net [70.43.63.23]) by core3.amsl.com (Postfix) with ESMTP id 5B30628C263 for ; Tue, 9 Feb 2010 10:17:36 -0800 (PST) Received: from LT6KW7CD1 (fw-nat.it.nuvox.net [216.215.144.201]) by smtp05.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o19IIe8A014666; Tue, 9 Feb 2010 13:18:40 -0500 Message-ID: <009601caa9b4$4e41c120$150610ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: "Dean Willis" , "MARTINI" References: Date: Tue, 9 Feb 2010 13:18:40 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [martini] Question on registration 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, 09 Feb 2010 18:17:37 -0000 I concur. One way or the other the PBX and any in-the-middle devices (like these SBC's we've invested so heavily in) need to be aware of what addresses the SSP considers registered/active. ----- Original Message ----- From: "Dean Willis" To: "MARTINI" Sent: Tuesday, February 09, 2010 1:08 PM Subject: [martini] Question on registration requirements > > A PBX is registering with an SSP expects the REGISTER transaction to > result in a number of bindings between "phone number" AORs and the PBX's > Contact. > > Do we expect that the response to the REGISTER request will indicate > whether these bindings have in fact been produced, or do we expect it to > convey no such information and instead rely on the PBX to execute a > re-event subscription and thereby learn what happened? > > Historical use of REGISTER is consistent with the first approach; if the > REGISTER request fails its authorization or authentication, it gets > rejected. > > > I propose a model: > > A PBX explicitly indicates which phone numbers it is binding in the > REGISTER request. If SSP determines that PBX is not authorized for one or > more of those phone numbers, it returns a 403 request letting the PBX > know that the registration has failed. This at least lets us detect a > configuration mismatch very early on. > > If a registration is later retracted by SSP, then we can either use > reg-event to inform PBX, or simply reject further re-registrations made > by PBX. > > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From jsburton@cablevision.com Tue Feb 9 10:18: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 0375128C266 for ; Tue, 9 Feb 2010 10:18:13 -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 ZEQ1X4xyPix3 for ; Tue, 9 Feb 2010 10:18:11 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 9411A28C265 for ; Tue, 9 Feb 2010 10:18:11 -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 o19IJHi1007904 for ; Tue, 9 Feb 2010 13:19:18 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o19IJHi1007904 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1265739558; bh=P783BsdOo4BWaEdzYu5sUR4Noth5uKNSgfyMBJh r0Dc=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=gV524+PkoWifbBi9MNOvFeUaMNeAw1rZHvhe+ jCBzPwn53kc097jnJiiHTue3L9YiKGAVJZW8rqcZ4KiUA33kwTHGjEwCEzFyPYc3DOA xCJeNVvJV+GRsBwKqxdbSRqT4nQNr/jvMKVCOkRSbpWFcJdQ3aJ3hZjnfh6xMJ07L4Y = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Tue, 09 Feb 2010 13:19:17 -0500 Message-Id: <4B7144AD.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Tue, 09 Feb 2010 13:19:09 -0500 From: "Jack Burton" To: "MARTINI" References: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartF8D2CF0D.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] Question on registration 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, 09 Feb 2010 18:18:13 -0000 --=__PartF8D2CF0D.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In other words, you propose to do away with "implicit" registration? I do not think that is desirable. I expect that a PBX will register its parent AOR and when it sees the 200 OK will imply registration for all associated DID number endpoints, such that calls from those numbers will be processed by the SSP. If credentials for the parent fail, then the SSP (and PBX) would not consider it, nor any of the associated DID numbers, registered. -Jack >>> Dean Willis 2/9/2010 11:08 >>> A PBX is registering with an SSP expects the REGISTER transaction to result in a number of bindings between "phone number" AORs and the PBX's Contact. Do we expect that the response to the REGISTER request will indicate whether these bindings have in fact been produced, or do we expect it to convey no such information and instead rely on the PBX to execute a re-event subscription and thereby learn what happened? Historical use of REGISTER is consistent with the first approach; if the REGISTER request fails its authorization or authentication, it gets rejected. I propose a model: A PBX explicitly indicates which phone numbers it is binding in the REGISTER request. If SSP determines that PBX is not authorized for one or more of those phone numbers, it returns a 403 request letting the PBX know that the registration has failed. This at least lets us detect a configuration mismatch very early on. If a registration is later retracted by SSP, then we can either use reg-event to inform PBX, or simply reject further re-registrations made by PBX. -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini -------------------------------------------------------- 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. -------------------------------------------------------- --=__PartF8D2CF0D.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
In other words, you propose to do away with "implicit" regis= tration?  I do not think that is desirable.
 
I expect that a PBX will register its parent AOR and when it sees the = 200 OK will imply registration for all associated DID number endpoints, suc= h that calls from those numbers will be processed by the SSP.  If cred= entials for the parent fail, then the SSP (and PBX) would not consider it, = nor any of the associated DID numbers, registered.
 
-Jack

>>> Dean Willis <dean.willis@softarmor.com>= ; 2/9/2010 11:08 >>>

A PBX is registering with an SSP expec= ts the REGISTER transaction to 
result in a number of bindings bet= ween "phone number" AORs and the 
PBX's Contact.

Do we expe= ct that the response to the REGISTER request will indicate 
whethe= r these bindings have in fact been produced, or do we expect it 
t= o convey no such information and instead rely on the PBX to execute a =
re-event subscription and thereby learn what happened?

Historic= al use of REGISTER is consistent with the first approach; if 
the = REGISTER request fails its authorization or authentication, it 
ge= ts rejected.


I propose a model:

A PBX explicitly indicate= s which phone numbers it is binding in the 
REGISTER request. If S= SP determines that PBX is not authorized for one 
or more of those= phone numbers, it returns a 403 request letting the 
PBX know tha= t the registration has failed. This at least lets us 
detect a con= figuration mismatch very early on.

If a registration is later retrac= ted by SSP, then we can either use 
reg-event to inform PBX, or si= mply reject further re-registrations 
made by PBX.

--
De= an
_______________________________________________
martini mailing li= st
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini
=
--------------------------------------------------------
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.
-------------------------------------------------------- --=__PartF8D2CF0D.0__=-- From md3135@att.com Tue Feb 9 10: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 2258D28C266 for ; Tue, 9 Feb 2010 10:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdUIQ2oy45WW for ; Tue, 9 Feb 2010 10:22:25 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 031473A7593 for ; Tue, 9 Feb 2010 10:22:24 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-14.tower-161.messagelabs.com!1265739808!18374002!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13787 invoked from network); 9 Feb 2010 18:23:29 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Feb 2010 18:23:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o19INLge032752 for ; Tue, 9 Feb 2010 13:23:21 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o19INHNw032694 for ; Tue, 9 Feb 2010 13:23:17 -0500 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_01CAA9B4.F74D5850" Date: Tue, 9 Feb 2010 13:23:24 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D2D@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Question on registration requirements Thread-Index: AcqptG6H+wtl+tJyRPKvOn3QiE16FQAAIjIn From: "DOLLY, MARTIN C (ATTLABS)" To: , Subject: Re: [martini] Question on registration 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, 09 Feb 2010 18:22:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA9B4.F74D5850 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhbiwgV2hhdCBhcmUgeW91IHRoaW5raW5nDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KRnJvbTogbWFydGluaS1ib3VuY2VzQGlldGYub3JnIDxtYXJ0aW5pLWJvdW5j ZXNAaWV0Zi5vcmc+IA0KVG86IE1BUlRJTkkgPG1hcnRpbmlAaWV0Zi5vcmc+IA0KU2VudDogVHVl IEZlYiAwOSAxMzoxOTowOSAyMDEwDQpTdWJqZWN0OiBSZTogW21hcnRpbmldIFF1ZXN0aW9uIG9u IHJlZ2lzdHJhdGlvbiByZXF1aXJlbWVudHMgDQoNCg0KSW4gb3RoZXIgd29yZHMsIHlvdSBwcm9w b3NlIHRvIGRvIGF3YXkgd2l0aCAiaW1wbGljaXQiIHJlZ2lzdHJhdGlvbj8gIEkgZG8gbm90IHRo aW5rIHRoYXQgaXMgZGVzaXJhYmxlLg0KIA0KSSBleHBlY3QgdGhhdCBhIFBCWCB3aWxsIHJlZ2lz dGVyIGl0cyBwYXJlbnQgQU9SIGFuZCB3aGVuIGl0IHNlZXMgdGhlIDIwMCBPSyB3aWxsIGltcGx5 IHJlZ2lzdHJhdGlvbiBmb3IgYWxsIGFzc29jaWF0ZWQgRElEIG51bWJlciBlbmRwb2ludHMsIHN1 Y2ggdGhhdCBjYWxscyBmcm9tIHRob3NlIG51bWJlcnMgd2lsbCBiZSBwcm9jZXNzZWQgYnkgdGhl IFNTUC4gIElmIGNyZWRlbnRpYWxzIGZvciB0aGUgcGFyZW50IGZhaWwsIHRoZW4gdGhlIFNTUCAo YW5kIFBCWCkgd291bGQgbm90IGNvbnNpZGVyIGl0LCBub3IgYW55IG9mIHRoZSBhc3NvY2lhdGVk IERJRCBudW1iZXJzLCByZWdpc3RlcmVkLg0KIA0KLUphY2sNCg0KPj4+IERlYW4gV2lsbGlzIDxk ZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPiAyLzkvMjAxMCAxMTowOCA+Pj4NCg0KQSBQQlggaXMg cmVnaXN0ZXJpbmcgd2l0aCBhbiBTU1AgZXhwZWN0cyB0aGUgUkVHSVNURVIgdHJhbnNhY3Rpb24g dG8gIA0KcmVzdWx0IGluIGEgbnVtYmVyIG9mIGJpbmRpbmdzIGJldHdlZW4gInBob25lIG51bWJl ciIgQU9ScyBhbmQgdGhlICANClBCWCdzIENvbnRhY3QuDQoNCkRvIHdlIGV4cGVjdCB0aGF0IHRo ZSByZXNwb25zZSB0byB0aGUgUkVHSVNURVIgcmVxdWVzdCB3aWxsIGluZGljYXRlICANCndoZXRo ZXIgdGhlc2UgYmluZGluZ3MgaGF2ZSBpbiBmYWN0IGJlZW4gcHJvZHVjZWQsIG9yIGRvIHdlIGV4 cGVjdCBpdCAgDQp0byBjb252ZXkgbm8gc3VjaCBpbmZvcm1hdGlvbiBhbmQgaW5zdGVhZCByZWx5 IG9uIHRoZSBQQlggdG8gZXhlY3V0ZSBhICANCnJlLWV2ZW50IHN1YnNjcmlwdGlvbiBhbmQgdGhl cmVieSBsZWFybiB3aGF0IGhhcHBlbmVkPw0KDQpIaXN0b3JpY2FsIHVzZSBvZiBSRUdJU1RFUiBp cyBjb25zaXN0ZW50IHdpdGggdGhlIGZpcnN0IGFwcHJvYWNoOyBpZiAgDQp0aGUgUkVHSVNURVIg cmVxdWVzdCBmYWlscyBpdHMgYXV0aG9yaXphdGlvbiBvciBhdXRoZW50aWNhdGlvbiwgaXQgIA0K Z2V0cyByZWplY3RlZC4NCg0KDQpJIHByb3Bvc2UgYSBtb2RlbDoNCg0KQSBQQlggZXhwbGljaXRs eSBpbmRpY2F0ZXMgd2hpY2ggcGhvbmUgbnVtYmVycyBpdCBpcyBiaW5kaW5nIGluIHRoZSAgDQpS RUdJU1RFUiByZXF1ZXN0LiBJZiBTU1AgZGV0ZXJtaW5lcyB0aGF0IFBCWCBpcyBub3QgYXV0aG9y aXplZCBmb3Igb25lICANCm9yIG1vcmUgb2YgdGhvc2UgcGhvbmUgbnVtYmVycywgaXQgcmV0dXJu cyBhIDQwMyByZXF1ZXN0IGxldHRpbmcgdGhlICANClBCWCBrbm93IHRoYXQgdGhlIHJlZ2lzdHJh dGlvbiBoYXMgZmFpbGVkLiBUaGlzIGF0IGxlYXN0IGxldHMgdXMgIA0KZGV0ZWN0IGEgY29uZmln dXJhdGlvbiBtaXNtYXRjaCB2ZXJ5IGVhcmx5IG9uLg0KDQpJZiBhIHJlZ2lzdHJhdGlvbiBpcyBs YXRlciByZXRyYWN0ZWQgYnkgU1NQLCB0aGVuIHdlIGNhbiBlaXRoZXIgdXNlICANCnJlZy1ldmVu dCB0byBpbmZvcm0gUEJYLCBvciBzaW1wbHkgcmVqZWN0IGZ1cnRoZXIgcmUtcmVnaXN0cmF0aW9u cyAgDQptYWRlIGJ5IFBCWC4NCg0KLS0NCkRlYW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptYXJ0aW5pIG1haWxpbmcgbGlzdA0KbWFydGluaUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYXJ0aW5pDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g DQpUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgaW4gdGhpcyBlbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0 byB3aGljaCBpdCBpcyBhZGRyZXNzZWQgYW5kIG1heSBjb250YWluIENhYmxldmlzaW9uIHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBDYWJsZXZpc2lvbi4gQW55IHJldmll dywgcmV0cmFuc21pc3Npb24sIGRpc3NlbWluYXRpb24gb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtp bmcgb2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uLCB0aGlzIGluZm9ybWF0aW9uIGJ5IHBl cnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgaW4gZXJy b3IsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBhbmQg ZGVzdHJveSB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYWxsIG9mIHRoZSBhdHRhY2htZW50cyB5b3Ug aGF2ZSByZWNlaXZlZCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLiANCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= ------_=_NextPart_001_01CAA9B4.F74D5850 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+DQoNCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAw LjYwMDEuMTg4NzYiPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJNQVJHSU46IDRweCA0cHggMXB4OyBG T05UOiAxMHB0IFRhaG9tYSI+PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFs Pg0KRGVhbiwgV2hhdCBhcmUgeW91IHRoaW5raW5nPGJyPjwvZm9udD48L2Rpdj4NCjxicj48ZGl2 PjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT4NCjxmb250 IGZhY2U9VGFob21hIHNpemU9Mj4NCjxiPkZyb208L2I+OiBtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5v cmcgJmx0O21hcnRpbmktYm91bmNlc0BpZXRmLm9yZyZndDsNPGJyPjxiPlRvPC9iPjogTUFSVElO SSAmbHQ7bWFydGluaUBpZXRmLm9yZyZndDsNPGJyPjxiPlNlbnQ8L2I+OiBUdWUgRmViIDA5IDEz OjE5OjA5IDIwMTA8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBbbWFydGluaV0gUXVlc3Rpb24gb24g cmVnaXN0cmF0aW9uIHJlcXVpcmVtZW50cw08YnI+PC9mb250Pjxicj48L2Rpdj4NCg0KPERJVj5J biBvdGhlciB3b3JkcywmbmJzcDt5b3UgcHJvcG9zZSB0byBkbyZuYnNwO2F3YXkgd2l0aCAiaW1w bGljaXQiIHJlZ2lzdHJhdGlvbj8mbmJzcDsgSSBkbyBub3QgdGhpbmsgdGhhdCBpcyBkZXNpcmFi bGUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIGV4cGVjdCB0aGF0IGEgUEJYIHdp bGwgcmVnaXN0ZXIgaXRzIHBhcmVudCBBT1IgYW5kIHdoZW4gaXQgc2VlcyB0aGUgMjAwIE9LIHdp bGwgaW1wbHkgcmVnaXN0cmF0aW9uIGZvciBhbGwgYXNzb2NpYXRlZCBESUQgbnVtYmVyIGVuZHBv aW50cywgc3VjaCB0aGF0IGNhbGxzIGZyb20gdGhvc2UgbnVtYmVycyB3aWxsIGJlIHByb2Nlc3Nl ZCBieSB0aGUgU1NQLiZuYnNwOyBJZiBjcmVkZW50aWFscyBmb3IgdGhlIHBhcmVudCBmYWlsLCB0 aGVuIHRoZSBTU1AgKGFuZCBQQlgpIHdvdWxkIG5vdCBjb25zaWRlciBpdCwgbm9yIGFueSBvZiB0 aGUgYXNzb2NpYXRlZCBESUQgbnVtYmVycywgcmVnaXN0ZXJlZC48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPi1KYWNrPEJSPjxCUj4mZ3Q7Jmd0OyZndDsgRGVhbiBXaWxsaXMgJmx0O2Rl YW4ud2lsbGlzQHNvZnRhcm1vci5jb20mZ3Q7IDIvOS8yMDEwIDExOjA4ICZndDsmZ3Q7Jmd0OzxC Uj48QlI+QSBQQlggaXMgcmVnaXN0ZXJpbmcgd2l0aCBhbiBTU1AgZXhwZWN0cyB0aGUgUkVHSVNU RVIgdHJhbnNhY3Rpb24gdG8mbmJzcDsgPEJSPnJlc3VsdCBpbiBhIG51bWJlciBvZiBiaW5kaW5n cyBiZXR3ZWVuICJwaG9uZSBudW1iZXIiIEFPUnMgYW5kIHRoZSZuYnNwOyA8QlI+UEJYJ3MgQ29u dGFjdC48QlI+PEJSPkRvIHdlIGV4cGVjdCB0aGF0IHRoZSByZXNwb25zZSB0byB0aGUgUkVHSVNU RVIgcmVxdWVzdCB3aWxsIGluZGljYXRlJm5ic3A7IDxCUj53aGV0aGVyIHRoZXNlIGJpbmRpbmdz IGhhdmUgaW4gZmFjdCBiZWVuIHByb2R1Y2VkLCBvciBkbyB3ZSBleHBlY3QgaXQmbmJzcDsgPEJS PnRvIGNvbnZleSBubyBzdWNoIGluZm9ybWF0aW9uIGFuZCBpbnN0ZWFkIHJlbHkgb24gdGhlIFBC WCB0byBleGVjdXRlIGEmbmJzcDsgPEJSPnJlLWV2ZW50IHN1YnNjcmlwdGlvbiBhbmQgdGhlcmVi eSBsZWFybiB3aGF0IGhhcHBlbmVkPzxCUj48QlI+SGlzdG9yaWNhbCB1c2Ugb2YgUkVHSVNURVIg aXMgY29uc2lzdGVudCB3aXRoIHRoZSBmaXJzdCBhcHByb2FjaDsgaWYmbmJzcDsgPEJSPnRoZSBS RUdJU1RFUiByZXF1ZXN0IGZhaWxzIGl0cyBhdXRob3JpemF0aW9uIG9yIGF1dGhlbnRpY2F0aW9u LCBpdCZuYnNwOyA8QlI+Z2V0cyByZWplY3RlZC48QlI+PEJSPjxCUj5JIHByb3Bvc2UgYSBtb2Rl bDo8QlI+PEJSPkEgUEJYIGV4cGxpY2l0bHkgaW5kaWNhdGVzIHdoaWNoIHBob25lIG51bWJlcnMg aXQgaXMgYmluZGluZyBpbiB0aGUmbmJzcDsgPEJSPlJFR0lTVEVSIHJlcXVlc3QuIElmIFNTUCBk ZXRlcm1pbmVzIHRoYXQgUEJYIGlzIG5vdCBhdXRob3JpemVkIGZvciBvbmUmbmJzcDsgPEJSPm9y IG1vcmUgb2YgdGhvc2UgcGhvbmUgbnVtYmVycywgaXQgcmV0dXJucyBhIDQwMyByZXF1ZXN0IGxl dHRpbmcgdGhlJm5ic3A7IDxCUj5QQlgga25vdyB0aGF0IHRoZSByZWdpc3RyYXRpb24gaGFzIGZh aWxlZC4gVGhpcyBhdCBsZWFzdCBsZXRzIHVzJm5ic3A7IDxCUj5kZXRlY3QgYSBjb25maWd1cmF0 aW9uIG1pc21hdGNoIHZlcnkgZWFybHkgb24uPEJSPjxCUj5JZiBhIHJlZ2lzdHJhdGlvbiBpcyBs YXRlciByZXRyYWN0ZWQgYnkgU1NQLCB0aGVuIHdlIGNhbiBlaXRoZXIgdXNlJm5ic3A7IDxCUj5y ZWctZXZlbnQgdG8gaW5mb3JtIFBCWCwgb3Igc2ltcGx5IHJlamVjdCBmdXJ0aGVyIHJlLXJlZ2lz dHJhdGlvbnMmbmJzcDsgPEJSPm1hZGUgYnkgUEJYLjxCUj48QlI+LS08QlI+RGVhbjxCUj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5tYXJ0aW5pIG1h aWxpbmcgbGlzdDxCUj5tYXJ0aW5pQGlldGYub3JnPEJSPjxBIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFydGluaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYXJ0aW5pPC9BPjxCUj48L0RJVj48L0JPRFk+PC9IVE1MPg0KPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g PGJyPg0KVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGluIHRoaXMgZW1haWwgYW5kIGFueSBv ZiBpdHMgYXR0YWNobWVudHMgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRp dHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBDYWJsZXZpc2lvbiBw cm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFs LCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gQ2FibGV2aXNpb24uIEFueSBy ZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNzZW1pbmF0aW9uIG9yIG90aGVyIHVzZSBvZiwgb3Ig dGFraW5nIG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2UgdXBvbiwgdGhpcyBpbmZvcm1hdGlvbiBi eSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBp cyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSByZWNlaXZlZCB0aGlzIGlu IGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUg YW5kIGRlc3Ryb3kgdGhlIGNvbW11bmljYXRpb24gYW5kIGFsbCBvZiB0aGUgYXR0YWNobWVudHMg eW91IGhhdmUgcmVjZWl2ZWQgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4gPGJyPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0= ------_=_NextPart_001_01CAA9B4.F74D5850-- From bruno.chatras@orange-ftgroup.com Tue Feb 9 10:23: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 3F5293A68B4 for ; Tue, 9 Feb 2010 10:23:35 -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.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 B4cFVPpdq3ig for ; Tue, 9 Feb 2010 10:23:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id B6DB73A7040 for ; Tue, 9 Feb 2010 10:23:33 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 721D23745EF; Tue, 9 Feb 2010 19:24:39 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 528D5180062; Tue, 9 Feb 2010 19:24:22 +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, 9 Feb 2010 19:24:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA9B5.19ACDF25" Date: Tue, 9 Feb 2010 19:24:19 +0100 Message-ID: <7181_1265739879_4B71A856_7181_182_1_9ECCF01B52E7AB408A7EB85352642141011432AB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B7144AD.6D98.00CB.0@cablevision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Question on registration requirements Thread-Index: AcqptHo2CgZ9+2fMStqJnDNd917epAAACV+Q References: <4B7144AD.6D98.00CB.0@cablevision.com> From: To: , X-OriginalArrivalTime: 09 Feb 2010 18:24:22.0662 (UTC) FILETIME=[1A2A1260:01CAA9B5] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.13.111532 Subject: Re: [martini] Question on registration 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, 09 Feb 2010 18:23:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA9B5.19ACDF25 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Same view. "Implicit" registration is definitely required ________________________________ De : martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] De la part= de Jack Burton Envoy=E9 : mardi 9 f=E9vrier 2010 19:19 =C0 : MARTINI Objet : Re: [martini] Question on registration requirements =09 =09 In other words, you propose to do away with "implicit" registration? I do= not think that is desirable. =09=20 I expect that a PBX will register its parent AOR and when it sees the 200 = OK will imply registration for all associated DID number endpoints, such th= at calls from those numbers will be processed by the SSP. If credentials f= or the parent fail, then the SSP (and PBX) would not consider it, nor any o= f the associated DID numbers, registered. =09=20 -Jack =09 >>> Dean Willis 2/9/2010 11:08 >>> =09 A PBX is registering with an SSP expects the REGISTER transaction to=20=20 result in a number of bindings between "phone number" AORs and the=20=20 PBX's Contact. =09 Do we expect that the response to the REGISTER request will indicate=20=20 whether these bindings have in fact been produced, or do we expect it=20= =20 to convey no such information and instead rely on the PBX to execute a=20= =20 re-event subscription and thereby learn what happened? =09 Historical use of REGISTER is consistent with the first approach; if=20=20 the REGISTER request fails its authorization or authentication, it=20=20 gets rejected. =09 =09 I propose a model: =09 A PBX explicitly indicates which phone numbers it is binding in the=20=20 REGISTER request. If SSP determines that PBX is not authorized for one=20= =20 or more of those phone numbers, it returns a 403 request letting the=20=20 PBX know that the registration has failed. This at least lets us=20=20 detect a configuration mismatch very early on. =09 If a registration is later retracted by SSP, then we can either use=20=20 reg-event to inform PBX, or simply reject further re-registrations=20=20 made by PBX. =09 -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini =09 --------------------------------------------------------=20 The information transmitted in this email and any of its attachments is in= tended only for the person or entity to which it is addressed and may conta= in Cablevision proprietary information, which is privileged, confidential, = or subject to copyright belonging to Cablevision. Any review, retransmissio= n, 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 co= ntact the sender immediately and delete and destroy the communication and a= ll of the attachments you have received and all copies thereof.=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. ******************************** ------_=_NextPart_001_01CAA9B5.19ACDF25 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Same view. "Im= plicit"=20 registration is definitely required

De : martini-bounces@ietf.org [mailto:martini-bounces@ietf.or= g]=20 De la part de Jack Burton
Envoy=E9 : mardi 9 f=E9vr= ier 2010=20 19:19
=C0 : MARTINI
Objet : Re: [martini] Q= uestion=20 on registration requirements

In other words, you propose to do away with "implicit"=20 registration?  I do not think that is desirable.
 
I expect that a PBX will register its parent AOR and when it sees th= e 200=20 OK will imply registration for all associated DID number endpoints, such = that=20 calls from those numbers will be processed by the SSP.  If credentia= ls=20 for the parent fail, then the SSP (and PBX) would not consider it, nor an= y of=20 the associated DID numbers, registered.
 
-Jack

>>> Dean Willis <dean.willis@softarmor.com&= gt;=20 2/9/2010 11:08 >>>

A PBX is registering with an SSP expec= ts=20 the REGISTER transaction to 
result in a number of bindings betw= een=20 "phone number" AORs and the 
PBX's Contact.

Do we expect = that=20 the response to the REGISTER request will indicate 
whether thes= e=20 bindings have in fact been produced, or do we expect it 
to conv= ey no=20 such information and instead rely on the PBX to execute a 
re-ev= ent=20 subscription and thereby learn what happened?

Historical use of=20 REGISTER is consistent with the first approach; if 
the REGISTER= =20 request fails its authorization or authentication, it 
gets=20 rejected.


I propose a model:

A PBX explicitly indicates= =20 which phone numbers it is binding in the 
REGISTER request. If S= SP=20 determines that PBX is not authorized for one 
or more of those = phone=20 numbers, it returns a 403 request letting the 
PBX know that the= =20 registration has failed. This at least lets us 
detect a=20 configuration mismatch very early on.

If a registration is later= =20 retracted by SSP, then we can either use 
reg-event to inform PB= X, or=20 simply reject further re-registrations 
made by=20 PBX.

--
Dean
_______________________________________________=
martini=20 mailing list
martini@ietf.org
https://www.ietf.o= rg/mailman/listinfo/martini

------------------------------= --------------------------=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 revie= w,=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 int= ended=20 recipient is prohibited and may be unlawful. If you received this in erro= r,=20 please contact the sender immediately and delete and destroy the communic= ation=20 and all of the attachments you have received and all copies thereof.=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.
********************************
------_=_NextPart_001_01CAA9B5.19ACDF25-- From tyler@foxfam.com Tue Feb 9 10:23: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 644F53A7230 for ; Tue, 9 Feb 2010 10:23:47 -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 JiCM-30QvqSg for ; Tue, 9 Feb 2010 10:23:46 -0800 (PST) Received: from smtp02.atlngahp.sys.nuvox.net (smtp-out2.atlngahp.sys.nuvox.net [70.43.63.19]) by core3.amsl.com (Postfix) with ESMTP id 6F7B43A7040 for ; Tue, 9 Feb 2010 10:23:46 -0800 (PST) Received: from LT6KW7CD1 (fw-nat.it.nuvox.net [216.215.144.201]) by smtp02.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o19IOnI0028583; Tue, 9 Feb 2010 13:24:49 -0500 Message-ID: <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: "Dean Willis" , "MARTINI" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> Date: Tue, 9 Feb 2010 13:24:49 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 18:23:47 -0000 The other issue with this is that when Alice unplugs her phone at #901 the PBX at that loc needs to be able to de-register her number. I'm pretty sure de-registering a single number that was previously registered with a bulk-register request was shot down. ----- Original Message ----- From: "Dean Willis" To: "MARTINI" Sent: Tuesday, February 09, 2010 10:50 AM Subject: [martini] DID Number Mobility and MARTINI > > One of my understanding of goals for corporate VoIP systems was the > ability to move a user from one PBX to another PBX without having to pay > a service provider MACD (move, add, change, delete) fee. > > In fact, it was my demonstrating this very capability to MCI's chief > engineering officer back in 1999 that got the first SIP project there > funded. > > Let's talk through a use case: > > Assume Alice is working today in our building at #901 I-street, which has > a PBX. Her DID number is routed to that PBX. Over lunch, her office gets > moved down the street to the lab at #400 I-Street. > > Three cases might apply: > > 1) Alice moves her phone and plugs it in and it "just works", because the > phone dynamically registers with the new PBX, which then dynamically > registers with the SSP proxy for that DID number, effectively moving the > binding from #901's PBX to #400's PBX. > > 2) Alice moves her phone to #400, waits until after lunch, then calls the > phone support people, who manually reprovision her onto the #400 PBX. > This PBX then re-registers with SSP, and her number starts working again. > > 3) Alice moves her pone to #400, and waits until after lunch to talk to > the phone support people, who reprovision her on the PBXes and then call > the SSP support people to move her DID number from #901's "trunk" to > 400's "trunk". Sometime, tomorrow, her phone line starts working AND we > get a $50 bill for the "change fee" from the SSP. > > > Our original design goal favored #1, we might have accepted #2, and #3 > was what we were most aggressively trying to avoid. > > > Yet my understanding of the consensus of MARTINI is that #3 is the > desired outcome. This is the difference, if I understand it, between > draft-gin's "()" proposal for implicit registration and the "XXXX" > proposal for explicit registration I made on-list. > > Why are we pushing ourselves ten years backwards in operational advances? > > And what happens when Alice has a WiFi phone and moves back and forth > from #901 to #400 several times a day? Does she just go without a phone, > or do we pay a $50 change fee each time? > > > > -- > Dean > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Tue Feb 9 10:28: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 3C5053A720D for ; Tue, 9 Feb 2010 10:28:57 -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.025, 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 E7a3H1azfD4A for ; Tue, 9 Feb 2010 10:28: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 0467C3A6F19 for ; Tue, 9 Feb 2010 10:28:50 -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 o19ITjtI015792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 12:29:46 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B71A999.30708@nostrum.com> Date: Tue, 09 Feb 2010 12:29:45 -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: Tyler Parkin References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> In-Reply-To: <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> 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 Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 18:28:57 -0000 On 2/9/10 12:24, Feb 9, Tyler Parkin wrote: > The other issue with this is that when Alice unplugs her phone at #901 > the PBX at that loc needs to be able to de-register her number. I'm > pretty sure de-registering a single number that was previously > registered with a bulk-register request was shot down. But that's not the same as omitting a number from the a subsequent registation, which will have the same net effect. So, for example, if you have a PBX servicing +12145550100 through +12145550120, and Alice (DID +12145550115) moves her phone, then the next PBX registration could be for the two ranges +12145550100 through +12145550114, and +12145550116 through +12145550120. This does get a bit into Richard's fragmentation issue, though. After a small number of phone number moves, you end up with a set of ranges that devolves almost into a complete enumeration of extensions. /a From jsburton@cablevision.com Tue Feb 9 10:31: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 80A063A72D1 for ; Tue, 9 Feb 2010 10:31:31 -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=[AWL=0.000, 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 URj3XrdQKmqk for ; Tue, 9 Feb 2010 10:31:30 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 420BE3A73B2 for ; Tue, 9 Feb 2010 10:31:30 -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 o19IWak4014543 for ; Tue, 9 Feb 2010 13:32:37 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o19IWak4014543 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1265740357; bh=49TnnE9KTpAz1jNK+JP8ym6tbS+LNsFc3dbyMvu AhZE=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=f9w9i6s6aTMTYQeHXO52ZtBGnfDZnfm9g3jSj jB1cxt2HVoVuxsAT2x0cYdjEUt5LcOS3pbRXE1SM+5Q8dTxva6fV00rfYCkvboTsK2c I9R4Dn93EDZSgTI416Lx455qJ5TeXDBPikPC/DaRw/GNFudVyEVKtbh2H8Ow1FSqf1o = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Tue, 09 Feb 2010 13:32:36 -0500 Message-Id: <4B7147C9.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Tue, 09 Feb 2010 13:32:25 -0500 From: "Jack Burton" To: "MARTINI" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> In-Reply-To: <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD1FBE629.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 18:31:31 -0000 --=__PartD1FBE629.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Tyler, The PBX would indeed de-register the phone when it is unplugged. That is not the issue here. Registrations between phones and the PBX are out of scope. To describe further: When the phone is unplugged, after some period the PBX de-registers the phone and knows it is offline. If a call comes in destined for the phone, the PBX would apply appropriate forwarding treatment for an unavailable extension. The SSP considers the number implicitly registered, and would continue to deliver calls to the PBX for that number. It is up to the PBX to treat those calls appropriately. If another phone on the PBX wished to make a call using the outbound number of the failed extension, such as in a multiple line appearance situation, the SSP would process those calls as if nothing happened. To the SSP, nothing did happen. The only time the SSP would change its treatment of calls to the extension in question is if the PBX parent de-registered. Then, the SSP would provide appropriate "endpoint not available" treatment to ALL associated DIDs. -Jack >>> "Tyler Parkin" 2/9/2010 11:24 >>> The other issue with this is that when Alice unplugs her phone at #901 the PBX at that loc needs to be able to de-register her number. I'm pretty sure de-registering a single number that was previously registered with a bulk-register request was shot down. -------------------------------------------------------- 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. -------------------------------------------------------- --=__PartD1FBE629.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML
Tyler,
 
The PBX would indeed de-register the phone when it is unplugged.  That is not the issue here.  Registrations between phones and the PBX are out of scope.
 
To describe further:
 
When the phone is unplugged, after some period the PBX de-registers the phone and knows it is offline.  If a call comes in destined for the phone, the PBX would apply appropriate forwarding treatment for an unavailable extension.  The SSP considers the number implicitly registered, and would continue to deliver calls to the PBX for that number.  It is up to the PBX to treat those calls appropriately.
 
If another phone on the PBX wished to make a call using the outbound number of the failed extension, such as in a multiple line appearance situation, the SSP would process those calls as if nothing happened.  To the SSP, nothing did happen.
 
The only time the SSP would change its treatment of calls to the extension in question is if the PBX parent de-registered.  Then, the SSP would provide appropriate "endpoint not available" treatment to ALL associated DIDs.
 
-Jack


>>> "Tyler Parkin" <tyler@foxfam.com> 2/9/2010 11:24 >>>
The other issue with this is that when Alice unplugs her phone at #901 the
PBX at that loc needs to be able to de-register her number.  I'm pretty sure
de-registering a single number that was previously registered with a
bulk-register request was shot down.


--------------------------------------------------------
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.
-------------------------------------------------------- --=__PartD1FBE629.0__=-- From adam@nostrum.com Tue Feb 9 10:39: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 E510D3A6858 for ; Tue, 9 Feb 2010 10:39: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, 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 x1dRVSXYLnzn for ; Tue, 9 Feb 2010 10: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 8CD5B3A695E for ; Tue, 9 Feb 2010 10:39:29 -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 o19IeYfG016679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Feb 2010 12:40:35 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B71AC22.3040805@nostrum.com> Date: Tue, 09 Feb 2010 12:40: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: "martini@ietf.org" Content-Type: multipart/alternative; boundary="------------090100080601060201090309" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Subject: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 09 Feb 2010 18:39:31 -0000 This is a multi-part message in MIME format. --------------090100080601060201090309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On today's call (and in his earlier email http://www.ietf.org/mail-archive/web/martini/current/msg00624.html), Dean raised an issue regarding the ability to indicate the DID numbers that the REGISTER corresponds to. There have been other concerns about this behavior (e.g. Tyler Parkin's message on Feb 5:http://www.ietf.org/mail-archive/web/martini/current/msg00582.html). Dean has started a thread on the semantics of this kind of registration, and a healthy dialog on the need for this property has begun. Some of the issues that people find objectionable may relate to the means that people might express this kind of thing syntactically. ISTM that this kind of information, if we include it, goes along with the Contact URI. In particular, you can define a syntax like: Contact: Which would mean "the range of 5 numbers starting with +12143290500, and the range of 30 numbers starting with +12143290440". I'm personally of two minds about this. I think for the scenarios Richard Shockey has been describing -- "buy a PBX at CostCo, bring it to the office, and plug it in" -- this is perfectly tractable. Those are very small PBXes, and they won't have a ludicrous number of extensions. The list of ranges in the "range" parameter stays reasonable. On the other hand, we have requirements the the MARTINI mechanism scale up to very, very large PBXes. In these circumstances, the list of ranges may become cumbersome. I agree with Dean that we've experienced pain with implicit operations in SIP in the past, and have a mild bias towards making as much explicit as is possible. If we could settle on a reasonable means to do so, I think we'll all be happier in the long run if we figure out a way to make this explicit. /a --------------090100080601060201090309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On today's call (and in his earlier email http://www.ietf.org/mail-archive/web/martini/current/msg00624.html), Dean raised an issue regarding the ability to indicate the DID numbers that the REGISTER corresponds to. There have been other concerns about this behavior (e.g. Tyler Parkin's message on Feb 5:http://www.ietf.org/mail-archive/web/martini/current/msg00582.html).

Dean has started a thread on the semantics of this kind of registration, and a healthy dialog on the need for this property has begun. Some of the issues that people find objectionable may relate to the means that people might express this kind of thing syntactically.

ISTM that this kind of information, if we include it, goes along with the Contact URI. In particular, you can define a syntax like:

   Contact: <sip:@198.51.100.3:5060;bnc;range=+12143290500;5,+12143290440;30>
Which would mean "the range of 5 numbers starting with +12143290500, and the range of 30 numbers starting with +12143290440".

I'm personally of two minds about this. I think for the scenarios Richard Shockey has been describing -- "buy a PBX at CostCo, bring it to the office, and plug it in" -- this is perfectly tractable. Those are very small PBXes, and they won't have a ludicrous number of extensions. The list of ranges in the "range" parameter stays reasonable.

On the other hand, we have requirements the the MARTINI mechanism scale up to very, very large PBXes. In these circumstances, the list of ranges may become cumbersome.

I agree with Dean that we've experienced pain with implicit operations in SIP in the past, and have a mild bias towards making as much explicit as is possible. If we could settle on a reasonable means to do so, I think we'll all be happier in the long run if we figure out a way to make this explicit.

/a
--------------090100080601060201090309-- From dean.willis@softarmor.com Tue Feb 9 11:01: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 0AF4F28C275 for ; Tue, 9 Feb 2010 11:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqueoIAc+okb for ; Tue, 9 Feb 2010 11:01:40 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id F241928C241 for ; Tue, 9 Feb 2010 11:01:32 -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 o19J2ZF1006429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2010 13:02:37 -0600 Message-Id: From: Dean Willis To: Jack Burton In-Reply-To: <4B7144AD.6D98.00CB.0@cablevision.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, 9 Feb 2010 13:02:30 -0600 References: <4B7144AD.6D98.00CB.0@cablevision.com> X-Mailer: Apple Mail (2.936) Cc: MARTINI Subject: Re: [martini] Question on registration 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, 09 Feb 2010 19:01:41 -0000 On Feb 9, 2010, at 12:19 PM, Jack Burton wrote: > In other words, you propose to do away with "implicit" > registration? I do not think that is desirable. > > I expect that a PBX will register its parent AOR and when it sees > the 200 OK will imply registration for all associated DID number > endpoints, such that calls from those numbers will be processed by > the SSP. If credentials for the parent fail, then the SSP (and PBX) > would not consider it, nor any of the associated DID numbers, > registered. I would like to point out that in the entire 12+-year history of SIP at IETF, every time we've done something "implicit" we've shot ourselves in the foot. Of course, we're not good at learning from our mistakes. Otherwise asked: How does the SSP know which of the customer's PBXes a specific DID should be associated with right now? Does the customer have to call the SSP, pay a MACD fee, and then wait for the SPP to reprovision everytime a DID moves between PBXes? Why do we think that's a good model? Neutering a SIP extension in order to require and preserve the use of an obsolete business model makes little sense to me. -- Dean From md3135@att.com Tue Feb 9 11:10: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 66E6E3A73F6 for ; Tue, 9 Feb 2010 11:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF8K+O2EOLiq for ; Tue, 9 Feb 2010 11:10:12 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 700F43A68B4 for ; Tue, 9 Feb 2010 11:10:12 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-14.tower-161.messagelabs.com!1265742678!18377473!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 5581 invoked from network); 9 Feb 2010 19:11:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Feb 2010 19:11:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o19JBAGV022490 for ; Tue, 9 Feb 2010 14:11:10 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o19JB6Ga022433 for ; Tue, 9 Feb 2010 14:11:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 9 Feb 2010 14:11:13 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D2F@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Question on registration requirements Thread-Index: Acqpuu9IcMNeqiicRtewT4oR4aSLegAALZM4 From: "DOLLY, MARTIN C (ATTLABS)" To: , Cc: martini@ietf.org Subject: Re: [martini] Question on registration 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, 09 Feb 2010 19:10:13 -0000 Rm9yIHRoaXMgaW1wbGljaXQgd29ya3MsIGl0IHdvcmtzIHcvbyByZWdpc3RyYXRpb24uDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IG1hcnRpbmktYm91bmNlc0BpZXRmLm9y ZyA8bWFydGluaS1ib3VuY2VzQGlldGYub3JnPg0KVG86IEphY2sgQnVydG9uIDxqc2J1cnRvbkBj YWJsZXZpc2lvbi5jb20+DQpDYzogTUFSVElOSSA8bWFydGluaUBpZXRmLm9yZz4NClNlbnQ6IFR1 ZSBGZWIgMDkgMTQ6MDI6MzAgMjAxMA0KU3ViamVjdDogUmU6IFttYXJ0aW5pXSBRdWVzdGlvbiBv biByZWdpc3RyYXRpb24gcmVxdWlyZW1lbnRzDQoNCg0KT24gRmViIDksIDIwMTAsIGF0IDEyOjE5 IFBNLCBKYWNrIEJ1cnRvbiB3cm90ZToNCg0KPiBJbiBvdGhlciB3b3JkcywgeW91IHByb3Bvc2Ug dG8gZG8gYXdheSB3aXRoICJpbXBsaWNpdCIgIA0KPiByZWdpc3RyYXRpb24/ICBJIGRvIG5vdCB0 aGluayB0aGF0IGlzIGRlc2lyYWJsZS4NCj4NCj4gSSBleHBlY3QgdGhhdCBhIFBCWCB3aWxsIHJl Z2lzdGVyIGl0cyBwYXJlbnQgQU9SIGFuZCB3aGVuIGl0IHNlZXMgIA0KPiB0aGUgMjAwIE9LIHdp bGwgaW1wbHkgcmVnaXN0cmF0aW9uIGZvciBhbGwgYXNzb2NpYXRlZCBESUQgbnVtYmVyICANCj4g ZW5kcG9pbnRzLCBzdWNoIHRoYXQgY2FsbHMgZnJvbSB0aG9zZSBudW1iZXJzIHdpbGwgYmUgcHJv Y2Vzc2VkIGJ5ICANCj4gdGhlIFNTUC4gIElmIGNyZWRlbnRpYWxzIGZvciB0aGUgcGFyZW50IGZh aWwsIHRoZW4gdGhlIFNTUCAoYW5kIFBCWCkgIA0KPiB3b3VsZCBub3QgY29uc2lkZXIgaXQsIG5v ciBhbnkgb2YgdGhlIGFzc29jaWF0ZWQgRElEIG51bWJlcnMsICANCj4gcmVnaXN0ZXJlZC4NCg0K SSB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IGluIHRoZSBlbnRpcmUgMTIrLXllYXIgaGlz dG9yeSBvZiBTSVAgIA0KYXQgSUVURiwgZXZlcnkgdGltZSB3ZSd2ZSBkb25lIHNvbWV0aGluZyAi aW1wbGljaXQiIHdlJ3ZlIHNob3QgIA0Kb3Vyc2VsdmVzIGluIHRoZSBmb290Lg0KDQpPZiBjb3Vy c2UsIHdlJ3JlIG5vdCBnb29kIGF0IGxlYXJuaW5nIGZyb20gb3VyIG1pc3Rha2VzLg0KDQpPdGhl cndpc2UgYXNrZWQ6IEhvdyBkb2VzIHRoZSBTU1Aga25vdyB3aGljaCBvZiB0aGUgY3VzdG9tZXIn cyBQQlhlcyBhICANCnNwZWNpZmljIERJRCBzaG91bGQgYmUgYXNzb2NpYXRlZCB3aXRoIHJpZ2h0 IG5vdz8gRG9lcyB0aGUgY3VzdG9tZXIgIA0KaGF2ZSB0byBjYWxsIHRoZSBTU1AsIHBheSBhIE1B Q0QgZmVlLCBhbmQgdGhlbiB3YWl0IGZvciB0aGUgU1BQIHRvICANCnJlcHJvdmlzaW9uICBldmVy eXRpbWUgYSBESUQgbW92ZXMgYmV0d2VlbiBQQlhlcz8gV2h5IGRvIHdlIHRoaW5rICANCnRoYXQn cyBhIGdvb2QgbW9kZWw/IE5ldXRlcmluZyBhIFNJUCBleHRlbnNpb24gaW4gb3JkZXIgdG8gcmVx dWlyZSBhbmQgIA0KcHJlc2VydmUgdGhlIHVzZSBvZiBhbiBvYnNvbGV0ZSBidXNpbmVzcyBtb2Rl bCBtYWtlcyBsaXR0bGUgc2Vuc2UgdG8gbWUuDQoNCi0tDQpEZWFuDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFydGluaSBtYWlsaW5nIGxpc3QNCm1h cnRpbmlAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFy dGluaQ0K From dean.willis@softarmor.com Tue Feb 9 11:10: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 A242F3A70CD for ; Tue, 9 Feb 2010 11:10:24 -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 Q604K1jHEfkY for ; Tue, 9 Feb 2010 11:10:23 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B018E3A68B4 for ; Tue, 9 Feb 2010 11:10:23 -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 o19JBMpm006539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2010 13:11:23 -0600 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <4B71A999.30708@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, 9 Feb 2010 13:11:16 -0600 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> <4B71A999.30708@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 19:10:24 -0000 On Feb 9, 2010, at 12:29 PM, Adam Roach wrote: > This does get a bit into Richard's fragmentation issue, though. > After a small number of phone number moves, you end up with a set of > ranges that devolves almost into a complete enumeration of extensions. Almost, but not quite. Ranging vs. enumeration is a just an abbreviation technique. If there are even two consecutive numbers in the set ranging reduces the specification size relative to enumeration. However, there is no assurance that there will be even two consecutive numbers. Therefore whatever technique we use MUST work with a fully- enumerated request (the most degenerate case of Shockey fragmentation) if it allows explicit registration. This means that any solution that requires regurgitating a large Contact set in the response is probably a non-starter in UDP land. The reg-event model is certainly cleaner for finding out "what is currently registered?". However, allowing a registration to succeed even when that registration produces no AOR-to-contact (but was expected to) also makes no sense to me. It violates the principle of minimal surprise. It also requires a lot of other provisioning triggerwork for associating Contacts with AORs that we've traditionally handled with REGISTER. -- Dean From dean.willis@softarmor.com Tue Feb 9 11:14: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 0F6793A67F6 for ; Tue, 9 Feb 2010 11:14: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 47bZk7YLSOeJ for ; Tue, 9 Feb 2010 11:13:59 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1DA8728C0E1 for ; Tue, 9 Feb 2010 11:13:59 -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 o19JF2FN006571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2010 13:15:03 -0600 Message-Id: From: Dean Willis To: Jack Burton In-Reply-To: <4B7147C9.6D98.00CB.0@cablevision.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, 9 Feb 2010 13:14:56 -0600 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> <4B7147C9.6D98.00CB.0@cablevision.com> X-Mailer: Apple Mail (2.936) Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 19:14:04 -0000 On Feb 9, 2010, at 12:32 PM, Jack Burton wrote: > Tyler, > > The PBX would indeed de-register the phone when it is unplugged. > That is not the issue here. Registrations between phones and the > PBX are out of scope. > > To describe further: > > When the phone is unplugged, after some period the PBX de-registers > the phone and knows it is offline. If a call comes in destined for > the phone, the PBX would apply appropriate forwarding treatment for > an unavailable extension. The SSP considers the number implicitly > registered, and would continue to deliver calls to the PBX for that > number. It is up to the PBX to treat those calls appropriately. > > If another phone on the PBX wished to make a call using the outbound > number of the failed extension, such as in a multiple line > appearance situation, the SSP would process those calls as if > nothing happened. To the SSP, nothing did happen. > > The only time the SSP would change its treatment of calls to the > extension in question is if the PBX parent de-registered. Then, the > SSP would provide appropriate "endpoint not available" treatment to > ALL associated DIDs. > But what if the phone and/or DID moves from one PBX to another within the customer organization? A lot of our thinking here has relied on the unstated assumption that the customer only has a single PBX and that AORs (phone numbers) do not dynamically migrate between PBXes. If that's a part of our model, we need to clearly state that as an underlying assumption. I find this to be an overly-simplistic and not particularly interesting case. -- Dean From dean.willis@softarmor.com Tue Feb 9 11:16: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 4A49828C245 for ; Tue, 9 Feb 2010 11:16: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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJn10-zAbj8A for ; Tue, 9 Feb 2010 11:15:55 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8662E28C1FB for ; Tue, 9 Feb 2010 11:15:47 -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 o19JGfkJ006595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2010 13:16:42 -0600 Message-Id: From: Dean Willis To: "DOLLY, MARTIN C (ATTLABS)" In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D2F@gaalpa1msgusr7e.ugd.att.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, 9 Feb 2010 13:16:35 -0600 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D2F@gaalpa1msgusr7e.ugd.att.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Question on registration 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, 09 Feb 2010 19:16:04 -0000 On Feb 9, 2010, at 1:11 PM, DOLLY, MARTIN C (ATTLABS) wrote: > For this implicit works, it works w/o registration. Ok, great! Then we have success and can close MARTINI. We're done here folks, Martin says the problem has been solved ;-). -- Dean From richard@shockey.us Tue Feb 9 11:16: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 697423A67F6 for ; Tue, 9 Feb 2010 11:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 ga9ew459AMeS for ; Tue, 9 Feb 2010 11:16:45 -0800 (PST) Received: from outbound-mail-350.bluehost.com (outbound-mail-350.bluehost.com [66.147.249.11]) by core3.amsl.com (Postfix) with SMTP id EB6A63A6F19 for ; Tue, 9 Feb 2010 11:16:44 -0800 (PST) Received: (qmail 19033 invoked by uid 0); 9 Feb 2010 19:17:51 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 9 Feb 2010 19:17: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=Hr98UVgwAJ4MpqNJATzyW0oTfn4ppXJbhG/Ub8gVYkWB0Wfu5rojO5xwWHs1LJvi1Ri7POChF90rWspfYBJf4CM5udaxhB2OkuR29U6uuBhKYhPYKfcR7fSZNVqbxfxE; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nevap-0004Pb-Fu; Tue, 09 Feb 2010 12:17:51 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Jack Burton'" References: <4B7144AD.6D98.00CB.0@cablevision.com> In-Reply-To: Date: Tue, 9 Feb 2010 14:17:48 -0500 Message-ID: <005101caa9bc$91ae8580$b50b9080$@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: Acqpun7PuJMTVjrQSFOxpnKSsiY/MgAAaI4w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: 'MARTINI' Subject: Re: [martini] Question on registration 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, 09 Feb 2010 19:16:46 -0000 Oh Dean this is so out of scope here. We have already said that currently how the PBX knows what DID it uses is not the issue here that is a provisioning problem more suited to MARTINI - VODKA. We are not going to debate SSP business practices.. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, February 09, 2010 2:03 PM To: Jack Burton Cc: MARTINI Subject: Re: [martini] Question on registration requirements On Feb 9, 2010, at 12:19 PM, Jack Burton wrote: > In other words, you propose to do away with "implicit" > registration? I do not think that is desirable. > > I expect that a PBX will register its parent AOR and when it sees > the 200 OK will imply registration for all associated DID number > endpoints, such that calls from those numbers will be processed by > the SSP. If credentials for the parent fail, then the SSP (and PBX) > would not consider it, nor any of the associated DID numbers, > registered. I would like to point out that in the entire 12+-year history of SIP at IETF, every time we've done something "implicit" we've shot ourselves in the foot. Of course, we're not good at learning from our mistakes. Otherwise asked: How does the SSP know which of the customer's PBXes a specific DID should be associated with right now? Does the customer have to call the SSP, pay a MACD fee, and then wait for the SPP to reprovision everytime a DID moves between PBXes? Why do we think that's a good model? Neutering a SIP extension in order to require and preserve the use of an obsolete business model makes little sense to me. -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From tyler@foxfam.com Tue Feb 9 11:23: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 1A26F3A75A8 for ; Tue, 9 Feb 2010 11:23:30 -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.185, 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 3IEiZmmoeO35 for ; Tue, 9 Feb 2010 11:23:29 -0800 (PST) Received: from smtp03.atlngahp.sys.nuvox.net (smtp-out3.atlngahp.sys.nuvox.net [70.43.63.20]) by core3.amsl.com (Postfix) with ESMTP id A5DA73A742D for ; Tue, 9 Feb 2010 11:23:28 -0800 (PST) Received: from LT6KW7CD1 (fw-nat.it.nuvox.net [216.215.144.201]) by smtp03.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o19JOSka008117; Tue, 9 Feb 2010 14:24:28 -0500 Message-ID: <00f601caa9bd$7f9d9fb0$150610ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: "Jack Burton" , "MARTINI" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> <4B7147C9.6D98.00CB.0@cablevision.com> Date: Tue, 9 Feb 2010 14:24:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F3_01CAA993.96A17210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 19:23:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00F3_01CAA993.96A17210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was speaking of the registration between the PBX and the SSP, not the = phone and the PBX. =20 If the intention is to let a SSP's customer move phones between two = PBX's without incurring a MACD fee, then there has to be a way for the = old PBX to declare that it's no longer resposible for a number and the = new PBX to declare that it is so that calls route to the "correct" PBX = for (and avoid treatment on a PBX that was last used 6 weeks ago). I didn't really dive too far into what would happen when the old PBX = refreshes it's reg, or how it would split the range, etc. I'm pretty = the whole concept of roaming between PBX's is contrary to implicit reg. = I wasn't necessarily advocating it, as a SSP it makes me sick. =3D) = More for technical reasons than MACD fees. Tyler =20 ----- Original Message -----=20 From: Jack Burton=20 To: MARTINI=20 Sent: Tuesday, February 09, 2010 1:32 PM Subject: Re: [martini] DID Number Mobility and MARTINI Tyler, The PBX would indeed de-register the phone when it is unplugged. That = is not the issue here. Registrations between phones and the PBX are out = of scope. To describe further: When the phone is unplugged, after some period the PBX de-registers = the phone and knows it is offline. If a call comes in destined for the = phone, the PBX would apply appropriate forwarding treatment for an = unavailable extension. The SSP considers the number implicitly = registered, and would continue to deliver calls to the PBX for that = number. It is up to the PBX to treat those calls appropriately. If another phone on the PBX wished to make a call using the outbound = number of the failed extension, such as in a multiple line appearance = situation, the SSP would process those calls as if nothing happened. To = the SSP, nothing did happen. The only time the SSP would change its treatment of calls to the = extension in question is if the PBX parent de-registered. Then, the SSP = would provide appropriate "endpoint not available" treatment to ALL = associated DIDs. -Jack >>> "Tyler Parkin" 2/9/2010 11:24 >>> The other issue with this is that when Alice unplugs her phone at #901 = the=20 PBX at that loc needs to be able to de-register her number. I'm = pretty sure=20 de-registering a single number that was previously registered with a=20 bulk-register request was shot down. --------------------------------------------------------=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_00F3_01CAA993.96A17210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I was speaking of the registration between the = PBX and the=20 SSP, not the phone and the PBX. 
 
If the intention is to let a SSP's customer move = phones=20 between two PBX's without incurring a MACD fee, then there has to be a = way=20 for the old PBX to declare that it's no longer resposible for = a number=20 and the new PBX to declare that it is so that calls route to the = "correct" PBX=20 for (and avoid treatment on a PBX that was last used 6 weeks=20 ago).
 
I didn't really dive too far into what = would=20 happen when the old PBX refreshes it's reg, or how it would split = the=20 range, etc.  I'm pretty the whole concept of roaming between = PBX's is=20 contrary to implicit reg. 
 
I wasn't necessarily advocating it, as a SSP it = makes me=20 sick. =3D)  More for technical reasons than MACD fees.

Tyler 
 
----- Original Message -----
From:=20 Jack=20 Burton
To: MARTINI
Sent: Tuesday, February 09, = 2010 1:32=20 PM
Subject: Re: [martini] DID = Number=20 Mobility and MARTINI

Tyler,
 
The PBX would indeed de-register the phone when it is = unplugged. =20 That is not the issue here.  Registrations between phones and the = PBX are=20 out of scope.
 
To describe further:
 
When the phone is unplugged, after some period the PBX = de-registers the=20 phone and knows it is offline.  If a call comes in destined for = the=20 phone, the PBX would apply appropriate forwarding treatment for an = unavailable=20 extension.  The SSP considers the number implicitly registered, = and would=20 continue to deliver calls to the PBX for that number.  It is up = to the=20 PBX to treat those calls appropriately.
 
If another phone on the PBX wished to make a call using the = outbound=20 number of the failed extension, such as in a multiple line appearance=20 situation, the SSP would process those calls as if nothing = happened.  To=20 the SSP, nothing did happen.
 
The only time the SSP would change its treatment of calls to the=20 extension in question is if the PBX parent de-registered.  Then, = the SSP=20 would provide appropriate "endpoint not available" treatment to ALL = associated=20 DIDs.
 
-Jack


>>> "Tyler Parkin" <tyler@foxfam.com> = 2/9/2010=20 11:24 >>>
The other issue with this is that when Alice = unplugs her=20 phone at #901 the
PBX at that loc needs to be able to de-register = her=20 number.  I'm pretty sure
de-registering a single number that = was=20 previously registered with a
bulk-register request was shot=20 = down.


--------------------------------------------------= ------=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_00F3_01CAA993.96A17210-- From richard@shockey.us Tue Feb 9 11:41: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 A90B33A70CB for ; Tue, 9 Feb 2010 11:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.221, 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 CvdROyIsLzQt for ; Tue, 9 Feb 2010 11:41:04 -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 82BA33A6F65 for ; Tue, 9 Feb 2010 11:41:04 -0800 (PST) Received: (qmail 22533 invoked by uid 0); 9 Feb 2010 19:42:10 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy8.bluehost.com.bluehost.com with SMTP; 9 Feb 2010 19:42:10 -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:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=IoD0wezyma14qb2GoldPVD7r6VgLGMXAkg3IaQjmVphI1gFHuYdXRMkhIhPk2LI7JP3ovdgw1zgsmWtYiTJLr/9+xVpkicVuz8Xiyz4xYMUo0APShYBjhs1wOwBkbOND; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NevyL-0002N9-Td; Tue, 09 Feb 2010 12:42:10 -0700 From: "Richard Shockey" To: "'Adam Roach'" , References: <4B71AC22.3040805@nostrum.com> In-Reply-To: <4B71AC22.3040805@nostrum.com> Date: Tue, 9 Feb 2010 14:42:06 -0500 Message-ID: <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01CAA996.0E2477E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqpt2C0hKA7yMocQ32J/dn3/ZMbQwAB4C9Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 09 Feb 2010 19:41:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01CAA996.0E2477E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I just don't think that is in scope for now. It's a issue for a more specific set of requirements that I think we could deal with now. This is touching on the larger provisioning issue between PBX systems and SSP that could take much more time than the limited scope of MARTINI was designed to address. In addition A. the IETF isn't very good at provisioning issues (I could say some things about CUA Config) . B. there are lots of proprietary solutions out there that vendors use. Though the goal is laudable I just haven't seen the SSP-PBX vendors agree that the pain point are sufficient to try and standardize the solution for a comprehensive plug and play solution. 5 Yards at a time . From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Tuesday, February 09, 2010 1:41 PM To: martini@ietf.org Subject: [martini] Explicit DID indication in REGISTER On today's call (and in his earlier email http://www.ietf.org/mail-archive/web/martini/current/msg00624.html), Dean raised an issue regarding the ability to indicate the DID numbers that the REGISTER corresponds to. There have been other concerns about this behavior (e.g. Tyler Parkin's message on Feb 5:http://www.ietf.org/mail-archive/web/martini/current/msg00582.html). Dean has started a thread on the semantics of this kind of registration, and a healthy dialog on the need for this property has begun. Some of the issues that people find objectionable may relate to the means that people might express this kind of thing syntactically. ISTM that this kind of information, if we include it, goes along with the Contact URI. In particular, you can define a syntax like: Contact: Which would mean "the range of 5 numbers starting with +12143290500, and the range of 30 numbers starting with +12143290440". I'm personally of two minds about this. I think for the scenarios Richard Shockey has been describing -- "buy a PBX at CostCo, bring it to the office, and plug it in" -- this is perfectly tractable. Those are very small PBXes, and they won't have a ludicrous number of extensions. The list of ranges in the "range" parameter stays reasonable. On the other hand, we have requirements the the MARTINI mechanism scale up to very, very large PBXes. In these circumstances, the list of ranges may become cumbersome. I agree with Dean that we've experienced pain with implicit operations in SIP in the past, and have a mild bias towards making as much explicit as is possible. If we could settle on a reasonable means to do so, I think we'll all be happier in the long run if we figure out a way to make this explicit. /a ------=_NextPart_000_005F_01CAA996.0E2477E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just don’t think that is in scope for = now.

 

 It’s a issue for a more specific set of = requirements that I think we could deal with now.  This is touching on the = larger provisioning issue between PBX systems and SSP that could take much more = time than the limited scope of MARTINI was designed to = address.

 

 In addition A. the IETF isn’t very good at provisioning issues (I could say some things about CUA Config) . B. = there are lots of proprietary solutions out there that vendors use. Though the = goal is laudable I just haven’t seen the SSP-PBX vendors agree that the pain point = are sufficient to try and standardize the solution for a comprehensive plug = and play solution.

 

5 Yards at a time …

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Tuesday, February 09, 2010 1:41 PM
To: martini@ietf.org
Subject: [martini] Explicit DID indication in = REGISTER

 

On today's call (and = in his earlier email http://www.ietf.org/mail-archive/web/martini/current/msg00624.html= ), Dean raised an issue regarding the ability to indicate the DID numbers = that the REGISTER corresponds to. There have been other concerns about this = behavior (e.g. Tyler Parkin's message on Feb 5:http://www.ietf.org/mail-archive/web/martini/current/msg00582.html= ).

Dean has started a thread on the semantics of this kind of registration, = and a healthy dialog on the need for this property has begun. Some of the = issues that people find objectionable may relate to the means that people might = express this kind of thing syntactically.

ISTM that this kind of information, if we include it, goes along with = the Contact URI. In particular, you can define a syntax like:

   Contact: <sip:@198.51.100.3:5060;bnc;range=3D+12143290500;5,+121432904=
40;30>
 
 =
;

Which would mean "the range of 5 numbers = starting with +12143290500, and the range of 30 numbers starting with = +12143290440".

I'm personally of two minds about this. I think for the scenarios = Richard Shockey has been describing -- "buy a PBX at CostCo, bring it to = the office, and plug it in" -- this is perfectly tractable. Those are = very small PBXes, and they won't have a ludicrous number of extensions. The = list of ranges in the "range" parameter stays reasonable.

On the other hand, we have requirements the the MARTINI mechanism scale = up to very, very large PBXes. In these circumstances, the list of ranges may = become cumbersome.

I agree with Dean that we've experienced pain with implicit operations = in SIP in the past, and have a mild bias towards making as much explicit as is possible. If we could settle on a reasonable means to do so, I think = we'll all be happier in the long run if we figure out a way to make this = explicit.

/a

------=_NextPart_000_005F_01CAA996.0E2477E0-- From richard@shockey.us Tue Feb 9 11:47: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 13E763A75F2 for ; Tue, 9 Feb 2010 11:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 2Af2QUjL9-jz for ; Tue, 9 Feb 2010 11:47:46 -0800 (PST) Received: from outbound-mail-350.bluehost.com (outbound-mail-350.bluehost.com [66.147.249.11]) by core3.amsl.com (Postfix) with SMTP id F35B53A75F1 for ; Tue, 9 Feb 2010 11:47:43 -0800 (PST) Received: (qmail 18481 invoked by uid 0); 9 Feb 2010 19:48:51 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 9 Feb 2010 19:48: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=E0e+nNQ8lUZnTZEVAb89c6kqF1wS04pERgTWL9ch7ID3+83HWjcfXAlU0Yqif5Qw1rkr9ec7xgKZvUzyIJ0JInCq8XxXILXWpYuWIviHoGFFRfY/wCOKUYbTlrHE6w/E; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1New4p-0006Mg-53; Tue, 09 Feb 2010 12:48:51 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Jack Burton'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> <4B7147C9.6D98.00CB.0@cablevision.com> In-Reply-To: Date: Tue, 9 Feb 2010 14:48:48 -0500 Message-ID: <006301caa9c0$e61dfb60$b259f220$@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: AcqpvDRO35wBcP+SQgC8uRyO8HycjwAA9qzw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 19:47:59 -0000 You might think is overly simplistic but it is the vast majority of the market. http://www.census.gov/epcd/www/smallbus.html Look at the percentage of firms with under 99 employees > But what if the phone and/or DID moves from one PBX to another within the customer organization? RS> that is not our problem A lot of our thinking here has relied on the unstated assumption that the customer only has a single PBX and that AORs (phone numbers) do not dynamically migrate between PBXes. If that's a part of our model, we need to clearly state that as an underlying assumption. I find this to be an overly-simplistic and not particularly interesting case. RS> IMHO it is the underlying assumption. Think about your dentist's office. I've said this before the business case assumption here are typically the sub 24 concurrent session market. -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From dean.willis@softarmor.com Tue Feb 9 12:54: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 37C003A7497 for ; Tue, 9 Feb 2010 12:54:30 -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 VF-OXszM5WQh for ; Tue, 9 Feb 2010 12:54:29 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D74FC3A724C for ; Tue, 9 Feb 2010 12:54:28 -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 o19KtRHf007422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2010 14:55:29 -0600 Message-Id: From: Dean Willis To: Richard Shockey In-Reply-To: <005101caa9bc$91ae8580$b50b9080$@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, 9 Feb 2010 14:55:22 -0600 References: <4B7144AD.6D98.00CB.0@cablevision.com> <005101caa9bc$91ae8580$b50b9080$@us> X-Mailer: Apple Mail (2.936) Cc: 'MARTINI' Subject: Re: [martini] Question on registration 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, 09 Feb 2010 20:54:30 -0000 On Feb 9, 2010, at 1:17 PM, Richard Shockey wrote: > Oh Dean this is so out of scope here. We have already said that > currently > how the PBX knows what DID it uses is not the issue here that is a > provisioning problem more suited to MARTINI - VODKA. We are not > going to > debate SSP business practices.. I'm not suggesting that the PBX learn what DID it is using via MARTINI. That's either a provisioning problem or a basic SIP registration problem requiring no new work here. I'm suggesting that MARTINI is how a PBX can tell an SSP (and arguably intermediaries who care, like Hadriel's SBCs) about which PBX (from a potential pool of many) is currently expecting calls to/from a specific DID. This is NOT PROVISIONING. Our apparent inability to distinguish between dynamic registration and provisioning is probably why we've got such a miss-matched set of requirements and expectations for MARTINI. -- Dean From dean.willis@softarmor.com Tue Feb 9 13:03: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 4AE523A72F4 for ; Tue, 9 Feb 2010 13:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_35=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 42kfbw7Qw37y for ; Tue, 9 Feb 2010 13:03:22 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 63DEE28C0F7 for ; Tue, 9 Feb 2010 13:03:22 -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 o19L4H3V007505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2010 15:04:18 -0600 From: Dean Willis To: Tyler Parkin In-Reply-To: <00f601caa9bd$7f9d9fb0$150610ac@CORPORATE.VOX.NET> X-Priority: 3 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> <4B7147C9.6D98.00CB.0@cablevision.com> <00f601caa9bd$7f9d9fb0$150610ac@CORPORATE.VOX.NET> 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, 9 Feb 2010 15:04:11 -0600 X-Mailer: Apple Mail (2.936) Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 21:03:23 -0000 On Feb 9, 2010, at 1:24 PM, Tyler Parkin wrote: > I was speaking of the registration between the PBX and the SSP, not > the phone and the PBX. Me too. > > If the intention is to let a SSP's customer move phones between two > PBX's without incurring a MACD fee, then there has to be a way for > the old PBX to declare that it's no longer resposible for a number > and the new PBX to declare that it is so that calls route to the > "correct" PBX for (and avoid treatment on a PBX that was last used 6 > weeks ago). > Right; that's the question I'm asking. Is this in-scope or out of scope? > I didn't really dive too far into what would happen when the old PBX > refreshes it's reg, or how it would split the range, etc. That's the subject of Adam's last two drafts. > I'm pretty the whole concept of roaming between PBX's is contrary to > implicit reg. Indeed it is, which is exactly my point. If we need to allow roaming between PBXes, then we require a solution for explicit registration. If however we rely entirely on back-end provisioning systems (and all their inherent latencies and costs) then an implicit registration system may suffice. > > I wasn't necessarily advocating it, as a SSP it makes me sick. =) > More for technical reasons than MACD fees. > Can you elaborate on those technical reasons? Most of what we've heard so far from the old-school service providers is: We map a DID to a fixed trunk, and a trunk to a fixed PBX, and all we want is for VoIP to work just like we do it now except dynamically discover the IP address and port number of the fixed PBX. We still want to have a fixed DID<->trunk relationship even though the trunks are entirely virtual and happen over the Internet (and we're having to make up a bunch of stuff to make it look like a trunk, because that's all we know how to model). Really, all we are doing is replacing an ISDN line with a dynamically changing IP peering. That's not a technical reason for an architecture -- it's an excuse for not having one. What technical reasons (and neither inertia nor apathy qualify) are driving that decision? -- Dean From tyler@foxfam.com Tue Feb 9 13:23: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 577EF3A7497 for ; Tue, 9 Feb 2010 13:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 5ZiYAl0LwJkh for ; Tue, 9 Feb 2010 13:23:48 -0800 (PST) Received: from smtp04.atlngahp.sys.nuvox.net (smtp-out4.atlngahp.sys.nuvox.net [70.43.63.22]) by core3.amsl.com (Postfix) with ESMTP id 3795B3A6919 for ; Tue, 9 Feb 2010 13:23:48 -0800 (PST) Received: from LT6KW7CD1 (fw-nat.it.nuvox.net [216.215.144.201]) by smtp04.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o19LOjs3019207; Tue, 9 Feb 2010 16:24:45 -0500 Message-ID: <014001caa9ce$4d20c1f0$150610ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: "Richard Shockey" , "'Dean Willis'" , "'Jack Burton'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> <4B7147C9.6D98.00CB.0@cablevision.com> <006301caa9c0$e61dfb60$b259f220$@us> Date: Tue, 9 Feb 2010 16:24:45 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 21:23:49 -0000 Numbers lie =) If you look at the numbers, sure, <99 makes up a huge percentage of firms and locations. However, looking at the bigger picture, most companies over subscribe users to concurrent sessions, so a customer with 24 concurrent calls could actually have 50-75 users. A single PRI with 100 DID's is not uncommon. Second, looking at the numbers in the link below: 1-4 employees SOHO, probably not going to have a PBX 5-9 employees approaching the point where they might need a PBX, but the lower half will probably stick w/ their key system 10-99 Probably have a PBX and might even have or be interested in an IP PBX The numbers for this group indicate it's basically one location per firm 100-499 Probably have a PBX, probably looking for advanced features and probably interested in an IP PBX The numbers for this group indicate ~4 locations per firm Of total locations for firms with 10-499 employees, the multilocation firms (100-499 emps) make up ~20% of all locs 20% is a big number of an SMB target market, and reflects why L3VPN is our second best selling product. The % grows as you weed out the bottom half of firms near 10 users. ----- Original Message ----- From: "Richard Shockey" To: "'Dean Willis'" ; "'Jack Burton'" Cc: "'MARTINI'" Sent: Tuesday, February 09, 2010 2:48 PM Subject: Re: [martini] DID Number Mobility and MARTINI > > You might think is overly simplistic but it is the vast majority of the > market. > > http://www.census.gov/epcd/www/smallbus.html > > Look at the percentage of firms with under 99 employees > >> > > But what if the phone and/or DID moves from one PBX to another within > the customer organization? > > RS> that is not our problem > > A lot of our thinking here has relied on the unstated assumption that > the customer only has a single PBX and that AORs (phone numbers) do > not dynamically migrate between PBXes. If that's a part of our model, > we need to clearly state that as an underlying assumption. I find this > to be an overly-simplistic and not particularly interesting case. > > RS> IMHO it is the underlying assumption. Think about your dentist's > office. > I've said this before the business case assumption here are typically the > sub 24 concurrent session market. > -- > 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 adam@nostrum.com Tue Feb 9 13:41: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 3ADF13A7288 for ; Tue, 9 Feb 2010 13:41:23 -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.023, 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 LhSopwz9tsLm for ; Tue, 9 Feb 2010 13:41: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 6984B3A7249 for ; Tue, 9 Feb 2010 13:41:18 -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 o19LgKOQ036887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 15:42:22 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B71D6BB.4080304@nostrum.com> Date: Tue, 09 Feb 2010 15:42: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: Richard Shockey References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us> In-Reply-To: <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us> Content-Type: multipart/alternative; boundary="------------010907090801060406040308" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 09 Feb 2010 21:41:23 -0000 This is a multi-part message in MIME format. --------------010907090801060406040308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/9/10 13:42, Feb 9, Richard Shockey wrote: > > In addition A. the IETF isn't very good at provisioning issues (I > could say some things about CUA Config) . B. there are lots of > proprietary solutions out there that vendors use. Though the goal is > laudable I just haven't seen the SSP-PBX vendors agree that the pain > point are sufficient to try and standardize the solution for a > comprehensive plug and play solution. > We're certainly in agreement that this mechanism isn't the way to provisioning. But this issue is about much more than provisioning. I agree that some unrelated provisioning action is required to let each side know what extensions are associated with a customer. On one end, this is about intermediary behavior. On the other, it is about terminal mobility between PBXes. /a --------------010907090801060406040308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/9/10 13:42, Feb 9, Richard Shockey wrote:

In addition A. the IETF isn’t very good at provisioning issues (I could say some things about CUA Config) . B. there are lots of proprietary solutions out there that vendors use. Though the goal is laudable I just haven’t seen the SSP-PBX vendors agree that the pain point are sufficient to try and standardize the solution for a comprehensive plug and play solution.


We're certainly in agreement that this mechanism isn't the way to provisioning.

But this issue is about much more than provisioning. I agree that some unrelated provisioning action is required to let each side know what extensions are associated with a customer.

On one end, this is about intermediary behavior. On the other, it is about terminal mobility between PBXes.

/a
--------------010907090801060406040308-- From jsburton@cablevision.com Tue Feb 9 13:43: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 7FB6A3A7288 for ; Tue, 9 Feb 2010 13:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.988 X-Spam-Level: X-Spam-Status: No, score=0.988 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MANGLED_PRIOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcp-7olt8U4N for ; Tue, 9 Feb 2010 13:43:13 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id E0A213A7249 for ; Tue, 9 Feb 2010 13:43:12 -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 o19LiJcv013947 for ; Tue, 9 Feb 2010 16:44:20 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o19LiJcv013947 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1265751860; bh=ug4DrYGi1vStyFnzA7tuEqOo0DDr3V20FIE68fP 7c14=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=AMELh2hLWIxaiPS4voxiuqf4SeMPLQ00tfJUJ GFROB8nh9NU4fsbhEMqayPKaJjM5r/Mg7RHqcJMisXFeSPDtZEXfSnObXsCNIfnkLBU ycqmmUfRptoKhBV41Q2YrxgbSb0mniG1Lo3QZpIGCpW9w3kZ9OkAZrPMl8EuGHlX8j0 = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Tue, 09 Feb 2010 16:44:19 -0500 Message-Id: <4B7174AA.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Tue, 09 Feb 2010 16:43:54 -0500 From: "Jack Burton" To: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> <4B7147C9.6D98.00CB.0@cablevision.com> <006301caa9c0$e61dfb60$b259f220$@us> <014001caa9ce$4d20c1f0$150610ac@CORPORATE.VOX.NET> In-Reply-To: <014001caa9ce$4d20c1f0$150610ac@CORPORATE.VOX.NET> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part8FA5B80A.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] DID Number Mobility and 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, 09 Feb 2010 21:43:14 -0000 --=__Part8FA5B80A.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit OK, now we're talking about the problem of multiple PBXs within a single customer. In my opinion... 1) Few organizations have multiple PBXs that share DID ranges. 2) Multiple PBXs have their own number ranges typically. They would be treated as different locations by the SSP. It is unusual for a firm to move extensions around multiple PBXs without changing DIDs when they do it. (DIDs usually stay with the PBX) 3) If a customer must move their DID to a different PBX, the SSP can make this change within the limits of the GIN proposal. Why does this rare operation have to be touch-free by the SSP? I think that it is very reasonable for the SSP to know when a customer moves a DID to a new PBX location - - if for nothing else but E911 reasons. 4) Think of how this is done today, with PRI or Analog trunks to each PBX. In every case, moving a DID from one PBX to another requires SP action. It seems to me that the efforts to avoid MAC charges for this very rare operation may be excessive. -Jack >>> "Tyler Parkin" 2/9/2010 14:24 >>> Numbers lie =) If you look at the numbers, sure, <99 makes up a huge percentage of firms and locations. However, looking at the bigger picture, most companies over subscribe users to concurrent sessions, so a customer with 24 concurrent calls could actually have 50-75 users. A single PRI with 100 DID's is not uncommon. Second, looking at the numbers in the link below: 1-4 employees SOHO, probably not going to have a PBX 5-9 employees approaching the point where they might need a PBX, but the lower half will probably stick w/ their key system 10-99 Probably have a PBX and might even have or be interested in an IP PBX The numbers for this group indicate it's basically one location per firm 100-499 Probably have a PBX, probably looking for advanced features and probably interested in an IP PBX The numbers for this group indicate ~4 locations per firm Of total locations for firms with 10-499 employees, the multilocation firms (100-499 emps) make up ~20% of all locs 20% is a big number of an SMB target market, and reflects why L3VPN is our second best selling product. The % grows as you weed out the bottom half of firms near 10 users. ----- Original Message ----- From: "Richard Shockey" To: "'Dean Willis'" ; "'Jack Burton'" Cc: "'MARTINI'" Sent: Tuesday, February 09, 2010 2:48 PM Subject: Re: [martini] DID Number Mobility and MARTINI > > You might think is overly simplistic but it is the vast majority of the > market. > > http://www.census.gov/epcd/www/smallbus.html > > Look at the percentage of firms with under 99 employees > >> > > But what if the phone and/or DID moves from one PBX to another within > the customer organization? > > RS> that is not our problem > > A lot of our thinking here has relied on the unstated assumption that > the customer only has a single PBX and that AORs (phone numbers) do > not dynamically migrate between PBXes. If that's a part of our model, > we need to clearly state that as an underlying assumption. I find this > to be an overly-simplistic and not particularly interesting case. > > RS> IMHO it is the underlying assumption. Think about your dentist's > office. > I've said this before the business case assumption here are typically the > sub 24 concurrent session market. > -- > 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 -------------------------------------------------------- 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. -------------------------------------------------------- --=__Part8FA5B80A.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
OK, now we're talking about the problem of multiple PBXs within a sing= le customer.
 
In my opinion...
 
1)  Few organizations have multiple PBXs that share DID ranges.
 
2)  Multiple PBXs have their own number ranges typically.  T= hey would be treated as different locations by the SSP.  It is unusual= for a firm to move extensions around multiple PBXs without changing DIDs w= hen they do it.  (DIDs usually stay with the PBX)
 
3)  If a customer must move their DID to a different PBX, the SSP= can make this change within the limits of the GIN proposal.  Why does= this rare operation have to be touch-free by the SSP?  I think that i= t is very reasonable for the SSP to know when a customer moves a DID to a n= ew PBX location - - if for nothing else but E911 reasons. 
 
4)  Think of how this is done today, with PRI or Analog trunks to= each PBX.  In every case, moving a DID from one PBX to another requir= es SP action. 
 
It seems to me that the efforts to avoid MAC charges for this very rar= e operation may be excessive.
 
-Jack

>>> "Tyler Parkin" <tyler@foxfam.com> 2/9/2010 14:2= 4 >>>
Numbers lie =3D)

If you look at the numbers, sure,= <99 makes up a huge percentage of firms
and locations.  Howeve= r, looking at the bigger picture, most companies over
subscribe users t= o concurrent sessions, so a customer with 24 concurrent
calls could act= ually have 50-75 users.  A single PRI with 100 DID's is not
uncomm= on.

Second, looking at the numbers in the link below:

1-4 emp= loyees
    SOHO, probably not going to have a PBX
5-9 = employees
    approaching the point where they might need= a PBX, but the lower half
will probably stick w/ their key system
1= 0-99
    Probably have a PBX and might even have or be in= terested in an IP PBX
    The numbers for this group indi= cate it's basically one location per firm
100-499
    = Probably have a PBX, probably looking for advanced features and probably interested in an IP PBX
    The numbers for this group = indicate ~4 locations per firm

Of total locations for firms with 10-= 499 employees, the multilocation firms
(100-499 emps) make up ~20% of a= ll locs

20% is a big number of an SMB target market, and reflects wh= y L3VPN is our
second best selling product.  The % grows as you we= ed out the bottom half of
firms near 10 users.


----- Origina= l Message -----
From: "Richard Shockey" <richard@shockey.us>
T= o: "'Dean Willis'" <dean.willis@softarmor.com>; "'Jack Burton'"
&= lt;jsburton@cablevision.com>
Cc: "'MARTINI'" <martini@ietf.org>=
Sent: Tuesday, February 09, 2010 2:48 PM
Subject: Re: [martini] DID = Number Mobility and MARTINI


>
> You might think is over= ly simplistic but it is the vast majority of the
> market.
>> http://www.c= ensus.gov/epcd/www/smallbus.html
>
> Look at the percentage= of firms with under 99 employees
>
>>
>
> But w= hat if the phone and/or DID moves from one PBX to another within
> th= e customer organization?
>
> RS> that is not our problem
= >
> A lot of our thinking here has relied on the unstated assumpti= on that
> the customer only has a single PBX and that AORs (phone num= bers)  do
> not dynamically migrate between PBXes. If that's a p= art of our model,
> we need to clearly state that as an underlying as= sumption. I find this
> to be an overly-simplistic and not particular= ly interesting case.
>
> RS> IMHO it is the underlying assum= ption. Think about your dentist's
> office.
> I've said this b= efore the business case assumption here are typically the
> sub 24 co= ncurrent session market.
> --
> 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


--------------------------------------------------------
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.
-------------------------------------------------------- --=__Part8FA5B80A.0__=-- From dean.willis@softarmor.com Tue Feb 9 16: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 9A60428C19A for ; Tue, 9 Feb 2010 16:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_00=-2.599, MANGLED_PRIOR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToMUBW0+Me8S for ; Tue, 9 Feb 2010 16:17:36 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D6D9D28C18F for ; Tue, 9 Feb 2010 16:17:35 -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 o1A0Idtx008701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Feb 2010 18:18:40 -0600 Message-Id: From: Dean Willis To: "Jack Burton" In-Reply-To: <4B7174AA.6D98.00CB.0@cablevision.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, 9 Feb 2010 18:18:34 -0600 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET> <4B7147C9.6D98.00CB.0@cablevision.com> <006301caa9c0$e61dfb60$b259f220$@us> <014001caa9ce$4d20c1f0$150610ac@CORPORATE.VOX.NET> <4B7174AA.6D98.00CB.0@cablevision.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 00:17:36 -0000 On Feb 9, 2010, at 3:43 PM, Jack Burton wrote: > > > 4) Think of how this is done today, with PRI or Analog trunks to > each PBX. In every case, moving a DID from one PBX to another > requires SP action. > Yeah, and that's why we came up with SIP. A few years back, one in ten people died young of Polio. That's why Salk invented a vaccine. SIP might not be quite that important, but "we've ALWAYS made it hard for the customer" is a really bad reason to perpetuate a design's physical limitations even after those physical limitations have ceased to be relevant,. -- dean From john.elwell@siemens-enterprise.com Wed Feb 10 00:31: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 8180728C136 for ; Wed, 10 Feb 2010 00:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoqWbiDII7Op for ; Wed, 10 Feb 2010 00:31:51 -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 B9CE728C0FA for ; Wed, 10 Feb 2010 00:31:50 -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-838628; Wed, 10 Feb 2010 09:32:58 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 78C0523F0278; Wed, 10 Feb 2010 09:32:58 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Feb 2010 09:32:58 +0100 From: "Elwell, John" To: Dean Willis , MARTINI Date: Wed, 10 Feb 2010 09:32:56 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqpn7BnJ2OjkcPxRkmhHbSvctsj+AAiJrmw Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> In-Reply-To: <1E8E2700-18FA-4DC1-8147-18EC9423C266@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] DID Number Mobility and 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: Wed, 10 Feb 2010 08:31:54 -0000 Dean, It is certainly the case that Alice should be able to move location and hav= e things "just work" without having to contact the service desk. Let's assu= me Alice's device normally registers with the PBX at site A, and that the P= BX registers with the SSP to receive calls to Alice's E.164 number. Alice m= oves to site B, but Alice's device (the same one or a different one) still = registers with the PBX at site A. If there are issues with being able to re= gister with a PBX on site A from a LAN on site B, that is outside the scope= of MARTINI work. Of course, calls from the SSP to Alice, on arrival at PBX-A, if the preferr= ed device at that time is on site B, need to be routed to that device on si= te B. How this is achieved might also be an issue, put presumably would be = based on a path established at registration time. I think this is also outs= ide the scope of MARTINI. What Dean proposes is that we support the nomadic user by moving the regist= rar for Alice's AOR from PBX-A to PBX-B. This would be a much bigger proble= m that just telling the SSP that Alice's E.164 number is now served by PBX-= B instead of PBX-A. You also need to arrange for calls from UAs within the = PBXs concerned to go to PBX-B instead of PBX-A for handling. Also all Alice= 's preferences known to the registrar at PBX-A need to be moved to PBX-B (e= .g., conditions for calls to be redirected to voicemail). Also, what if Ali= ce still has other devices that stay on site A? How does it help by moving = the registrar to PBX-B. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 09 February 2010 15:51 > To: MARTINI > Subject: [martini] DID Number Mobility and MARTINI >=20 >=20 > One of my understanding of goals for corporate VoIP systems was the =20 > ability to move a user from one PBX to another PBX without having to =20 > pay a service provider MACD (move, add, change, delete) fee. >=20 > In fact, it was my demonstrating this very capability to MCI's chief =20 > engineering officer back in 1999 that got the first SIP=20 > project there =20 > funded. >=20 > Let's talk through a use case: >=20 > Assume Alice is working today in our building at #901=20 > I-street, which =20 > has a PBX. Her DID number is routed to that PBX. Over lunch, her =20 > office gets moved down the street to the lab at #400 I-Street. >=20 > Three cases might apply: >=20 > 1) Alice moves her phone and plugs it in and it "just works",=20 > because =20 > the phone dynamically registers with the new PBX, which then =20 > dynamically registers with the SSP proxy for that DID number, =20 > effectively moving the binding from #901's PBX to #400's PBX. >=20 > 2) Alice moves her phone to #400, waits until after lunch,=20 > then calls =20 > the phone support people, who manually reprovision her onto the #400 =20 > PBX. This PBX then re-registers with SSP, and her number starts =20 > working again. >=20 > 3) Alice moves her pone to #400, and waits until after lunch to talk =20 > to the phone support people, who reprovision her on the PBXes=20 > and then =20 > call the SSP support people to move her DID number from=20 > #901's "trunk" =20 > to 400's "trunk". Sometime, tomorrow, her phone line starts working =20 > AND we get a $50 bill for the "change fee" from the SSP. >=20 >=20 > Our original design goal favored #1, we might have accepted=20 > #2, and #3 =20 > was what we were most aggressively trying to avoid. >=20 >=20 > Yet my understanding of the consensus of MARTINI is that #3 is the =20 > desired outcome. This is the difference, if I understand it, between =20 > draft-gin's "()" proposal for implicit registration and the "XXXX" =20 > proposal for explicit registration I made on-list. >=20 > Why are we pushing ourselves ten years backwards in operational =20 > advances? >=20 > And what happens when Alice has a WiFi phone and moves back=20 > and forth =20 > from #901 to #400 several times a day? Does she just go without a =20 > phone, or do we pay a $50 change fee each time? >=20 >=20 >=20 > -- > Dean >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Wed Feb 10 00:43: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 70A7528C156 for ; Wed, 10 Feb 2010 00:43:21 -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 PY8BpojingsR for ; Wed, 10 Feb 2010 00:43:20 -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 4C11D28C14F for ; Wed, 10 Feb 2010 00:43:19 -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-838798; Wed, 10 Feb 2010 09:44:28 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 792AF1EB82AB; Wed, 10 Feb 2010 09:44:28 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 10 Feb 2010 09:44:28 +0100 From: "Elwell, John" To: Dean Willis , Richard Shockey Date: Wed, 10 Feb 2010 09:44:26 +0100 Thread-Topic: [martini] Question on registration requirements Thread-Index: Acqpyj0Vv1Rn/KdaQJOEBUgIXGxSrQAYplPA Message-ID: References: <4B7144AD.6D98.00CB.0@cablevision.com> <005101caa9bc$91ae8580$b50b9080$@us> 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' Subject: Re: [martini] Question on registration 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, 10 Feb 2010 08:43:21 -0000 Dean, I have already answered this on the other thread. The nomadic user moving b= etween two PBXs does not need to be dealt with through the MARTINI registra= tion process. I agree with what Jack, Richard, Bruno and others have alread= y said - the PBX needs to be able to register implicitly for those E.164 nu= mbers that have been provisioned. The reg-event package is good enough for = determining what actually is registered. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 09 February 2010 20:55 > To: Richard Shockey > Cc: 'MARTINI' > Subject: Re: [martini] Question on registration requirements >=20 >=20 > On Feb 9, 2010, at 1:17 PM, Richard Shockey wrote: >=20 > > Oh Dean this is so out of scope here. We have already said that =20 > > currently > > how the PBX knows what DID it uses is not the issue here that is a > > provisioning problem more suited to MARTINI - VODKA. We are not =20 > > going to > > debate SSP business practices.. >=20 > I'm not suggesting that the PBX learn what DID it is using via =20 > MARTINI. That's either a provisioning problem or a basic SIP =20 > registration problem requiring no new work here. >=20 > I'm suggesting that MARTINI is how a PBX can tell an SSP (and=20 > arguably =20 > intermediaries who care, like Hadriel's SBCs) about which PBX=20 > (from a =20 > potential pool of many) is currently expecting calls to/from a =20 > specific DID. >=20 > This is NOT PROVISIONING. Our apparent inability to distinguish =20 > between dynamic registration and provisioning is probably why we've =20 > got such a miss-matched set of requirements and expectations for =20 > MARTINI. >=20 > -- > Dean >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Wed Feb 10 00:51: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 2C2C73A7684 for ; Wed, 10 Feb 2010 00:51:49 -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.048, 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 hhbZ9kwK96oN for ; Wed, 10 Feb 2010 00:51:44 -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 9367E3A7637 for ; Wed, 10 Feb 2010 00:51:44 -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-839194; Wed, 10 Feb 2010 09:52:53 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 772A823F0278; Wed, 10 Feb 2010 09:52:53 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Feb 2010 09:52:53 +0100 From: "Elwell, John" To: Adam Roach , Richard Shockey Date: Wed, 10 Feb 2010 09:52:52 +0100 Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: Acqp0Mp7zOGhKo1URzGsXdKagW+QcwAXOKZw Message-ID: References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us> <4B71D6BB.4080304@nostrum.com> In-Reply-To: <4B71D6BB.4080304@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_A444A0F8084434499206E78C106220CAB92FE83FMCHP058Aglobala_" MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Feb 2010 08:51:49 -0000 --_000_A444A0F8084434499206E78C106220CAB92FE83FMCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, I don't believe this is about terminal mobility between PBXs, as I have det= ailed in another thread. Although inter-PBX mobility is an issue for which = we don't necessarily have all the answers at present, I don' think dynamic = changing of the set of AORs registered through MARTINI is a necessary and s= ufficient solution. If we were to take on board inter-PBX mobility, we woul= d also have to take on board inter-PBX internal enterprise traffic, which w= ould be an explosion of the scope of MARTINI. John ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 09 February 2010 21:42 To: Richard Shockey Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER On 2/9/10 13:42, Feb 9, Richard Shockey wrote: In addition A. the IETF isn't very good at provisioning issues (I could say= some things about CUA Config) . B. there are lots of proprietary solutions= out there that vendors use. Though the goal is laudable I just haven't see= n the SSP-PBX vendors agree that the pain point are sufficient to try and s= tandardize the solution for a comprehensive plug and play solution. We're certainly in agreement that this mechanism isn't the way to provision= ing. But this issue is about much more than provisioning. I agree that some unre= lated provisioning action is required to let each side know what extensions= are associated with a customer. On one end, this is about intermediary behavior. On the other, it is about = terminal mobility between PBXes. /a --_000_A444A0F8084434499206E78C106220CAB92FE83FMCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adam,
 
I don't believe this is about terminal mobility be= tween=20 PBXs, as I have detailed in another thread. Although inter-PBX mobility is = an=20 issue for which we don't necessarily have all the answers at present, I don= '=20 think dynamic changing of the set of AORs registered through MARTINI is a=20 necessary and sufficient solution. If we were to take on board inter-PBX=20 mobility, we would also have to take on board inter-PBX internal enterprise= =20 traffic, which would be an explosion of the scope of=20 MARTINI.
 
John
 

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: 09 February 2010 21:42
To: Richard=20 Shockey
Cc: martini@ietf.org
Subject: Re: [martini]=20 Explicit DID indication in REGISTER

On 2/9/10 13:42, Feb 9, Richard Shockey wrote:=20

In=20 addition A. the IETF isn’t very good at provisioning issues (I co= uld say=20 some things about CUA Config) . B. there are lots of proprietary soluti= ons=20 out there that vendors use. Though the goal is laudable I just haven= 217;t seen=20 the SSP-PBX vendors agree that the pain point are sufficient to try and= =20 standardize the solution for a comprehensive plug and play=20 solution.


We're certainly in agreement= that=20 this mechanism isn't the way to provisioning.

But this issue is ab= out=20 much more than provisioning. I agree that some unrelated provisioning act= ion=20 is required to let each side know what extensions are associated with a=20 customer.

On one end, this is about intermediary behavior. On the= =20 other, it is about terminal mobility between=20 PBXes.

/a
--_000_A444A0F8084434499206E78C106220CAB92FE83FMCHP058Aglobala_-- From john.elwell@siemens-enterprise.com Wed Feb 10 02:18: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 4200E3A76A8 for ; Wed, 10 Feb 2010 02:18:39 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKKyDOOuC19E for ; Wed, 10 Feb 2010 02:18:38 -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 9470E3A76A4 for ; Wed, 10 Feb 2010 02:18:37 -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-840378; Wed, 10 Feb 2010 11:19:46 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B6CDC1EB82AB; Wed, 10 Feb 2010 11:19:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Feb 2010 11:19:46 +0100 From: "Elwell, John" To: "martini@ietf.org" , Hadriel Kaplan Date: Wed, 10 Feb 2010 11:19:44 +0100 Thread-Topic: Integration of problem-statement material into requirements draft Thread-Index: AcqqOpDqF4EGVcmgQHGObFCNFohJHw== 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] Integration of problem-statement material into requirements draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Feb 2010 10:18:39 -0000 As discussed at the virtual meeting yesterday, there seems to be an intenti= on to integrate relevant material from draft-kaplan-martini-mixing-problems= -00 into the requirements draft, so that we only need the one deliverable t= o cover both aspects. I have reviewed the mixing-problems document, and these are my proposals fo= r the various sections. Section 1 (Introduction). Section 1 of the martini-reqs contains text close= ly aligned with some of the text in the MARTINI charter, so I don't particu= larly want to change that. I don't think it is necessary to reference the S= IP Forum SIPconnect or 3GPP/ETSI specifications and their issues in section= 1. So I don't think we need anything from section 1 of mixing-problems. Section 2 (Definitions). The need for additional definitions will depend on= what other text we import. Section 3 (Background on current mechanisms). Basically we should incorpora= te this, because it is background needed to understand the issues in sectio= ns 4 onwards. This would include explicit references to the ETSI/3GPP mecha= nism, as an example of current techniques. Section 4.1 (No Explicit Indicator). Include. Section 4.2 (Undefined behaviour on PAU mismatch). Include. Section 4.3 (REGISTER response growth). I am not sure we should include thi= s, because we never agreed a requirement that the mechanism must work over = UDP. Section 4.4 (Illegal wildcarding syntax). Include. Section 5.1 (Loss of target information). Include. Section 5.2 (Request-URI vs. loose-route mismatches). Include. Section 5.3 (Request-URI mis-routing). Include. Section 6.1 (Authorization policy mismatches). I am not sure about this. Th= e problem is that the SSP is being too strict, i.e., it doesn't permit the = Contact URI to identify the calling UA (the Route header field, on the othe= r hand, might bear some resemblance to the registered contact URI). I guess= MARTINI deliverables can at least make statements about practices in this = area, but MARTINI will not provide a solution that allows such authorizatio= n policies to work. My inclination, nevertheless, is to include this sectio= n. Section 6.2 (P-Asserted-Identity URI mismatches). This is a policy issue, a= nd MARTINI will not provide a solution that allows such a policy to work in= all cases. So is this really part of the problem statement? If not, I woul= d suggest we could omit this. Section 6.3 (Trust domain mismatches for privacy/identity). Is this strayin= g outside the scope of MARTINI? The issue applies even if RFC 3263 is used,= rather than registration, between the PBX and the SSP. I would suggest we = could omit this. So in summary, I think we can import most of sections 3, 4 and 5 of the mix= ing-problems draft into the requirements draft, and perhaps some of section= 6 too. I would propose they all go into a new section, prior to the Requir= ements section. Please comment. John From dean.willis@softarmor.com Wed Feb 10 10: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 5294528C224 for ; Wed, 10 Feb 2010 10:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 npmQcxSTGJjw for ; Wed, 10 Feb 2010 10:25:34 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5D8923A777C for ; Wed, 10 Feb 2010 10:25:34 -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 o1AIQhI0016496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 12:26:45 -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, 10 Feb 2010 12:26:38 -0600 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 18:25:35 -0000 On Feb 10, 2010, at 2:32 AM, Elwell, John wrote: > Dean, > > It is certainly the case that Alice should be able to move location > and have things "just work" without having to contact the service > desk. Let's assume Alice's device normally registers with the PBX at > site A, and that the PBX registers with the SSP to receive calls to > Alice's E.164 number. Alice moves to site B, but Alice's device (the > same one or a different one) still registers with the PBX at site A. > If there are issues with being able to register with a PBX on site A > from a LAN on site B, that is outside the scope of MARTINI work. Since Site A and Site B each have their own firewall/NATs between them and the Internet, it's not going to work; we'd end up with inside-out Outbound. However, they do share an authentication database. > > Of course, calls from the SSP to Alice, on arrival at PBX-A, if the > preferred device at that time is on site B, need to be routed to > that device on site B. How this is achieved might also be an issue, > put presumably would be based on a path established at registration > time. I think this is also outside the scope of MARTINI. > That'sa lot of triggerwork, when she could have just registered to the B PBX. > What Dean proposes is that we support the nomadic user by moving the > registrar for Alice's AOR from PBX-A to PBX-B. This would be a much > bigger problem that just telling the SSP that Alice's E.164 number > is now served by PBX-B instead of PBX-A. You also need to arrange > for calls from UAs within the PBXs concerned to go to PBX-B instead > of PBX-A for handling. Also all Alice's preferences known to the > registrar at PBX-A need to be moved to PBX-B (e.g., conditions for > calls to be redirected to voicemail). Also, what if Alice still has > other devices that stay on site A? How does it help by moving the > registrar to PBX-B. A and B need a dynamic routing table between themselves. That's definitely outside the scope of MARTINI, although I've been pondering an event-packaged based framework for dynamic routing in SIP. Alternatively, B could "MARTINI" to A, or vice-versa, as needed to handle inter-PBX routing. It might be entirely reasonable for Alice's phone number to be registered simultaneously at A and B. We have this thing called "forking" that I've always wanted to get rid of, but can't seem to shake. -- Dean From spencer@wonderhamster.org Wed Feb 10 10:39: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 3D3CB28C169 for ; Wed, 10 Feb 2010 10:39:29 -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 PExjei8WzHXV for ; Wed, 10 Feb 2010 10:39:23 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 3CEEC3A73B6 for ; Wed, 10 Feb 2010 10:39:23 -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 0MVvZQ-1NCYQX10Ia-00Xgyv; Wed, 10 Feb 2010 13:40:33 -0500 Message-ID: From: "Spencer Dawkins" To: "Dean Willis" , "Adam Roach" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET><4B71A999.30708@nostrum.com> Date: Wed, 10 Feb 2010 12:40:27 -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: V01U2FsdGVkX18ubKPVJGOHnjG5lEB/9Af8ZgV1LIRmR5y14AW V7z05BC/qBlQbxTGlW8BZD3XffgsIkaxQ25obTiJjJErvihDqB /c+Kc/aIBXKjR2ydnRLA8dlAwlJhyL1bb5rueqiFVA= Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 18:39:29 -0000 Speaking as a participant - and if it wasn't clear that I was speaking as a participant I talked about this on the call this week, I apologize... >> This does get a bit into Richard's fragmentation issue, though. After a >> small number of phone number moves, you end up with a set of ranges that >> devolves almost into a complete enumeration of extensions. > > Almost, but not quite. Ranging vs. enumeration is a just an abbreviation > technique. If there are even two consecutive numbers in the set ranging > reduces the specification size relative to enumeration. > > However, there is no assurance that there will be even two consecutive > numbers. Therefore whatever technique we use MUST work with a fully- > enumerated request (the most degenerate case of Shockey fragmentation) if > it allows explicit registration. > > This means that any solution that requires regurgitating a large Contact > set in the response is probably a non-starter in UDP land. The reg-event > model is certainly cleaner for finding out "what is currently > registered?". This is exactly why I am where I am, on this question. It does make sense to me to send a list of numbers between the SP and the SIP-PBX so that mismatches can be identified at REGISTER time. In discussions at the SIP Forum, I encouraged that. *BUT* my understanding from discussions at the IETF is that we would need to - accommodate fragmented number ranges, with full enumeration as the degenerate case, - while not exceeding the SIP UDP request/response size limit, which isn't large. So, I think we would be limited in practice to something like 20-30 number ranges (using an encoding like Adam has proposed), which might translate into 20-30 numbers, in the degenerate case, for MARTINI. I don't see that as desireable, because it significantly low-balls the size of SIP-PBX we could expect to support (based on the requirements draft that John has put together). I'm happy to participate in discussion about this topic, but at the onset of that discussion I'd like to make sure whether we really have the constraints I've identified in this note. Without a common understanding of the constraints, we're just wasting valuable time. Thanks, Spencer From dean.willis@softarmor.com Wed Feb 10 11:08: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 0F0CE3A75B7 for ; Wed, 10 Feb 2010 11:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 M8F+IMmC8nw8 for ; Wed, 10 Feb 2010 11:08:37 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1CF8B28C165 for ; Wed, 10 Feb 2010 11:08:37 -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 o1AJ9khw016966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 13:09:47 -0600 From: Dean Willis To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><009c01caa9b5$2a808180$150610ac@CORPORATE.VOX.NET><4B71A999.30708@nostrum.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: Wed, 10 Feb 2010 13:09:41 -0600 X-Mailer: Apple Mail (2.936) Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 19:08:38 -0000 On Feb 10, 2010, at 12:40 PM, Spencer Dawkins wrote: > Speaking as a participant - and if it wasn't clear that I was > speaking as a participant I talked about this on the call this week, > I apologize... > >>> This does get a bit into Richard's fragmentation issue, though. >>> After a small number of phone number moves, you end up with a set >>> of ranges that devolves almost into a complete enumeration of >>> extensions. >> >> Almost, but not quite. Ranging vs. enumeration is a just an >> abbreviation technique. If there are even two consecutive numbers >> in the set ranging reduces the specification size relative to >> enumeration. >> >> However, there is no assurance that there will be even two >> consecutive numbers. Therefore whatever technique we use MUST work >> with a fully- enumerated request (the most degenerate case of >> Shockey fragmentation) if it allows explicit registration. >> >> This means that any solution that requires regurgitating a large >> Contact set in the response is probably a non-starter in UDP land. >> The reg-event model is certainly cleaner for finding out "what is >> currently registered?". > > This is exactly why I am where I am, on this question. > > It does make sense to me to send a list of numbers between the SP > and the SIP-PBX so that mismatches can be identified at REGISTER > time. In discussions at the SIP Forum, I encouraged that. > > *BUT* my understanding from discussions at the IETF is that we would > need to > > - accommodate fragmented number ranges, with full enumeration as the > degenerate case, > > - while not exceeding the SIP UDP request/response size limit, which > isn't large. > > So, I think we would be limited in practice to something like 20-30 > number ranges (using an encoding like Adam has proposed), which > might translate into 20-30 numbers, in the degenerate case, for > MARTINI. I don't see that as desireable, because it significantly > low-balls the size of SIP-PBX we could expect to support (based on > the requirements draft that John has put together). > > I'm happy to participate in discussion about this topic, but at the > onset of that discussion I'd like to make sure whether we really > have the constraints I've identified in this note. Without a common > understanding of the constraints, we're just wasting valuable time. > Too-large requests can be rejected by intermediaries. We have no way of rejecting responses, however. So the important thing is to keep the RESPONSES from becoming too big. So, while we could conceivably send a fairly large request (and in fact the requester has the option of using TCP), what we have to do prevent is an overly-large response. I do think it is important for SSP to be able to say "I'm sorry, you are not authorized to use one (or more) of the telephone-number- expressions you have just requested" in a response to a REGISTER. I think it might be reasonable to limit the volume of that response, by perhaps including only the first "failed" telephone-number-expression in the response. -- Dean From jsburton@cablevision.com Wed Feb 10 11:31: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 88CC928C14E for ; Wed, 10 Feb 2010 11:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[AWL=0.181, 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 DIgURgIqNo5t for ; Wed, 10 Feb 2010 11:31:29 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 686AA3A757E for ; Wed, 10 Feb 2010 11:31:28 -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 o1AJWcWo020428 for ; Wed, 10 Feb 2010 14:32:38 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o1AJWcWo020428 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1265830359; bh=8s+6jzMZQR1TwGrIQv5Q+V1hBAluWh7DpcM8GAC Ed6o=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=PUNt7sgZkLgn5eSPdD5BCBD8hYyE/NFdRG8vo Y5bSHBfxtBXpXDFuHvEHGUqVPz3ucTOZywVQ7nhA3i/HcW3GlaOuLNS12Q4/9oFKx92 9Ex/alKC/Fc9Cp+wNumFaK/LizgQp6Tyitxh4aDRKFL5pFlRhe85aG4ZCJvHPVoAQsc = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Wed, 10 Feb 2010 14:32:38 -0500 Message-Id: <4B72A724.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Wed, 10 Feb 2010 14:31:32 -0500 From: "Jack Burton" To: "MARTINI" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartDDF7E884.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 19:31:30 -0000 --=__PartDDF7E884.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit An excellent point. The SSP could implicitly register the entire list of PBX-A and PBX-B phone numbers when EITHER of them registers. Problem solved. Well, the problem of PBX-B knowing what to do when a PBX-A phone hooks up remains out of scope. Invites from either PBX involving any of the DIDs would be honored. Outbound calls to any DID (assuming both PBXs are online and registered) would be forked to both. This seems kind of silly, but if it will get us moving along, I'm OK with it. -Jack >>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >> ( mailto:dean.willis@softarmor.com> ) It might be entirely reasonable for Alice's phone number to be registered simultaneously at A and B. We have this thing called "forking" that I've always wanted to get rid of, but can't seem to shake. -- -------------------------------------------------------- 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. -------------------------------------------------------- --=__PartDDF7E884.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML
An excellent point.
 
The SSP could implicitly register the entire list of PBX-A and PBX-B phone numbers when EITHER of them registers.  Problem solved.  Well, the problem of PBX-B knowing what to do when a PBX-A phone hooks up remains out of scope.
 
Invites from either PBX involving any of the DIDs would be honored.
Outbound calls to any DID (assuming both PBXs are online and registered) would be forked to both.
 
This seems kind of silly, but if it will get us moving along, I'm OK with it.
-Jack

>>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >>

It might be entirely reasonable for Alice's phone number to be 
registered simultaneously at A and B. We have this thing called 
"forking" that I've always wanted to get rid of, but can't seem to 
shake.

--

--------------------------------------------------------
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.
-------------------------------------------------------- --=__PartDDF7E884.0__=-- From spencer@wonderhamster.org Wed Feb 10 11: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 1FFF628C224 for ; Wed, 10 Feb 2010 11:51:07 -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.013, 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 2Y0myP1ArJ9R for ; Wed, 10 Feb 2010 11:51:06 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id EA4F728C160 for ; Wed, 10 Feb 2010 11:51:05 -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 0LpKGb-1OB4ee0l3V-00fdwn; Wed, 10 Feb 2010 14:52:06 -0500 Message-ID: From: "Spencer Dawkins" To: "MARTINI" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> Date: Wed, 10 Feb 2010 13:52:03 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0400_01CAAA58.399FAC10" 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+FZE4y5DwirGgn/R+FjgXoXWkq5vr5ZXFXkna 9eHJsWMcKw9WwZwqygS/e06sF4CWIASHpPG02nOvOvaJKG79C9 otPFOpn55OdhS8TF4e4wNBMOpaBgSqPXKLKM4rtciw= Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 19:51:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0400_01CAAA58.399FAC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, the obvious question (to me as co-chair) is, "does this just work = like two UAs that register diffferent contacts for the same AOR, or = would we need to say anything about it in MARTINI documents?" Any thoughts? Spencer, speaking as co-chair ----- Original Message -----=20 From: Jack Burton=20 To: MARTINI=20 Sent: Wednesday, February 10, 2010 1:31 PM Subject: Re: [martini] DID Number Mobility and MARTINI An excellent point. The SSP could implicitly register the entire list of PBX-A and PBX-B = phone numbers when EITHER of them registers. Problem solved. Well, the = problem of PBX-B knowing what to do when a PBX-A phone hooks up remains = out of scope. Invites from either PBX involving any of the DIDs would be honored. Outbound calls to any DID (assuming both PBXs are online and = registered) would be forked to both. This seems kind of silly, but if it will get us moving along, I'm OK = with it. -Jack >>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >> It might be entirely reasonable for Alice's phone number to be =20 registered simultaneously at A and B. We have this thing called =20 "forking" that I've always wanted to get rid of, but can't seem to =20 shake. -- --------------------------------------------------------=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_0400_01CAAA58.399FAC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So, the obvious question (to me as = co-chair) is,=20 "does this just work like two UAs that register diffferent contacts for = the same=20 AOR, or would we need to say anything about it in MARTINI=20 documents?"
 
Any thoughts?
 
Spencer, speaking as = co-chair
----- Original Message -----
From:=20 Jack=20 Burton
To: MARTINI
Sent: Wednesday, February 10, = 2010 1:31=20 PM
Subject: Re: [martini] DID = Number=20 Mobility and MARTINI

An excellent point.
 
The SSP could implicitly register the entire list of PBX-A and = PBX-B=20 phone numbers when EITHER of them registers.  Problem = solved.  Well,=20 the problem of PBX-B knowing what to do when a PBX-A phone hooks up = remains=20 out of scope.
 
Invites from either PBX involving any of the DIDs would be = honored.
Outbound calls to any DID (assuming both PBXs are online and = registered)=20 would be forked to both.
 
This seems kind of silly, but if it will get us moving = along, I'm OK=20 with it.
-Jack

>>> Dean Willis 2/10/2010 11:26 = >>">dean.willis@softarmor.com>=20 2/10/2010 11:26 >>

It might be entirely reasonable = for=20 Alice's phone number to be 
registered simultaneously at A = and B. We=20 have this thing called 
"forking" that I've always wanted to = get rid=20 of, but can't seem to =20 =
shake.

--

-------------------------------------------= -------------=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_0400_01CAAA58.399FAC10-- From john.elwell@siemens-enterprise.com Wed Feb 10 12:08: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 674973A7791 for ; Wed, 10 Feb 2010 12:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_42=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 A932k2v7UyGq for ; Wed, 10 Feb 2010 12:08:29 -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 35C603A75D0 for ; Wed, 10 Feb 2010 12:08:28 -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-850359; Wed, 10 Feb 2010 21:09:39 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 88BBA23F028E; Wed, 10 Feb 2010 21:09:39 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 10 Feb 2010 21:09:39 +0100 From: "Elwell, John" To: Dean Willis Date: Wed, 10 Feb 2010 21:09:38 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqqfpuYkpugcfi9TrqkQDRGhWYN3wADXRgg Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@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 Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 20:08:30 -0000 I didn't say that keeping the registrar at PBX-A was without issues, but al= so being able to move the registrar from A to B has issues, and it is not c= lear that providing a means in MARTINI for dynamically varying the set of n= umbers registered from each PBX is a necessary part of the overall solution= . Building extra complexity into the MARTINI solution just because it might= form part of the solution to another problem seems wrong. I think we just have to make do with the suggested forking solution. Or rel= y on inter-registrar communication between the two PBXs to ensure that if a= call arrives at the wrong PBX, that PBX can retarget or redirect to the ot= her PBX. Either way, MARTINI does not need to solve it. John =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 10 February 2010 18:27 > To: Elwell, John > Cc: MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 >=20 > On Feb 10, 2010, at 2:32 AM, Elwell, John wrote: >=20 > > Dean, > > > > It is certainly the case that Alice should be able to move=20 > location =20 > > and have things "just work" without having to contact the service =20 > > desk. Let's assume Alice's device normally registers with=20 > the PBX at =20 > > site A, and that the PBX registers with the SSP to receive=20 > calls to =20 > > Alice's E.164 number. Alice moves to site B, but Alice's=20 > device (the =20 > > same one or a different one) still registers with the PBX=20 > at site A. =20 > > If there are issues with being able to register with a PBX=20 > on site A =20 > > from a LAN on site B, that is outside the scope of MARTINI work. >=20 > Since Site A and Site B each have their own firewall/NATs=20 > between them =20 > and the Internet, it's not going to work; we'd end up with=20 > inside-out =20 > Outbound. >=20 > However, they do share an authentication database. >=20 > > > > Of course, calls from the SSP to Alice, on arrival at=20 > PBX-A, if the =20 > > preferred device at that time is on site B, need to be routed to =20 > > that device on site B. How this is achieved might also be=20 > an issue, =20 > > put presumably would be based on a path established at=20 > registration =20 > > time. I think this is also outside the scope of MARTINI. > > >=20 > That'sa lot of triggerwork, when she could have just=20 > registered to the =20 > B PBX. >=20 > > What Dean proposes is that we support the nomadic user by=20 > moving the =20 > > registrar for Alice's AOR from PBX-A to PBX-B. This would=20 > be a much =20 > > bigger problem that just telling the SSP that Alice's E.164 number =20 > > is now served by PBX-B instead of PBX-A. You also need to arrange =20 > > for calls from UAs within the PBXs concerned to go to PBX-B=20 > instead =20 > > of PBX-A for handling. Also all Alice's preferences known to the =20 > > registrar at PBX-A need to be moved to PBX-B (e.g., conditions for =20 > > calls to be redirected to voicemail). Also, what if Alice=20 > still has =20 > > other devices that stay on site A? How does it help by moving the =20 > > registrar to PBX-B. >=20 >=20 > A and B need a dynamic routing table between themselves. That's =20 > definitely outside the scope of MARTINI, although I've been=20 > pondering =20 > an event-packaged based framework for dynamic routing in SIP. =20 > Alternatively, B could "MARTINI" to A, or vice-versa, as needed to =20 > handle inter-PBX routing. >=20 > It might be entirely reasonable for Alice's phone number to be =20 > registered simultaneously at A and B. We have this thing called =20 > "forking" that I've always wanted to get rid of, but can't seem to =20 > shake. >=20 > -- > Dean > = From spencer@wonderhamster.org Wed Feb 10 12:12: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 DF3B53A7795 for ; Wed, 10 Feb 2010 12:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, 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 NThtSiLSBVPe for ; Wed, 10 Feb 2010 12:12:35 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id E16D63A75D2 for ; Wed, 10 Feb 2010 12:12:30 -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-1NfIwL318a-000CNp; Wed, 10 Feb 2010 15:13:41 -0500 Message-ID: <08FDE15F8F244A23A4B0FE28835F7A68@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "Dean Willis" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> Date: Wed, 10 Feb 2010 14:13: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: V01U2FsdGVkX18oxNjo+temGi9FNoMlTz5kw9rFT2dIW7T/+xs mMdyi5gxrQK0NLF3Hh/tfqpHZGbqW3NLzZTRcI05EJ5iwwVktO 7QMoFhuUwgtb/OXR0Lg24mvOVHu3ctRPEM/DLq6E3k= Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 20:12:37 -0000 John, So please tell me if I'm misunderstanding or not... > I think we just have to make do with the suggested forking solution. Or > rely on inter-registrar communication between the two PBXs to ensure that > if a call arrives at the wrong PBX, that PBX can retarget or redirect to > the other PBX. Either way, MARTINI does not need to solve it. Your answer is that forking "just works" for AORs that have two or more contacts, pointing to different PBXes, right? So no document impact? Thanks, Spencer From root@core3.amsl.com Wed Feb 10 12:15:03 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 A43A73A75CA; Wed, 10 Feb 2010 12:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100210201502.A43A73A75CA@core3.amsl.com> Date: Wed, 10 Feb 2010 12:15:02 -0800 (PST) X-Mailman-Approved-At: Wed, 10 Feb 2010 12:16:40 -0800 Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-reqs-00.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Feb 2010 20:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF. Title : Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) Author(s) : J. Elwell Filename : draft-ietf-martini-reqs-00.txt Pages : 8 Date : 2010-02-10 This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized PBXs. The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This work is being discussed on the martini@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-martini-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-10121302.I-D@ietf.org> --NextPart-- From john.elwell@siemens-enterprise.com Wed Feb 10 12:21: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 A0FDB28C269 for ; Wed, 10 Feb 2010 12:21:01 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body 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.062, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC3Sai51fmKp for ; Wed, 10 Feb 2010 12:21: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 83EC83A7479 for ; Wed, 10 Feb 2010 12:21:00 -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-850335 for martini@ietf.org; Wed, 10 Feb 2010 21:22:10 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id C347C23F0278 for ; Wed, 10 Feb 2010 21:22:10 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 10 Feb 2010 21:22:10 +0100 From: "Elwell, John" To: MARTINI Date: Wed, 10 Feb 2010 21:22:08 +0100 Thread-Topic: I-D Action:draft-ietf-martini-reqs-00.txt Thread-Index: AcqqjizNiWhtJMCVQNefXnsLHKbaWQAAEB9A Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_A444A0F8084434499206E78C106220CAB92FEDE2MCHP058Aglobala_" MIME-Version: 1.0 Subject: [martini] FW: I-D Action:draft-ietf-martini-reqs-00.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Feb 2010 20:21:01 -0000 --_003_A444A0F8084434499206E78C106220CAB92FEDE2MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No change from draft-elwell-00. In accordance with discussions in the Interim and my posting earlier today,= I plan to produce an 01 shortly to incorporate material from mixing-proble= ms and add Hadriel as co-author. John=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 10 February 2010 20:15 > To: i-d-announce@ietf.org > Cc: martini@ietf.org > Subject: I-D Action:draft-ietf-martini-reqs-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Multiple AoR reachabiliTy=20 > InformatioN Indication Working Group of the IETF. >=20 >=20 > Title : Requirements for multiple address of=20 > record (AOR) reachability information in the Session=20 > Initiation Protocol (SIP) > Author(s) : J. Elwell > Filename : draft-ietf-martini-reqs-00.txt > Pages : 8 > Date : 2010-02-10 >=20 > This document states requirements for a standardized SIP registration > mechanism for multiple addresses of record, the mechanism being > suitable for deployment by SIP service providers on a large scale in > support of small to medium sized PBXs. The requirements are for a > solution that can, as a minimum, support AORs based on E.164 numbers. >=20 > This work is being discussed on the martini@ietf.org mailing list. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = --_003_A444A0F8084434499206E78C106220CAB92FEDE2MCHP058Aglobala_ Content-Type: message/external-body; name="draft-ietf-martini-reqs-00.url" Content-Description: draft-ietf-martini-reqs-00.url Content-Disposition: attachment; filename="draft-ietf-martini-reqs-00.url"; size=91; creation-date="Wed, 10 Feb 2010 21:18:14 GMT"; modification-date="Wed, 10 Feb 2010 21:18:14 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1hcnRpbmktcmVxcy0wMC50eHQNCg== --_003_A444A0F8084434499206E78C106220CAB92FEDE2MCHP058Aglobala_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=258; creation-date="Wed, 10 Feb 2010 21:18:14 GMT"; modification-date="Wed, 10 Feb 2010 21:18:14 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_A444A0F8084434499206E78C106220CAB92FEDE2MCHP058Aglobala_-- From BLINDSAY@nortel.com Wed Feb 10 12:24: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 4679628C0F2 for ; Wed, 10 Feb 2010 12:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.215, 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 5JottpZHykMN for ; Wed, 10 Feb 2010 12:24:03 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D7F8A3A75BB for ; Wed, 10 Feb 2010 12:24: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 o1AKP8l09888; Wed, 10 Feb 2010 20:25:08 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_01CAAA8F.1F3BFBCA" Date: Wed, 10 Feb 2010 15:24:54 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C7D50D7@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqqip0NeMmdMhwDQBGr1N2/8AGAnwAAL1zg References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com> From: "Brian Lindsay" To: "Spencer Dawkins" , "MARTINI" Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 20:24:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAAA8F.1F3BFBCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Hadriel's MARTINI-SHAKEN draft allowed for registration from multiple SIP PBXs, but for serial forking purposes (presumeably for backup cases). =20 One comment on this topic: In the discussions within the SIP Forum and in the work on the SIP Connect specification, the "registration" mode of operation was one of two modes for supporting SIP PBXs, the other being a "static" mode in which the SIP PBX did not register but had a static IP address or the address is obtained from DNS (e.g. RFC 3263 approach). The only substantial difference was intended to be the means by which the SSP obtained the reachability information to be able to route the request to the SIP PBX (which birthed the effort to start MARTINI for the non-"static" mode). We seem to be getting into areas, such as mobility and exchange of numbering info, that are well beyond the original intended scope, and are perhaps equally asked about the non-registration based approach. If these are "common" topics to both modes, perhaps they should be tabled as out of scope for this effort (they may have common solutions). =20 Thanks Brian ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, February 10, 2010 2:52 PM To: MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI So, the obvious question (to me as co-chair) is, "does this just work like two UAs that register diffferent contacts for the same AOR, or would we need to say anything about it in MARTINI documents?" =20 Any thoughts? =20 Spencer, speaking as co-chair ----- Original Message -----=20 From: Jack Burton =20 To: MARTINI =20 Sent: Wednesday, February 10, 2010 1:31 PM Subject: Re: [martini] DID Number Mobility and MARTINI An excellent point. =20 The SSP could implicitly register the entire list of PBX-A and PBX-B phone numbers when EITHER of them registers. Problem solved. Well, the problem of PBX-B knowing what to do when a PBX-A phone hooks up remains out of scope. =20 Invites from either PBX involving any of the DIDs would be honored. Outbound calls to any DID (assuming both PBXs are online and registered) would be forked to both. =20 This seems kind of silly, but if it will get us moving along, I'm OK with it. -Jack >>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >> 2/10/2010 11:26 >>>=20 =09 It might be entirely reasonable for Alice's phone number to be =20 registered simultaneously at A and B. We have this thing called "forking" that I've always wanted to get rid of, but can't seem to =20 shake. =09 -- --------------------------------------------------------=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 --------------------------------------------------------=20 =09 ________________________________ =09 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini =09 ------_=_NextPart_001_01CAAA8F.1F3BFBCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
   = Hadriel's=20 MARTINI-SHAKEN draft allowed for registration from multiple SIP PBXs, = but for=20 serial forking purposes (presumeably for backup = cases).
 
   = One comment on=20 this topic: In the discussions within the SIP Forum and in the work on = the SIP=20 Connect specification, the "registration" mode of operation was one of = two modes=20 for supporting SIP PBXs, the other being a "static" mode in which the = SIP PBX=20 did not register but had a static IP address or the address is obtained = from DNS=20 (e.g. RFC 3263 approach). The only substantial difference was intended = to be the=20 means by which the SSP obtained the reachability information to be able = to route=20 the request to the SIP PBX (which birthed the effort to start MARTINI = for the=20 non-"static" mode). We seem to = be getting=20 into areas, such as mobility and exchange of numbering info, that = are well=20 beyond the original intended scope, and are perhaps equally asked about = the=20 non-registration based approach. If these are "common" topics to both = modes,=20 perhaps they should be tabled as out of scope for this effort (they may = have=20 common solutions).
 
 =20 Thanks
      = Brian

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] = On=20 Behalf Of Spencer Dawkins
Sent: Wednesday, February 10, = 2010 2:52=20 PM
To: MARTINI
Subject: Re: [martini] DID Number = Mobility=20 and MARTINI

So, the obvious question (to me as = co-chair) is,=20 "does this just work like two UAs that register diffferent contacts for = the same=20 AOR, or would we need to say anything about it in MARTINI=20 documents?"
 
Any thoughts?
 
Spencer, speaking as = co-chair
----- Original Message -----
From:=20 Jack=20 Burton
To: MARTINI
Sent: Wednesday, February 10, = 2010 1:31=20 PM
Subject: Re: [martini] DID = Number=20 Mobility and MARTINI

An excellent point.
 
The SSP could implicitly register the entire list of PBX-A and = PBX-B=20 phone numbers when EITHER of them registers.  Problem = solved.  Well,=20 the problem of PBX-B knowing what to do when a PBX-A phone hooks up = remains=20 out of scope.
 
Invites from either PBX involving any of the DIDs would be = honored.
Outbound calls to any DID (assuming both PBXs are online and = registered)=20 would be forked to both.
 
This seems kind of silly, but if it will get us moving = along, I'm OK=20 with it.
-Jack

>>> Dean Willis 2/10/2010 11:26 = >>">dean.willis@softarmor.com>=20 2/10/2010 11:26 >>

It might be entirely reasonable = for=20 Alice's phone number to be 
registered simultaneously at A = and B. We=20 have this thing called 
"forking" that I've always wanted to = get rid=20 of, but can't seem to =20 =
shake.

--

-------------------------------------------= -------------=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
--------------------------------------------------------=20

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------_=_NextPart_001_01CAAA8F.1F3BFBCA-- From john.elwell@siemens-enterprise.com Wed Feb 10 12:26: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 ED91B28C0F2 for ; Wed, 10 Feb 2010 12:26: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 r0SYwsTfaQ0E for ; Wed, 10 Feb 2010 12:26:34 -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 E516F28C25C for ; Wed, 10 Feb 2010 12:26:33 -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-850377; Wed, 10 Feb 2010 21:27:44 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D77C623F028E; Wed, 10 Feb 2010 21:27:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Feb 2010 21:27:44 +0100 From: "Elwell, John" To: Spencer Dawkins , Dean Willis Date: Wed, 10 Feb 2010 21:27:42 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqqjZH5llTaW+kOSdWB2TKAHinJNwAATgnQ Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <08FDE15F8F244A23A4B0FE28835F7A68@china.huawei.com> In-Reply-To: <08FDE15F8F244A23A4B0FE28835F7A68@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 Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 20:26:35 -0000 I am saying we can make it work in two ways, without impacting MARTINI: 1. By both PBXs registering all the time with the SSP, as Dean and Jack hav= e suggested. 2. By only one PBX registering at any one time, and relying on intra-regist= rar communication (between the registrar in PBX-A and the registrar in PBX-= B) ensuring that each registrar is aware of all contacts for Alice, whichev= er registrar they are registered at. Then the PBX that has registered with = the SSP will receive calls from the SSP and can retarget or redirect to the= other PBX. And of course, there is also: 3. There is only a single registrar (at PBX A), and if Alice goes to PBX B,= her UA registers from there. This, as Dean points out, is subject to the f= irewall situation between the two PBXs. None of these require MARTINI work. John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 10 February 2010 20:14 > To: Elwell, John; Dean Willis > Cc: MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > John, >=20 > So please tell me if I'm misunderstanding or not... >=20 > > I think we just have to make do with the suggested forking=20 > solution. Or=20 > > rely on inter-registrar communication between the two PBXs=20 > to ensure that=20 > > if a call arrives at the wrong PBX, that PBX can retarget=20 > or redirect to=20 > > the other PBX. Either way, MARTINI does not need to solve it. >=20 > Your answer is that forking "just works" for AORs that have=20 > two or more=20 > contacts, pointing to different PBXes, right? So no document impact? >=20 > Thanks, >=20 > Spencer=20 >=20 > = From john.elwell@siemens-enterprise.com Wed Feb 10 12:32: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 6F11128C287 for ; Wed, 10 Feb 2010 12:32:19 -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.051, 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 ciq3K4sMufAO for ; Wed, 10 Feb 2010 12:32:18 -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 9E0A428C27E for ; Wed, 10 Feb 2010 12:32:14 -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-851160; Wed, 10 Feb 2010 21:33:22 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id DE96623F0278; Wed, 10 Feb 2010 21:33:22 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Feb 2010 21:33:22 +0100 From: "Elwell, John" To: Brian Lindsay , Spencer Dawkins , MARTINI Date: Wed, 10 Feb 2010 21:33:21 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqqip0NeMmdMhwDQBGr1N2/8AGAnwAAL1zgAAE6gNA= Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com> <09B7DBFE70A9E24BBB21689DAD3A06141C7D50D7@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C7D50D7@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_A444A0F8084434499206E78C106220CAB92FEDF3MCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 20:32:19 -0000 --_000_A444A0F8084434499206E78C106220CAB92FEDF3MCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed. John ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Brian Lindsay Sent: 10 February 2010 20:25 To: Spencer Dawkins; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI Hi, Hadriel's MARTINI-SHAKEN draft allowed for registration from multiple SI= P PBXs, but for serial forking purposes (presumeably for backup cases). One comment on this topic: In the discussions within the SIP Forum and i= n the work on the SIP Connect specification, the "registration" mode of ope= ration was one of two modes for supporting SIP PBXs, the other being a "sta= tic" mode in which the SIP PBX did not register but had a static IP address= or the address is obtained from DNS (e.g. RFC 3263 approach). The only sub= stantial difference was intended to be the means by which the SSP obtained = the reachability information to be able to route the request to the SIP PBX= (which birthed the effort to start MARTINI for the non-"static" mode). We = seem to be getting into areas, such as mobility and exchange of numbering i= nfo, that are well beyond the original intended scope, and are perhaps equa= lly asked about the non-registration based approach. If these are "common" = topics to both modes, perhaps they should be tabled as out of scope for thi= s effort (they may have common solutions). Thanks Brian ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Spencer Dawkins Sent: Wednesday, February 10, 2010 2:52 PM To: MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI So, the obvious question (to me as co-chair) is, "does this just work like = two UAs that register diffferent contacts for the same AOR, or would we nee= d to say anything about it in MARTINI documents?" Any thoughts? Spencer, speaking as co-chair ----- Original Message ----- From: Jack Burton To: MARTINI Sent: Wednesday, February 10, 2010 1:31 PM Subject: Re: [martini] DID Number Mobility and MARTINI An excellent point. The SSP could implicitly register the entire list of PBX-A and PBX-B phone = numbers when EITHER of them registers. Problem solved. Well, the problem = of PBX-B knowing what to do when a PBX-A phone hooks up remains out of scop= e. Invites from either PBX involving any of the DIDs would be honored. Outbound calls to any DID (assuming both PBXs are online and registered) wo= uld be forked to both. This seems kind of silly, but if it will get us moving along, I'm OK with i= t. -Jack >>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >>%202/10/2010%2011:26%20>>> It might be entirely reasonable for Alice's phone number to be registered simultaneously at A and B. We have this thing called "forking" that I've always wanted to get rid of, but can't seem to shake. -- -------------------------------------------------------- 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. -------------------------------------------------------- ________________________________ _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini --_000_A444A0F8084434499206E78C106220CAB92FEDF3MCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Agreed.=
 <= /DIV>
John
From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] <= B>On=20 Behalf Of Brian Lindsay
Sent: 10 February 2010=20 20:25
To: Spencer Dawkins; MARTINI
Subject: Re: [mart= ini]=20 DID Number Mobility and MARTINI

Hi,
 
   Had= riel's=20 MARTINI-SHAKEN draft allowed for registration from multiple SIP PBXs, but= for=20 serial forking purposes (presumeably for backup cases).
 
   One= comment=20 on this topic: In the discussions within the SIP Forum and in the work on= the=20 SIP Connect specification, the "registration" mode of operation was one o= f two=20 modes for supporting SIP PBXs, the other being a "static" mode in which t= he=20 SIP PBX did not register but had a static IP address or the address is=20 obtained from DNS (e.g. RFC 3263 approach). The only substantial differen= ce=20 was intended to be the means by which the SSP obtained the reachability=20 information to be able to route the request to the SIP PBX (which birthed= the=20 effort to start MARTINI for the non-"static" mode). We seem to be getting into areas, such as mobi= lity=20 and exchange of numbering info, that are well beyond the original=20 intended scope, and are perhaps equally asked about the non-registration = based=20 approach. If these are "common" topics to both modes, perhaps they should= be=20 tabled as out of scope for this effort (they may have common=20 solutions).
 
 =20 Thanks
      Brian

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] <= B>On=20 Behalf Of Spencer Dawkins
Sent: Wednesday, February 10, 201= 0=20 2:52 PM
To: MARTINI
Subject: Re: [martini] DID Number= =20 Mobility and MARTINI

So, the obvious question (to me as co-cha= ir) is,=20 "does this just work like two UAs that register diffferent contacts for t= he=20 same AOR, or would we need to say anything about it in MARTINI=20 documents?"
 
Any thoughts?
 
Spencer, speaking as co-chair
----- Original Message -----
F= rom:=20 Jack Burton
To: MARTINI
Sent: Wednesday, February 10, 20= 10 1:31=20 PM
Subject: Re: [martini] DID Numbe= r=20 Mobility and MARTINI

An excellent point.
 
The SSP could implicitly register the entire list of PBX-A and PBX= -B=20 phone numbers when EITHER of them registers.  Problem solved. = ;=20 Well, the problem of PBX-B knowing what to do when a PBX-A phone hooks = up=20 remains out of scope.
 
Invites from either PBX involving any of the DIDs would be=20 honored.
Outbound calls to any DID (assuming both PBXs are online and=20 registered) would be forked to both.
 
This seems kind of silly, but if it will get us moving along,= I'm=20 OK with it.
-Jack

>>> Dean Willis 2/10/2010 11:26 >>">dean.will= is@softarmor.com>=20 2/10/2010 11:26 >>

It might be entirely reasonable for= =20 Alice's phone number to be 
registered simultaneously at A and= B.=20 We have this thing called 
"forking" that I've always wanted t= o get=20 rid of, but can't seem to =20
shake.

--

-----------------------------------------= ---------------=20
The information transmitted in this email and any of its attachment= s 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 rev= iew,=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=20 intended recipient is prohibited and may be unlawful. If you received t= his=20 in error, please contact the sender immediately and delete and destroy = the=20 communication and all of the attachments you have received and all copi= es=20 thereof.
--------------------------------------------------------=20

_______________________________________________
martini maili= ng=20 list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/marti= ni
--_000_A444A0F8084434499206E78C106220CAB92FEDF3MCHP058Aglobala_-- From jsburton@cablevision.com Wed Feb 10 12:46: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 D7AEF28C295 for ; Wed, 10 Feb 2010 12:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.161, 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 VJYu5n6JZG3U for ; Wed, 10 Feb 2010 12:46:50 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 6E38228C279 for ; Wed, 10 Feb 2010 12:46: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 o1AKm07j021251 for ; Wed, 10 Feb 2010 15:48:00 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o1AKm07j021251 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1265834880; bh=ywdH+071EK8rwVKJd22/fMCcvrX/2wfyIYlLzib i0cI=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=cEj8WeU6AYLOhChZTrkVEIHAFDJ1Fbyd1/l0a N1Lnk3Jbf78g5jayfhCM0vIev2qya4kDQUD2aYH/sH3O85H3f+YH1UiO+fNZpRpfNfx Ta9t/Xg268NN1O3K/lBpiJZ7fbgzU4wFA+5DVwW172x+gPFwGYePq0ml0RApqeSJXw4 = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Wed, 10 Feb 2010 15:48:00 -0500 Message-Id: <4B72B902.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Wed, 10 Feb 2010 15:47:46 -0500 From: "Jack Burton" To: "MARTINI" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <08FDE15F8F244A23A4B0FE28835F7A68@china.huawei.com> In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part29031C62.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] DID Number Mobility and 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: Wed, 10 Feb 2010 20:46:52 -0000 --=__Part29031C62.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I may have suggested (1), but I much prefer we rely upon (3) and keep away from forking things up. -Jack >>> "Elwell, John" 2/10/2010 13:27 >>> I am saying we can make it work in two ways, without impacting MARTINI: 1. By both PBXs registering all the time with the SSP, as Dean and Jack have suggested. 2. By only one PBX registering at any one time, and relying on intra-registrar communication (between the registrar in PBX-A and the registrar in PBX-B) ensuring that each registrar is aware of all contacts for Alice, whichever registrar they are registered at. Then the PBX that has registered with the SSP will receive calls from the SSP and can retarget or redirect to the other PBX. And of course, there is also: 3. There is only a single registrar (at PBX A), and if Alice goes to PBX B, her UA registers from there. This, as Dean points out, is subject to the firewall situation between the two PBXs. None of these require MARTINI work. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 10 February 2010 20:14 > To: Elwell, John; Dean Willis > Cc: MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI > > John, > > So please tell me if I'm misunderstanding or not... > > > I think we just have to make do with the suggested forking > solution. Or > > rely on inter-registrar communication between the two PBXs > to ensure that > > if a call arrives at the wrong PBX, that PBX can retarget > or redirect to > > the other PBX. Either way, MARTINI does not need to solve it. > > Your answer is that forking "just works" for AORs that have > two or more > contacts, pointing to different PBXes, right? So no document impact? > > Thanks, > > Spencer > > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini -------------------------------------------------------- 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. -------------------------------------------------------- --=__Part29031C62.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
I may have suggested (1), but I much prefer we rely upon (3) and keep = away from forking things up.
-Jack

>>> "Elwell, John" <john.elwell@siemens-enter= prise.com> 2/10/2010 13:27 >>>
I am saying we can make it wo= rk in two ways, without impacting MARTINI:

1. By both PBXs registeri= ng all the time with the SSP, as Dean and Jack have suggested.

2. By= only one PBX registering at any one time, and relying on intra-registrar c= ommunication (between the registrar in PBX-A and the registrar in PBX-B) en= suring that each registrar is aware of all contacts for Alice, whichever re= gistrar they are registered at. Then the PBX that has registered with the S= SP will receive calls from the SSP and can retarget or redirect to the othe= r PBX.

And of course, there is also:
3. There is only a single re= gistrar (at PBX A), and if Alice goes to PBX B, her UA registers from there= . This, as Dean points out, is subject to the firewall situation between th= e two PBXs.

None of these require MARTINI work.

John

= > -----Original Message-----
> From: Spencer Dawkins [mailto:spenc= er@wonderhamster.org]
> Sent: 10 February 2010 20:14
> To: Elw= ell, John; Dean Willis
> Cc: MARTINI
> Subject: Re: [martini] D= ID Number Mobility and MARTINI
>
> John,
>
> So p= lease tell me if I'm misunderstanding or not...
>
> > I thi= nk we just have to make do with the suggested forking
> solution. Or=
> > rely on inter-registrar communication between the two PBXs <= BR>> to ensure that
> > if a call arrives at the wrong PBX, th= at PBX can retarget
> or redirect to
> > the other PBX. Ei= ther way, MARTINI does not need to solve it.
>
> Your answer i= s that forking "just works" for AORs that have
> two or more
>= ; contacts, pointing to different PBXes, right? So no document impact?
&= gt;
> Thanks,
>
> Spencer
>
>
_______= ________________________________________
martini mailing list
martini= @ietf.org
http= s://www.ietf.org/mailman/listinfo/martini

--------------------------------------------------------
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.
-------------------------------------------------------- --=__Part29031C62.0__=-- From bernard_aboba@hotmail.com Wed Feb 10 13:28: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 C569728C24B for ; Wed, 10 Feb 2010 13:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_BAYES_5x7=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 2JkBEZvfetIW for ; Wed, 10 Feb 2010 13:28:45 -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 1F7F33A77B7 for ; Wed, 10 Feb 2010 13:28:45 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.73]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 13:27:45 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 10 Feb 2010 13:27:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01CAAA54.D4662840" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqql+JQDkHDkKBMS3exqf448i1qDg== Content-Language: en-us X-OriginalArrivalTime: 10 Feb 2010 21:27:45.0212 (UTC) FILETIME=[E29BB7C0:01CAAA97] Subject: [martini] Request for Input: MARTINI Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Feb 2010 21:28:48 -0000 ------=_NextPart_000_0014_01CAAA54.D4662840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Doodle Poll for selection of a date for MARTINI Virtual Interim IV is open: http://www.doodle.com/hgndgicqw9ymesav During MARTINI Virtual Interim III on Tuesday, the question arose as to whether holding another virtual interim so close to IETF 77 makes sense. Some points that were made: a. The prospective dates are only two weeks away from IETF 77. b. Holding another Virtual Interim could detract from activities required to prepare for the meeting (reading drafts, creating presentations, etc.) c. MARTINI has already held three Virtual Interims so far. A fourth could create the potential for a "MARTINI Overdose" (see http://www.drinkswap.com/strawberry-overdose.htm ) What say you? ------=_NextPart_000_0014_01CAAA54.D4662840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Doodle Poll for selection of a date for MARTINI = Virtual Interim IV is open:

http://www.doodle.com/hgn= dgicqw9ymesav

 

During MARTINI Virtual Interim III on Tuesday, the = question arose as to whether holding another virtual interim so close to IETF 77 makes = sense.  Some points that were made:

 

a.       The prospective dates are only two weeks away = from IETF 77.   

b.      Holding another Virtual Interim could detract = from activities required to prepare for the meeting (reading drafts, creating presentations, etc.)

c.       MARTINI has already held three Virtual Interims = so far.   A fourth could create the potential for a =  “MARTINI Overdose” (see http://www.drin= kswap.com/strawberry-overdose.htm )

 

What say you?

 

 

------=_NextPart_000_0014_01CAAA54.D4662840-- From bernard_aboba@hotmail.com Wed Feb 10 13:51: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 F34C23A77C0 for ; Wed, 10 Feb 2010 13:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.578, 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 uFwQDf8D4RJw for ; Wed, 10 Feb 2010 13:51:36 -0800 (PST) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by core3.amsl.com (Postfix) with ESMTP id C00BA3A77BD for ; Wed, 10 Feb 2010 13:51:35 -0800 (PST) Received: from BLU137-DS1 ([65.55.116.74]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 13:52:47 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Elwell, John'" , , "'Hadriel Kaplan'" References: In-Reply-To: Date: Wed, 10 Feb 2010 13:52:46 -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: AcqqOpBYZErrM/jqTCi/vU/bvJeFJgAYIqUg Content-Language: en-us X-OriginalArrivalTime: 10 Feb 2010 21:52:47.0406 (UTC) FILETIME=[61FC54E0:01CAAA9B] Subject: Re: [martini] Integration of problem-statement material into requirements draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Feb 2010 21:51:37 -0000 Speaking for myself (co-chair hat off), this looks like a reasonable approach. Once you do the integration, it might make sense to post a pointer to a strawman, so people can look it over and comment before you submit it. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Wednesday, February 10, 2010 2:20 AM To: martini@ietf.org; Hadriel Kaplan Subject: [martini] Integration of problem-statement material into requirements draft As discussed at the virtual meeting yesterday, there seems to be an intention to integrate relevant material from draft-kaplan-martini-mixing-problems-00 into the requirements draft, so that we only need the one deliverable to cover both aspects. I have reviewed the mixing-problems document, and these are my proposals for the various sections. Section 1 (Introduction). Section 1 of the martini-reqs contains text closely aligned with some of the text in the MARTINI charter, so I don't particularly want to change that. I don't think it is necessary to reference the SIP Forum SIPconnect or 3GPP/ETSI specifications and their issues in section 1. So I don't think we need anything from section 1 of mixing-problems. Section 2 (Definitions). The need for additional definitions will depend on what other text we import. Section 3 (Background on current mechanisms). Basically we should incorporate this, because it is background needed to understand the issues in sections 4 onwards. This would include explicit references to the ETSI/3GPP mechanism, as an example of current techniques. Section 4.1 (No Explicit Indicator). Include. Section 4.2 (Undefined behaviour on PAU mismatch). Include. Section 4.3 (REGISTER response growth). I am not sure we should include this, because we never agreed a requirement that the mechanism must work over UDP. Section 4.4 (Illegal wildcarding syntax). Include. Section 5.1 (Loss of target information). Include. Section 5.2 (Request-URI vs. loose-route mismatches). Include. Section 5.3 (Request-URI mis-routing). Include. Section 6.1 (Authorization policy mismatches). I am not sure about this. The problem is that the SSP is being too strict, i.e., it doesn't permit the Contact URI to identify the calling UA (the Route header field, on the other hand, might bear some resemblance to the registered contact URI). I guess MARTINI deliverables can at least make statements about practices in this area, but MARTINI will not provide a solution that allows such authorization policies to work. My inclination, nevertheless, is to include this section. Section 6.2 (P-Asserted-Identity URI mismatches). This is a policy issue, and MARTINI will not provide a solution that allows such a policy to work in all cases. So is this really part of the problem statement? If not, I would suggest we could omit this. Section 6.3 (Trust domain mismatches for privacy/identity). Is this straying outside the scope of MARTINI? The issue applies even if RFC 3263 is used, rather than registration, between the PBX and the SSP. I would suggest we could omit this. So in summary, I think we can import most of sections 3, 4 and 5 of the mixing-problems draft into the requirements draft, and perhaps some of section 6 too. I would propose they all go into a new section, prior to the Requirements section. Please comment. John From spencer@wonderhamster.org Wed Feb 10 13:58: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 0B7FF3A6CD5 for ; Wed, 10 Feb 2010 13:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, 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 4btAe-Jkv7eC for ; Wed, 10 Feb 2010 13:58:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 495BB3A726B for ; Wed, 10 Feb 2010 13:58:57 -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 0Lgq9m-1O1zyL2Bhm-00o72g; Wed, 10 Feb 2010 17:00:05 -0500 Message-ID: <8FA15015979F4DA496BDE413750F786C@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , "'Elwell, John'" , , "'Hadriel Kaplan'" References: Date: Wed, 10 Feb 2010 15:59:57 -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/JUc3l+z6ecYp7hLYG9/6ONukR/fBD/KilgV7 2UuAvviMgV9UnpAsD8lf9gBZFrIh1qja+umuGGqDo5raHGj/Sd 9/MlQvcrIk8k+Tde7nEJmx/wTtSBHG8Lmp9HmQibrI= Subject: Re: [martini] Integration of problem-statement material intorequirements draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Feb 2010 21:58:58 -0000 Yet Another E-mail from Spencer about UDP ... it's been a long week already! As individual: > Section 4.3 (REGISTER response growth). I am not sure we should include > this, because we never agreed a requirement that the mechanism must work > over UDP. The best requirements are the ones that everyone thinks everyone agrees with and never asks, but ... if this is a requirement, I would like to see it mentioned in the requirements document. If it's not a requirement, a whole range of possibilities opens up (beneath our feet)... Thanks, Spencer From adam@nostrum.com Wed Feb 10 14:20: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 9EBE83A7497 for ; Wed, 10 Feb 2010 14:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_BAYES_5x7=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 cgWNHNumwZk2 for ; Wed, 10 Feb 2010 14:20: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 B8B2228C141 for ; Wed, 10 Feb 2010 14:20:03 -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 o1AMLCo9014198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 16:21:12 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B733158.9010104@nostrum.com> Date: Wed, 10 Feb 2010 16:21:12 -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: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060306000907070402010102" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Request for Input: MARTINI Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 10 Feb 2010 22:20:10 -0000 This is a multi-part message in MIME format. --------------060306000907070402010102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/10/10 15:27, Feb 10, Bernard Aboba wrote: > > The Doodle Poll for selection of a date for MARTINI Virtual Interim IV > is open: > > http://www.doodle.com/hgndgicqw9ymesav > > During MARTINI Virtual Interim III on Tuesday, the question arose as > to whether holding another virtual interim so close to IETF 77 makes > sense. Some points that were made: > > a. The prospective dates are only two weeks away from IETF 77. > > b. Holding another Virtual Interim could detract from activities > required to prepare for the meeting (reading drafts, creating > presentations, etc.) > > c. MARTINI has already held three Virtual Interims so far. A fourth > could create the potential for a "MARTINI Overdose" (see > http://www.drinkswap.com/strawberry-overdose.htm ) > > What say you? > > Speaking as the chair of a different working group (which will require significant preparation in the window proposed for Interim IV), I would strongly prefer _not_ to have a 4th interim before IETF 77. /a --------------060306000907070402010102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/10/10 15:27, Feb 10, Bernard Aboba wrote:

The Doodle Poll for selection of a date for MARTINI Virtual Interim IV is open:

http://www.doodle.com/hgndgicqw9ymesav

 

During MARTINI Virtual Interim III on Tuesday, the question arose as to whether holding another virtual interim so close to IETF 77 makes sense.  Some points that were made:

 

a.       The prospective dates are only two weeks away from IETF 77.   

b.      Holding another Virtual Interim could detract from activities required to prepare for the meeting (reading drafts, creating presentations, etc.)

c.       MARTINI has already held three Virtual Interims so far.   A fourth could create the potential for a  “MARTINI Overdose” (see http://www.drinkswap.com/strawberry-overdose.htm )

 

What say you?

 


Speaking as the chair of a different working group (which will require significant preparation in the window proposed for Interim IV), I would strongly prefer _not_ to have a 4th interim before IETF 77.

/a
--------------060306000907070402010102-- From john.elwell@siemens-enterprise.com Wed Feb 10 23:10: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 EA0F63A731D for ; Wed, 10 Feb 2010 23:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTaJTMnLLks0 for ; Wed, 10 Feb 2010 23:10: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 29ABC3A7166 for ; Wed, 10 Feb 2010 23:10:54 -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-853286; Thu, 11 Feb 2010 08:12:01 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2926523F0278; Thu, 11 Feb 2010 08:12:01 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 11 Feb 2010 08:12:01 +0100 From: "Elwell, John" To: Spencer Dawkins , Bernard Aboba , "martini@ietf.org" , 'Hadriel Kaplan' Date: Thu, 11 Feb 2010 08:11:58 +0100 Thread-Topic: [martini] Integration of problem-statement material intorequirements draft Thread-Index: AcqqnHmCxzixrtyaRY67lSy6B/J9vQATDQYg Message-ID: References: <8FA15015979F4DA496BDE413750F786C@china.huawei.com> In-Reply-To: <8FA15015979F4DA496BDE413750F786C@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 Subject: Re: [martini] Integration of problem-statement material intorequirements draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Feb 2010 07:10:57 -0000 Spencer, I proposed it before, but we didn't gain consensus. So I will ask again. Sh= ould we add: "The solution MUST work over any existing transport specified for SIP, incl= uding UDP"? John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 10 February 2010 22:00 > To: Bernard Aboba; Elwell, John; martini@ietf.org; 'Hadriel Kaplan' > Subject: Re: [martini] Integration of problem-statement=20 > material intorequirements draft >=20 > Yet Another E-mail from Spencer about UDP ... it's been a=20 > long week already! >=20 > As individual: >=20 > > Section 4.3 (REGISTER response growth). I am not sure we=20 > should include > > this, because we never agreed a requirement that the=20 > mechanism must work > > over UDP. >=20 > The best requirements are the ones that everyone thinks=20 > everyone agrees with=20 > and never asks, but ... if this is a requirement, I would=20 > like to see it=20 > mentioned in the requirements document. If it's not a=20 > requirement, a whole=20 > range of possibilities opens up (beneath our feet)... >=20 > Thanks, >=20 > Spencer=20 >=20 > = From spencer@wonderhamster.org Thu Feb 11 05:17: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 73E3A3A7842 for ; Thu, 11 Feb 2010 05:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Jz9ibO-XhNij for ; Thu, 11 Feb 2010 05:17:29 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id C3A533A76DE for ; Thu, 11 Feb 2010 05:17:29 -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 0LpsZ5-1OAF2n3bXT-00fmMY; Thu, 11 Feb 2010 08:17:41 -0500 Message-ID: <1F28E968B63441D792C5F94D77F07C49@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "Bernard Aboba" , , "'Hadriel Kaplan'" References: <8FA15015979F4DA496BDE413750F786C@china.huawei.com> Date: Thu, 11 Feb 2010 07:17:33 -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/JXct7FQhJROHGx2OCuMH5Tf4Hut6Uitpgp7+ Tuai1GeuUQpo1oVrLwa92ysaV/RfbVtyAbfARKDqqe/ZUd/V+4 rVNDIGQV455PRX58J90rYPfZFVYeyLcoyYhnmBPW2w= Subject: Re: [martini] Integration of problem-statement material intorequirements draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Feb 2010 13:17:37 -0000 Speaking only as a participant, if this is NOT a requirement, I would have a much harder time arguing against including explicit lists in at least one direction. I understand Dean's concern that the SIP experience has been "implicit side effects = does not end well", and the only reason I'm not leaning that direction as a participant is that I'm assuming that "works over UDP" IS a requirement in the IETF, and I don't like what that does to our ability to support mid-sized PBXes (where "mid-sized" means "more than 20-30 AoRs"). If "works over UDP" is NOT a requirement, what other technical reasons do we have for not doing explicit signaling? Thanks, Spencer ----- Original Message ----- From: "Elwell, John" To: "Spencer Dawkins" ; "Bernard Aboba" ; ; "'Hadriel Kaplan'" Sent: Thursday, February 11, 2010 1:11 AM Subject: RE: [martini] Integration of problem-statement material intorequirements draft Spencer, I proposed it before, but we didn't gain consensus. So I will ask again. Should we add: "The solution MUST work over any existing transport specified for SIP, including UDP"? John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 10 February 2010 22:00 > To: Bernard Aboba; Elwell, John; martini@ietf.org; 'Hadriel Kaplan' > Subject: Re: [martini] Integration of problem-statement > material intorequirements draft > > Yet Another E-mail from Spencer about UDP ... it's been a > long week already! > > As individual: > > > Section 4.3 (REGISTER response growth). I am not sure we > should include > > this, because we never agreed a requirement that the > mechanism must work > > over UDP. > > The best requirements are the ones that everyone thinks > everyone agrees with > and never asks, but ... if this is a requirement, I would > like to see it > mentioned in the requirements document. If it's not a > requirement, a whole > range of possibilities opens up (beneath our feet)... > > Thanks, > > Spencer > > = From john.elwell@siemens-enterprise.com Thu Feb 11 07:30: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 97C6C3A6F88 for ; Thu, 11 Feb 2010 07:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkqY-fLP-98h for ; Thu, 11 Feb 2010 07:30: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 0B5363A6ED9 for ; Thu, 11 Feb 2010 07:30: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-861514; Thu, 11 Feb 2010 16:31:37 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 15FEE1EB82B5; Thu, 11 Feb 2010 16:31:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 11 Feb 2010 16:31:37 +0100 From: "Elwell, John" To: Spencer Dawkins , Bernard Aboba , "martini@ietf.org" , 'Hadriel Kaplan' Date: Thu, 11 Feb 2010 16:31:35 +0100 Thread-Topic: [martini] Integration of problem-statement material intorequirements draft Thread-Index: AcqrHYyn037E5S4pTKmcw/dZ1XkQawAD1YqA Message-ID: References: <8FA15015979F4DA496BDE413750F786C@china.huawei.com> <1F28E968B63441D792C5F94D77F07C49@china.huawei.com> In-Reply-To: <1F28E968B63441D792C5F94D77F07C49@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 Subject: Re: [martini] Integration of problem-statement material intorequirements draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Feb 2010 15:30:24 -0000 First, I think the argument that UDP is not a requirement came from the fac= t that SIPconnect 1.1 does not specify UDP. I am not sure that is a valid a= rgument, since SIPconnect 1.1 applies only between the PBX and the border e= lement in the SSP, not all the way to the SSP's registrar. However, I do ag= ree that avoiding UDP on any such hop would be a good thing. Secondly, even if the ability to operate over UDP is not a requirement, thi= s does not mean there is a requirement for an explicit indication of the se= t of registered numbers in the REGISTER request. It still adds extra comple= xity, which should be avoided unless there is a specific requirement or the= re are significant drawbacks to not doing so. I understand a concern has been expressed that implicit has proved to be a = bad thing in the past in other contexts. To me, that is a rather nebulous a= rgument, so I would like to hear more concrete arguments relating to this p= articular situation. Also, as stated on another thread, I don't think the m= obility scenario raised by Dean is a sufficient argument. I would not necessarily oppose including a list of intended E.164 numbers i= n the REGISTER message if that is what others want, but I get the impressio= n a lot of people don't want that. It would make messages potentially very = big, even for TCP. As a desirable we stated several hundred numbers. If non= e of these are adjacent, this could mean, say, 5000 number times 15 charact= ers per number, or 750000 bytes / 6M bits. Admittedly this would be an extr= eme case, and in most large PBX cases I would expect considerable compressi= on arising from the use of blocks of numbers, but it's a pretty huge SIP me= ssage. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 11 February 2010 13:18 > To: Elwell, John; Bernard Aboba; martini@ietf.org; 'Hadriel Kaplan' > Subject: Re: [martini] Integration of problem-statement=20 > material intorequirements draft >=20 > Speaking only as a participant, if this is NOT a requirement,=20 > I would have a=20 > much harder time arguing against including explicit lists in=20 > at least one=20 > direction. >=20 > I understand Dean's concern that the SIP experience has been=20 > "implicit side=20 > effects =3D does not end well", and the only reason I'm not=20 > leaning that=20 > direction as a participant is that I'm assuming that "works=20 > over UDP" IS a=20 > requirement in the IETF, and I don't like what that does to=20 > our ability to=20 > support mid-sized PBXes (where "mid-sized" means "more than=20 > 20-30 AoRs"). >=20 > If "works over UDP" is NOT a requirement, what other=20 > technical reasons do we=20 > have for not doing explicit signaling? >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message -----=20 > From: "Elwell, John" > To: "Spencer Dawkins" ; "Bernard Aboba"=20 > ; ; "'Hadriel Kaplan'"=20 > > Sent: Thursday, February 11, 2010 1:11 AM > Subject: RE: [martini] Integration of problem-statement material=20 > intorequirements draft >=20 >=20 > Spencer, >=20 > I proposed it before, but we didn't gain consensus. So I will=20 > ask again.=20 > Should we add: > "The solution MUST work over any existing transport specified=20 > for SIP,=20 > including UDP"? >=20 > John >=20 > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > Sent: 10 February 2010 22:00 > > To: Bernard Aboba; Elwell, John; martini@ietf.org; 'Hadriel Kaplan' > > Subject: Re: [martini] Integration of problem-statement > > material intorequirements draft > > > > Yet Another E-mail from Spencer about UDP ... it's been a > > long week already! > > > > As individual: > > > > > Section 4.3 (REGISTER response growth). I am not sure we > > should include > > > this, because we never agreed a requirement that the > > mechanism must work > > > over UDP. > > > > The best requirements are the ones that everyone thinks > > everyone agrees with > > and never asks, but ... if this is a requirement, I would > > like to see it > > mentioned in the requirements document. If it's not a > > requirement, a whole > > range of possibilities opens up (beneath our feet)... > > > > Thanks, > > > > Spencer > > > > =3D=20 >=20 > = From keith.drage@alcatel-lucent.com Thu Feb 11 05:12: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 33D4D28C1C5 for ; Thu, 11 Feb 2010 05:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=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 1+NVhKfDF+jU for ; Thu, 11 Feb 2010 05:12:39 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 518E73A76DE for ; Thu, 11 Feb 2010 05:12:39 -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.14.3/8.14.3/ICT) with ESMTP id o1BDDhOH031716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Feb 2010 14:13:49 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 11 Feb 2010 14:13:48 +0100 From: "DRAGE, Keith (Keith)" To: Bernard Aboba , "martini@ietf.org" Date: Thu, 11 Feb 2010 14:13:43 +0100 Thread-Topic: [martini] Request for Input: MARTINI Interim IV Thread-Index: Acqql+JQDkHDkKBMS3exqf448i1qDgAg/Y/Q 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_EDC0A1AE77C57744B664A310A0B23AE20AFB8A1DFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 X-Mailman-Approved-At: Thu, 11 Feb 2010 08:00:49 -0800 Subject: Re: [martini] Request for Input: MARTINI Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 11 Feb 2010 13:33:36 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE20AFB8A1DFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No, I refuse to try and guess the timezones yet again. I get too many of th= ese to try and remember whether it might have beent he same one as last tim= e. In regard to the question, I will support it if it is scheduled, but I am r= unning out of resource for yet another meeting. regards Keith ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: Wednesday, February 10, 2010 9:28 PM To: martini@ietf.org Subject: [martini] Request for Input: MARTINI Interim IV The Doodle Poll for selection of a date for MARTINI Virtual Interim IV is o= pen: http://www.doodle.com/hgndgicqw9ymesav During MARTINI Virtual Interim III on Tuesday, the question arose as to whe= ther holding another virtual interim so close to IETF 77 makes sense. Some= points that were made: a. The prospective dates are only two weeks away from IETF 77. b. Holding another Virtual Interim could detract from activities requi= red to prepare for the meeting (reading drafts, creating presentations, etc= .) c. MARTINI has already held three Virtual Interims so far. A fourth= could create the potential for a =93MARTINI Overdose=94 (see http://www.d= rinkswap.com/strawberry-overdose.htm ) What say you? --_000_EDC0A1AE77C57744B664A310A0B23AE20AFB8A1DFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
No, I refuse to try and guess the timezones yet ag= ain. I=20 get too many of these to try and remember whether it might have beent he sa= me=20 one as last time.
 
In regard to the question, I will support it if it= is=20 scheduled, but I am running out of resource for yet another=20 meeting.
 
regards
 
Keith

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Wednesday, February 10, 2010 9:28 PM
To:= =20 martini@ietf.org
Subject: [martini] Request for Input: MARTINI= =20 Interim IV

The Doodle Poll for selection of a date for MARTINI = Virtual=20 Interim IV is open:

http://www.doodle.com/hgn= dgicqw9ymesav

 

During MARTINI Virtual Interim III on Tuesday, the q= uestion=20 arose as to whether holding another virtual interim so close to IETF 77 m= akes=20 sense.  Some points that were made:

 

a.      = ;=20 The prospective dates are only two weeks away fro= m=20 IETF 77.   

b.     =20 Holding another Virtual Interim could detract fro= m=20 activities required to prepare for the meeting (reading drafts, creating= =20 presentations, etc.)

c.      = ;=20 MARTINI has already held three Virtual Interims s= o=20 far.   A fourth could create the potential for a  =93MARTI= NI=20 Overdose=94 (see http://www.drin= kswap.com/strawberry-overdose.htm=20 )

 

What say you?

 

 

--_000_EDC0A1AE77C57744B664A310A0B23AE20AFB8A1DFRMRSSXCHMBSC3d_-- From dwsauder@dsauder.com Thu Feb 11 09:21: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 F2C813A776E for ; Thu, 11 Feb 2010 09:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 fMTqT5edTjDB for ; Thu, 11 Feb 2010 09:21:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 1BDEB3A776A for ; Thu, 11 Feb 2010 09:21:57 -0800 (PST) Received: from [192.168.40.18] ([8.18.34.2]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Likh3-1OGK120ard-00dPrA; Thu, 11 Feb 2010 12:23:11 -0500 Message-ID: <4B743CF9.2070108@dsauder.com> Date: Thu, 11 Feb 2010 12:23:05 -0500 From: Doug Sauder User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> In-Reply-To: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/1j4G+ELLmS7R/LfpH5eiLrbhVdEt7RTdSyQf FNiXjEIzpWQRTWDjslooJVtH1vPYYk75ss1w23/PrEsURld1+6 FofbMarIlNVlsJAHj4HPh9sB9fcDa8u Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 11 Feb 2010 17:21:58 -0000 Dean, There is another option that you didn't include: 4) Alice calls her administrator, who brings up a web page hosted by the SSP and changes the selection in a drop-down list from PBX-901 to PBX-400. It really is that simple. I think what Richard is trying to promote, and which I agree with, is that we're trying to solve the problem of SSPs who prefer a Walmart-like model: lots of customers and low prices. The SSPs who charge a fee for every provisioning change will not survive. The SSPs that can provide self-service options for their customers will. Having said that, I agree with others who have pointed out that the "mobility" issue is out of scope. -- Doug Dean Willis wrote: > > One of my understanding of goals for corporate VoIP systems was the > ability to move a user from one PBX to another PBX without having to > pay a service provider MACD (move, add, change, delete) fee. > > In fact, it was my demonstrating this very capability to MCI's chief > engineering officer back in 1999 that got the first SIP project there > funded. > > Let's talk through a use case: > > Assume Alice is working today in our building at #901 I-street, which > has a PBX. Her DID number is routed to that PBX. Over lunch, her > office gets moved down the street to the lab at #400 I-Street. > > Three cases might apply: > > 1) Alice moves her phone and plugs it in and it "just works", because > the phone dynamically registers with the new PBX, which then > dynamically registers with the SSP proxy for that DID number, > effectively moving the binding from #901's PBX to #400's PBX. > > 2) Alice moves her phone to #400, waits until after lunch, then calls > the phone support people, who manually reprovision her onto the #400 > PBX. This PBX then re-registers with SSP, and her number starts > working again. > > 3) Alice moves her pone to #400, and waits until after lunch to talk > to the phone support people, who reprovision her on the PBXes and then > call the SSP support people to move her DID number from #901's "trunk" > to 400's "trunk". Sometime, tomorrow, her phone line starts working > AND we get a $50 bill for the "change fee" from the SSP. > > > Our original design goal favored #1, we might have accepted #2, and #3 > was what we were most aggressively trying to avoid. > > > Yet my understanding of the consensus of MARTINI is that #3 is the > desired outcome. This is the difference, if I understand it, between > draft-gin's "()" proposal for implicit registration and the "XXXX" > proposal for explicit registration I made on-list. > > Why are we pushing ourselves ten years backwards in operational advances? > > And what happens when Alice has a WiFi phone and moves back and forth > from #901 to #400 several times a day? Does she just go without a > phone, or do we pay a $50 change fee each time? > > > > -- > Dean > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Thu Feb 11 09:24: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 A69A53A775B for ; Thu, 11 Feb 2010 09:24:42 -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.047, 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 63dbnfkR9MTy for ; Thu, 11 Feb 2010 09:24: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 8FCD83A7757 for ; Thu, 11 Feb 2010 09:24:41 -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 o1BHPrZR055560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 11:25:53 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B743DA0.6010201@nostrum.com> Date: Thu, 11 Feb 2010 11:25:52 -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: Doug Sauder References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B743CF9.2070108@dsauder.com> In-Reply-To: <4B743CF9.2070108@dsauder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 11 Feb 2010 17:24:42 -0000 On 2/11/10 11:23 AM, Doug Sauder wrote: > Dean, > > There is another option that you didn't include: > > 4) Alice calls her administrator, who brings up a web page hosted by > the SSP and changes the selection in a drop-down list from PBX-901 to > PBX-400. If we can do that, then the administrator can just as easily pull up a web page hosted by the SSP and enter their PBX's IP address. Voilà! The whole MARTINI problem, solved by a web page! /a From pkyzivat@cisco.com Thu Feb 11 09:27: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 110FD28C117 for ; Thu, 11 Feb 2010 09:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.551 X-Spam-Level: X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 Bj+-LRP9GIam for ; Thu, 11 Feb 2010 09:27:05 -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 844FB28C21B for ; Thu, 11 Feb 2010 09:27:04 -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: AvsEALPMc0tAZnwM/2dsb2JhbACae3SmWJdhhFYEgxM X-IronPort-AV: E=Sophos;i="4.49,453,1262563200"; d="scan'208";a="85558745" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2010 17:28:18 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1BHSIr1019960; Thu, 11 Feb 2010 17:28:18 GMT Message-ID: <4B743E31.4000200@cisco.com> Date: Thu, 11 Feb 2010 12:28:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Doug Sauder References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B743CF9.2070108@dsauder.com> In-Reply-To: <4B743CF9.2070108@dsauder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 11 Feb 2010 17:27:06 -0000 Doug Sauder wrote: > It really is that simple. I think what Richard is trying to promote, > and which I agree with, is that we're trying to solve the problem of > SSPs who prefer a Walmart-like model: lots of customers and low prices. > The SSPs who charge a fee for every provisioning change will not > survive. The SSPs that can provide self-service options for their > customers will. Such providers exist??? They certainly haven't taken hold in the consumer space. Thanks, Paul From dwsauder@dsauder.com Thu Feb 11 09:51: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 412C528C117 for ; Thu, 11 Feb 2010 09:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 Sl-Qarj1kx-h for ; Thu, 11 Feb 2010 09:51:07 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 5C4CA28C0CF for ; Thu, 11 Feb 2010 09:51:07 -0800 (PST) Received: from [192.168.40.18] ([8.18.34.2]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lsl4T-1Nr12s1Ud7-012b2a; Thu, 11 Feb 2010 12:51:54 -0500 Message-ID: <4B7443AE.9080309@dsauder.com> Date: Thu, 11 Feb 2010 12:51:42 -0500 From: Doug Sauder User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B743CF9.2070108@dsauder.com> <4B743DA0.6010201@nostrum.com> In-Reply-To: <4B743DA0.6010201@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V01U2FsdGVkX1/as4Rc0UaiKEVw5lH00bkplw114QraU/62Bi7 EMMBpW23w+snovUuEbsijMPjioaxigbK4lAmRo1DHYok4Ly7fR ad22FexKVnZ8/UYvhSAVwwt64XN4aZQ Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 11 Feb 2010 17:51:08 -0000 Adam, Dean wanted to argue that the PBX should register its DIDs because it is = expensive to have the DID-to-PBX association changed by the SSP. I=20 meant to suggest that that is not a legitimate reason. I'm sure you know that there is a difference between a registrar=20 receiving a REGISTER request and a statically provisioned IP address. -- Doug Adam Roach wrote: > On 2/11/10 11:23 AM, Doug Sauder wrote: >> Dean, >> >> There is another option that you didn't include: >> >> 4) Alice calls her administrator, who brings up a web page hosted by=20 >> the SSP and changes the selection in a drop-down list from PBX-901 to = >> PBX-400. > > If we can do that, then the administrator can just as easily pull up a = > web page hosted by the SSP and enter their PBX's IP address. > > Voil=E0! The whole MARTINI problem, solved by a web page! > > /a From adam@nostrum.com Thu Feb 11 10:25: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 55C323A786F for ; Thu, 11 Feb 2010 10:25:58 -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.029, 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-qdYwBTbF1d for ; Thu, 11 Feb 2010 10:25: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 189923A786E for ; Thu, 11 Feb 2010 10:25:53 -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 o1BIR3MO060087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 12:27:04 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B744BF7.2080906@nostrum.com> Date: Thu, 11 Feb 2010 12:27:03 -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: Doug Sauder References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B743CF9.2070108@dsauder.com> <4B743DA0.6010201@nostrum.com> <4B7443AE.9080309@dsauder.com> In-Reply-To: <4B7443AE.9080309@dsauder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 11 Feb 2010 18:25:58 -0000 Wait a second... the very existence of MARTINI as a working group is predicated on exactly one fact: we have accepted the assertion that it is impractical -- notably, too expensive -- for SSPs to provision PBX IP addresses into their system. Once we start asserting that these same SSPs allow customer self-provisioning, then the rationale for MARTINI evaporates. In other words: I think we can safely assume that the SSPs that are clamoring for the MARTINI solution have a vanishingly small chance of deploying a self-provisioning system. /a On 2/11/10 11:51, Feb 11, Doug Sauder wrote: > Adam, > > Dean wanted to argue that the PBX should register its DIDs because it > is expensive to have the DID-to-PBX association changed by the SSP. I > meant to suggest that that is not a legitimate reason. > > I'm sure you know that there is a difference between a registrar > receiving a REGISTER request and a statically provisioned IP address. > > -- > Doug > > Adam Roach wrote: >> On 2/11/10 11:23 AM, Doug Sauder wrote: >>> Dean, >>> >>> There is another option that you didn't include: >>> >>> 4) Alice calls her administrator, who brings up a web page hosted by >>> the SSP and changes the selection in a drop-down list from PBX-901 >>> to PBX-400. >> >> If we can do that, then the administrator can just as easily pull up >> a web page hosted by the SSP and enter their PBX's IP address. >> >> Voilà! The whole MARTINI problem, solved by a web page! >> >> /a > From richard@shockey.us Thu Feb 11 10:37: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 D51B93A7874 for ; Thu, 11 Feb 2010 10:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 VVe3n9-1I9ez for ; Thu, 11 Feb 2010 10:37:25 -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 BC9A928C10D for ; Thu, 11 Feb 2010 10:37:25 -0800 (PST) Received: (qmail 28242 invoked by uid 0); 11 Feb 2010 18:38:39 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy8.bluehost.com.bluehost.com with SMTP; 11 Feb 2010 18:38:39 -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=R4KaIrlT24vhrDePMyHDIW3awmt59FzYVDioI+DqyZ16KMOMiAi9zmnykZH4OGJfBQluXktb7j4K3VsEyuP9QJKxrydrYmgKa4hySH6ol3vBefe9ZnzTKXObHPWNh/IP; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nfdvz-0002V9-Br; Thu, 11 Feb 2010 11:38:39 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Doug Sauder'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B743CF9.2070108@dsauder.com> <4B743E31.4000200@cisco.com> In-Reply-To: <4B743E31.4000200@cisco.com> Date: Thu, 11 Feb 2010 13:38:36 -0500 Message-ID: <000901caab49$6cd8f2c0$468ad840$@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: AcqrP5x5PuMGwAGySn2QAGy2qBDN7wACDI0g Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 11 Feb 2010 18:37:26 -0000 Paul .. they are certainly starting to emerge in SMB oriented CLEC space and certainly the Cable Co's are moving in that direction. Cox and Cbeyond for years has had highly competitive products with some innovative self-serve provisioning mechanisms. There are lots of examples of EC Cable Operators drop shipping PBX systems directly to small business customers preconfigured and given to the customer free of charge for a specified service contract. Taking the mobile model to the SMB-PBX space. This entire concept of "Plug n' Dial" has been the business case and philosophy behind the SIP Forum SIP Connect initiative and the participants ( who are all here on this list ) who proposed the MARTINI WG in the first place. The largest constraints for the Plug and Dial SSP model are the lack of standardization of the provisioning mechanism and the lack of real Local Number Portability in the EC and ASIA-Pac. I cannot emphasize enough how important this is to competitive markets for SIP services. Duh its about phone numbers..business will not switch providers if they have to switch their numbers. The sooner we make these things work better..the sooner product fly's off the shelf. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, February 11, 2010 12:28 PM To: Doug Sauder Cc: MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI Doug Sauder wrote: > It really is that simple. I think what Richard is trying to promote, > and which I agree with, is that we're trying to solve the problem of > SSPs who prefer a Walmart-like model: lots of customers and low prices. > The SSPs who charge a fee for every provisioning change will not > survive. The SSPs that can provide self-service options for their > customers will. Such providers exist??? They certainly haven't taken hold in the consumer space. Thanks, Paul _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Fri Feb 12 11:22: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 EF07B3A776A for ; Fri, 12 Feb 2010 11:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.637, 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 NTKofMp0PvxB for ; Fri, 12 Feb 2010 11:22:19 -0800 (PST) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by core3.amsl.com (Postfix) with ESMTP id 2C8393A7736 for ; Fri, 12 Feb 2010 11:22:19 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 11:23:38 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 12 Feb 2010 11:23:37 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EF_01CAABD5.D2892EF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqsGOBs6uEAXLBBRq25IX4do4k/LQ== Content-Language: en-us X-OriginalArrivalTime: 12 Feb 2010 19:23:38.0377 (UTC) FILETIME=[E0C65F90:01CAAC18] Subject: [martini] MARTINI Virtual Interim IV: Cancelled X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 12 Feb 2010 19:22:20 -0000 ------=_NextPart_000_01EF_01CAABD5.D2892EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Due to the difficulty in finding acceptable dates > 2 weeks away from IETF 77, and the modest response to the Doodle Poll, we have decided to cancel MARTINI Virtual Interim IV. Rather than holding another virtual interim, it makes more sense to put energy into preparing for IETF 77, at which MARTINI has requested two sessions. ------=_NextPart_000_01EF_01CAABD5.D2892EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Due to the  difficulty in finding acceptable = dates > 2 weeks away from IETF 77, and the modest response to the Doodle Poll, we = have decided to cancel MARTINI Virtual Interim IV.

 

Rather than holding another virtual interim, it = makes more sense to put energy into preparing for IETF 77, at which MARTINI has = requested two sessions.

 

 

------=_NextPart_000_01EF_01CAABD5.D2892EF0-- From pkyzivat@cisco.com Fri Feb 12 13:01: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 4D06828C228 for ; Fri, 12 Feb 2010 13:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 xax1RAuBnJLC for ; Fri, 12 Feb 2010 13:01:36 -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 1AEEC28C14E for ; Fri, 12 Feb 2010 13:01:36 -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: AvsEAKBQdUtAZnwN/2dsb2JhbACbAXSnaZdIgkyCDASDEw X-IronPort-AV: E=Sophos;i="4.49,463,1262563200"; d="scan'208";a="85851465" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2010 21:02:55 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1CL2rRw013251; Fri, 12 Feb 2010 21:02:53 GMT Message-ID: <4B75C1FD.1080300@cisco.com> Date: Fri, 12 Feb 2010 16:02:53 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us> <4B71D6BB.4080304@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "martini@ietf.org" Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 12 Feb 2010 21:01:37 -0000 I've been ignoring this thread because it was going too fast for me to keep up. I think it has finally died down and I just read all the posts. I think terminal mobility is an interesting problem/feature. But I agree with John that there is more to it than the registration problem. I've been through this with some proprietary implementations, and there are lots of approaches, governed by many things including a lot of non-technical ones. Some cases that seem to beg for different sorts of solutions: - temporary moves vs. permanent moves. - "services" (like VM) shared between multiple pbxes vs. dedicated to specific pbx. - pbxes in the same geography, where the numbers are "local" to both, vs. pbxes further removed from one another So I'm inclined to punt this issue right now. Thanks, Paul Elwell, John wrote: > Adam, > > I don't believe this is about terminal mobility between PBXs, as I have > detailed in another thread. Although inter-PBX mobility is an issue for > which we don't necessarily have all the answers at present, I don' think > dynamic changing of the set of AORs registered through MARTINI is a > necessary and sufficient solution. If we were to take on board inter-PBX > mobility, we would also have to take on board inter-PBX internal > enterprise traffic, which would be an explosion of the scope of MARTINI. > > John > > > ------------------------------------------------------------------------ > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] > *On Behalf Of *Adam Roach > *Sent:* 09 February 2010 21:42 > *To:* Richard Shockey > *Cc:* martini@ietf.org > *Subject:* Re: [martini] Explicit DID indication in REGISTER > > On 2/9/10 13:42, Feb 9, Richard Shockey wrote: >> >> In addition A. the IETF isn’t very good at provisioning issues (I >> could say some things about CUA Config) . B. there are lots of >> proprietary solutions out there that vendors use. Though the goal >> is laudable I just haven’t seen the SSP-PBX vendors agree that the >> pain point are sufficient to try and standardize the solution for >> a comprehensive plug and play solution. >> > > We're certainly in agreement that this mechanism isn't the way to > provisioning. > > But this issue is about much more than provisioning. I agree that > some unrelated provisioning action is required to let each side know > what extensions are associated with a customer. > > On one end, this is about intermediary behavior. On the other, it is > about terminal mobility between PBXes. > > /a > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From christer.holmberg@ericsson.com Fri Feb 12 14:25: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 194113A6F43 for ; Fri, 12 Feb 2010 14:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=-0.365, 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 UmLFyJFMpfrk for ; Fri, 12 Feb 2010 14:25:54 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F1A5C3A6AD0 for ; Fri, 12 Feb 2010 14:25:53 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-0b-4b75d5c00adc Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4E.79.31641.0C5D57B4; Fri, 12 Feb 2010 23:27:12 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.147]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 12 Feb 2010 23:27:12 +0100 From: Christer Holmberg To: 'Adam Roach' , Paul Kyzivat Date: Fri, 12 Feb 2010 23:27:12 +0100 Thread-Topic: [martini] GIN Draft Thread-Index: AcqpNQ6m8+rBc+bWT82VQ50UtugHKQC/OqRw Message-ID: References: <4B68BEB4.2020207@nostrum.com> <4B6C3C26.80908@cisco.com> <4B6C5304.9070605@nostrum.com> <4B6C59D1.20706@cisco.com> <4B6C7232.4090009@nostrum.com> <4B70C117.4090900@cisco.com> <4B70D17C.7050601@nostrum.com> In-Reply-To: <4B70D17C.7050601@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 Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 12 Feb 2010 22:25:55 -0000 Hi,=20 >>>>>> * Need for Proxy-Require >>>>>> >>>>>> You say we need because we are altering the semantics of REGISTER.=20 >>>>>> But which semantics of register *that pertain to proxies* are we=20 >>>>>> altering? >>>>> >>>>> Policy decisions that have historically applied to a single AOR=20 >>>>> will now be applied to REGISTER transactions that pertain to=20 >>>>> multiple AORs. That's a change. >>>>> >>>>> Really: why else are you going to have proxies between the PBX and=20 >>>>> the SSP? It pretty much comes down to NAT traversal and application=20 >>>>> of policy. >>>> >>>> AFAIK all of these things are making leaps of faith that aren't=20 >>>> supported by the standards. >>> >>> I think RFCs 3327 and 3608 actually provide such support, after a=20 >>> fashion. They're designed explicitly to put proxies in the path at=20 >>> registration time. What are these proxies ostensibly used for? >> >> Putting a proxy in the path doesn't say anything about why it is there. >> (Maybe just for data gathering/monitoring, ...) >> >> There is still nothing that justifies such a proxy making assumptions=20 >> such as: "only the registered contact will validly appear in outgoing=20 >> requests on this path". > >Or something less broken (although admittedly more baroque) like: "I know = AOR sip:+12145550107@foo.com needs to go through proxy Y, so I'll add it to= the Path list." Such text exists in RFC 5626: Section 5.1 says: "When an edge proxy receives a registration request with a "reg-id" header field parameter in the Contact header field, it needs to determine if it (the edge proxy) will have to be visited for any subsequent requests sent to the User Agent identified in the Contact header field, or not." Regards, Christer From christer.holmberg@ericsson.com Sat Feb 13 05:23: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 0F5A628C0F3 for ; Sat, 13 Feb 2010 05:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=-0.356, 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 0y-fGZ+rANQa for ; Sat, 13 Feb 2010 05:23:13 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 85ECF3A79C5 for ; Sat, 13 Feb 2010 05:23:12 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-3d-4b76a81186eb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5F.77.31641.118A67B4; Sat, 13 Feb 2010 14:24:33 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.147]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sat, 13 Feb 2010 14:24:32 +0100 From: Christer Holmberg To: 'Spencer Dawkins' , MARTINI Date: Sat, 13 Feb 2010 14:24:32 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqqio+53lUHNQAOSZ2lLlTWxHhdcQCJE8fQ Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.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: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC743F2509AD4DESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] DID Number Mobility and 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: Sat, 13 Feb 2010 13:23:14 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC743F2509AD4DESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was thinking about the same as Dean, whether it could be seen as a normal= forking case, where a single user (again, I think the PBX is seen as a sin= gle user from the SIP core perspectiv, but let's not go into that here and = now) registers multiple contacts for the same AOR. A major advantage would be that we would not trigger SIP registration updat= es towards the SSP every time a PBX user is "roaming". Regards, Christer ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Spencer Dawkins Sent: 10. helmikuuta 2010 21:52 To: MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI So, the obvious question (to me as co-chair) is, "does this just work like = two UAs that register diffferent contacts for the same AOR, or would we nee= d to say anything about it in MARTINI documents?" Any thoughts? Spencer, speaking as co-chair ----- Original Message ----- From: Jack Burton To: MARTINI Sent: Wednesday, February 10, 2010 1:31 PM Subject: Re: [martini] DID Number Mobility and MARTINI An excellent point. The SSP could implicitly register the entire list of PBX-A and PBX-B phone = numbers when EITHER of them registers. Problem solved. Well, the problem = of PBX-B knowing what to do when a PBX-A phone hooks up remains out of scop= e. Invites from either PBX involving any of the DIDs would be honored. Outbound calls to any DID (assuming both PBXs are online and registered) wo= uld be forked to both. This seems kind of silly, but if it will get us moving along, I'm OK with i= t. -Jack >>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >>%202/10/2010%2011:26%20>>> It might be entirely reasonable for Alice's phone number to be registered simultaneously at A and B. We have this thing called "forking" that I've always wanted to get rid of, but can't seem to shake. -- -------------------------------------------------------- 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. -------------------------------------------------------- ________________________________ _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini --_000_FF84A09F50A6DC48ACB6714F4666CC743F2509AD4DESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 <= /DIV>
I was thinking= about the=20 same as Dean, whether it could be seen as a normal forking case, where a si= ngle=20 user (again, I think the PBX is seen as a single user from the SIP core=20 perspectiv, but let's not go into that here and now) registers multiple con= tacts=20 for the same AOR.
 <= /DIV>
A major a= dvantage=20 would be that we would not trigger SIP registration updates towards th= e SSP=20 every time a PBX user is "roaming".
 <= /DIV>
Regards,
 <= /DIV>
Christer

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] = On=20 Behalf Of Spencer Dawkins
Sent: 10. helmikuuta 2010=20 21:52
To: MARTINI
Subject: Re: [martini] DID Number Mob= ility=20 and MARTINI

So, the obvious question (to me as co-chair= ) is,=20 "does this just work like two UAs that register diffferent contacts for the= same=20 AOR, or would we need to say anything about it in MARTINI=20 documents?"
 
Any thoughts?
 
Spencer, speaking as co-chair
----- Original Message -----
Fro= m:=20 Jack=20 Burton
To: MARTINI
Sent: Wednesday, February 10, 2010= 1:31=20 PM
Subject: Re: [martini] DID Number= =20 Mobility and MARTINI

An excellent point.
 
The SSP could implicitly register the entire list of PBX-A and PBX-B= =20 phone numbers when EITHER of them registers.  Problem solved.  = Well,=20 the problem of PBX-B knowing what to do when a PBX-A phone hooks up remai= ns=20 out of scope.
 
Invites from either PBX involving any of the DIDs would be honored.<= /DIV>
Outbound calls to any DID (assuming both PBXs are online and registe= red)=20 would be forked to both.
 
This seems kind of silly, but if it will get us moving along, I= 'm OK=20 with it.
-Jack

>>> Dean Willis 2/10/2010 11:26 >>">dean.willis= @softarmor.com>=20 2/10/2010 11:26 >>

It might be entirely reasonable for=20 Alice's phone number to be 
registered simultaneously at A and B= . We=20 have this thing called 
"forking" that I've always wanted to get= rid=20 of, but can't seem to =20
shake.

--

-------------------------------------------= -------------=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 revie= w,=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 int= ended=20 recipient is prohibited and may be unlawful. If you received this in erro= r,=20 please contact the sender immediately and delete and destroy the communic= ation=20 and all of the attachments you have received and all copies thereof.=20
--------------------------------------------------------=20

_______________________________________________
martini mailing= =20 list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
--_000_FF84A09F50A6DC48ACB6714F4666CC743F2509AD4DESESSCMS0354e_-- From christer.holmberg@ericsson.com Sat Feb 13 05:29: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 0CD953A70E2 for ; Sat, 13 Feb 2010 05:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+rEjChzSnez for ; Sat, 13 Feb 2010 05:29:13 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id ECCD43A6A6B for ; Sat, 13 Feb 2010 05:29:12 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-bc-4b76a97adc9e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D4.B7.31641.A79A67B4; Sat, 13 Feb 2010 14:30:34 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.147]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Sat, 13 Feb 2010 14:30:34 +0100 From: Christer Holmberg To: 'Adam Roach' , Doug Sauder Date: Sat, 13 Feb 2010 14:30:33 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqrP0giLaog20D6QVqhTkH7DMsWOwBcOoHA Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B743CF9.2070108@dsauder.com> <4B743DA0.6010201@nostrum.com> In-Reply-To: <4B743DA0.6010201@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-Brightmail-Tracker: AAAAAA== Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Sat, 13 Feb 2010 13:29:14 -0000 Hi, Well, you could use a web based mechanism where the PBXs contact the SSP be= hind which contact a specific user is, and the SSP can use that to make for= king decissions. The good thing with 3261 is that it doesn't say how forkin= g decissions must be made :) Another way is to simply paralell fork inbound request to every PBX contact= , and all but one should return a "dude, the user is not here" response. However, I don't think it solves the core MARTINI problem, because there ma= y be many reasons why the PBXs want to use SIP registration to register the= PBXs. Regards, Christer =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 11. helmikuuta 2010 19:26 To: Doug Sauder Cc: MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI On 2/11/10 11:23 AM, Doug Sauder wrote: > Dean, > > There is another option that you didn't include: > > 4) Alice calls her administrator, who brings up a web page hosted by=20 > the SSP and changes the selection in a drop-down list from PBX-901 to=20 > PBX-400. If we can do that, then the administrator can just as easily pull up a web = page hosted by the SSP and enter their PBX's IP address. Voil=E0! The whole MARTINI problem, solved by a web page! /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Sun Feb 14 12:09: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 5F4FD3A6870 for ; Sun, 14 Feb 2010 12:09:47 -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 ORpD9kpc0Qbp for ; Sun, 14 Feb 2010 12:09:42 -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 942CC3A72D9 for ; Sun, 14 Feb 2010 12:09:42 -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: AvsEAN7nd0tAZnwN/2dsb2JhbACbHXSlDJZWhFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,472,1262563200"; d="scan'208";a="85968537" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Feb 2010 20:11:09 +0000 Received: from [10.86.251.81] (bxb-vpn3-849.cisco.com [10.86.251.81]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1EKB9H1011340; Sun, 14 Feb 2010 20:11:09 GMT Message-ID: <4B7858E0.90602@cisco.com> Date: Sun, 14 Feb 2010 15:11:12 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MARTINI Subject: Re: [martini] DID Number Mobility and 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: Sun, 14 Feb 2010 20:09:47 -0000 This seems like a straightforward approach. Some obviouls drawbacks to it are: - sounds like many SSPs don't support forking like this. - all calls will be delivered to all the related pbxes, increasing the amount of signaling that must be handled on both the SSP and pbx sides. - unless their is coordination between the pbxes, it seems highly likely that in some cases one may answer with VM while another is alerting. (At least I would expect if my phone was off/ not connected to my PBX then the pbx ought to provide VM or an announcement.) Bottom line - there are a lot of aspects to getting such a mobility feature to work right. The registration aspects are just one part of that. Thanks, Paul Christer Holmberg wrote: > > Hi, > > I was thinking about the same as Dean, whether it could be seen as a > normal forking case, where a single user (again, I think the PBX is seen > as a single user from the SIP core perspectiv, but let's not go into > that here and now) registers multiple contacts for the same AOR. > > A major advantage would be that we would not trigger SIP registration > updates towards the SSP every time a PBX user is "roaming". > > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Spencer Dawkins > *Sent:* 10. helmikuuta 2010 21:52 > *To:* MARTINI > *Subject:* Re: [martini] DID Number Mobility and MARTINI > > So, the obvious question (to me as co-chair) is, "does this just work > like two UAs that register diffferent contacts for the same AOR, or > would we need to say anything about it in MARTINI documents?" > > Any thoughts? > > Spencer, speaking as co-chair > > ----- Original Message ----- > *From:* Jack Burton > *To:* MARTINI > *Sent:* Wednesday, February 10, 2010 1:31 PM > *Subject:* Re: [martini] DID Number Mobility and MARTINI > > An excellent point. > > The SSP could implicitly register the entire list of PBX-A and PBX-B > phone numbers when EITHER of them registers. Problem solved. Well, > the problem of PBX-B knowing what to do when a PBX-A phone hooks up > remains out of scope. > > Invites from either PBX involving any of the DIDs would be honored. > Outbound calls to any DID (assuming both PBXs are online and > registered) would be forked to both. > > This seems kind of silly, but if it will get us moving along, I'm OK > with it. > -Jack > > >>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >> > 2/10/2010 11:26 >>> > > It might be entirely reasonable for Alice's phone number to be > registered simultaneously at A and B. We have this thing called > "forking" that I've always wanted to get rid of, but can't seem to > shake. > > -- > > -------------------------------------------------------- > 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. > -------------------------------------------------------- > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 christer.holmberg@ericsson.com Sun Feb 14 12:30: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 62E413A6F88 for ; Sun, 14 Feb 2010 12:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=-0.338, 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 hLQMsLfV+GGE for ; Sun, 14 Feb 2010 12:30:43 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D2A8628C10B for ; Sun, 14 Feb 2010 12:30:42 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-08-4b785dc80a27 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C3.BF.02429.8CD587B4; Sun, 14 Feb 2010 21:32:08 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 14 Feb 2010 21:32:08 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.147]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Sun, 14 Feb 2010 21:32:08 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Sun, 14 Feb 2010 21:32:07 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqtsdrPwpMQQGhyTQ2/xtxZJp8h8QAATBDM Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> , <4B7858E0.90602@cisco.com> In-Reply-To: <4B7858E0.90602@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 Subject: Re: [martini] DID Number Mobility and 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: Sun, 14 Feb 2010 20:30:47 -0000 Hi, >This seems like a straightforward approach. Some obviouls drawbacks to >it are: >- sounds like many SSPs don't support forking like this. True. But, the point was that the forking mechanism would not require any m= ultiple PBX specific work, since it's part of basic SIP. >- all calls will be delivered to all the related pbxes, increasing > the amount of signaling that must be handled on both the SSP and > pbx sides. Not necessarily. The SSP could do serial forking, based on whatever priorit= y logic (or, as I said in my reply to Adam, some non-registration PBX-SSP c= ommunication mechanism). >- unless their is coordination between the pbxes, it seems highly > likely that in some cases one may answer with VM while another > is alerting. (At least I would expect if my phone was off/ not > connected to my PBX then the pbx ought to provide VM or an > announcement.) That could of course happen, yes. >Bottom line - there are a lot of aspects to getting such a mobility featur= e to work right. The registration aspects are just one part of that. Sure. The question is whether the non-registration aspects are within the s= cope of MARTINI. Regards, Christer Christer Holmberg wrote: > > Hi, > > I was thinking about the same as Dean, whether it could be seen as a > normal forking case, where a single user (again, I think the PBX is seen > as a single user from the SIP core perspectiv, but let's not go into > that here and now) registers multiple contacts for the same AOR. > > A major advantage would be that we would not trigger SIP registration > updates towards the SSP every time a PBX user is "roaming". > > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Spencer Dawkins > *Sent:* 10. helmikuuta 2010 21:52 > *To:* MARTINI > *Subject:* Re: [martini] DID Number Mobility and MARTINI > > So, the obvious question (to me as co-chair) is, "does this just work > like two UAs that register diffferent contacts for the same AOR, or > would we need to say anything about it in MARTINI documents?" > > Any thoughts? > > Spencer, speaking as co-chair > > ----- Original Message ----- > *From:* Jack Burton > *To:* MARTINI > *Sent:* Wednesday, February 10, 2010 1:31 PM > *Subject:* Re: [martini] DID Number Mobility and MARTINI > > An excellent point. > > The SSP could implicitly register the entire list of PBX-A and PBX-B > phone numbers when EITHER of them registers. Problem solved. Well, > the problem of PBX-B knowing what to do when a PBX-A phone hooks up > remains out of scope. > > Invites from either PBX involving any of the DIDs would be honored. > Outbound calls to any DID (assuming both PBXs are online and > registered) would be forked to both. > > This seems kind of silly, but if it will get us moving along, I'm OK > with it. > -Jack > > >>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >> > 2/10/2010 11:26 >>> > > It might be entirely reasonable for Alice's phone number to be > registered simultaneously at A and B. We have this thing called > "forking" that I've always wanted to get rid of, but can't seem to > shake. > > -- > > -------------------------------------------------------- > 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. > -------------------------------------------------------- > > ---------------------------------------------------------------------= --- > > _______________________________________________ > 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 Mon Feb 15 11:40: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 38AE83A7BCF for ; Mon, 15 Feb 2010 11:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 XMkvRKYp5Q+U for ; Mon, 15 Feb 2010 11:40:58 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 6AA6628C25C for ; Mon, 15 Feb 2010 11:40:57 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQiRh-1NFNmT3fn3-00Uiam; Mon, 15 Feb 2010 14:42:24 -0500 Message-ID: <9C91E78253724086BA827FEA0501524A@china.huawei.com> From: "Spencer Dawkins" To: "Paul Kyzivat" , "Elwell, John" References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> Date: Mon, 15 Feb 2010 13:42:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response 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: V01U2FsdGVkX18s+9yEWZSp99mrSijx6IisgTjXiR55H3OyDtT ZXEtrh8vwDlpptPmuB06NJ9iEHKlrkdb5sdNduwsxQyXHUhTZ/ yYSGEYLsmdLqp+rZcGg6+YluttjFhpEnHRPo9abiRI= Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Feb 2010 19:40:59 -0000 Bernard and I talked this past weekend, and we both think that the question on mobility is the major open issue that we need to close before asking to adopt the next version of GIN as a working group draft. Speaking as an individual, I'm inclined to punt on this topic as well, because I agree with Paul that this isn't a small anount of work, and MARTINI would be useful without it. In conversations I've been involved with, over the past couple of years (I'm new here), I don't even think we have agreement on which end of the protocol "knows" the information it will be passing to the other end using MARTINI signaling. I've been in conversations with service providers who say "we have to know about the phone numbers, because we have to be able to route them anyway, so we can configure a blank-slate SIP-PBX that someone bought at Walmart". I've been in conversations with SIP-PBX providers who say "we have to configure all the AoRs because we have to define what services are available, etc. so we can configure what we want the SPs to route to us". It does not seem that we're close to consensus on this topic. It might be possible to say "here's what I think you have for me"/"here's what I actually have for you", and define possible ways to recover if those two lists don't agree, but I'm not sure what more we could do. Other points of view, before Bernard and I declare consensus? Please speak quickly... Thanks, Spencer ----- Original Message ----- From: "Paul Kyzivat" To: "Elwell, John" Cc: Sent: Friday, February 12, 2010 3:02 PM Subject: Re: [martini] Explicit DID indication in REGISTER I've been ignoring this thread because it was going too fast for me to keep up. I think it has finally died down and I just read all the posts. I think terminal mobility is an interesting problem/feature. But I agree with John that there is more to it than the registration problem. I've been through this with some proprietary implementations, and there are lots of approaches, governed by many things including a lot of non-technical ones. Some cases that seem to beg for different sorts of solutions: - temporary moves vs. permanent moves. - "services" (like VM) shared between multiple pbxes vs. dedicated to specific pbx. - pbxes in the same geography, where the numbers are "local" to both, vs. pbxes further removed from one another So I'm inclined to punt this issue right now. Thanks, Paul Elwell, John wrote: > Adam, > I don't believe this is about terminal mobility between PBXs, as I have > detailed in another thread. Although inter-PBX mobility is an issue for > which we don't necessarily have all the answers at present, I don' think > dynamic changing of the set of AORs registered through MARTINI is a > necessary and sufficient solution. If we were to take on board inter-PBX > mobility, we would also have to take on board inter-PBX internal > enterprise traffic, which would be an explosion of the scope of MARTINI. > John > > ------------------------------------------------------------------------ > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] > *On Behalf Of *Adam Roach > *Sent:* 09 February 2010 21:42 > *To:* Richard Shockey > *Cc:* martini@ietf.org > *Subject:* Re: [martini] Explicit DID indication in REGISTER > > On 2/9/10 13:42, Feb 9, Richard Shockey wrote: >> >> In addition A. the IETF isn’t very good at provisioning issues (I >> could say some things about CUA Config) . B. there are lots of >> proprietary solutions out there that vendors use. Though the goal >> is laudable I just haven’t seen the SSP-PBX vendors agree that the >> pain point are sufficient to try and standardize the solution for >> a comprehensive plug and play solution. >> > > We're certainly in agreement that this mechanism isn't the way to > provisioning. > > But this issue is about much more than provisioning. I agree that > some unrelated provisioning action is required to let each side know > what extensions are associated with a customer. > > On one end, this is about intermediary behavior. On the other, it is > about terminal mobility between PBXes. > > /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 john.elwell@siemens-enterprise.com Mon Feb 15 12:28: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 5787928C287 for ; Mon, 15 Feb 2010 12:28:42 -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 eP9ANGF8MkFf for ; Mon, 15 Feb 2010 12:28:41 -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 91E0828C288 for ; Mon, 15 Feb 2010 12:28:40 -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-896190; Mon, 15 Feb 2010 21:30:11 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0A15323F0278; Mon, 15 Feb 2010 21:30:11 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 15 Feb 2010 21:30:10 +0100 From: "Elwell, John" To: Spencer Dawkins , Paul Kyzivat Date: Mon, 15 Feb 2010 21:30:08 +0100 Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: Acqudw/HtvOMaoItRF+3Ga18Kmhv6AABo7Bw Message-ID: References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> In-Reply-To: <9C91E78253724086BA827FEA0501524A@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] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Feb 2010 20:28:42 -0000 I agree the mobility question is outside the scope of MARTINI. John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 15 February 2010 19:42 > To: Paul Kyzivat; Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] Explicit DID indication in REGISTER >=20 > Bernard and I talked this past weekend, and we both think=20 > that the question=20 > on mobility is the major open issue that we need to close=20 > before asking to=20 > adopt the next version of GIN as a working group draft. >=20 > Speaking as an individual, I'm inclined to punt on this topic=20 > as well,=20 > because I agree with Paul that this isn't a small anount of work, and=20 > MARTINI would be useful without it. >=20 > In conversations I've been involved with, over the past=20 > couple of years (I'm=20 > new here), I don't even think we have agreement on which end=20 > of the protocol=20 > "knows" the information it will be passing to the other end=20 > using MARTINI=20 > signaling. >=20 > I've been in conversations with service providers who say "we=20 > have to know=20 > about the phone numbers, because we have to be able to route=20 > them anyway, so=20 > we can configure a blank-slate SIP-PBX that someone bought at=20 > Walmart". >=20 > I've been in conversations with SIP-PBX providers who say "we have to=20 > configure all the AoRs because we have to define what services are=20 > available, etc. so we can configure what we want the SPs to=20 > route to us". >=20 > It does not seem that we're close to consensus on this topic.=20 > It might be=20 > possible to say "here's what I think you have for me"/"here's what I=20 > actually have for you", and define possible ways to recover=20 > if those two=20 > lists don't agree, but I'm not sure what more we could do. >=20 > Other points of view, before Bernard and I declare consensus?=20 > Please speak=20 > quickly... >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message -----=20 > From: "Paul Kyzivat" > To: "Elwell, John" > Cc: > Sent: Friday, February 12, 2010 3:02 PM > Subject: Re: [martini] Explicit DID indication in REGISTER >=20 >=20 > I've been ignoring this thread because it was going too fast for me to > keep up. I think it has finally died down and I just read all=20 > the posts. >=20 > I think terminal mobility is an interesting problem/feature.=20 > But I agree > with John that there is more to it than the registration problem. I've > been through this with some proprietary implementations, and there are > lots of approaches, governed by many things including a lot of > non-technical ones. >=20 > Some cases that seem to beg for different sorts of solutions: >=20 > - temporary moves vs. permanent moves. > - "services" (like VM) shared between multiple pbxes > vs. dedicated to specific pbx. > - pbxes in the same geography, where the numbers are "local" > to both, vs. pbxes further removed from one another >=20 > So I'm inclined to punt this issue right now. >=20 > Thanks, > Paul >=20 > Elwell, John wrote: > > Adam, > > I don't believe this is about terminal mobility between=20 > PBXs, as I have=20 > > detailed in another thread. Although inter-PBX mobility is=20 > an issue for=20 > > which we don't necessarily have all the answers at present,=20 > I don' think=20 > > dynamic changing of the set of AORs registered through MARTINI is a=20 > > necessary and sufficient solution. If we were to take on=20 > board inter-PBX=20 > > mobility, we would also have to take on board inter-PBX internal=20 > > enterprise traffic, which would be an explosion of the=20 > scope of MARTINI. > > John > > > > =20 > -------------------------------------------------------------- > ---------- > > *From:* martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] > > *On Behalf Of *Adam Roach > > *Sent:* 09 February 2010 21:42 > > *To:* Richard Shockey > > *Cc:* martini@ietf.org > > *Subject:* Re: [martini] Explicit DID indication in REGISTER > > > > On 2/9/10 13:42, Feb 9, Richard Shockey wrote: > >> > >> In addition A. the IETF isn't very good at=20 > provisioning issues (I > >> could say some things about CUA Config) . B. there are lots of > >> proprietary solutions out there that vendors use.=20 > Though the goal > >> is laudable I just haven't seen the SSP-PBX vendors=20 > agree that the > >> pain point are sufficient to try and standardize the=20 > solution for > >> a comprehensive plug and play solution. > >> > > > > We're certainly in agreement that this mechanism isn't=20 > the way to > > provisioning. > > > > But this issue is about much more than provisioning. I=20 > agree that > > some unrelated provisioning action is required to let=20 > each side know > > what extensions are associated with a customer. > > > > On one end, this is about intermediary behavior. On the=20 > other, it is > > about terminal mobility between PBXes. > > > > /a > > > > > >=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 >=20 > = From richard@shockey.us Mon Feb 15 12:36: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 EF7E43A7BDA for ; Mon, 15 Feb 2010 12:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 Elm9MVA-NegI for ; Mon, 15 Feb 2010 12:36:32 -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 8059C3A7BD9 for ; Mon, 15 Feb 2010 12:36:32 -0800 (PST) Received: (qmail 5876 invoked by uid 0); 15 Feb 2010 20:38:04 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 15 Feb 2010 20:38:04 -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=lOnZhTd7xueIm/sS+mZ6TbEOhnrRvUtBdYcoMnGxErF1gPBBkIZurZ783GcT0hONnSV2OM5GUbx5PuptLQ0CMGEcOHs/eYYaVRBJmX1cdSIfWDzlWEkGiGvAjNGg2DHh; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nh7hi-0004Cs-Es; Mon, 15 Feb 2010 13:38:04 -0700 From: "Richard Shockey" To: "'Elwell, John'" , "'Spencer Dawkins'" , "'Paul Kyzivat'" References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> In-Reply-To: Date: Mon, 15 Feb 2010 15:37:59 -0500 Message-ID: <00ae01caae7e$c3c2db40$4b4891c0$@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: Acqudw/HtvOMaoItRF+3Ga18Kmhv6AABo7BwAABFOpA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Feb 2010 20:36:34 -0000 +1 .. out of scope -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: Monday, February 15, 2010 3:30 PM To: Spencer Dawkins; Paul Kyzivat Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER I agree the mobility question is outside the scope of MARTINI. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 15 February 2010 19:42 > To: Paul Kyzivat; Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] Explicit DID indication in REGISTER > > Bernard and I talked this past weekend, and we both think > that the question > on mobility is the major open issue that we need to close > before asking to > adopt the next version of GIN as a working group draft. > > Speaking as an individual, I'm inclined to punt on this topic > as well, > because I agree with Paul that this isn't a small anount of work, and > MARTINI would be useful without it. > > In conversations I've been involved with, over the past > couple of years (I'm > new here), I don't even think we have agreement on which end > of the protocol > "knows" the information it will be passing to the other end > using MARTINI > signaling. > > I've been in conversations with service providers who say "we > have to know > about the phone numbers, because we have to be able to route > them anyway, so > we can configure a blank-slate SIP-PBX that someone bought at > Walmart". > > I've been in conversations with SIP-PBX providers who say "we have to > configure all the AoRs because we have to define what services are > available, etc. so we can configure what we want the SPs to > route to us". > > It does not seem that we're close to consensus on this topic. > It might be > possible to say "here's what I think you have for me"/"here's what I > actually have for you", and define possible ways to recover > if those two > lists don't agree, but I'm not sure what more we could do. > > Other points of view, before Bernard and I declare consensus? > Please speak > quickly... > > Thanks, > > Spencer > > ----- Original Message ----- > From: "Paul Kyzivat" > To: "Elwell, John" > Cc: > Sent: Friday, February 12, 2010 3:02 PM > Subject: Re: [martini] Explicit DID indication in REGISTER > > > I've been ignoring this thread because it was going too fast for me to > keep up. I think it has finally died down and I just read all > the posts. > > I think terminal mobility is an interesting problem/feature. > But I agree > with John that there is more to it than the registration problem. I've > been through this with some proprietary implementations, and there are > lots of approaches, governed by many things including a lot of > non-technical ones. > > Some cases that seem to beg for different sorts of solutions: > > - temporary moves vs. permanent moves. > - "services" (like VM) shared between multiple pbxes > vs. dedicated to specific pbx. > - pbxes in the same geography, where the numbers are "local" > to both, vs. pbxes further removed from one another > > So I'm inclined to punt this issue right now. > > Thanks, > Paul > > Elwell, John wrote: > > Adam, > > I don't believe this is about terminal mobility between > PBXs, as I have > > detailed in another thread. Although inter-PBX mobility is > an issue for > > which we don't necessarily have all the answers at present, > I don' think > > dynamic changing of the set of AORs registered through MARTINI is a > > necessary and sufficient solution. If we were to take on > board inter-PBX > > mobility, we would also have to take on board inter-PBX internal > > enterprise traffic, which would be an explosion of the > scope of MARTINI. > > John > > > > > -------------------------------------------------------------- > ---------- > > *From:* martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] > > *On Behalf Of *Adam Roach > > *Sent:* 09 February 2010 21:42 > > *To:* Richard Shockey > > *Cc:* martini@ietf.org > > *Subject:* Re: [martini] Explicit DID indication in REGISTER > > > > On 2/9/10 13:42, Feb 9, Richard Shockey wrote: > >> > >> In addition A. the IETF isn't very good at > provisioning issues (I > >> could say some things about CUA Config) . B. there are lots of > >> proprietary solutions out there that vendors use. > Though the goal > >> is laudable I just haven't seen the SSP-PBX vendors > agree that the > >> pain point are sufficient to try and standardize the > solution for > >> a comprehensive plug and play solution. > >> > > > > We're certainly in agreement that this mechanism isn't > the way to > > provisioning. > > > > But this issue is about much more than provisioning. I > agree that > > some unrelated provisioning action is required to let > each side know > > what extensions are associated with a customer. > > > > On one end, this is about intermediary behavior. On the > other, it is > > about terminal mobility between PBXes. > > > > /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 bernard_aboba@hotmail.com Mon Feb 15 14:42: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 2215F3A7A63 for ; Mon, 15 Feb 2010 14:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.663, 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 OId3OQ4DEaoO for ; Mon, 15 Feb 2010 14:42:53 -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 D85FE3A7BD5 for ; Mon, 15 Feb 2010 14:42:52 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.72]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 14:44:24 -0800 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Paul Kyzivat'" , "'Christer Holmberg'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> In-Reply-To: <4B7858E0.90602@cisco.com> Date: Mon, 15 Feb 2010 14:44:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRp1VZdj52hPuOrHnBQHHahqJ91AImR3jnArAcgWEBK5n+SgGuzU+IAhvemikCbKt+BY9YBQuQ Content-Language: en-us X-OriginalArrivalTime: 15 Feb 2010 22:44:24.0551 (UTC) FILETIME=[6C17E770:01CAAE90] Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Mon, 15 Feb 2010 22:42:54 -0000 Speaking as co-chair, the non-registration aspects of DID number mobility are outside the scope of the current MARTINI WG charter. The question on the table (see http://www.ietf.org/mail-archive/web/martini/current/msg00687.html ) is whether the registration aspects represent a requirement or not. Feel free to respond and provide your opinion on that thread. -----Original Message----- From: Christer Holmberg Sent: Sunday, February 14, 2010 12:11 PM To: Paul Kyzivat Cc: MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI Hi, >This seems like a straightforward approach. Some obvious drawbacks to >it are: >- sounds like many SSPs don't support forking like this. True. But, the point was that the forking mechanism would not require any multiple PBX specific work, since it's part of basic SIP. >- all calls will be delivered to all the related pbxes, increasing > the amount of signaling that must be handled on both the SSP and > pbx sides. Not necessarily. The SSP could do serial forking, based on whatever priority logic (or, as I said in my reply to Adam, some non-registration PBX-SSP communication mechanism). >- unless there is coordination between the pbxes, it seems highly > likely that in some cases one may answer with VM while another > is alerting. (At least I would expect if my phone was off/ not > connected to my PBX then the pbx ought to provide VM or an > announcement.) That could of course happen, yes. >Bottom line - there are a lot of aspects to getting such a mobility feature to work right. The registration aspects are just one part of that. Sure. The question is whether the non-registration aspects are within the scope of MARTINI. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Sunday, February 14, 2010 12:11 PM To: Christer Holmberg Cc: MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI This seems like a straightforward approach. Some obvious drawbacks to it are: - sounds like many SSPs don't support forking like this. - all calls will be delivered to all the related pbxes, increasing the amount of signaling that must be handled on both the SSP and pbx sides. - unless there is coordination between the pbxes, it seems highly likely that in some cases one may answer with VM while another is alerting. (At least I would expect if my phone was off/ not connected to my PBX then the pbx ought to provide VM or an announcement.) Bottom line - there are a lot of aspects to getting such a mobility feature to work right. The registration aspects are just one part of that. Thanks, Paul Christer Holmberg wrote: > > Hi, > > I was thinking about the same as Dean, whether it could be seen as a > normal forking case, where a single user (again, I think the PBX is > seen as a single user from the SIP core perspectiv, but let's not go > into that here and now) registers multiple contacts for the same AOR. > > A major advantage would be that we would not trigger SIP registration > updates towards the SSP every time a PBX user is "roaming". > > Regards, > > Christer > > ---------------------------------------------------------------------- > -- > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Spencer Dawkins > *Sent:* 10. helmikuuta 2010 21:52 > *To:* MARTINI > *Subject:* Re: [martini] DID Number Mobility and MARTINI > > So, the obvious question (to me as co-chair) is, "does this just work > like two UAs that register diffferent contacts for the same AOR, or > would we need to say anything about it in MARTINI documents?" > > Any thoughts? > > Spencer, speaking as co-chair > > ----- Original Message ----- > *From:* Jack Burton > *To:* MARTINI > *Sent:* Wednesday, February 10, 2010 1:31 PM > *Subject:* Re: [martini] DID Number Mobility and MARTINI > > An excellent point. > > The SSP could implicitly register the entire list of PBX-A and PBX-B > phone numbers when EITHER of them registers. Problem solved. Well, > the problem of PBX-B knowing what to do when a PBX-A phone hooks up > remains out of scope. > > Invites from either PBX involving any of the DIDs would be honored. > Outbound calls to any DID (assuming both PBXs are online and > registered) would be forked to both. > > This seems kind of silly, but if it will get us moving along, I'm OK > with it. > -Jack > > >>> Dean Willis dean.willis@softarmor.com> 2/10/2010 11:26 >> > 2/10/2010 11:26 >>> > > It might be entirely reasonable for Alice's phone number to be > registered simultaneously at A and B. We have this thing called > "forking" that I've always wanted to get rid of, but can't seem to > shake. > > -- > > -------------------------------------------------------- > 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. > -------------------------------------------------------- > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Feb 15 15:08: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 2ABCC3A7A6E for ; Mon, 15 Feb 2010 15:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 vaZQeLbeQOd2 for ; Mon, 15 Feb 2010 15:08:40 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D772F3A7A6C for ; Mon, 15 Feb 2010 15:08:39 -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 o1FNA3Z27719; Mon, 15 Feb 2010 23:10:03 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, 15 Feb 2010 18:09:36 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C875F39@zcarhxm1.corp.nortel.com> In-Reply-To: <00ae01caae7e$c3c2db40$4b4891c0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: Acqudw/HtvOMaoItRF+3Ga18Kmhv6AABo7BwAABFOpAABUT3sA== References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <00ae01caae7e$c3c2db40$4b4891c0$@us> From: "Brian Lindsay" To: "Richard Shockey" , "Elwell, John" , "Spencer Dawkins" , "Paul Kyzivat" Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Feb 2010 23:08:41 -0000 Hi, Agree with mobility out of scope, and ranges not being included in register transaction. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, February 15, 2010 3:38 PM To: 'Elwell, John'; 'Spencer Dawkins'; 'Paul Kyzivat' Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER +1 .. out of scope -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: Monday, February 15, 2010 3:30 PM To: Spencer Dawkins; Paul Kyzivat Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER I agree the mobility question is outside the scope of MARTINI. John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 15 February 2010 19:42 > To: Paul Kyzivat; Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] Explicit DID indication in REGISTER >=20 > Bernard and I talked this past weekend, and we both think that the=20 > question on mobility is the major open issue that we need to close=20 > before asking to adopt the next version of GIN as a working group=20 > draft. >=20 > Speaking as an individual, I'm inclined to punt on this topic as well, > because I agree with Paul that this isn't a small anount of work, and=20 > MARTINI would be useful without it. >=20 > In conversations I've been involved with, over the past couple of=20 > years (I'm new here), I don't even think we have agreement on which=20 > end of the protocol "knows" the information it will be passing to the=20 > other end using MARTINI signaling. >=20 > I've been in conversations with service providers who say "we have to=20 > know about the phone numbers, because we have to be able to route them > anyway, so we can configure a blank-slate SIP-PBX that someone bought=20 > at Walmart". >=20 > I've been in conversations with SIP-PBX providers who say "we have to=20 > configure all the AoRs because we have to define what services are=20 > available, etc. so we can configure what we want the SPs to route to=20 > us". >=20 > It does not seem that we're close to consensus on this topic.=20 > It might be > possible to say "here's what I think you have for me"/"here's what I=20 > actually have for you", and define possible ways to recover if those=20 > two lists don't agree, but I'm not sure what more we could do. >=20 > Other points of view, before Bernard and I declare consensus?=20 > Please speak > quickly... >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message ----- > From: "Paul Kyzivat" > To: "Elwell, John" > Cc: > Sent: Friday, February 12, 2010 3:02 PM > Subject: Re: [martini] Explicit DID indication in REGISTER >=20 >=20 > I've been ignoring this thread because it was going too fast for me to > keep up. I think it has finally died down and I just read all the=20 > posts. >=20 > I think terminal mobility is an interesting problem/feature.=20 > But I agree > with John that there is more to it than the registration problem. I've > been through this with some proprietary implementations, and there are > lots of approaches, governed by many things including a lot of=20 > non-technical ones. >=20 > Some cases that seem to beg for different sorts of solutions: >=20 > - temporary moves vs. permanent moves. > - "services" (like VM) shared between multiple pbxes > vs. dedicated to specific pbx. > - pbxes in the same geography, where the numbers are "local" > to both, vs. pbxes further removed from one another >=20 > So I'm inclined to punt this issue right now. >=20 > Thanks, > Paul >=20 > Elwell, John wrote: > > Adam, > > I don't believe this is about terminal mobility between > PBXs, as I have > > detailed in another thread. Although inter-PBX mobility is > an issue for > > which we don't necessarily have all the answers at present, > I don' think > > dynamic changing of the set of AORs registered through MARTINI is a=20 > > necessary and sufficient solution. If we were to take on > board inter-PBX > > mobility, we would also have to take on board inter-PBX internal=20 > > enterprise traffic, which would be an explosion of the > scope of MARTINI. > > John > > > > =20 > -------------------------------------------------------------- > ---------- > > *From:* martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] > > *On Behalf Of *Adam Roach > > *Sent:* 09 February 2010 21:42 > > *To:* Richard Shockey > > *Cc:* martini@ietf.org > > *Subject:* Re: [martini] Explicit DID indication in REGISTER > > > > On 2/9/10 13:42, Feb 9, Richard Shockey wrote: > >> > >> In addition A. the IETF isn't very good at > provisioning issues (I > >> could say some things about CUA Config) . B. there are lots of > >> proprietary solutions out there that vendors use.=20 > Though the goal > >> is laudable I just haven't seen the SSP-PBX vendors > agree that the > >> pain point are sufficient to try and standardize the > solution for > >> a comprehensive plug and play solution. > >> > > > > We're certainly in agreement that this mechanism isn't > the way to > > provisioning. > > > > But this issue is about much more than provisioning. I > agree that > > some unrelated provisioning action is required to let > each side know > > what extensions are associated with a customer. > > > > On one end, this is about intermediary behavior. On the > other, it is > > about terminal mobility between PBXes. > > > > /a > > > > > >=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 >=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 From bernard_aboba@hotmail.com Mon Feb 15 15:41: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 3833928C11B for ; Mon, 15 Feb 2010 15:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.656, 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 xNKRiudB9hKy for ; Mon, 15 Feb 2010 15:41:51 -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 06E5E3A7BED for ; Mon, 15 Feb 2010 15:41:50 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.73]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 15:43:23 -0800 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Richard Shockey'" , "'Elwell, John'" , "'Spencer Dawkins'" , "'Paul Kyzivat'" References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <00ae01caae7e$c3c2db40$4b4891c0$@us> In-Reply-To: <00ae01caae7e$c3c2db40$4b4891c0$@us> Date: Mon, 15 Feb 2010 15:43:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGftRsxaJNvfOGuJLGRe857dk6hlgBPBkxuAdNNR3UCHJ7fagCJirTTAeHOG9sBmgs7NgEpJAKPkdJbKyA= Content-Language: en-us X-OriginalArrivalTime: 15 Feb 2010 23:43:23.0154 (UTC) FILETIME=[A943DF20:01CAAE98] Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Feb 2010 23:41:52 -0000 +1. -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Monday, February 15, 2010 12:38 PM To: 'Elwell, John'; 'Spencer Dawkins'; 'Paul Kyzivat' Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER +1 .. out of scope -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: Monday, February 15, 2010 3:30 PM To: Spencer Dawkins; Paul Kyzivat Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER I agree the mobility question is outside the scope of MARTINI. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 15 February 2010 19:42 > To: Paul Kyzivat; Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] Explicit DID indication in REGISTER > > Bernard and I talked this past weekend, and we both think that the > question on mobility is the major open issue that we need to close > before asking to adopt the next version of GIN as a working group > draft. > > Speaking as an individual, I'm inclined to punt on this topic as well, > because I agree with Paul that this isn't a small anount of work, and > MARTINI would be useful without it. > > In conversations I've been involved with, over the past couple of > years (I'm new here), I don't even think we have agreement on which > end of the protocol "knows" the information it will be passing to the > other end using MARTINI signaling. > > I've been in conversations with service providers who say "we have to > know about the phone numbers, because we have to be able to route them > anyway, so we can configure a blank-slate SIP-PBX that someone bought > at Walmart". > > I've been in conversations with SIP-PBX providers who say "we have to > configure all the AoRs because we have to define what services are > available, etc. so we can configure what we want the SPs to route to > us". > > It does not seem that we're close to consensus on this topic. > It might be > possible to say "here's what I think you have for me"/"here's what I > actually have for you", and define possible ways to recover if those > two lists don't agree, but I'm not sure what more we could do. > > Other points of view, before Bernard and I declare consensus? > Please speak > quickly... > > Thanks, > > Spencer > > ----- Original Message ----- > From: "Paul Kyzivat" > To: "Elwell, John" > Cc: > Sent: Friday, February 12, 2010 3:02 PM > Subject: Re: [martini] Explicit DID indication in REGISTER > > > I've been ignoring this thread because it was going too fast for me to > keep up. I think it has finally died down and I just read all the > posts. > > I think terminal mobility is an interesting problem/feature. > But I agree > with John that there is more to it than the registration problem. I've > been through this with some proprietary implementations, and there are > lots of approaches, governed by many things including a lot of > non-technical ones. > > Some cases that seem to beg for different sorts of solutions: > > - temporary moves vs. permanent moves. > - "services" (like VM) shared between multiple pbxes > vs. dedicated to specific pbx. > - pbxes in the same geography, where the numbers are "local" > to both, vs. pbxes further removed from one another > > So I'm inclined to punt this issue right now. > > Thanks, > Paul > > Elwell, John wrote: > > Adam, > > I don't believe this is about terminal mobility between > PBXs, as I have > > detailed in another thread. Although inter-PBX mobility is > an issue for > > which we don't necessarily have all the answers at present, > I don' think > > dynamic changing of the set of AORs registered through MARTINI is a > > necessary and sufficient solution. If we were to take on > board inter-PBX > > mobility, we would also have to take on board inter-PBX internal > > enterprise traffic, which would be an explosion of the > scope of MARTINI. > > John > > > > > -------------------------------------------------------------- > ---------- > > *From:* martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] > > *On Behalf Of *Adam Roach > > *Sent:* 09 February 2010 21:42 > > *To:* Richard Shockey > > *Cc:* martini@ietf.org > > *Subject:* Re: [martini] Explicit DID indication in REGISTER > > > > On 2/9/10 13:42, Feb 9, Richard Shockey wrote: > >> > >> In addition A. the IETF isn't very good at > provisioning issues (I > >> could say some things about CUA Config) . B. there are lots of > >> proprietary solutions out there that vendors use. > Though the goal > >> is laudable I just haven't seen the SSP-PBX vendors > agree that the > >> pain point are sufficient to try and standardize the > solution for > >> a comprehensive plug and play solution. > >> > > > > We're certainly in agreement that this mechanism isn't > the way to > > provisioning. > > > > But this issue is about much more than provisioning. I > agree that > > some unrelated provisioning action is required to let > each side know > > what extensions are associated with a customer. > > > > On one end, this is about intermediary behavior. On the > other, it is > > about terminal mobility between PBXes. > > > > /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 dean.willis@softarmor.com Mon Feb 15 15:59: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 603853A7910 for ; Mon, 15 Feb 2010 15:59:17 -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 M2YgQX8akITY for ; Mon, 15 Feb 2010 15:59:16 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 967523A773D for ; Mon, 15 Feb 2010 15:59:16 -0800 (PST) Received: from [192.168.2.102] (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 o1G00Q5O029792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Feb 2010 18:00:27 -0600 From: Dean Willis To: Spencer Dawkins In-Reply-To: <9C91E78253724086BA827FEA0501524A@china.huawei.com> X-Priority: 3 References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> Message-Id: <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@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: Mon, 15 Feb 2010 18:00:20 -0600 X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 15 Feb 2010 23:59:17 -0000 On Feb 15, 2010, at 1:42 PM, Spencer Dawkins wrote: > Bernard and I talked this past weekend, and we both think that the > question on mobility is the major open issue that we need to close > before asking to adopt the next version of GIN as a working group > draft. I disagree. I think explicit indication of the numbers being registered is the open-question for MARTINI. Explicit registration is required but not sufficient for the mobility scenarios. Doing MARTINI registration without explicit indication will preclude using this mechanism. However, doing the followup work is probably outside of MARTINI's immediate scope. Further, we know from our history that "implicit" is AWLAYS a mistake. We never realize the implications at the time -- it always comes back to bite us later. Perhaps we should learn from this and stop doing implicit stuff. So, I think we should continue with an explicit registration mechanism that is adequate to meet our current needs ASAP, without sawing our legs off for the future. -- Dean From dean.willis@softarmor.com Mon Feb 15 16:05: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 7C67728C144 for ; Mon, 15 Feb 2010 16:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooq1Ltvi0hnc for ; Mon, 15 Feb 2010 16:05:06 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4948B28C122 for ; Mon, 15 Feb 2010 16:05:06 -0800 (PST) Received: from [192.168.2.102] (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 o1G06WY3029849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Feb 2010 18:06:33 -0600 Message-Id: <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> From: Dean Willis To: Bernard Aboba 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: Mon, 15 Feb 2010 18:06:26 -0600 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> X-Mailer: Apple Mail (2.936) Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 00:05:09 -0000 On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > Speaking as co-chair, the non-registration aspects of DID number > mobility > are outside the scope of the current MARTINI WG charter. > > The question on the table (see > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html ) > is > whether the registration aspects represent a requirement or not. > Feel free > to respond and provide your opinion on that thread. Explicit is its own reward. Remember, the one thing that RFC 3261 REGISTER really does is bind an AOR to a Contact. Both the AOR and the Contact involved are explicitly encoded in the request. I'm OKAY with extending REGISTER to bind multiple AORs to multiple Contacts. This seems like a reasonable extension to simplify life for a "multi user" SIP user agent. But I really think we should respect the history of REGISTERs explicit encoding of the AORs and Contacts involved. From a requirements perspective, I'd be happy with a requirement along the lines of "must not preclude AOR mobility indicated by the registration." I agree that we can't justify a requirement to produce a mechanism at the time for the whole enchilada. -- Dean From spencer@wonderhamster.org Mon Feb 15 16:35: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 6B1DC3A7A75 for ; Mon, 15 Feb 2010 16:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 4lLydCq+6Dj0 for ; Mon, 15 Feb 2010 16:35:44 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 921F83A71D3 for ; Mon, 15 Feb 2010 16:35:44 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LcSJK-1O947l1AZC-00jBtO; Mon, 15 Feb 2010 19:37:08 -0500 Message-ID: <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> Date: Mon, 15 Feb 2010 18:36:57 -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: V01U2FsdGVkX19jqgKWj7xXN03KmgWcyZwg4RlkoSYQ35fhfdI 8UdKumMZpW6x+0jQyuZ6wIo7j3zYecCPnXojSPjwyhfGISX5aR ycUbIYrTCMyF2twhTK0jG1lP6MJYecSI/4ZjG9EWeI= Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 00:35:45 -0000 Hi, Dean, >> Bernard and I talked this past weekend, and we both think that the >> question on mobility is the major open issue that we need to close >> before asking to adopt the next version of GIN as a working group draft. > > I disagree. I think explicit indication of the numbers being registered > is the open-question for MARTINI. > > Explicit registration is required but not sufficient for the mobility > scenarios. Doing MARTINI registration without explicit indication will > preclude using this mechanism. However, doing the followup work is > probably outside of MARTINI's immediate scope. My post morphed pretty quickly into a discussion of explicit indication while considering mobility, so one side of my brain apparently agreed with you about the close relationship, and I don't disagree with your assertion that explicit indication may be the longest pole in the tent. Thanks, Spencer From spencer@wonderhamster.org Mon Feb 15 16:51: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 9DDE03A7BF5 for ; Mon, 15 Feb 2010 16:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 ekp2xRixLetZ for ; Mon, 15 Feb 2010 16:51:45 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id B61D33A7BF3 for ; Mon, 15 Feb 2010 16:51:45 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MIMh5-1NgLwV3GKF-003pcB; Mon, 15 Feb 2010 19:53:09 -0500 Message-ID: <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" , "Bernard Aboba" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> Date: Mon, 15 Feb 2010 18:52:59 -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: V01U2FsdGVkX19wDxsWUFYdrZSArcg96lRJPb/28ZGEsPSeh+m HXw2+ybzWwP8HqcXE0sUNNEpeU2J1sBLStJmyKTWCitOvTcSqy 0Z+xg3DGuqfgq6p16yBqYDsXvmMSTVLr+tUmjmf5kk= Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 00:51:46 -0000 Hi, Dean, >> Speaking as co-chair, the non-registration aspects of DID number >> mobility >> are outside the scope of the current MARTINI WG charter. >> >> The question on the table (see >> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html ) is >> whether the registration aspects represent a requirement or not. Feel >> free >> to respond and provide your opinion on that thread. > > Explicit is its own reward. > > Remember, the one thing that RFC 3261 REGISTER really does is bind an AOR > to a Contact. Both the AOR and the Contact involved are explicitly > encoded in the request. > > I'm OKAY with extending REGISTER to bind multiple AORs to multiple > Contacts. This seems like a reasonable extension to simplify life for a > "multi user" SIP user agent. But I really think we should respect the > history of REGISTERs explicit encoding of the AORs and Contacts involved. > > From a requirements perspective, I'd be happy with a requirement along > the lines of "must not preclude AOR mobility indicated by the > registration." I agree that we can't justify a requirement to produce a > mechanism at the time for the whole enchilada. OK, I happen to like your proposed resolution here, but want to try to act like a responsible chair, and want to make sure that if we go this direction, we're not just declaring victory and sailing out of the harbor. I was most concerned about the request/response size, based on MTU limitations. We've said that anyone who loses sleep over that is welcome to REGISTER TCP. Check. I have been reminded by someone smarter than me that intermediate devices may puke on large requests/responses (where "large" is measured at the SIP level, not at the IP MTU level), and that they can reject large requests, but not large responses. So, I'm back to my previous concern, just higher in the stack, if including explicit lists of what's being registered can mean that the request (and, more so, the response) can be big enough to cause problems. Several people have been saying "use regevents, because you want an ongoing understanding of what the other guy thinks anyway, not just a snapshot at REGISTER time", and I've been listening. So, I think my next question is, does using regevents make what's being registered explicit ENOUGH to satisfy the concern Dean is voicing here? If the answer is "yes", I'm good with "must not preclude". Thanks, Spencer From bernard_aboba@hotmail.com Mon Feb 15 16:54: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 4EF8228C11B for ; Mon, 15 Feb 2010 16:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.648, 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 grtOmepkWHrr for ; Mon, 15 Feb 2010 16:53:41 -0800 (PST) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by core3.amsl.com (Postfix) with ESMTP id AA1BB3A7BF3 for ; Mon, 15 Feb 2010 16:53:40 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.71]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 16:55:12 -0800 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 15 Feb 2010 16:55:08 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01CAAE5F.A165F420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acquoq1YhzWbEdAORG+R2DNoZ6hG5Q== Content-Language: en-us X-OriginalArrivalTime: 16 Feb 2010 00:55:12.0957 (UTC) FILETIME=[B21B9ED0:01CAAEA2] Subject: [martini] MARTINI Virtual Interim III Draft Minutes (please review) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 00:54:02 -0000 ------=_NextPart_000_0065_01CAAE5F.A165F420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI WG Virtual Interim Meeting III Date: Tuesday Feb 9th, 2010 Time: 10:00 AM - 12:30 PM PST Minute takers: David Hancock, Brian Lindsay Attendees: Adam Roach Alan Johnston Ben Campbell Bernard Aboba Brian Lindsay Christian Schmidt Cullen Jennings Dan Romascanu David Hancock Dean Willis David Schmidt Hadriel Kaplan James Swan John Elwell Keith Drage Martin Dolly Mary Barnes Michael Lunsford Paul Kyzivat Rich Shockey Robert Sparks Spencer Dawkins Tyler Parkin ======================================================================= 1. Agenda bashing No comments. 2. Requirements and Usage Scenarios MARTINI Requirement Update (John) John Elwell: Is requirements doc ready for last call? Keith Drage: Could problem statements (if we need them) be merged into requirements document? Adam Roach & John Elwell agreed. Dean Willis: Propose new requirement to allow a DID phone number to move dynamically among PBXs serving the same enterprise (and connected to the same SSP). The SSP will route requests to the IP-PBX where the user is currently located. The current drafts would require the SSP to make changes to point a DID at a different PBX. Some syntax could be added to the GIN draft to allow this. Keith Drage: such a requirement could be supported by the SSP, in which case MARTINI is not impacted. Dean Willis: so maybe the requirement is "martini must not preclude" or "must support"? Dean Willis: this requirement would add the ability to move a person from one building to another w/o having to take provisioning steps in the SSP to remove/add the user from one PBX to the other. It eliminates the need to have the user call the enterprise IT department, enterprise IT call the SSP, etc. The syntax that is proposed in Adam's draft requires someone in another channel to move the number from one PBX to the other. Keith Drage: does this mean media goes to PBX too? Dean Willis: yes. Cullen Jennings: Flip side is adding a new number that is available to the SIP PBX and allowing the PBX to automatically discover the number. Cable operators want the ability to have the SSP tell the small 10-line PBX what numbers it is assigned. Keith Drage: yes, but this is a provisioning issue, not a sip issue. Dean Willis: Agree with Cullen that the PBX should have a way to discover the range of numbers it is authorized to use. The proposed new requirement is that it can dynamically use a subset of those numbers. Martin Dolly: Don't understand requirement - the PBX already knows its numbers, so why does it need to discover them? Richard Shockey: There are two main issues: lack of any "explicit" indication in the implicit registration models, plus provisioning of SIP PBXs. The latter should be out of scope of MARTINI. Spencer Dawkins: Lovely to do, but not in scope. Needs to be dealt with as a separate problem. Dean Willis: Agree - but the problem of which PBX the DID is bound to should be in scope. A discovery mechanism would help in the case where the enterprise asks for a new number - it could be used to inform the PBX when the number is available. Martin Dolly: yes, but is this a requirement that MARTINI needs to address? Or is it feature creep that will make MARTINI overly complex? Richard Shockey: we're dealing with 2 issues here - a) explicit indicator of the special REGISTER, and b) syncing numbers between SSP and PBX. Agree that b) is out-of-scope. Martin Dolly: understand the need for PBX to implicitly register on behalf of users. But a specific number must be assigned to someone, so let's leave discovery outside scope of MARTINI. Dean Willis: OK, discovery can be out-of-scope, but the "which PBX is this number on right now" is in-scope? Spencer Dawkins: Let's not solve this today, but move this discussion to the list. Martin Dolly: does this have to be solved now or later? John Elwell: should we move problems into the requirements draft? Cullen Jennings: we need to see what is moved before agreeing to additional text. Keith Drage: how do we do it - does John get pre-approval of what to add, or does he make his best-guess include it in draft that we review? The group agreed on the former. Cullen Jennings: less is more. Plus the WG-chairs should be clear on identifying the individual authors of the requirements draft. [discussion returned to next steps on the requirement I-D] John Elwell: Proposal: a. Produce -00 Requirements I-D b. Propose on the mailing list which portions of the problem statement I-D should be included c. Produce -01 Requirements I-D based on discussion of the above Keith Drage: assume that we're not going to add new requirements without onlist discussion/consensus. John Elwell: Right, any new requirements need to be handled separately. [ no objections to John's proposal ] Service Provider Perspective (Martin Dolly) Martin Dolly: Many of todays PBXs don't register at all. Instead, Acme Packet does a surrogate registration on behalf of the PBX. So having a registration that is implicit is good, and sufficient. Dean Willis: what about the case where the E.164 number is located on two PBXs at the same time? Paul Kyzivat: PBXs are probably geo-close to each other. If you provision the set of implicitly registered E.164 numbers to each PBX, and the sets across multiple PBXs overlap, then the SSP can fork calls to the overlapping numbers to those multiple PBXs. Martin Dolly: Dean is describing a nomadic behavior. Current models are static. Haven't seen any requirements for a nomadic model. Most carriers don't do forking. Hadriel Kaplan: This is a provisioned phone # model. David Hancock: In internal discussions with Cable operators a nomadic model has been viewed as out of scope and could be supported within a PBX campus model that hides the nomadicity from the service provider. Cullen Jennings: what is timeliness of this action? If the move needs to happen quickly then it needs to be supported via SIP, whereas if there isn't a tight time constraint, then a conventional provisioning solution would suffice. Dean Willis: Could be supported with slight modification to current proposals David Hancock: Would like to see discussion on list. Worried about feature creep. Spencer Dawkins: If Dean has a simple tweak to Adam's mechanism, then put it on the list Keith Drage: First we should agree on whether or not this is a requirement. If we don't follow this process rigorously we'll end up with feature creep. Usage Scenarios (Adam Roach) Slide-2: Keith Drage: why limit to INVITEs? This would also apply to other requests such as OPTIONS/SUBSCRIBE/REFER/etc. Adam Roach: agree, this applies any out-of-dialog request that can be sent to the PBX. If we get it right for INVITE, then everything else should work. Slide-7 (Use-Case 4): Adam Roach: In this case SP receives incoming request from Internet addressed to pbx.com. Paul Kyzivat: if SSP is OK with this, then it is not a problem. Spencer Dawkins: RFC 3263 routing would be used between the Internet and the SSP. Adam Roach: considering the entire flow, when the black phone dials 10 digits, who adds the "pbx.com" domain? Paul Kyzivat: the question is - can this be supported. Not how does it occur, but can it occur, and if yes, will it be supported? Spencer Dawkins: I think UC-4 is OK from a "don't preclude" standpoint. Adam Roach: Use-case should be ok as a "don't preclude" Dean Willis: yes, this case could occur when someone uses a SIP URI from a business card. [brief group discussion on whether anyone would really list a phone number with a domain on their business cards ] Paul Kyzivat: this SIP URI could also leak out for some features like callback, where the originating user initiates a call to the URI contained in a previously received From: header. Cullen Jennings: my address book has SIP URIs. So SIP URIs are definitely out there. Spencer Dawkins: don't need to make decision on call, take this to the list. Paul Kyzivat: my current position on this is "don't preclude". Slide-8: (Use-Case 5: use Tel URIs on the wire) Brian Lindsay: does this really require registering a Tel URI? Adam Roach: Agreed this is using Tel URIs on the wire, doesn't actually require Tel URI registration. Dean Willis: Whether tel URI is implict (doesn't appear in REGISTER request) or explicit (does appear in REGISTER request) is open to debate. But I think we're in agreement that this case is not supported. Slide-9: (Use-Case 6) Adam Roach: This slide is not correct. It should show ssp.com as the domain name for both invites, per the original mailing list posting. Slide-10: (Use-Case 7) Adam Roach: Problem is this requires History-Info update and that may be a long time. Mary Barnes: History-Info is moving quickly. New 4244bis draft will be out in the next day or so, don't think there is a time issue. Martin Dolly: expresses doubt on History-Info. Slide-11: (Use-Case 8) Adam Roach: This is the same as UC-6 except that the PBX registers with its own domain, instead of IP address. So this requires 3263 procedures, and since we've said that PBX doesn't support DNS update, it seems like this should be out-of-scope. Keith Drage: could someone describe on-list the specific problem this case causes? Paul Kyzivat: independent of violating RFC3263, this violates domain responsibility. So this is as bad as UC-6. Slide-12: (Use-Case 9) Adam Roach: This case is relatively clean. Keith Drage: how does this differ from UC6? Adam Roach: diagram for UC-6 is wrong. Both legs should have ssp.com, not pbx.com. Adam will update the slides on the archive (http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-III/ ). See mailing list Feb 1st - use-case 6 is correct in that email. Hadriel Kaplan: UC-6 is 3GPP. Keith Drage: why is UC-3 different than normal location routing behavior? Adam Roach: it is the same, but the registration has to work as described in the GIN draft. Keith Drage: need to go back and look at why IMS did the loose-routing mechanism vs. the location-routing UC-3 solution. Brian Lindsay: did IMS do it to align subscription and peering models? Keith Drage: yes, maybe that's the reason, but in addition the Route header may have been needed by the P-CSCF. Spencer Dawkins: put question on-list asking whether we should support UC-3 or UC-9. Meanwhile, Keith and others can study the use-cases. Request to Adam - add to GIN draft the example that is chosen. Adam Roach: GIN already has example for UC-3, and could add UC-9, if that is required. Brian Lindsay: UC-9 aligns with MARTINI-Shaken, should keep on table Spencer: hold off on adding additional use-cases -- the goal is to pick one mechanism. Hadriel Kaplan: [General comment] These are "scenarios" rather than use cases. Spencer Dawkins: Likes the structure these have provided. 3. Solution Updates MARTINI with Globally Identifiable Numbers (GIN) Draft (Adam Roach) Slide-3: Adam Roach: Regarding bullet-2, you don't have to actually add 100 rows in the location database. Since it is algorithmic, it could be optimized. Slide-4: Adam Roach: "bnc" URI parameter says this is a special Contact URI that must be expanded before it is used. Slide-5: Adam Roach: the '*' character indicates where PBX can add its own unique material. Spencer Dawkins: can this GRUU enhancement be done within MARTINI, or does it require work outside of MARTINI? Adam Roach: need to put to one of the AD's. Thinks MARTINI owns it. Hadriel Kaplan: we may in fact not need to make changes to GRUU. Slide-6: Public GRUU Brian Lindsay: wouldn't there be SP hairpinning issues if these GRUU's were exchanged between clients within SIP PBX Adam Roach: PBX could know AoRs it's responsible for to avoid hairpinning, could recognize its own GRUUs with the ssp.example.com domain. Martin Dolly: why do we need GRUUs? Paul Kyzivat: need a globally routable URI. Keith Drage: it's just that the PBX might want to use its own GRUUs, in which case it needs to be able to create a GRUU that actually works. Martin Dolly: not arguing against the GRUU RFC. Within 3GPP GRUU it is a MUST, so it's well-defined and therefore not an interoperability issue. Keith Drage: the only requirement is that the PBX should be able to coin GRUUs, and therefore they should work. Paul Kyzivat: GRUU is optionally supported for a registrar. In this case there are 2-layers of registration; one from enterprise UA to PBX, and one from PBX to SSP network. Therefore if either PBX or SSP does not support GRUU, then the endpoint cannot support GRUU. So, this is the case where both PBX and SSP do support GRUU, and we need to make sure that in that this case works. Adam Roach: The draft is not mandating GRUU support - just explaining how the mechanism interworks with GRUU Slide-8: Reg-Event Package Adam Roach: SIP reg event package. Need to proxy the SIP reg-event SUBSCRIBE to the PBX, since it knows the actual registration status of GRUU. Slide-9: Contact Syntax Paul Kyzivat: This implies a constraint on the PBX. It has to manage the user portion - make sure that its own internal URIs don't collide with internally used AORs. Adam Roach: the fact that we're using E.164 numbers with '+' sign should avoid any collisions. Something about this restriction probably needs to be stated in the Requirements draft. If transformation, beyond simple replace is needed, we need the requirements. Paul Kyzivat : proposal in slides seems workable. Do we need rules about whether separators are removed? We should at least decide whether Tel URI separator/formatting chars are allowed on the interface. Adam Roach: Whatever is decided should be made explicit in the draft. Conclusion: get rid of parentheses. Slide-11: (Simplify GRUU operation by getting rid of '*' character) Agree with simplification -- always append local data to the received 'gr' parameter, instead of allowing local data to be anywhere. Slide-12 & 13: (Temp GRUU issues) Paul Kyzivat: my solution only requires action by the PBX, and is therefore out-of-scope on the SIP-Trunk interface. Therefore, GIN maybe only needs a Note to explain what the PBX needs to do here. Cullen Jennings: Temp-GRUUs are required. Paul Kyzivat: The most common use-case is a PBX user includes a Temp-GRUU in a request to a remote user, and the remote user addresses a out-of-dialog request to that received temp-GRUU. If the temp-GRUU is associated with a non-DID user, then the call should be routed to the attendant. Dean Willis: Approach won't work with outbound. Adam Roach: would there be a critical mass of PBXs that would be able to do this or is it a non-starter? Adam Roach: Could replace mechanism in draft with Paul's alternate approach Hadriel Kaplan: Like Paul's approach. Adam Roach: Leaning towards Paul's approach. Paul Kyzivat: Need to do no more in the draft than outline there is no normative impact Adam Roach: Hope to be able to limit to an explanation of how it would work, although may need extensions for Public GRUUs. Any objections limiting to some implementation notes? Rich Shockey: Less is more. Slide-14: (signaling enterprise phone numbers during registration) Someone: leaving this out paints ourselves into a corner. Richard Shockey: short answer is, no, we should not do this. First of all, numbers may not be in a range. Paul Kyzivat: Counting on ranges to reduce size is going to be a problem. Dean Willis: need to be able to express multi ranges. Spencer: original discussions removed this capability because of UDP message size limitations. Keith Drage: Can't the reg-event be used for this? There is a need to use reg-event to sync reg-state between SSP and PBX. E.g. 3GPP/IMS procedures allow the SSP network to remove a registration (e.g., due to prepay money running out) - the reg-event is the mechanism used for this. Spencer Dawkins: want to use reg event to manage state question. Dean Willis: there is a need for the SSP to reject a registration to tell PBX that some of the numbers it thinks it is registering aren't in fact registered by the SSP. Paul Kyzivat: what if there is no numbers configured in the SSP for a registering PBX? Hadriel Kaplan: use the registration transaction to register the pbx, and then use reg-event to tell the PBX exactly what was registered. Dean Willis: will take phone-number issue to the list. Slide-15: (Proxy-Require) Adam Roach: It's not the kiss of death if we don't define a new Proxy-Require tag, since the proxies that need to understand and participate in this registration are all within one domain, and spread across multiple domains. Slide-16: (Security) Adam Roach: There may be some security issues with these other SIP extensions. They may not "just work". We need some experts well versed in SIP and security to look into multiple AoR registration. Spencer Dawkins: who should be involved? Need a SIP/Security subject matter expert (e.g., Jon Peterson) Keith Drage: why do we think we need a security analysis? Adam Roach: just a gut feeling that there may be security issues. Of course we also need to make sure they work at all. This should be easy in the straightforward case. Bernard Aboba: chairs will try to roundup experts. MARTINI Shaken Update draft (Hadriel Kaplan) Hadriel Kaplan: No updates to the draft. "shaken" is essentially Adam's use-case 9. It makes the routing of requests look more like the peering model than contact routing. Shaken currently doesn't talk about GRUUs, but that could be added. Bernard Aboba: Should we have a hum on "GIN" vs "Shaken"? Keith Drage: not ready to go there yet. Hadriel Kaplan: At end of day we just need to pick a mechanism. The advantage of shaken is that it supports email style, in addition to E.164 numbers. 4. Wrap-up Richard Shockey: Do we want to discuss merging GIN & shaken? Bernard Aboba: if there are suggestions for changes to GIN, they can be posted on the list. Cullen Jennings: there is already some consensus on simplification the GIN syntax. Bernard Aboba: New doodle pool is out on possible dates for next call, may be difficult to find an appropriate date due to conflicts with 3GPP and IETF/3GPP IPv6 transition meeting. Adam Roach: Not enthusiastic about a fourth virtual interim. Potential dates are too close to IETF 77, and would interfere with preparation. There is also the exhaustion factor. Action items * Dean Willis: take phone-number mobility issue to the list. * Chairs: round up security experts for GIN security review ------=_NextPart_000_0065_01CAAE5F.A165F420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI WG Virtual Interim Meeting = III

 

Date: Tuesday Feb 9th, = 2010
Time: 10:00 AM – 12:30 PM PST

Minute = takers:  David Hancock, Brian Lindsay

 

Attendees:

 

Adam = Roach

Alan = Johnston

Ben = Campbell

Bernard Aboba
Brian = Lindsay

Christian = Schmidt

Cullen Jennings
Dan = Romascanu

David = Hancock

Dean = Willis

David = Schmidt

Hadriel Kaplan
James = Swan

John = Elwell

Keith = Drage

Martin = Dolly

Mary = Barnes

Michael Lunsford
Paul = Kyzivat

Rich Shockey =

Robert = Sparks

Spencer = Dawkins

Tyler = Parkin

 

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

 

1.  Agenda bashing

No = comments.

 

2.  Requirements and Usage = Scenarios

MARTINI Requirement = Update = (John)

John Elwell: Is = requirements doc ready for last call?

 

Keith Drage: Could = problem statements (if we need them) be merged into requirements = document?

 

Adam Roach & = John Elwell agreed.

 

Dean Willis: = Propose new requirement to allow a DID phone number to move dynamically = among PBXs serving the same enterprise (and connected to the same SSP). = The SSP will route requests to the IP-PBX where the user is currently = located. The current drafts would require = the SSP to make changes to point a DID at a different PBX. Some syntax = could be added to the GIN draft to allow = this.

 

 

 

Keith Drage: such a = requirement could be supported by the SSP, in which case MARTINI is not = impacted.

 

Dean Willis: so = maybe the requirement is “martini must not preclude” or = “must support”?

 

Dean Willis: this = requirement would add the ability to move a person from one building to = another w/o having to take provisioning steps in the SSP to remove/add = the user from one PBX to the other. It eliminates the need to have the = user call the enterprise IT department, enterprise IT call the SSP, etc. = The syntax that is proposed in Adam’s draft requires someone in = another channel to move the number from one PBX to the other. =

 

Keith Drage: does = this mean media goes to PBX too?

 

Dean Willis: yes. =

 

Cullen Jennings: = Flip side is adding a new number that is = available to the SIP PBX and allowing the PBX to automatically discover = the number.

Cable operators = want the ability to have the SSP tell the small 10-line PBX what numbers = it is assigned.

 

Keith Drage: yes, = but this is a provisioning issue, not a sip = issue.

 

Dean Willis: Agree = with Cullen that the PBX should have a way to discover the range of = numbers it is authorized to use. The proposed new requirement is that it = can dynamically use a subset of those numbers.  =

 

Martin Dolly: = Don’t understand requirement – the PBX already knows its = numbers, so why does it need to discover them?

 

Richard = Shockey: There are two main issues: lack of any “explicit” = indication in the implicit registration models, plus provisioning of SIP = PBXs. The latter should be out of scope of = MARTINI.

 

Spencer Dawkins: Lovely = to do, but not in scope. Needs to be dealt with as a separate = problem.

 

Dean = Willis: Agree – but the problem of which PBX the DID is bound to = should be in scope.  A discovery = mechanism would help in the case where the enterprise asks for a new = number – it could be used to inform the PBX when the number is = available.

 

Martin Dolly: yes, = but is this a requirement that MARTINI needs to address? Or is it = feature creep that will make MARTINI overly complex?  =

 

Richard Shockey: = we’re dealing with 2 issues here – a) explicit indicator of = the special REGISTER, and b) syncing numbers between SSP and PBX. Agree = that b) is out-of-scope.

 

Martin Dolly: = understand the need for PBX to implicitly register on behalf of users. = But a specific number must be assigned to someone, so let’s leave = discovery outside scope of MARTINI.

 

Dean Willis: OK, = discovery can be out-of-scope, but the “which PBX is this number = on right now” is in-scope? 

 

Spencer Dawkins: = Let’s not solve this today, but move this discussion to the list. =

 

Martin Dolly: does = this have to be solved now or later?

 

 

 

John Elwell: should = we move problems into the requirements draft?

 

Cullen Jennings: we = need to see what is moved before agreeing to additional text. =

 

Keith Drage: how do = we do it – does John get pre-approval of what to add, or does he = make his best-guess include it in draft that we review? =

 

The group agreed on = the former.

 

Cullen Jennings: = less is more. Plus the WG-chairs should be clear on identifying the = individual authors of the requirements draft.

 

[discussion returned to next steps on the requirement = I-D]

 

John = Elwell: Proposal:

a.  Produce = -00 Requirements I-D

b.  Propose = on the mailing list which portions of the problem statement I-D should = be included

c.  Produce = -01 Requirements I-D based on discussion of the = above

  

Keith Drage: assume that we’re not going to add new = requirements without onlist = discussion/consensus.

 

John = Elwell: Right, any new requirements need to be handled = separately.

 

[ no = objections to John’s proposal ]

 

 

Service Provider = Perspective (Martin Dolly) =

 

Martin Dolly: Many = of todays PBXs don’t register at all. Instead, Acme Packet does a = surrogate registration on behalf of the PBX. So having a registration = that is implicit is good, and sufficient.

 

Dean Willis: what = about the case where the E.164 number is located on two PBXs at the same = time?

 

Paul Kyzivat: PBXs = are probably geo-close to each other. If you provision the set of = implicitly registered E.164 numbers to each PBX, and the sets across = multiple PBXs overlap, then the SSP can fork calls to the overlapping = numbers to those multiple PBXs.

 

Martin = Dolly: Dean is describing a nomadic behavior. Current models are static. = Haven’t seen any requirements for a nomadic model. Most carriers = don’t do forking.

 

Hadriel Kaplan: This is a = provisioned phone # model.

David Hancock: In = internal discussions with Cable operators a nomadic model has been = viewed as out of scope and could be supported within a PBX campus model = that hides the nomadicity from the service provider. =

 

Cullen Jennings: = what is timeliness of this action? If the move needs to happen quickly = then it needs to be supported via SIP, whereas if there isn’t a = tight time constraint, then a conventional provisioning solution would = suffice.

 

Dean Willis: Could be = supported with slight modification to current = proposals

 

David Hancock: Would like = to see discussion on list. Worried about feature = creep.

 

Spencer Dawkins: If = Dean has a simple tweak to Adam’s mechanism, then put it on the = list

 

Keith Drage: First = we should agree on whether or not this is a requirement. If we = don’t follow this process rigorously we’ll end up with = feature creep.

 

Usage = Scenarios (Adam = Roach)

 

Slide-2:

Keith Drage: why = limit to INVITEs? This would also apply to other requests such as = OPTIONS/SUBSCRIBE/REFER/etc.

 

Adam Roach: agree, = this applies any out-of-dialog request that can be sent to the = PBX.  If we get it right for = INVITE, then everything else should work.

 

Slide-7 (Use-Case = 4):

 

Adam Roach: In this = case SP receives incoming request from Internet addressed to pbx.com. =

 

Paul Kyzivat: if = SSP is OK with this, then it is not a problem.

 

Spencer Dawkins: = RFC 3263 routing would be used between the Internet and the SSP.  =

 

Adam Roach: = considering the entire flow, when the black phone dials 10 digits, who = adds the “pbx.com” domain?

 

Paul Kyzivat: the = question is – can this be supported. Not how does it occur, but = can it occur, and if yes, will it be supported?

 

Spencer Dawkins: I = think UC-4 is OK from a “don’t preclude” standpoint. =

 

Adam Roach: Use-case = should be ok as a “don’t = preclude”

 

Dean Willis: yes, = this case could occur when someone uses a SIP URI from a business card. =

 

[brief group discussion = on whether anyone would really list a phone number with a domain on = their business cards ]

 

 

 

Paul Kyzivat: this = SIP URI could also leak out for some features like callback, where the = originating user initiates a call to the URI contained in a previously = received From: header.

 

Cullen Jennings: my = address book has SIP URIs. So SIP URIs are definitely out there. =

 

Spencer Dawkins: = don’t need to make decision on call, take this to the list. =

 

Paul Kyzivat: my = current position on this is “don’t preclude”. =

 

Slide-8: = (Use-Case 5: use Tel URIs on the wire)

 

Brian Lindsay: does = this really require registering a Tel URI?

 

Adam Roach: Agreed this = is using Tel URIs on the wire, doesn’t actually require Tel URI = registration.

 

Dean Willis: = Whether tel URI is implict (doesn’t appear in REGISTER request) or = explicit (does appear in REGISTER request) is open to debate. But I = think we’re in agreement that this case is not = supported.

 

Slide-9: = (Use-Case 6)

 

Adam Roach:  This = slide is not correct.  It should show ssp.com as the domain name = for both invites, per the original mailing list posting.  =

 

Slide-10: = (Use-Case 7)

Adam Roach: Problem = is this requires History-Info update and that may be a long time. =

 

Mary Barnes: = History-Info is moving quickly. New 4244bis draft will be = out in the next day or so, don’t think there is a time = issue.

 

Martin Dolly: = expresses doubt on History-Info. 

 

Slide-11: (Use-Case 8) =

Adam Roach: This is = the same as UC-6 except that the PBX registers with its own domain, = instead of IP address. So this requires 3263 procedures, and since = we’ve said that PBX doesn’t support DNS update, it seems = like this should be out-of-scope.

 

Keith Drage: could = someone describe on-list the specific problem this case causes? =

 

Paul Kyzivat: = independent of violating RFC3263, this violates domain responsibility. = So this is as bad as UC-6.

 

Slide-12: = (Use-Case 9)

Adam Roach: This = case is relatively clean.

 

Keith Drage: how = does this differ from UC6? 

 

Adam Roach: diagram = for UC-6 is wrong. Both legs should have ssp.com, not pbx.com. Adam will = update the slides on the archive (http://ww= w.drizzle.com/~aboba/MARTINI/Jan-Interim-III/  ). See mailing = list Feb 1st – use-case 6 is correct in that email. =

 

Hadriel Kaplan: = UC-6 is 3GPP.

 

Keith Drage: why is = UC-3 different than normal location routing = behavior?

 

Adam Roach: it is = the same, but the registration has to work as described in the GIN = draft.

 

Keith Drage: need = to go back and look at why IMS did the loose-routing mechanism vs. the = location-routing UC-3 solution.

 

Brian Lindsay: did = IMS do it to align subscription and peering models? =

 

Keith Drage: yes, = maybe that’s the reason, but in addition the Route header may have = been needed by the P-CSCF.

 

Spencer Dawkins: = put question on-list asking whether we should support UC-3 or UC-9. = Meanwhile, Keith and others can study the use-cases. Request to Adam = – add to GIN draft the example that is chosen. =

 

Adam Roach: GIN = already has example for UC-3, and could add UC-9, if that is required. =

 

Brian Lindsay: UC-9 = aligns with MARTINI-Shaken, should keep on table

 

Spencer: hold off = on adding additional use-cases -- the goal is to pick one = mechanism.

 

Hadriel Kaplan: [General = comment] These are “scenarios” rather than use = cases.

 

Spencer Dawkins: Likes = the structure these have provided.

 

3.  Solution Updates

MARTINI with = Globally Identifiable Numbers (GIN) Draft (Adam = Roach)

Slide-3: =

Adam Roach: = Regarding bullet-2, you don’t have to actually add 100 rows in the = location database. Since it is algorithmic, it could be = optimized.

 

Slide-4: =

Adam Roach: = “bnc” URI parameter says this is a special Contact URI that = must be expanded before it is used.

 

Slide-5: =

Adam Roach: the = ‘*’ character indicates where PBX can add its own unique = material.

 

Spencer Dawkins: = can this GRUU enhancement be done within MARTINI, or does it require = work outside of MARTINI?

 

Adam Roach: need to put = to one of the AD’s.  Thinks MARTINI owns = it.

Hadriel Kaplan: we = may in fact not need to make changes to GRUU.

 

Slide-6: Public = GRUU

Brian Lindsay: = wouldn’t there be SP hairpinning issues if these GRUU’s were = exchanged between clients within SIP PBX

 

Adam Roach: PBX could = know AoRs it’s responsible for to avoid hairpinning, could = recognize its own GRUUs with the ssp.example.com domain. =

 

Martin Dolly: why = do we need GRUUs?

 

Paul Kyzivat: need = a globally routable URI.

 

Keith Drage: = it’s just that the PBX might want to use its own GRUUs, in which = case it needs to be able to create a GRUU that actually works. =

 

Martin Dolly: not = arguing against the GRUU RFC. Within 3GPP GRUU it is a MUST, so = it’s well-defined and therefore not an interoperability issue. =

 

Keith Drage: the = only requirement is that the PBX should be able to coin GRUUs, and = therefore they should work.

 

Paul Kyzivat: = GRUU is = optionally supported for a registrar. In this case = there are 2-layers of registration; one from enterprise UA to PBX, and = one from PBX to SSP network. Therefore if either PBX or SSP does not = support GRUU, then the endpoint cannot support GRUU. So, this is the = case where both PBX and SSP do support GRUU, and we need to make sure = that in that this case works.

 

Adam Roach: The draft is = not mandating GRUU support – just explaining how the mechanism = interworks with GRUU

 

Slide-8: Reg-Event = Package

Adam Roach: SIP reg = event package. Need to proxy the SIP reg-event SUBSCRIBE to the PBX, = since it knows the actual registration status of GRUU. =

 

Slide-9: Contact = Syntax

 

Paul Kyzivat: This = implies a constraint on the PBX. It has to manage the user portion = – make sure that its own internal URIs don’t collide with = internally used AORs. 

 

Adam Roach: the = fact that we’re using E.164 numbers with ‘+’ sign = should avoid any collisions.  Something about this restriction = probably needs to be stated in the Requirements draft. If transformation, beyond = simple replace is needed, we need the requirements.

 

Paul Kyzivat : proposal = in slides seems workable. Do we need rules about whether separators are = removed?  We should at least = decide whether Tel URI separator/formatting chars are allowed on the = interface. 

 

Adam Roach: = Whatever is = decided should be made explicit in the draft. =

 

Conclusion: get rid = of parentheses.

 

Slide-11: (Simplify GRUU = operation by getting rid of ‘*’ = character)

Agree with = simplification -- always append local data to the received = ‘gr’ parameter, instead of allowing local data to be = anywhere.

 

Slide-12 & = 13: (Temp GRUU issues)

Paul Kyzivat: my solution only requires action by the PBX, and is = therefore out-of-scope on the SIP-Trunk interface. Therefore, GIN maybe = only needs a Note to explain what the PBX needs to do here. =

 

Cullen Jennings: = Temp-GRUUs are required.

 

Paul Kyzivat: The = most common use-case is a PBX user includes a Temp-GRUU in a request to = a remote user, and the remote user addresses a out-of-dialog request to = that received temp-GRUU. If the temp-GRUU is associated with a non-DID = user, then the call should be routed to the attendant. =

 

Dean Willis: Approach = won’t work with outbound.

 

Adam Roach: would there = be a critical mass of PBXs that would be able to do this or is it a = non-starter?

 

Adam Roach: Could replace = mechanism in draft with Paul’s alternate = approach

 

Hadriel Kaplan: Like = Paul’s approach.

 

Adam Roach: Leaning = towards Paul’s approach.

 

Paul Kyzivat: Need to do = no more in the draft than outline there is no normative = impact

 

Adam Roach: Hope to be = able to limit to an explanation of how it would work, although may need = extensions for Public GRUUs. Any objections limiting to some = implementation notes?

 

Rich Shockey: Less is = more.

 

Slide-14: (signaling = enterprise phone numbers during registration)

 

Someone: leaving = this out paints ourselves into a corner.

 

Richard Shockey: = short answer is, no, we should not do this. First of all, numbers may = not be in a range.

 

Paul Kyzivat: Counting on = ranges to reduce size is going to be a problem.

 

Dean Willis: need = to be able to express multi ranges. Spencer: original discussions = removed this capability because of UDP message size limitations. =

 

 

 

Keith Drage: = Can’t the reg-event be used for this? There is a need to use = reg-event to sync reg-state between SSP and PBX. E.g. 3GPP/IMS = procedures allow the SSP network to remove a registration (e.g., due to = prepay money running out) – the reg-event is the mechanism used = for this.

 

Spencer Dawkins: want to = use reg event to manage state question.

 

Dean Willis: there = is a need for the SSP to reject a registration to tell PBX that some of = the numbers it thinks it is registering aren’t in fact registered = by the SSP.

 

Paul Kyzivat: what = if there is no numbers configured in the SSP for a registering PBX? =

 

Hadriel Kaplan: use = the registration transaction to register the pbx, and then use reg-event = to tell the PBX exactly what was registered.

 

Dean Willis: will = take phone-number issue to the list.

 

Slide-15: = (Proxy-Require)

Adam Roach: = It’s not the kiss of death if we don’t define a new = Proxy-Require tag, since the proxies that need to understand and = participate in this registration are all within one domain, and spread = across multiple domains.

 

Slide-16: = (Security)

Adam Roach: There = may be some security issues with these other SIP extensions. They may = not “just work”.  We need some experts well = versed in SIP and security to look into multiple AoR = registration.

 

Spencer Dawkins: = who should be involved? Need a SIP/Security subject matter expert (e.g., = Jon Peterson)

 

Keith Drage: why do = we think we need a security analysis?

 

Adam Roach: just a = gut feeling that there may be security issues. Of course we also need to = make sure they work at all. This should be easy in the straightforward = case.

 

Bernard Aboba: chairs = will try to roundup experts.

 

 

MARTINI Shaken = Update draft (Hadriel = Kaplan)

Hadriel Kaplan: No = updates to the draft. “shaken” is essentially Adam’s = use-case 9. It makes the routing of requests look more like the peering = model than contact routing. Shaken currently doesn’t talk about = GRUUs, but that could be added.

 

Bernard Aboba: Should we = have a hum on “GIN” vs = “Shaken”?

 

Keith = Drage: not ready to go there yet.

 

Hadriel Kaplan: At = end of day we just need to pick a mechanism. The advantage of shaken is = that it supports email style, in addition to E.164 = numbers.

 

 

4.  Wrap-up

 

Richard Shockey: Do = we want to discuss merging GIN & shaken?

 

Bernard Aboba: if = there are suggestions for changes to GIN, they can be posted on the = list.

 =

Cullen = Jennings: there is already some consensus on simplification the GIN = syntax.

 =

Bernard = Aboba: New doodle pool is out on possible dates for next call, may be = difficult to find an appropriate date due to conflicts with 3GPP and = IETF/3GPP IPv6 transition meeting.

 =

Adam = Roach:  Not enthusiastic about a fourth virtual interim.  = Potential dates are too close to IETF 77, and would interfere with = preparation.  There is also the exhaustion factor. =

 

Action = items

 

  • Dean Willis: take = phone-number mobility issue to the list.
  • Chairs: round up security = experts for GIN security review

 

 =

------=_NextPart_000_0065_01CAAE5F.A165F420-- From pkyzivat@cisco.com Mon Feb 15 17:05: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 BB7EB3A7BF6 for ; Mon, 15 Feb 2010 17:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 k6AR3T6Op4sh for ; Mon, 15 Feb 2010 17:05:33 -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 A60F33A797C for ; Mon, 15 Feb 2010 17:05: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: AvsEAIh+eUtAZnwN/2dsb2JhbACbGXSmO5cvhFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,480,1262563200"; d="scan'208";a="86357969" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2010 01:07:05 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1G1758A027381; Tue, 16 Feb 2010 01:07:05 GMT Message-ID: <4B79EFB9.8000209@cisco.com> Date: Mon, 15 Feb 2010 20:07:05 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> In-Reply-To: <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 01:05:34 -0000 Dean, In principle I agree with you. But this horse is already out of the barn with IMS implicit registration. It was never explicitly brought to the ietf, though things linked to it like P-Asserted-ID and P-Associated-URI were. While we could say that is not our problem, I think we already implicitly approved it via benign neglect. Thanks, Paul Dean Willis wrote: > > On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > >> Speaking as co-chair, the non-registration aspects of DID number mobility >> are outside the scope of the current MARTINI WG charter. >> >> The question on the table (see >> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html ) is >> whether the registration aspects represent a requirement or not. Feel >> free >> to respond and provide your opinion on that thread. > > Explicit is its own reward. > > Remember, the one thing that RFC 3261 REGISTER really does is bind an > AOR to a Contact. Both the AOR and the Contact involved are explicitly > encoded in the request. > > I'm OKAY with extending REGISTER to bind multiple AORs to multiple > Contacts. This seems like a reasonable extension to simplify life for a > "multi user" SIP user agent. But I really think we should respect the > history of REGISTERs explicit encoding of the AORs and Contacts involved. > > From a requirements perspective, I'd be happy with a requirement along > the lines of "must not preclude AOR mobility indicated by the > registration." I agree that we can't justify a requirement to produce a > mechanism at the time for the whole enchilada. > > -- > Dean > From bernard_aboba@hotmail.com Mon Feb 15 17:23: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 4D27F3A7A03 for ; Mon, 15 Feb 2010 17:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.648, 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 sm2DMthxBAWn for ; Mon, 15 Feb 2010 17:23:14 -0800 (PST) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id 74DAC3A67AC for ; Mon, 15 Feb 2010 17:23:14 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.71]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 17:24:46 -0800 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 15 Feb 2010 17:24:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01CAAE63.C43B0CC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcqupoQqb4FkWc4MRG6x703kHTqAcw== Content-Language: en-us X-OriginalArrivalTime: 16 Feb 2010 01:24:46.0843 (UTC) FILETIME=[D36D24B0:01CAAEA6] Subject: [martini] MARTINI Virtual Interim Proceedings X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 01:23:16 -0000 ------=_NextPart_000_0078_01CAAE63.C43B0CC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Until the IETF 77 proceedings site comes online, the agenda, presentations and minutes from the MARTINI Virtual Interims will be located here: MARTINI Virtual Interim I Agenda: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/agenda.txt Presentations: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/ Minutes: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/MARTINI-Virtual-Interim- I.htm MARTINI Virtual Interim II Agenda: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-II/agenda.txt Presentations: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-II/ Minutes: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-II/Jan%2026th-MARTINI-No tes-ba.doc MARTINI Virtual Interim III Agenda: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/agenda.txt Presentations: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/ Minutes: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/Feb-9th-MARTINI-Note s-dch-bl-merger.doc ------=_NextPart_000_0078_01CAAE63.C43B0CC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Until the = IETF 77 proceedings site comes online, the agenda, presentations and = minutes from the MARTINI Virtual Interims will be located = here:

 

MARTINI Virtual Interim I

 

Agenda: h= ttp://aboba.drizzlehosting.com/MARTINI/Jan-Interim/agenda.txt

Presentations: http://abob= a.drizzlehosting.com/MARTINI/Jan-Interim/

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

 

MARTINI = Virtual Interim II

 

Agenda: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-II/agenda.txt

Presentations: http://a= boba.drizzlehosting.com/MARTINI/Jan-Interim-II/

Minutes: http://aboba.drizzlehosting.com/MARTINI/Jan-Interi= m-II/Jan%2026th-MARTINI-Notes-ba.doc

 

MARTINI = Virtual Interim III

 

Agenda: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/agenda.txt=

Presentations: http://= aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/

Minutes: http://aboba.drizzlehosting.com/MARTINI/J= an-Interim-III/Feb-9th-MARTINI-Notes-dch-bl-merger.doc

=

 

 

 

 

------=_NextPart_000_0078_01CAAE63.C43B0CC0-- From dean.willis@softarmor.com Mon Feb 15 17:26: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 27B423A7BF6 for ; Mon, 15 Feb 2010 17:26:00 -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 hEKDIts3T1Ir for ; Mon, 15 Feb 2010 17:25:59 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 027BA3A7A03 for ; Mon, 15 Feb 2010 17:25:58 -0800 (PST) Received: from [192.168.2.102] (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 o1G1RTIS030343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Feb 2010 19:27:30 -0600 From: Dean Willis To: Spencer Dawkins In-Reply-To: <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> X-Priority: 3 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> Message-Id: <07865983-66A8-4B15-BA06-754D0A154DC1@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: Mon, 15 Feb 2010 19:27:23 -0600 X-Mailer: Apple Mail (2.936) Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 01:26:00 -0000 On Feb 15, 2010, at 6:52 PM, Spencer Dawkins wrote: > > I was most concerned about the request/response size, based on MTU > limitations. We've said that anyone who loses sleep over that is > welcome to REGISTER TCP. Check. > > I have been reminded by someone smarter than me that intermediate > devices may puke on large requests/responses (where "large" is > measured at the SIP level, not at the IP MTU level), and that they > can reject large requests, but not large responses. So, I'm back to > my previous concern, just higher in the stack, if including explicit > lists of what's being registered can mean that the request (and, > more so, the response) can be big enough to cause problems. > I believe I raised the request/response rejection dichotomy. If your request fails because it is too large, you can break the request up into "pieces" and do each piece separately. So for example if we find we can get 20 number ranges in a request, and you have 40 to REGISTER, it MIGHT take two requests. But that's only if either 1) an intermediary kicks it back as "too large" or 2) you just KNOW it isn't going to work. The problematic side is the response. I argue that we don't really need to know about the ranges that succeeded. If we get back a 200 OK, that's enough to say that the ranges we sent worked. The problem comes from RFC 3261, which I quote below: > 10.2.3 Fetching Bindings > A success response to any REGISTER request contains the complete > list of existing bindings, regardless of whether the request > contained a Contact header field. If no Contact header field is > present in a REGISTER request, the list of bindings is left unchanged. So, regardless of whether the REQUEST was explicit or implicit in declaring the scope of bindings, RFC 3261 requires that the register RESPONSE contain the full set. This is obviously problematic for very large registration sets, whether resulting from a single "mass registration" or many individual registration operations. This might lead one to think of the AOR being registered as singular, with a singular Contact, and that the telephone-numbers involved are "aliases" for this AOR. One can certainly envision explicit or implicit alias registration, and even consider that explicit transmission could occur in either direction. IMS makes it explicit using the P-Associated-URI List which is passed in the registrar->UAC direction. This of course raises the question we asked early on: How does a request coming in to the PBX, resulting from a contact-routing operation that maps the AOR to the Contact, indicate which alias the call is actually for? IMS doesn't really answer this for "aliases that are really different users", but does give is the RFC 3455 P-Called- Party-ID header that some people (Keith, I believe) keeps reminding us about. As we know, going down this path starts to get muddy very quickly. The other alternative is for MARTINI to simply amend the RFC 3261 behavior for REGISTER by mandating that responses to requests wherein the target is a "bnc" (or whatever other flag we use) do not contain the full set of registered contacts, but instead include some (presumably useful and size-limited) subset. My proposal is that, for "bnc" contacts, a successful REGISTER response return not the "expansion" of the macro-registration, but the set of unexpanded "To, Contact" vectors currently registered. Yes, this isn't a fully-explicit indication of registration state, but I think it's the best we can do in a REGISTER response over UDP. This leaves the question of what to do in a response to a failed REGISTER request. If we incorporate PBX->SSP explicit indication in the request, I propose that the failed response (specifically a 403, in most cases) contain only the first range that failed. Yes, if you have a really messed-up REGISTER request it could take a few tries before you get informed about all the failing range requests, but I don't see that as a huge problem. Ypu'll still know you have a failed registration, and that response will contain enough useful information for SOME sort of debugging. This is much better than the "implicit registration" case, where you might just THINK you'd had a successful registration, even though nothing is actually working. -- Dean From dean.willis@softarmor.com Mon Feb 15 17:29: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 DABDE3A7A03 for ; Mon, 15 Feb 2010 17:29:13 -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 IvVY1C-TDUxc for ; Mon, 15 Feb 2010 17:29:13 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1A1E23A75BC for ; Mon, 15 Feb 2010 17:29:13 -0800 (PST) Received: from [192.168.2.102] (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 o1G1UcQA030361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Feb 2010 19:30:40 -0600 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B79EFB9.8000209@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: Mon, 15 Feb 2010 19:30:33 -0600 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <4B79EFB9.8000209@cisco.com> X-Mailer: Apple Mail (2.936) Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 01:29:14 -0000 On Feb 15, 2010, at 7:07 PM, Paul Kyzivat wrote: > Dean, > > In principle I agree with you. > But this horse is already out of the barn with IMS implicit > registration. > Not really. IMS simply has a set of aliases for each registering AOR, and it explicitly reports those aliases back to the UAC in P- Associated-URI. It doesn't really address the situation where each "alias" is actually supposed to ring a different handset. RFC 3455 comes close to providing a solution in P-Called-Party-ID, but that's really more for distinctive-ring than it is for sub-AOR call routing operations. We don't think of P-Called-Party-ID as a routing header. --- Dean From christer.holmberg@ericsson.com Mon Feb 15 22:34: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 B15C63A7934 for ; Mon, 15 Feb 2010 22:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=-0.330, 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 ETo4BloiZ-YZ for ; Mon, 15 Feb 2010 22:34:30 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CBCF13A722C for ; Mon, 15 Feb 2010 22:34:28 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-3f-4b7a3cd0eb62 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 3D.CB.02429.0DC3A7B4; Tue, 16 Feb 2010 07:36:00 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 16 Feb 2010 07:35:59 +0100 From: Christer Holmberg To: Dean Willis , Paul Kyzivat Date: Tue, 16 Feb 2010 07:35:58 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqup6lXsMwaE9h7Ql2seq0EmZjJmQAKaRXA Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <4B79EFB9.8000209@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 06:34:31 -0000 Hi Dean, >>In principle I agree with you. >>But this horse is already out of the barn with IMS implicit=20 >>registration. >> >=20 >Not really. IMS simply has a set of aliases for each=20 >registering AOR, and it explicitly reports those aliases back to the UAC i= n P-=20 >Associated-URI. >=20 >It doesn't really address the situation where each "alias" is=20 >actually supposed to ring a different handset. RFC 3455 comes close to =20 >providing a solution in P-Called-Party-ID, but that's really=20 >more for distinctive-ring than it is for sub-AOR call routing operations. = We =20 >don't think of P-Called-Party-ID as a routing header. Have you looked into the 3GPP/TISPAN work on enterprises? The R-URI is forw= arded unchanged, so you don't need to rely on P-CPI. Regards, Christer From christer.holmberg@ericsson.com Mon Feb 15 22:44: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 7AFD83A7934 for ; Mon, 15 Feb 2010 22:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=-0.322, 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 u0Wd7YUHzWNl for ; Mon, 15 Feb 2010 22:44:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5BB5D3A722C for ; Mon, 15 Feb 2010 22:44:08 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-ff-4b7a3f152764 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A3.9C.02429.51F3A7B4; Tue, 16 Feb 2010 07:45:41 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 16 Feb 2010 07:45:41 +0100 From: Christer Holmberg To: Spencer Dawkins , Dean Willis Date: Tue, 16 Feb 2010 07:45:39 +0100 Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: AcquoDPRzvTtkmeyRouSKTuZhE3EwwAMma5g Message-ID: References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> In-Reply-To: <08FAA3A98AEF48828EA9B851F1FC22B7@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-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 06:44:10 -0000 Hi, I think that mobility and explicit response indication are two different th= ings - or we simply think about different things when we talk about mobilit= y :) In my opinion, MOBILITY is about when a PBX user goes from one PBX contact = to another, and how the SSP knows behind which contact the user is located.= The solution for that would most likely have impact on the communication i= n the PBX-to-SSP direction (no matter whether based on registration or some= other mechanism). Explicit indication in the response simply who is registered, in the SSP-to= -PBX direction, and that might be a requirement to solve even if mobility (= as defined above) is left out. Regards, Christer =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 16. helmikuuta 2010 2:37 > To: Dean Willis > Cc: martini@ietf.org > Subject: Re: [martini] Explicit DID indication in REGISTER >=20 > Hi, Dean, >=20 > >> Bernard and I talked this past weekend, and we both think that the=20 > >> question on mobility is the major open issue that we need to close=20 > >> before asking to adopt the next version of GIN as a=20 > working group draft. > > > > I disagree. I think explicit indication of the numbers being =20 > > registered is the open-question for MARTINI. > > > > Explicit registration is required but not sufficient for=20 > the mobility=20 > > scenarios. Doing MARTINI registration without explicit=20 > indication will=20 > > preclude using this mechanism. However, doing the followup work is=20 > > probably outside of MARTINI's immediate scope. >=20 > My post morphed pretty quickly into a discussion of explicit=20 > indication while considering mobility, so one side of my=20 > brain apparently agreed with you about the close=20 > relationship, and I don't disagree with your assertion that=20 > explicit indication may be the longest pole in the tent. >=20 > Thanks, >=20 > Spencer=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From spencer@wonderhamster.org Mon Feb 15 22:51: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 BACF03A7934 for ; Mon, 15 Feb 2010 22:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, 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 qDupipoGG7CV for ; Mon, 15 Feb 2010 22:51:15 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id E87B63A722C for ; Mon, 15 Feb 2010 22:51:14 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MXI1F-1NDqL00ja9-00WuK6; Tue, 16 Feb 2010 01:52:47 -0500 Message-ID: <8AD40E1BA95447159ABB7115687403AE@china.huawei.com> From: "Spencer Dawkins" To: "Christer Holmberg" , "Dean Willis" References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> Date: Tue, 16 Feb 2010 00:52: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: V01U2FsdGVkX184F5ZqoAhZMUX6BXnD7frx+CiN6YCX1Z1tl0C F3MCqdxjZXr/3bCsXjuS7pEhQAW43423Kb8n71GAcmJ+zed+dO vro5fpBamXvjTkOgsfBmcq9sYx0Y3q00bgCCS84DOY= Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 06:51:15 -0000 Hi, Christer, I believe that your opinion matches Dean's opinion, if I understand both... Thanks, Spencer ----- Original Message ----- From: "Christer Holmberg" To: "Spencer Dawkins" ; "Dean Willis" Cc: Sent: Tuesday, February 16, 2010 12:45 AM Subject: RE: [martini] Explicit DID indication in REGISTER Hi, I think that mobility and explicit response indication are two different things - or we simply think about different things when we talk about mobility :) In my opinion, MOBILITY is about when a PBX user goes from one PBX contact to another, and how the SSP knows behind which contact the user is located. The solution for that would most likely have impact on the communication in the PBX-to-SSP direction (no matter whether based on registration or some other mechanism). Explicit indication in the response simply who is registered, in the SSP-to-PBX direction, and that might be a requirement to solve even if mobility (as defined above) is left out. Regards, Christer From john.elwell@siemens-enterprise.com Mon Feb 15 23:15: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 58B313A74A6 for ; Mon, 15 Feb 2010 23:15:55 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJKVsBe9Jw8G for ; Mon, 15 Feb 2010 23:15: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 290D13A6F89 for ; Mon, 15 Feb 2010 23:15:53 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-898893; Tue, 16 Feb 2010 08:17:26 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 2771B23F028E; Tue, 16 Feb 2010 08:17:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 16 Feb 2010 08:17:26 +0100 From: "Elwell, John" To: Dean Willis , Spencer Dawkins Date: Tue, 16 Feb 2010 08:17:24 +0100 Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: AcqumxsP/k0jRur2QXqtYy0VNTS/KgAPDVUg Message-ID: References: <4B71AC22.3040805@nostrum.com> <005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> In-Reply-To: <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@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] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 07:15:55 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 16 February 2010 00:00 > To: Spencer Dawkins > Cc: Paul Kyzivat; Elwell, John; martini@ietf.org > Subject: Re: [martini] Explicit DID indication in REGISTER >=20 >=20 > On Feb 15, 2010, at 1:42 PM, Spencer Dawkins wrote: >=20 > > Bernard and I talked this past weekend, and we both think that the =20 > > question on mobility is the major open issue that we need to close =20 > > before asking to adopt the next version of GIN as a working group =20 > > draft. >=20 > I disagree. I think explicit indication of the numbers being =20 > registered is the open-question for MARTINI. >=20 > Explicit registration is required but not sufficient for the=20 > mobility =20 > scenarios. [JRE] In my opinion it is not proven that explicit registration is required= in order to achieve mobility. During the earlier discussion I thought ther= e were one or two proposals for mobility that did not depend on explicit re= gistration. John > Doing MARTINI registration without explicit=20 > indication will =20 > preclude using this mechanism. However, doing the followup work is =20 > probably outside of MARTINI's immediate scope. >=20 > Further, we know from our history that "implicit" is AWLAYS a=20 > mistake. =20 > We never realize the implications at the time -- it always=20 > comes back =20 > to bite us later. Perhaps we should learn from this and stop doing =20 > implicit stuff. >=20 > So, I think we should continue with an explicit registration=20 > mechanism =20 > that is adequate to meet our current needs ASAP, without sawing our =20 > legs off for the future. >=20 > -- > Dean >=20 > = From christer.holmberg@ericsson.com Mon Feb 15 23:19: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 E2CCF3A74A6 for ; Mon, 15 Feb 2010 23:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=-0.314, 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 D32c-TQ4lZPA for ; Mon, 15 Feb 2010 23:18:54 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 157CE3A6F89 for ; Mon, 15 Feb 2010 23:18:45 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-05-4b7a47316dda Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6B.9F.02429.1374A7B4; Tue, 16 Feb 2010 08:20:17 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 16 Feb 2010 08:20:16 +0100 From: Christer Holmberg To: Dean Willis , Spencer Dawkins Date: Tue, 16 Feb 2010 08:20:15 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqupzlgwRS9BneLQYGXNLqn0N2iwAAMOn+g Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <07865983-66A8-4B15-BA06-754D0A154DC1@softarmor.com> In-Reply-To: <07865983-66A8-4B15-BA06-754D0A154DC1@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 07:19:01 -0000 One more thing on this.=20 >This might lead one to think of the AOR being registered as=20 >singular, with a singular Contact, and that the=20 >telephone-numbers involved are "aliases" for this AOR. One=20 >can certainly envision explicit or implicit alias=20 >registration, and even consider that explicit transmission=20 >could occur in either direction. IMS makes it explicit using=20 >the P-Associated-URI List which is passed in the=20 >registrar->UAC direction. >=20 >This of course raises the question we asked early on: How=20 >does a request coming in to the PBX, resulting from a=20 >contact-routing operation that maps the AOR to the Contact,=20 >indicate which alias the call is actually for? IMS doesn't=20 >really answer this for "aliases that are really different=20 >users", As said before, the whole idea is that it doesn't have to answer. The PBX i= s seen as a single user, and what happens within the PBX is outside the sco= pe. Regards, Christer From christer.holmberg@ericsson.com Mon Feb 15 23:29: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 917CF3A6F89 for ; Mon, 15 Feb 2010 23:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=-0.307, 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 fHSpNzD8SP07 for ; Mon, 15 Feb 2010 23:29:41 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 229D93A659A for ; Mon, 15 Feb 2010 23:29:40 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-33-4b7a49c19d21 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B6.F0.02429.1C94A7B4; Tue, 16 Feb 2010 08:31:13 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 16 Feb 2010 08:31:12 +0100 From: Christer Holmberg To: Dean Willis , Spencer Dawkins Date: Tue, 16 Feb 2010 08:31:11 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqupzlgwRS9BneLQYGXNLqn0N2iwAAMo+AA Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <07865983-66A8-4B15-BA06-754D0A154DC1@softarmor.com> In-Reply-To: <07865983-66A8-4B15-BA06-754D0A154DC1@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 07:29:42 -0000 Hi, H.248 has (or, at least used to have) a mechanism where you could split a b= ig message into multiple messages. So, maybe would need something similar: a '188 (More stuff is coming dude)'= provisional response for REGISTER, and you keep sending those until the fu= ll set has been delivered :) Regards, Christer =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 16. helmikuuta 2010 3:27 > To: Spencer Dawkins > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 >=20 > On Feb 15, 2010, at 6:52 PM, Spencer Dawkins wrote: >=20 > > > > I was most concerned about the request/response size, based on MTU=20 > > limitations. We've said that anyone who loses sleep over that is=20 > > welcome to REGISTER TCP. Check. > > > > I have been reminded by someone smarter than me that intermediate=20 > > devices may puke on large requests/responses (where "large" is=20 > > measured at the SIP level, not at the IP MTU level), and=20 > that they can=20 > > reject large requests, but not large responses. So, I'm back to my=20 > > previous concern, just higher in the stack, if including explicit=20 > > lists of what's being registered can mean that the request=20 > (and, more=20 > > so, the response) can be big enough to cause problems. > > >=20 >=20 > I believe I raised the request/response rejection dichotomy. >=20 > If your request fails because it is too large, you can break=20 > the request up into "pieces" and do each piece separately. =20 > So for example if we find we can get 20 number ranges in a=20 > request, and you have 40 to REGISTER, it MIGHT take two=20 > requests. But that's only if either 1) an intermediary kicks=20 > it back as "too large" or 2) you just KNOW it isn't going to work. >=20 > The problematic side is the response. >=20 > I argue that we don't really need to know about the ranges=20 > that succeeded. If we get back a 200 OK, that's enough to say=20 > that the ranges we sent worked. >=20 >=20 > The problem comes from RFC 3261, which I quote below: >=20 > > 10.2.3 Fetching Bindings > > A success response to any REGISTER request contains the=20 > complete list=20 > > of existing bindings, regardless of whether the request contained a=20 > > Contact header field. If no Contact header field is present in a=20 > > REGISTER request, the list of bindings is left unchanged. >=20 > So, regardless of whether the REQUEST was explicit or=20 > implicit in declaring the scope of bindings, RFC 3261=20 > requires that the register RESPONSE contain the full set.=20 > This is obviously problematic for very large registration=20 > sets, whether resulting from a single "mass registration" or=20 > many individual registration operations. >=20 > This might lead one to think of the AOR being registered as=20 > singular, with a singular Contact, and that the=20 > telephone-numbers involved are "aliases" for this AOR. One=20 > can certainly envision explicit or implicit alias=20 > registration, and even consider that explicit transmission=20 > could occur in either direction. IMS makes it explicit using=20 > the P-Associated-URI List which is passed in the=20 > registrar->UAC direction. >=20 > This of course raises the question we asked early on: How=20 > does a request coming in to the PBX, resulting from a=20 > contact-routing operation that maps the AOR to the Contact,=20 > indicate which alias the call is actually for? IMS doesn't=20 > really answer this for "aliases that are really different=20 > users", but does give is the RFC 3455 P-Called- Party-ID=20 > header that some people (Keith, I believe) keeps reminding us=20 > about. As we know, going down this path starts to get muddy=20 > very quickly. >=20 >=20 > The other alternative is for MARTINI to simply amend the RFC=20 > 3261 behavior for REGISTER by mandating that responses to=20 > requests wherein the target is a "bnc" (or whatever other=20 > flag we use) do not contain the full set of registered=20 > contacts, but instead include some (presumably useful and=20 > size-limited) subset. >=20 > My proposal is that, for "bnc" contacts, a successful=20 > REGISTER response return not the "expansion" of the=20 > macro-registration, but the set of unexpanded "To, Contact"=20 > vectors currently registered. Yes, this isn't a=20 > fully-explicit indication of registration state, but I think=20 > it's the best we can do in a REGISTER response over UDP. >=20 > This leaves the question of what to do in a response to a =20 > failed REGISTER request. If we incorporate PBX->SSP explicit=20 > indication in the request, I propose that the failed response=20 > (specifically a 403, in most cases) contain only the first=20 > range that failed. >=20 > Yes, if you have a really messed-up REGISTER request it could=20 > take a few tries before you get informed about all the=20 > failing range requests, but I don't see that as a huge=20 > problem. Ypu'll still know you have a failed registration,=20 > and that response will contain enough useful information for=20 > SOME sort of debugging. This is much better than the=20 > "implicit registration" case, where you might just THINK=20 > you'd had a successful registration, even though nothing is=20 > actually working. >=20 >=20 > -- > Dean >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From spencer@wonderhamster.org Tue Feb 16 01: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 4C7753A7C95 for ; Tue, 16 Feb 2010 01:47:36 -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.099, 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 ihY1frVoB7vd for ; Tue, 16 Feb 2010 01:47:35 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 87A993A7C93 for ; Tue, 16 Feb 2010 01:47:35 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MWTnm-1N9g7J2MDC-00X9Qt; Tue, 16 Feb 2010 04:49:09 -0500 Message-ID: <0E0FCD5A0D5D4495B55D95D3234A8019@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "Dean Willis" References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> Date: Tue, 16 Feb 2010 03:48:57 -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: V01U2FsdGVkX18xd212AgfsEPtmIisNr4kZ/AywmHnhSvJSdxL 2OxfLaL4kIeqWg9UfjmhG78hZCtOUyRPH7D34yhJhsVWqA37QT CC+Zc3fn4PNxMbcT28iWzSI7Gp+3ZUQUzP1yAifNC4= Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 09:47:36 -0000 Hi, John, Just so Bernard and I can keep up with the cats being herded, you're referring to proposals for serial forking that were made onlist, right? Thanks, Spencer ----- Original Message ----- From: "Elwell, John" > Explicit registration is required but not sufficient for the > mobility > scenarios. [JRE] In my opinion it is not proven that explicit registration is required in order to achieve mobility. During the earlier discussion I thought there were one or two proposals for mobility that did not depend on explicit registration. From john.elwell@siemens-enterprise.com Tue Feb 16 01:52: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 789E03A7C9B for ; Tue, 16 Feb 2010 01:52:56 -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 VofspYoSD7ss for ; Tue, 16 Feb 2010 01:52: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 658B03A7C06 for ; Tue, 16 Feb 2010 01:52:55 -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-900603; Tue, 16 Feb 2010 10:54:28 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7305523F0294; Tue, 16 Feb 2010 10:54:28 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 16 Feb 2010 10:54:28 +0100 From: "Elwell, John" To: Spencer Dawkins , Dean Willis Date: Tue, 16 Feb 2010 10:54:26 +0100 Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: Acqu7UslpRjMbjq/RZe60ULKQuEYFgAAJIOA Message-ID: References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <0E0FCD5A0D5D4495B55D95D3234A8019@china.huawei.com> In-Reply-To: <0E0FCD5A0D5D4495B55D95D3234A8019@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] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 09:52:56 -0000 Spencer, That's one case, another case is where the PBX user always uses a registrar= at the same PBX, even when roaming to other PBXs. John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 16 February 2010 09:49 > To: Elwell, John; Dean Willis > Cc: Paul Kyzivat; martini@ietf.org > Subject: Re: [martini] Explicit DID indication in REGISTER >=20 > Hi, John, >=20 > Just so Bernard and I can keep up with the cats being herded, you're=20 > referring to proposals for serial forking that were made=20 > onlist, right? >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message -----=20 > From: "Elwell, John" >=20 > > Explicit registration is required but not sufficient for the > > mobility > > scenarios. > [JRE] In my opinion it is not proven that explicit=20 > registration is required=20 > in order to achieve mobility. During the earlier discussion I=20 > thought there=20 > were one or two proposals for mobility that did not depend on=20 > explicit=20 > registration.=20 >=20 > = From dean.willis@softarmor.com Tue Feb 16 06:26: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 52B303A7D15 for ; Tue, 16 Feb 2010 06:26:06 -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 bqdzjOUqinha for ; Tue, 16 Feb 2010 06:26:05 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7C8123A7D14 for ; Tue, 16 Feb 2010 06:26:05 -0800 (PST) Received: from [192.168.2.102] (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 o1GERXFA003568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2010 08:27:36 -0600 From: Dean Willis To: Spencer Dawkins In-Reply-To: <8AD40E1BA95447159ABB7115687403AE@china.huawei.com> X-Priority: 3 References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> <8AD40E1BA95447159ABB7115687403AE@china.huawei.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: Tue, 16 Feb 2010 08:27:27 -0600 X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 14:26:06 -0000 On Feb 16, 2010, at 12:52 AM, Spencer Dawkins wrote: > Hi, Christer, > > I believe that your opinion matches Dean's opinion, if I understand > both... Not quite. Christer seems to think that a PBX has only one Contact, independent of however many AORs it might have. This requires the PBX to be a UA or SBC/B2BUA, and precludes upstream registration-based routing (And forking) to the AORs of the PBX. I, in general, presume that there is at least one Contact per AOR currently "live". This allows the PBX to be a proxy if it wants to, and allows for upstream routing logic to use the set of Contacts. For example, consider an AO that is bound to two PBX instances and also to my PC. If all three instances REGISTER to my "service provider" proxy, then said proxy can do things like fork incoming INVITES to all three instances, without requiring any special tricky logic to know reachability-state for the PBXes. It treats the PBX Contacts no differently than the PC's Contact -- they're all just ordinary contacts once they're in the location service. AS I understand it, Christer's model requires the proxy using the location service to know that PBXes are somehow special, then go do a Reg-Event on them, in order to find out what their current "real Contact" set is and perform routing logic. This seems highly baroque, probably even "broken". -- Dean From dean.willis@softarmor.com Tue Feb 16 06:29: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 69FA23A7B6A for ; Tue, 16 Feb 2010 06:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K16TjAZD+X4O for ; Tue, 16 Feb 2010 06:29:05 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E9A6F3A7982 for ; Tue, 16 Feb 2010 06:29:04 -0800 (PST) Received: from [192.168.2.102] (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 o1GEUZ6w003599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Feb 2010 08:30:36 -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, 16 Feb 2010 08:30:29 -0600 References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <0E0FCD5A0D5D4495B55D95D3234A8019@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: MARTINI Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 14:29:06 -0000 On Feb 16, 2010, at 3:54 AM, Elwell, John wrote: > Spencer, > > That's one case, another case is where the PBX user always uses a > registrar at the same PBX, even when roaming to other PBXs. But what about when an upstream proxy is trying to fork to multiple PBXes as well as non-PBX SIP UAs? How does it "know" which AORs are "active" on a given PBX right now? If you don't have a fully populated location service with all the AORs and all the Contacts corresponding to those AORs, you need a whole new type of routing logic. -- Dean From BLINDSAY@nortel.com Tue Feb 16 06:59: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 343B83A6B45 for ; Tue, 16 Feb 2010 06:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 2St+pHUg0Utc for ; Tue, 16 Feb 2010 06:59:21 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2D2323A6906 for ; Tue, 16 Feb 2010 06:59:20 -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 o1GF0kY14147; Tue, 16 Feb 2010 15:00:47 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, 16 Feb 2010 10:00:06 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C876312@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: AcqvFKba40taDhxdSqyzBtmx5jHJLwAAN2ZQ References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com><0E0FCD5A0D5D4495B55D95D3234A8019@china.huawei.com> From: "Brian Lindsay" To: "Dean Willis" , "Elwell, John" Cc: MARTINI Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 14:59:22 -0000 Hi, I believe the model we have here is that the enterprise has a registrar/proxy responsible for the AoRs. The end clients need to register with the enterprise registrar/proxy. There technically wouldn't be a "non-PBX SIP UA" since it would also register with the same enterprise entity. The intent is that the Service Provider is simply routing requests to a set of E.164 numbers to the enterprise entity (aka SIP PBX). The registration transaction from the enterprise to the SSP provides the reachability information (this transaction uses an AoR that represents the enterprise entity) in lieu of any static addressing information. But otherwise this should at a high level work the same way (and support the same types of capabilities) as if the Service Provider had a static IP address for the enterprise, and there was no registration transaction between the enterprise and the Service Provider. Regards Brian =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, February 16, 2010 9:30 AM To: Elwell, John Cc: MARTINI Subject: Re: [martini] Explicit DID indication in REGISTER On Feb 16, 2010, at 3:54 AM, Elwell, John wrote: > Spencer, > > That's one case, another case is where the PBX user always uses a=20 > registrar at the same PBX, even when roaming to other PBXs. But what about when an upstream proxy is trying to fork to multiple PBXes as well as non-PBX SIP UAs? How does it "know" which AORs are "active" on a given PBX right now? If you don't have a fully populated location service with all the AORs and all the Contacts corresponding to those AORs, you need a whole new type of routing logic. -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Tue Feb 16 07:38: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 683AA28C15D for ; Tue, 16 Feb 2010 07:38:05 -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 E5acHYunmdHK for ; Tue, 16 Feb 2010 07:38:04 -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 3D4A728C155 for ; Tue, 16 Feb 2010 07:38:03 -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-906181; Tue, 16 Feb 2010 16:39:38 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6F3CD23F0294; Tue, 16 Feb 2010 16:39:38 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 16 Feb 2010 16:39:38 +0100 From: "Elwell, John" To: Brian Lindsay , Dean Willis Date: Tue, 16 Feb 2010 16:39:36 +0100 Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: AcqvFKba40taDhxdSqyzBtmx5jHJLwAAN2ZQAAIsFaA= Message-ID: References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com><0E0FCD5A0D5D4495B55D95D3234A8019@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876312@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C876312@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 Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 15:38:05 -0000 Exactly John=20 > -----Original Message----- > From: Brian Lindsay [mailto:blindsay@nortel.com]=20 > Sent: 16 February 2010 15:00 > To: Dean Willis; Elwell, John > Cc: MARTINI > Subject: RE: [martini] Explicit DID indication in REGISTER >=20 > Hi, >=20 > I believe the model we have here is that the enterprise has a > registrar/proxy responsible for the AoRs. The end clients need to > register with the enterprise registrar/proxy. There=20 > technically wouldn't > be a "non-PBX SIP UA" since it would also register with the same > enterprise entity. >=20 > The intent is that the Service Provider is simply routing=20 > requests to > a set of E.164 numbers to the enterprise entity (aka SIP PBX). The > registration transaction from the enterprise to the SSP provides the > reachability information (this transaction uses an AoR that represents > the enterprise entity) in lieu of any static addressing information. >=20 > But otherwise this should at a high level work the same way (and > support the same types of capabilities) as if the Service=20 > Provider had a > static IP address for the enterprise, and there was no registration > transaction between the enterprise and the Service Provider. >=20 > Regards > Brian >=20 > =20 >=20 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Tuesday, February 16, 2010 9:30 AM > To: Elwell, John > Cc: MARTINI > Subject: Re: [martini] Explicit DID indication in REGISTER >=20 >=20 > On Feb 16, 2010, at 3:54 AM, Elwell, John wrote: >=20 > > Spencer, > > > > That's one case, another case is where the PBX user always uses a=20 > > registrar at the same PBX, even when roaming to other PBXs. >=20 > But what about when an upstream proxy is trying to fork to multiple > PBXes as well as non-PBX SIP UAs? How does it "know" which AORs are > "active" on a given PBX right now? If you don't have a fully populated > location service with all the AORs and all the Contacts=20 > corresponding to > those AORs, you need a whole new type of routing logic. >=20 > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From spencer@wonderhamster.org Tue Feb 16 08:02: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 9A69928C163 for ; Tue, 16 Feb 2010 08:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, 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 ykO9vOUo6rnp for ; Tue, 16 Feb 2010 08:02:52 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id EAFD93A7D52 for ; Tue, 16 Feb 2010 08:02:51 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MXZCY-1ND9pY0E10-00W31j; Tue, 16 Feb 2010 11:04:19 -0500 Message-ID: From: "Spencer Dawkins" To: "Elwell, John" , "Dean Willis" References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com> <4B75C1FD.1080300@cisco.com> <9C91E78253724086BA827FEA0501524A@china.huawei.com> <9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <0E0FCD5A0D5D4495B55D95D3234A8019@china.huawei.com> Date: Tue, 16 Feb 2010 10:04:07 -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+2mg8AOsbJrUwNpNhQNCNzH8jn5qVTARutuUI zTLCB5+KMas8rujI5pET4M3ucdb6Nb5eIzraPdccqkp1eSMgkG QtKoaaWu3FJRoxSs9RIfHjcSv7SIn0lALIsDw6A/8I= Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 16:02:56 -0000 Hi, John, Thank you for resynchronizing me. Thanks, Spencer ----- Original Message ----- From: "Elwell, John" To: "Spencer Dawkins" ; "Dean Willis" Cc: "Paul Kyzivat" ; Sent: Tuesday, February 16, 2010 3:54 AM Subject: RE: [martini] Explicit DID indication in REGISTER Spencer, That's one case, another case is where the PBX user always uses a registrar at the same PBX, even when roaming to other PBXs. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 16 February 2010 09:49 > To: Elwell, John; Dean Willis > Cc: Paul Kyzivat; martini@ietf.org > Subject: Re: [martini] Explicit DID indication in REGISTER > > Hi, John, > > Just so Bernard and I can keep up with the cats being herded, you're > referring to proposals for serial forking that were made > onlist, right? > > Thanks, > > Spencer > > ----- Original Message ----- > From: "Elwell, John" > > > Explicit registration is required but not sufficient for the > > mobility > > scenarios. > [JRE] In my opinion it is not proven that explicit > registration is required > in order to achieve mobility. During the earlier discussion I > thought there > were one or two proposals for mobility that did not depend on > explicit > registration. > > = From spencer@wonderhamster.org Tue Feb 16 09:01: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 3CAB228C1A1 for ; Tue, 16 Feb 2010 09:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 nQZjNAmknt1b for ; Tue, 16 Feb 2010 09:01:38 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 288CC3A7D4D for ; Tue, 16 Feb 2010 09:01:38 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MFeCz-1NVebB1dht-00Ep8L; Tue, 16 Feb 2010 12:03:12 -0500 Message-ID: <35E311B1DC924E31B1B6EDEA3C46BFF2@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> <8AD40E1BA95447159ABB7115687403AE@china.huawei.com> Date: Tue, 16 Feb 2010 11:03:01 -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: V01U2FsdGVkX189wN3yflOoBiErBRweN8G2XqC/GwEsBJGKVKP HJsiWpQQ5pIPo19Qxpvc0ZQbNUk89WCoj32U3dSjlqYRURp+fc y7i8kQYKaMr+2ZnPv+lXhjoI84sHJmRbGTu9fbUnUU= Cc: martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 17:01:39 -0000 Hi, Dean, >> Hi, Christer, >> >> I believe that your opinion matches Dean's opinion, if I understand >> both... > > Not quite. Christer seems to think that a PBX has only one Contact, > independent of however many AORs it might have. This requires the PBX to > be a UA or SBC/B2BUA, and precludes upstream registration-based routing > (And forking) to the AORs of the PBX. My apologies for not including a scoping identifier on "your opinion matches Dean's opinion" - what I meant to say was that both of you were calling out explicit lists and mobility as seperate, but related, topics that the working group needs to close on (quickly). Thank you for your helpful post in followup, though. It captures several points that I've heard referred to in passing, but have not seen previous discussed on our mailing list. Spencer From adam@nostrum.com Tue Feb 16 10:19: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 301F33A6B67 for ; Tue, 16 Feb 2010 10:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 g3Nd02SAV1b9 for ; Tue, 16 Feb 2010 10:19: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 DDC683A7BB3 for ; Tue, 16 Feb 2010 10:19:15 -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 o1GIKeP6054901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 12:20:41 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7AE1F8.3040006@nostrum.com> Date: Tue, 16 Feb 2010 12:20: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: Christer Holmberg References: <4B68BEB4.2020207@nostrum.com> <4B6C3C26.80908@cisco.com> <4B6C5304.9070605@nostrum.com> <4B6C59D1.20706@cisco.com> <4B6C7232.4090009@nostrum.com> <4B70C117.4090900@cisco.com> <4B70D17C.7050601@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 Subject: Re: [martini] GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 18:19:18 -0000 On 2/12/10 16:27, Feb 12, Christer Holmberg wrote: > Hi, > > >>>>>>> * Need for Proxy-Require >>>>>>> >>>>>>> You say we need because we are altering the semantics of REGISTER. >>>>>>> But which semantics of register *that pertain to proxies* are we >>>>>>> altering? >>>>>>> >>>>>> Policy decisions that have historically applied to a single AOR >>>>>> will now be applied to REGISTER transactions that pertain to >>>>>> multiple AORs. That's a change. >>>>>> >>>>>> Really: why else are you going to have proxies between the PBX and >>>>>> the SSP? It pretty much comes down to NAT traversal and application >>>>>> of policy. >>>>>> >>>>> AFAIK all of these things are making leaps of faith that aren't >>>>> supported by the standards. >>>>> >>>> I think RFCs 3327 and 3608 actually provide such support, after a >>>> fashion. They're designed explicitly to put proxies in the path at >>>> registration time. What are these proxies ostensibly used for? >>>> >>> Putting a proxy in the path doesn't say anything about why it is there. >>> (Maybe just for data gathering/monitoring, ...) >>> >>> There is still nothing that justifies such a proxy making assumptions >>> such as: "only the registered contact will validly appear in outgoing >>> requests on this path". >>> >> Or something less broken (although admittedly more baroque) like: "I know AOR sip:+12145550107@foo.com needs to go through proxy Y, so I'll add it to the Path list." >> > Such text exists in RFC 5626: > > Section 5.1 says: > > "When an edge proxy receives a registration request with a "reg-id" > header field parameter in the Contact header field, it needs to > determine if it (the edge proxy) will have to be visited for any > subsequent requests sent to the User Agent identified in the Contact > header field, or not." > > So that strengthens the argument for using a Proxy-Require. /a From adam@nostrum.com Tue Feb 16 10:30: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 308D53A7D85 for ; Tue, 16 Feb 2010 10:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 3jPLF-02Ug2M for ; Tue, 16 Feb 2010 10:30: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 F01243A7D75 for ; Tue, 16 Feb 2010 10:30:26 -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 o1GIVxJ5055688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 12:32:00 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7AE49F.6080007@nostrum.com> Date: Tue, 16 Feb 2010 12:31:59 -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: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080101040506010104020803" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] MARTINI Virtual Interim III Draft Minutes (please review) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 18:30:31 -0000 This is a multi-part message in MIME format. --------------080101040506010104020803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/15/10 18:55, Feb 15, Bernard Aboba wrote: > > *Slide-15:* (Proxy-Require) > > Adam Roach: It's not the kiss of death if we don't define a new > Proxy-Require tag, since the proxies that need to understand and > participate in this registration are all within one domain, and spread > across multiple domains. > That's backwards from what I said. We've generally been hesitant to define Proxy-Require feature tags, since the chance that they'll get all the way through the network is vanishingly small. Without some kind of network-wide coordination -- which isn't possible on the general Internet -- there's no way to get the entire body of deployed proxies upgraded to support the new feature tag. However, during registration, only one domain is involved. This makes upgrading the entire proxy network that might be involved far more tractable. /a --------------080101040506010104020803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/15/10 18:55, Feb 15, Bernard Aboba wrote:

Slide-15: (Proxy-Require)

Adam Roach: It’s not the kiss of death if we don’t define a new Proxy-Require tag, since the proxies that need to understand and participate in this registration are all within one domain, and spread across multiple domains.


That's backwards from what I said.

We've generally been hesitant to define Proxy-Require feature tags, since the chance that they'll get all the way through the network is vanishingly small. Without some kind of network-wide coordination -- which isn't possible on the general Internet -- there's no way to get the entire body of deployed proxies upgraded to support the new feature tag.

However, during registration, only one domain is involved. This makes upgrading the entire proxy network that might be involved far more tractable.

/a
--------------080101040506010104020803-- From adam@nostrum.com Tue Feb 16 10:33: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 2E97F3A7D8E for ; Tue, 16 Feb 2010 10:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.026, 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 W5PYQksNhiZC for ; Tue, 16 Feb 2010 10:33: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 02A503A7D8D for ; Tue, 16 Feb 2010 10:33:20 -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 o1GIYr5k055870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 12:34:54 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7AE54D.3010708@nostrum.com> Date: Tue, 16 Feb 2010 12:34:53 -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: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> In-Reply-To: <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.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: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 18:33:22 -0000 On 2/15/10 18:52, Feb 15, Spencer Dawkins wrote: > I have been reminded by someone smarter than me that intermediate > devices may puke on large requests/responses (where "large" is > measured at the SIP level, not at the IP MTU level), and that they can > reject large requests, but not large responses. So, I'm back to my > previous concern, just higher in the stack, if including explicit > lists of what's being registered can mean that the request (and, more > so, the response) can be big enough to cause problems. > > Several people have been saying "use regevents, because you want an > ongoing understanding of what the other guy thinks anyway, not just a > snapshot at REGISTER time", and I've been listening. Wait, what? The REGISTER will be too big if we include a list of extensions in it, but the NOTIFY won't? What kind of magic is this? /a From adam@nostrum.com Tue Feb 16 10:38: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 A8B203A7BAF for ; Tue, 16 Feb 2010 10:38: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.025, 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 dA+ArSFzEZLa for ; Tue, 16 Feb 2010 10:38: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 41E7F28C183 for ; Tue, 16 Feb 2010 10:38:49 -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 o1GIcvhI056182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 12:38:57 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7AE641.70904@nostrum.com> Date: Tue, 16 Feb 2010 12:38:57 -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: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <4B79EFB9.8000209@cisco.com> In-Reply-To: <4B79EFB9.8000209@cisco.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: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 18:38:52 -0000 So, here's what I don't understand: 3GPP at least defined a procedure -- through a questionable use of P-Associated-URI -- to indicate which URIs the registrar would be registering on behalf of the user. So even the original 3GPP implicit approach had an enumeration of the AORs associated with the registration process. We're proposing to be even more sparse than that. Rather than just "implicit with a list of AORs," we're proposing "implicit with *no* list of AORs." So, even if your assertion that our allowing the implicit mechanism to stand is somehow tacit approval, what's being proposed here is even one step more nebulous. /a On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > Dean, > > In principle I agree with you. > But this horse is already out of the barn with IMS implicit registration. > > It was never explicitly brought to the ietf, though things linked to > it like P-Asserted-ID and P-Associated-URI were. While we could say > that is not our problem, I think we already implicitly approved it via > benign neglect. > > Thanks, > Paul > > Dean Willis wrote: >> >> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: >> >>> Speaking as co-chair, the non-registration aspects of DID number >>> mobility >>> are outside the scope of the current MARTINI WG charter. >>> >>> The question on the table (see >>> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html ) is >>> whether the registration aspects represent a requirement or not. >>> Feel free >>> to respond and provide your opinion on that thread. >> >> Explicit is its own reward. >> >> Remember, the one thing that RFC 3261 REGISTER really does is bind an >> AOR to a Contact. Both the AOR and the Contact involved are >> explicitly encoded in the request. >> >> I'm OKAY with extending REGISTER to bind multiple AORs to multiple >> Contacts. This seems like a reasonable extension to simplify life >> for a "multi user" SIP user agent. But I really think we should >> respect the history of REGISTERs explicit encoding of the AORs and >> Contacts involved. >> >> From a requirements perspective, I'd be happy with a requirement >> along the lines of "must not preclude AOR mobility indicated by the >> registration." I agree that we can't justify a requirement to produce >> a mechanism at the time for the whole enchilada. >> >> -- >> Dean >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Tue Feb 16 10:40: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 524C33A7BF4 for ; Tue, 16 Feb 2010 10:40:29 -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.025, 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 dSps2VIZ8i1H for ; Tue, 16 Feb 2010 10:40: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 265653A7B73 for ; Tue, 16 Feb 2010 10:40:27 -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 o1GIfx1M056443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 12:41:59 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7AE6F7.9080703@nostrum.com> Date: Tue, 16 Feb 2010 12:41:59 -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: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> <8AD40E1BA95447159ABB7115687403AE@china.huawei.com> In-Reply-To: <8AD40E1BA95447159ABB7115687403AE@china.huawei.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] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 18:40:29 -0000 And mine, for that matter. Explicit DID lists in the REGISTER have a number of applications. Terminal mobility is just one of them. And it's not (IMHO) even the most important one. /a On 2/16/10 00:52, Feb 16, Spencer Dawkins wrote: > Hi, Christer, > > I believe that your opinion matches Dean's opinion, if I understand > both... > > Thanks, > > Spencer > > ----- Original Message ----- From: "Christer Holmberg" > > To: "Spencer Dawkins" ; "Dean Willis" > > Cc: > Sent: Tuesday, February 16, 2010 12:45 AM > Subject: RE: [martini] Explicit DID indication in REGISTER > > > > Hi, > > I think that mobility and explicit response indication are two > different things - or we simply think about different things when we > talk about mobility :) > > In my opinion, MOBILITY is about when a PBX user goes from one PBX > contact to another, and how the SSP knows behind which contact the > user is located. The solution for that would most likely have impact > on the communication in the PBX-to-SSP direction (no matter whether > based on registration or some other mechanism). > > Explicit indication in the response simply who is registered, in the > SSP-to-PBX direction, and that might be a requirement to solve even if > mobility (as defined above) is left out. > > Regards, > > Christer > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Tue Feb 16 10:55: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 32CA33A7D9C for ; Tue, 16 Feb 2010 10:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.641, 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 LZStKpJGc2Nb for ; Tue, 16 Feb 2010 10:55:51 -0800 (PST) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by core3.amsl.com (Postfix) with ESMTP id E573A3A7D8A for ; Tue, 16 Feb 2010 10:55:50 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 10:57:26 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Adam Roach'" References: <4B7AE49F.6080007@nostrum.com> In-Reply-To: <4B7AE49F.6080007@nostrum.com> Date: Tue, 16 Feb 2010 10:58:08 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01CAAEF6.ECDA2E70" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcqvNlOmPrpspFxGSbeihbL7hvukhgAA5QEQ Content-Language: en-us X-OriginalArrivalTime: 16 Feb 2010 18:57:26.0369 (UTC) FILETIME=[E16FFD10:01CAAF39] Cc: martini@ietf.org Subject: Re: [martini] MARTINI Virtual Interim III Draft Minutes (please review) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 18:55:55 -0000 ------=_NextPart_000_0099_01CAAEF6.ECDA2E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for the correction. An updated version of the minutes is available here: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/Feb-9th-MARTINI-Note s-dch-bl-merger.doc From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, February 16, 2010 10:32 AM To: Bernard Aboba Cc: martini@ietf.org Subject: Re: [martini] MARTINI Virtual Interim III Draft Minutes (please review) On 2/15/10 18:55, Feb 15, Bernard Aboba wrote: Slide-15: (Proxy-Require) Adam Roach: It's not the kiss of death if we don't define a new Proxy-Require tag, since the proxies that need to understand and participate in this registration are all within one domain, and spread across multiple domains. That's backwards from what I said. We've generally been hesitant to define Proxy-Require feature tags, since the chance that they'll get all the way through the network is vanishingly small. Without some kind of network-wide coordination -- which isn't possible on the general Internet -- there's no way to get the entire body of deployed proxies upgraded to support the new feature tag. However, during registration, only one domain is involved. This makes upgrading the entire proxy network that might be involved far more tractable. /a ------=_NextPart_000_0099_01CAAEF6.ECDA2E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the correction.  An updated version of = the minutes is available here:

http://aboba.drizzlehosting.com/MARTINI/J= an-Interim-III/Feb-9th-MARTINI-Notes-dch-bl-merger.doc

 

 

From: Adam Roach = [mailto:adam@nostrum.com]
Sent: Tuesday, February 16, 2010 10:32 AM
To: Bernard Aboba
Cc: martini@ietf.org
Subject: Re: [martini] MARTINI Virtual Interim III Draft Minutes = (please review)

 

On 2/15/10 18:55, Feb 15, Bernard Aboba wrote: =

Slide-15: = (Proxy-Require)

Adam Roach: = It’s not the kiss of death if we don’t define a new Proxy-Require tag, since = the proxies that need to understand and participate in this registration are all = within one domain, and spread across multiple domains.


That's backwards from what I said.

We've generally been hesitant to define Proxy-Require feature tags, = since the chance that they'll get all the way through the network is vanishingly = small. Without some kind of network-wide coordination -- which isn't possible = on the general Internet -- there's no way to get the entire body of deployed = proxies upgraded to support the new feature tag.

However, during registration, only one domain is involved. This makes = upgrading the entire proxy network that might be involved far more tractable.

/a

------=_NextPart_000_0099_01CAAEF6.ECDA2E70-- From spencer@wonderhamster.org Tue Feb 16 11:16: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 1A1E93A7CB7 for ; Tue, 16 Feb 2010 11:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 pjkNX1WTzcA8 for ; Tue, 16 Feb 2010 11:16:55 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 4AD6C3A7D8A for ; Tue, 16 Feb 2010 11:16:55 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Ln8jt-1OBIxu0NkT-00hPn2; Tue, 16 Feb 2010 14:17:42 -0500 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com> Date: Tue, 16 Feb 2010 13:17:28 -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: V01U2FsdGVkX19enjrx8dNDczUlWUnnvax9QqV13+lXHE7JMXo D2YB0A/7hOGj4Lrgle+r2bZjK5kySjDIpR9edLdQAa4iPKBuci 6XL5g3n6LDGsB9/fkSWUkiCu40cS0yJRGXhGTLfOBE= Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 19:16:57 -0000 Hi, Adam, >> I have been reminded by someone smarter than me that intermediate devices >> may puke on large requests/responses (where "large" is measured at the >> SIP level, not at the IP MTU level), and that they can reject large >> requests, but not large responses. So, I'm back to my previous concern, >> just higher in the stack, if including explicit lists of what's being >> registered can mean that the request (and, more so, the response) can be >> big enough to cause problems. >> >> Several people have been saying "use regevents, because you want an >> ongoing understanding of what the other guy thinks anyway, not just a >> snapshot at REGISTER time", and I've been listening. > > Wait, what? > > The REGISTER will be too big if we include a list of extensions in it, but > the NOTIFY won't? What kind of magic is this? I wasn't intending magic here... just saying that the REGISTER would no longer have the problem. I was assuming (maybe this is a bad assumption) that we didn't have to send back the entire list in one NOTIFY, but that we would have to send the entire list in one REGISTER (whether in the request, the response, or both). I didn't say that, of course, and if other people aren't thinking what I'm thinking, I could be confused. Thanks, Spencer From BLINDSAY@nortel.com Tue Feb 16 11: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 5115828C100 for ; Tue, 16 Feb 2010 11:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwX2jELW+IJC for ; Tue, 16 Feb 2010 11:35:41 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 26D423A78B1 for ; Tue, 16 Feb 2010 11:35: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 o1GJadG02398; Tue, 16 Feb 2010 19:36:39 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, 16 Feb 2010 14:36:12 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> In-Reply-To: <4B7AE641.70904@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvN4YjgJyZRYmpRiaDXBx4b4RGGgAAtS9A References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com> <4B7AE641.70904@nostrum.com> From: "Brian Lindsay" To: "Adam Roach" , "Paul Kyzivat" Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 19:35:42 -0000 Hi, I think it's been stated many times in the threads that E.164 number provisioning between the enterprise and service provider is out of scope of MARTINI. So we're not using the register transaction to perform any syncronization on these numbers betweeen the enterprise and service provider. The registration is just being used to provide reachability info, to allow requests to a set of E.164 numbers to be routed to the SIP PBX. As such, I don't think the number ranges need to be part of the registration transaction. It'll just add extra complexity to the implementations. Regards Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Tuesday, February 16, 2010 1:39 PM To: Paul Kyzivat Cc: Bernard Aboba; 'MARTINI' Subject: Re: [martini] DID Number Mobility and MARTINI So, here's what I don't understand: 3GPP at least defined a procedure -- through a questionable use of P-Associated-URI -- to indicate which URIs the registrar would be registering on behalf of the user. So even the original 3GPP implicit approach had an enumeration of the AORs associated with the registration process. We're proposing to be even more sparse than that. Rather than just "implicit with a list of AORs," we're proposing "implicit with *no* list of AORs." So, even if your assertion that our allowing the implicit mechanism to stand is somehow tacit approval, what's being proposed here is even one step more nebulous. /a On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > Dean, > > In principle I agree with you. > But this horse is already out of the barn with IMS implicit registration. > > It was never explicitly brought to the ietf, though things linked to=20 > it like P-Asserted-ID and P-Associated-URI were. While we could say=20 > that is not our problem, I think we already implicitly approved it via > benign neglect. > > Thanks, > Paul > > Dean Willis wrote: >> >> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: >> >>> Speaking as co-chair, the non-registration aspects of DID number=20 >>> mobility are outside the scope of the current MARTINI WG charter. >>> >>> The question on the table (see >>> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html ) >>> is whether the registration aspects represent a requirement or not. >>> Feel free >>> to respond and provide your opinion on that thread. >> >> Explicit is its own reward. >> >> Remember, the one thing that RFC 3261 REGISTER really does is bind an >> AOR to a Contact. Both the AOR and the Contact involved are=20 >> explicitly encoded in the request. >> >> I'm OKAY with extending REGISTER to bind multiple AORs to multiple=20 >> Contacts. This seems like a reasonable extension to simplify life for >> a "multi user" SIP user agent. But I really think we should respect=20 >> the history of REGISTERs explicit encoding of the AORs and Contacts=20 >> involved. >> >> From a requirements perspective, I'd be happy with a requirement=20 >> along the lines of "must not preclude AOR mobility indicated by the=20 >> registration." I agree that we can't justify a requirement to produce >> a mechanism at the time for the whole enchilada. >> >> -- >> 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 christer.holmberg@ericsson.com Tue Feb 16 12: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 9702B28C1BF for ; Tue, 16 Feb 2010 12:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.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 5QSFjWbY-Akr for ; Tue, 16 Feb 2010 12:57:36 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 80EDE28C171 for ; Tue, 16 Feb 2010 12:57:36 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-2c-4b7b071e4d0d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 10.81.31641.E170B7B4; Tue, 16 Feb 2010 21:59:11 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 16 Feb 2010 21:59:11 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 16 Feb 2010 21:59:10 +0100 From: Christer Holmberg To: Spencer Dawkins , Adam Roach Date: Tue, 16 Feb 2010 21:57:59 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvPN058CJBnaA8TMy3FTz2jJG3uQADdsV3 Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@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: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 20:57:37 -0000 Hi, In IMS the P-Associated-URI header field is included in the REGISTER respon= se. I don't know if anyone is claiming otherwise, but just to be clear :) Regards, Christer ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Spen= cer Dawkins [spencer@wonderhamster.org] Sent: Tuesday, February 16, 2010 9:17 PM To: Adam Roach Cc: Bernard Aboba; 'MARTINI' Subject: Re: [martini] DID Number Mobility and MARTINI Hi, Adam, >> I have been reminded by someone smarter than me that intermediate device= s >> may puke on large requests/responses (where "large" is measured at the >> SIP level, not at the IP MTU level), and that they can reject large >> requests, but not large responses. So, I'm back to my previous concern, >> just higher in the stack, if including explicit lists of what's being >> registered can mean that the request (and, more so, the response) can be >> big enough to cause problems. >> >> Several people have been saying "use regevents, because you want an >> ongoing understanding of what the other guy thinks anyway, not just a >> snapshot at REGISTER time", and I've been listening. > > Wait, what? > > The REGISTER will be too big if we include a list of extensions in it, bu= t > the NOTIFY won't? What kind of magic is this? I wasn't intending magic here... just saying that the REGISTER would no longer have the problem. I was assuming (maybe this is a bad assumption) that we didn't have to send back the entire list in one NOTIFY, but that we would have to send the entire list in one REGISTER (whether in the request, the response, or both)= . I didn't say that, of course, and if other people aren't thinking what I'm thinking, I could be confused. Thanks, Spencer _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini= From christer.holmberg@ericsson.com Tue Feb 16 13:16: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 AE3F03A7BD9 for ; Tue, 16 Feb 2010 13:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=-0.294, 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 wUwYwTtUoPuU for ; Tue, 16 Feb 2010 13:16:36 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 743B93A7BF1 for ; Tue, 16 Feb 2010 13:16:36 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-c0-4b7b0b92dfb8 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F3.05.02429.29B0B7B4; Tue, 16 Feb 2010 22:18:11 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 16 Feb 2010 22:18:10 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 16 Feb 2010 22:18:10 +0100 From: Christer Holmberg To: Dean Willis , Spencer Dawkins Date: Tue, 16 Feb 2010 22:18:10 +0100 Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: AcqvFDP3dAbk4ixpSsu8Fk4S5dpcogAN3pD5 Message-ID: References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> <8AD40E1BA95447159ABB7115687403AE@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] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 21:16:37 -0000 Hi, >Not quite. Christer seems to think that a PBX has only one Contact, >independent of however many AORs it might have. This requires the PBX >to be a UA or SBC/B2BUA, If you put the contact (which points to the PBX) in a Route header, and the= called PBX number in the R-URI, I believe the PBX can act as a proxy. For the rest of your e-mail, we would probably need to draw some pictures, = to make sure we have a common understanding of "proxies", "real contacts" e= tc :) Regards, Christer >and precludes upstream registration-based routing (And forking) to the AOR= s of the PBX. > >I, in general, presume that there is at least one Contact per AOR >currently "live". This allows the PBX to be a proxy if it wants to, >and allows for upstream routing logic to use the set of Contacts. > >For example, consider an AO that is bound to two PBX instances and >also to my PC. If all three instances REGISTER to my "service >provider" proxy, then said proxy can do things like fork incoming >INVITES to all three instances, without requiring any special tricky >logic to know reachability-state for the PBXes. It treats the PBX >Contacts no differently than the PC's Contact -- they're all just >ordinary contacts once they're in the location service. > >AS I understand it, Christer's model requires the proxy using the >location service to know that PBXes are somehow special, then go do a >Reg-Event on them, in order to find out what their current "real >Contact" set is and perform routing logic. This seems highly baroque, >probably even "broken". -- Dean= From spencer@wonderhamster.org Tue Feb 16 13:36: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 9C1083A7BD4 for ; Tue, 16 Feb 2010 13:36:26 -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.064, 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 jlUeZ3IjM5Ln for ; Tue, 16 Feb 2010 13:36:24 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 8C2263A79BE for ; Tue, 16 Feb 2010 13:36:24 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MDhri-1NSgTO3xMM-00GkjU; Tue, 16 Feb 2010 16:37:20 -0500 Message-ID: <7026622AD49444D2AFAD40F584A08028@china.huawei.com> From: "Spencer Dawkins" To: "Brian Lindsay" , "Adam Roach" , "Paul Kyzivat" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> Date: Tue, 16 Feb 2010 15:37:06 -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+T1PG9kKfswkyBknhUaJl20TknB6ejBF0Qeyn rF1P9JcPmOy6i5Oo9Pjt4JvipY/GYirURj1v6UEDp0HHpuKGWl 8zSh9YvdKAPSe15nZwY2yK8H/Uk/UeH+e8Al8orsx0= Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 21:36:26 -0000 Hi, Brian, Just trying to stay synchronized here. Speaking as an individual, I think you're right about provisioning being out of scope, based on what I've been hearing on this list and in telechats, etc. What I thought Adam was talking about isn't quite provisioning (ignoring the question direction - I've heard some people suggest each direction). It was more like "I expect these numbers to be registered" and/or "I registered these numbers on your behalf", with the question of how each end knows what numbers "should" be registered being out of scope - because "knowing" was provisioned. At least, that's the context in which I was reading Adam's note below. Thanks, Spencer > Hi, > > I think it's been stated many times in the threads that E.164 number > provisioning between the enterprise and service provider is out of scope > of MARTINI. So we're not using the register transaction to perform any > syncronization on these numbers betweeen the enterprise and service > provider. The registration is just being used to provide reachability > info, to allow requests to a set of E.164 numbers to be routed to the > SIP PBX. As such, I don't think the number ranges need to be part of the > registration transaction. It'll just add extra complexity to the > implementations. > > Regards > Brian > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Tuesday, February 16, 2010 1:39 PM > To: Paul Kyzivat > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI > > So, here's what I don't understand: 3GPP at least defined a procedure -- > through a questionable use of P-Associated-URI -- to indicate which URIs > the registrar would be registering on behalf of the user. So even the > original 3GPP implicit approach had an enumeration of the AORs > associated with the registration process. > > We're proposing to be even more sparse than that. Rather than just > "implicit with a list of AORs," we're proposing "implicit with *no* list > of AORs." > > So, even if your assertion that our allowing the implicit mechanism to > stand is somehow tacit approval, what's being proposed here is even one > step more nebulous. > > /a > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: >> Dean, >> >> In principle I agree with you. >> But this horse is already out of the barn with IMS implicit > registration. >> >> It was never explicitly brought to the ietf, though things linked to >> it like P-Asserted-ID and P-Associated-URI were. While we could say >> that is not our problem, I think we already implicitly approved it via > >> benign neglect. >> >> Thanks, >> Paul >> >> Dean Willis wrote: >>> >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: >>> >>>> Speaking as co-chair, the non-registration aspects of DID number >>>> mobility are outside the scope of the current MARTINI WG charter. >>>> >>>> The question on the table (see >>>> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html ) > >>>> is whether the registration aspects represent a requirement or not. >>>> Feel free >>>> to respond and provide your opinion on that thread. >>> >>> Explicit is its own reward. >>> >>> Remember, the one thing that RFC 3261 REGISTER really does is bind an > >>> AOR to a Contact. Both the AOR and the Contact involved are >>> explicitly encoded in the request. >>> >>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple >>> Contacts. This seems like a reasonable extension to simplify life for > >>> a "multi user" SIP user agent. But I really think we should respect >>> the history of REGISTERs explicit encoding of the AORs and Contacts >>> involved. >>> >>> From a requirements perspective, I'd be happy with a requirement >>> along the lines of "must not preclude AOR mobility indicated by the >>> registration." I agree that we can't justify a requirement to produce > >>> a mechanism at the time for the whole enchilada. >>> >>> -- >>> 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 BLINDSAY@nortel.com Tue Feb 16 13:51: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 BC9653A7DDB for ; Tue, 16 Feb 2010 13:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 kM3pz6aB8tCU for ; Tue, 16 Feb 2010 13:51:26 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 49E853A7DDE for ; Tue, 16 Feb 2010 13:51:26 -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 o1GLpwe05009; Tue, 16 Feb 2010 21:51:58 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, 16 Feb 2010 16:51:39 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> In-Reply-To: <7026622AD49444D2AFAD40F584A08028@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvUE+LR+8KtHODTMqK3AvExWSYRgAAFEUw References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> From: "Brian Lindsay" To: "Spencer Dawkins" , "Adam Roach" , "Paul Kyzivat" Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 21:51:27 -0000 Hi Spencer, So basically since the provisioning/sync of the E.164 numbers/ranges is out of scope I don't see a strong argument for including them in the registration transaction. The Service Provider has a set of E.164 numbers that, based on prior assignment/arrangement, it is responsible to route to the SIP PBX. The SIP PBX is aware of these numbers already. The registration process (using an AoR identifying the SIP PBX) is intended to provide reachability information for the SIP PBX, in the absence of static IP address configuration / DNS (hence the ranges are not actually required in this transaction). Thanks Brian -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 Sent: Tuesday, February 16, 2010 4:37 PM To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat Cc: Bernard Aboba; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI Hi, Brian, Just trying to stay synchronized here. Speaking as an individual, I think you're right about provisioning being out of scope, based on what I've been hearing on this list and in telechats, etc. What I thought Adam was talking about isn't quite provisioning (ignoring the question direction - I've heard some people suggest each direction). It was more like "I expect these numbers to be registered" and/or "I registered these numbers on your behalf", with the question of how each end knows what numbers "should" be registered being out of scope - because "knowing" was provisioned. At least, that's the context in which I was reading Adam's note below. Thanks, Spencer > Hi, > > I think it's been stated many times in the threads that E.164 number > provisioning between the enterprise and service provider is out of=20 > scope of MARTINI. So we're not using the register transaction to=20 > perform any syncronization on these numbers betweeen the enterprise=20 > and service provider. The registration is just being used to provide=20 > reachability info, to allow requests to a set of E.164 numbers to be=20 > routed to the SIP PBX. As such, I don't think the number ranges need=20 > to be part of the registration transaction. It'll just add extra=20 > complexity to the implementations. > > Regards > Brian > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > Behalf Of Adam Roach > Sent: Tuesday, February 16, 2010 1:39 PM > To: Paul Kyzivat > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI > > So, here's what I don't understand: 3GPP at least defined a procedure=20 > -- through a questionable use of P-Associated-URI -- to indicate which > URIs the registrar would be registering on behalf of the user. So even > the original 3GPP implicit approach had an enumeration of the AORs=20 > associated with the registration process. > > We're proposing to be even more sparse than that. Rather than just=20 > "implicit with a list of AORs," we're proposing "implicit with *no*=20 > list of AORs." > > So, even if your assertion that our allowing the implicit mechanism to > stand is somehow tacit approval, what's being proposed here is even=20 > one step more nebulous. > > /a > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: >> Dean, >> >> In principle I agree with you. >> But this horse is already out of the barn with IMS implicit > registration. >> >> It was never explicitly brought to the ietf, though things linked to=20 >> it like P-Asserted-ID and P-Associated-URI were. While we could say=20 >> that is not our problem, I think we already implicitly approved it=20 >> via > >> benign neglect. >> >> Thanks, >> Paul >> >> Dean Willis wrote: >>> >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: >>> >>>> Speaking as co-chair, the non-registration aspects of DID number=20 >>>> mobility are outside the scope of the current MARTINI WG charter. >>>> >>>> The question on the table (see >>>> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html=20 >>>> ) > >>>> is whether the registration aspects represent a requirement or not. >>>> Feel free >>>> to respond and provide your opinion on that thread. >>> >>> Explicit is its own reward. >>> >>> Remember, the one thing that RFC 3261 REGISTER really does is bind=20 >>> an > >>> AOR to a Contact. Both the AOR and the Contact involved are=20 >>> explicitly encoded in the request. >>> >>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple=20 >>> Contacts. This seems like a reasonable extension to simplify life=20 >>> for > >>> a "multi user" SIP user agent. But I really think we should respect=20 >>> the history of REGISTERs explicit encoding of the AORs and Contacts=20 >>> involved. >>> >>> From a requirements perspective, I'd be happy with a requirement=20 >>> along the lines of "must not preclude AOR mobility indicated by the >>> registration." I agree that we can't justify a requirement to=20 >>> produce > >>> a mechanism at the time for the whole enchilada. >>> >>> -- >>> 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 Tue Feb 16 14:06: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 E99383A7754 for ; Tue, 16 Feb 2010 14:06:18 -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 HvWOnSt18Uvg for ; Tue, 16 Feb 2010 14:06:16 -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 61ABB28C1E3 for ; Tue, 16 Feb 2010 14:06:10 -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: AvsEAA+mektAZnwM/2dsb2JhbACbG3SlGZd6hFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,486,1262563200"; d="scan'208";a="86685828" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2010 22:07:34 +0000 Received: from [10.86.245.160] ([10.86.245.160]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1GM7Y1X000211; Tue, 16 Feb 2010 22:07:34 GMT Message-ID: <4B7B1726.3090101@cisco.com> Date: Tue, 16 Feb 2010 17:07:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> <8AD40E1BA95447159ABB7115687403AE@china.huawei.com>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 16 Feb 2010 22:06:19 -0000 Christer, Christer Holmberg wrote: > Hi, > >> Not quite. Christer seems to think that a PBX has only one Contact, >> independent of however many AORs it might have. This requires the PBX >> to be a UA or SBC/B2BUA, > > If you put the contact (which points to the PBX) in a Route header, and the called PBX number in the R-URI, I believe the PBX can act as a proxy. I'm getting deja vu (and not for the first time). You are looping back through the cases that have been discussed ad nauseum. That approach works well with "stirred", but problems were found with stirred, so we dropped it. There have been issues raised using it with "shaken" as well. AFAIK we were *closest* to a consensus when we were talking about the registration actually (at least virtually) creates a registered contact for each AOR. Thanks, Paul > For the rest of your e-mail, we would probably need to draw some pictures, to make sure we have a common understanding of "proxies", "real contacts" etc :) > > Regards, > > Christer > > >> and precludes upstream registration-based routing (And forking) to the AORs of the PBX. >> >> I, in general, presume that there is at least one Contact per AOR >> currently "live". This allows the PBX to be a proxy if it wants to, >> and allows for upstream routing logic to use the set of Contacts. >> >> For example, consider an AO that is bound to two PBX instances and >> also to my PC. If all three instances REGISTER to my "service >> provider" proxy, then said proxy can do things like fork incoming >> INVITES to all three instances, without requiring any special tricky >> logic to know reachability-state for the PBXes. It treats the PBX >> Contacts no differently than the PC's Contact -- they're all just >> ordinary contacts once they're in the location service. >> >> AS I understand it, Christer's model requires the proxy using the >> location service to know that PBXes are somehow special, then go do a >> Reg-Event on them, in order to find out what their current "real >> Contact" set is and perform routing logic. This seems highly baroque, >> probably even "broken". > > > > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From spencer@wonderhamster.org Tue Feb 16 14:22: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 7E4E528C1FB for ; Tue, 16 Feb 2010 14:22:39 -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.061, 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 3dGFE2e-GBTr for ; Tue, 16 Feb 2010 14:22:38 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 2D30828C1F3 for ; Tue, 16 Feb 2010 14:22:38 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MBW0s-1NZIcz0pcc-00AA3k; Tue, 16 Feb 2010 17:23:27 -0500 Message-ID: From: "Spencer Dawkins" To: "Brian Lindsay" , "Adam Roach" , "Paul Kyzivat" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> Date: Tue, 16 Feb 2010 16:23:12 -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: V01U2FsdGVkX182Asx30a/hlHc4/RJ33ysjZHhjNIL7abNrTG2 hd/eK++VJ5xzodlzM7ewMrhVjwnEHqA++myTBqDVMuH94WcMeB wU8pqqk89wmTacdYlaKk7Qwmj+85KRtvnJhBTsEYgk= Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 22:22:39 -0000 Hi, Brian, Speaking carefully as chair, and Bernard can correct me if I am saying things I should not be saying as chair, at this point... I happen to agree with your reasoning, re: REGISTER. What I'm trying to tease out is whether we can just say "we're not providing that information in the REGISTER exchange, BUT you can get that information using regevents", so that we can move on - I haven't heard anyone propose that MARTINI would say "MUST NOT use regevents" :-) I would be comfortable if our specifications were silent on this point, and might be more comfortable if we pointer out somewhere that the REGISTER exchange does not provide this information, but people who want the information can use regevents or whatever other method seems appropriate to get the information that they want. But (Bernard and) I don't get to decide what working group consensus is - we only get to recognize what consensus is, and when it exists. For that, we need to hear from other participants (including you, of course - and "thank you" to participants who care, and have expressed opinions about this, in the current thread. I hope this is helpful. Thanks, Spencer ----- Original Message ----- From: "Brian Lindsay" To: "Spencer Dawkins" ; "Adam Roach" ; "Paul Kyzivat" Cc: "Bernard Aboba" ; "MARTINI" Sent: Tuesday, February 16, 2010 3:51 PM Subject: RE: [martini] DID Number Mobility and MARTINI Hi Spencer, So basically since the provisioning/sync of the E.164 numbers/ranges is out of scope I don't see a strong argument for including them in the registration transaction. The Service Provider has a set of E.164 numbers that, based on prior assignment/arrangement, it is responsible to route to the SIP PBX. The SIP PBX is aware of these numbers already. The registration process (using an AoR identifying the SIP PBX) is intended to provide reachability information for the SIP PBX, in the absence of static IP address configuration / DNS (hence the ranges are not actually required in this transaction). Thanks Brian -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org] Sent: Tuesday, February 16, 2010 4:37 PM To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat Cc: Bernard Aboba; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI Hi, Brian, Just trying to stay synchronized here. Speaking as an individual, I think you're right about provisioning being out of scope, based on what I've been hearing on this list and in telechats, etc. What I thought Adam was talking about isn't quite provisioning (ignoring the question direction - I've heard some people suggest each direction). It was more like "I expect these numbers to be registered" and/or "I registered these numbers on your behalf", with the question of how each end knows what numbers "should" be registered being out of scope - because "knowing" was provisioned. At least, that's the context in which I was reading Adam's note below. Thanks, Spencer > Hi, > > I think it's been stated many times in the threads that E.164 number > provisioning between the enterprise and service provider is out of > scope of MARTINI. So we're not using the register transaction to > perform any syncronization on these numbers betweeen the enterprise > and service provider. The registration is just being used to provide > reachability info, to allow requests to a set of E.164 numbers to be > routed to the SIP PBX. As such, I don't think the number ranges need > to be part of the registration transaction. It'll just add extra > complexity to the implementations. > > Regards > Brian > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Tuesday, February 16, 2010 1:39 PM > To: Paul Kyzivat > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI > > So, here's what I don't understand: 3GPP at least defined a procedure > -- through a questionable use of P-Associated-URI -- to indicate which > URIs the registrar would be registering on behalf of the user. So even > the original 3GPP implicit approach had an enumeration of the AORs > associated with the registration process. > > We're proposing to be even more sparse than that. Rather than just > "implicit with a list of AORs," we're proposing "implicit with *no* > list of AORs." > > So, even if your assertion that our allowing the implicit mechanism to > stand is somehow tacit approval, what's being proposed here is even > one step more nebulous. > > /a > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: >> Dean, >> >> In principle I agree with you. >> But this horse is already out of the barn with IMS implicit > registration. >> >> It was never explicitly brought to the ietf, though things linked to >> it like P-Asserted-ID and P-Associated-URI were. While we could say >> that is not our problem, I think we already implicitly approved it >> via > >> benign neglect. >> >> Thanks, >> Paul >> >> Dean Willis wrote: >>> >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: >>> >>>> Speaking as co-chair, the non-registration aspects of DID number >>>> mobility are outside the scope of the current MARTINI WG charter. >>>> >>>> The question on the table (see >>>> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html >>>> ) > >>>> is whether the registration aspects represent a requirement or not. >>>> Feel free >>>> to respond and provide your opinion on that thread. >>> >>> Explicit is its own reward. >>> >>> Remember, the one thing that RFC 3261 REGISTER really does is bind >>> an > >>> AOR to a Contact. Both the AOR and the Contact involved are >>> explicitly encoded in the request. >>> >>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple >>> Contacts. This seems like a reasonable extension to simplify life >>> for > >>> a "multi user" SIP user agent. But I really think we should respect >>> the history of REGISTERs explicit encoding of the AORs and Contacts >>> involved. >>> >>> From a requirements perspective, I'd be happy with a requirement >>> along the lines of "must not preclude AOR mobility indicated by the >>> registration." I agree that we can't justify a requirement to >>> produce > >>> a mechanism at the time for the whole enchilada. >>> >>> -- >>> 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 bernard_aboba@hotmail.com Tue Feb 16 14:38: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 CCE5F28C1EA for ; Tue, 16 Feb 2010 14:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.629, 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 jf6-axJN68kX for ; Tue, 16 Feb 2010 14:38:14 -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 E0EF928C1E3 for ; Tue, 16 Feb 2010 14:38:12 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.72]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 14:39:48 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Spencer Dawkins'" , "'Brian Lindsay'" , "'Adam Roach'" , "'Paul Kyzivat'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> In-Reply-To: Date: Tue, 16 Feb 2010 14:39:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRp1VZdj52hPuOrHnBQHHahqJ91AImR3jnArAcgWEBK5n+SgGuzU+IAhvemikCbKt+BQHPthVyAlhDj8wCikgFSwKbOWWoAMfxg+gCRZ0iSgMMlVWNAOTrwjOO1zAUkA== Content-Language: en-us X-OriginalArrivalTime: 16 Feb 2010 22:39:48.0753 (UTC) FILETIME=[F21E3810:01CAAF58] Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 22:38:15 -0000 There are a number of related things that have been discussed in this (and other) threads, and sometimes it's hard to tease the issues apart: a. Use of REGISTER vs. reg-events to find out what DIDs were registered. b. Use of REGISTER for provisioning vs. telling the SSP "what DIDs the PBX thinks it has" (which the SSP is free to find fault with, as in a conventional registration) c. Error handling (e.g. what happens when the SSP/PBX are not in sync, and how the PBX admin figures out what went wrong). I read Brian's message below as expressing an opinion on issue b), and Spencer's message as relating to that as well as Issue a). In one of the threads, Dean brought up issue c). Ideally, the requirements document would touch on each of these issues with enough clarity so that we can tell them apart. Behind a number of these issues seems to be the general question of whether a multiple AOR registration is in principle expected to produce very similar results to many single AOR registrations (minus the additional traffic, of course). Registering multiple AORs w/multiple contacts, providing similar error semantics, etc. seem to point in that direction, but I'm not sure that this principle has been explicitly discussed (or even agreed to as a goal). -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org] Sent: Tuesday, February 16, 2010 2:23 PM To: Brian Lindsay; Adam Roach; Paul Kyzivat Cc: Bernard Aboba; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI Hi, Brian, Speaking carefully as chair, and Bernard can correct me if I am saying things I should not be saying as chair, at this point... I happen to agree with your reasoning, re: REGISTER. What I'm trying to tease out is whether we can just say "we're not providing that information in the REGISTER exchange, BUT you can get that information using regevents", so that we can move on - I haven't heard anyone propose that MARTINI would say "MUST NOT use regevents" :-) I would be comfortable if our specifications were silent on this point, and might be more comfortable if we pointer out somewhere that the REGISTER exchange does not provide this information, but people who want the information can use regevents or whatever other method seems appropriate to get the information that they want. But (Bernard and) I don't get to decide what working group consensus is - we only get to recognize what consensus is, and when it exists. For that, we need to hear from other participants (including you, of course - and "thank you" to participants who care, and have expressed opinions about this, in the current thread. I hope this is helpful. Thanks, Spencer ----- Original Message ----- From: "Brian Lindsay" To: "Spencer Dawkins" ; "Adam Roach" ; "Paul Kyzivat" Cc: "Bernard Aboba" ; "MARTINI" Sent: Tuesday, February 16, 2010 3:51 PM Subject: RE: [martini] DID Number Mobility and MARTINI Hi Spencer, So basically since the provisioning/sync of the E.164 numbers/ranges is out of scope I don't see a strong argument for including them in the registration transaction. The Service Provider has a set of E.164 numbers that, based on prior assignment/arrangement, it is responsible to route to the SIP PBX. The SIP PBX is aware of these numbers already. The registration process (using an AoR identifying the SIP PBX) is intended to provide reachability information for the SIP PBX, in the absence of static IP address configuration / DNS (hence the ranges are not actually required in this transaction). Thanks Brian -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org] Sent: Tuesday, February 16, 2010 4:37 PM To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat Cc: Bernard Aboba; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI Hi, Brian, Just trying to stay synchronized here. Speaking as an individual, I think you're right about provisioning being out of scope, based on what I've been hearing on this list and in telechats, etc. What I thought Adam was talking about isn't quite provisioning (ignoring the question direction - I've heard some people suggest each direction). It was more like "I expect these numbers to be registered" and/or "I registered these numbers on your behalf", with the question of how each end knows what numbers "should" be registered being out of scope - because "knowing" was provisioned. At least, that's the context in which I was reading Adam's note below. Thanks, Spencer > Hi, > > I think it's been stated many times in the threads that E.164 number > provisioning between the enterprise and service provider is out of > scope of MARTINI. So we're not using the register transaction to > perform any syncronization on these numbers betweeen the enterprise > and service provider. The registration is just being used to provide > reachability info, to allow requests to a set of E.164 numbers to be > routed to the SIP PBX. As such, I don't think the number ranges need > to be part of the registration transaction. It'll just add extra > complexity to the implementations. > > Regards > Brian > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Tuesday, February 16, 2010 1:39 PM > To: Paul Kyzivat > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI > > So, here's what I don't understand: 3GPP at least defined a procedure > -- through a questionable use of P-Associated-URI -- to indicate which > URIs the registrar would be registering on behalf of the user. So even > the original 3GPP implicit approach had an enumeration of the AORs > associated with the registration process. > > We're proposing to be even more sparse than that. Rather than just > "implicit with a list of AORs," we're proposing "implicit with *no* > list of AORs." > > So, even if your assertion that our allowing the implicit mechanism to > stand is somehow tacit approval, what's being proposed here is even > one step more nebulous. > > /a > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: >> Dean, >> >> In principle I agree with you. >> But this horse is already out of the barn with IMS implicit > registration. >> >> It was never explicitly brought to the ietf, though things linked to >> it like P-Asserted-ID and P-Associated-URI were. While we could say >> that is not our problem, I think we already implicitly approved it >> via > >> benign neglect. >> >> Thanks, >> Paul >> >> Dean Willis wrote: >>> >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: >>> >>>> Speaking as co-chair, the non-registration aspects of DID number >>>> mobility are outside the scope of the current MARTINI WG charter. >>>> >>>> The question on the table (see >>>> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html >>>> ) > >>>> is whether the registration aspects represent a requirement or not. >>>> Feel free >>>> to respond and provide your opinion on that thread. >>> >>> Explicit is its own reward. >>> >>> Remember, the one thing that RFC 3261 REGISTER really does is bind >>> an > >>> AOR to a Contact. Both the AOR and the Contact involved are >>> explicitly encoded in the request. >>> >>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple >>> Contacts. This seems like a reasonable extension to simplify life >>> for > >>> a "multi user" SIP user agent. But I really think we should respect >>> the history of REGISTERs explicit encoding of the AORs and Contacts >>> involved. >>> >>> From a requirements perspective, I'd be happy with a requirement >>> along the lines of "must not preclude AOR mobility indicated by the >>> registration." I agree that we can't justify a requirement to >>> produce > >>> a mechanism at the time for the whole enchilada. >>> >>> -- >>> 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 adam@nostrum.com Tue Feb 16 14:41: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 F2C9528C123 for ; Tue, 16 Feb 2010 14:41:38 -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.024, 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 2Tzu1WkExeUW for ; Tue, 16 Feb 2010 14:41: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 E322B28C0F8 for ; Tue, 16 Feb 2010 14:41:37 -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 o1GMh9mW074258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 16:43:10 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7B1F7D.80306@nostrum.com> Date: Tue, 16 Feb 2010 16: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.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Bernard Aboba References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.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' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 22:41:39 -0000 On 2/16/10 16:39, Feb 16, Bernard Aboba wrote: > There are a number of related things that have been discussed in this (and > other) threads, and sometimes it's hard to tease the issues apart: > > a. Use of REGISTER vs. reg-events to find out what DIDs were registered. > b. Use of REGISTER for provisioning vs. telling the SSP "what DIDs the PBX > thinks it has" (which the SSP is free to find fault with, as in a > conventional registration) > c. Error handling (e.g. what happens when the SSP/PBX are not in sync, and > how the PBX admin figures out what went wrong). > I think you've omitted: d. Use of REGISTER for *intermediaries* to find out what DIDs have been registered. /a From adam@nostrum.com Tue Feb 16 15:01: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 DD43D28C1A3 for ; Tue, 16 Feb 2010 15:01:42 -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.024, 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 igtTJokDuE2C for ; Tue, 16 Feb 2010 15:01: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 8604928C1F8 for ; Tue, 16 Feb 2010 15:01: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 o1GN3DUw075687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 17:03:13 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7B2431.2070103@nostrum.com> Date: Tue, 16 Feb 2010 17:03:13 -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: Christer Holmberg References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@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: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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, 16 Feb 2010 23:01:43 -0000 On 2/16/10 14:57, Feb 16, Christer Holmberg wrote: > I was assuming (maybe this is a bad assumption) that we didn't have to > send back the entire list in one NOTIFY... The first time it's sent, yeah, you do. After that, there are things you can do to make it smaller, but there's no getting around the fact that the first NOTIFY ever sent will need to contain all the DID, and still fit in a single SIP message. If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in fact, the format for reg event will be even more bulky than anything anyone has in mind for REGISTER, so it makes the problem worse, not better). So, while message size might be a valid topic of conversation, moving the ranges of extensions from REGISTER to NOTIFY is simply reducing the entire issue to a previously unsolved problem. /a From keith.drage@alcatel-lucent.com Tue Feb 16 16:27: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 9331828C12B for ; Tue, 16 Feb 2010 16:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.592, 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 9ehk60xqagDB for ; Tue, 16 Feb 2010 16:27:56 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 8A7BB28C108 for ; Tue, 16 Feb 2010 16:27:56 -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.14.3/8.14.3/ICT) with ESMTP id o1H0TRKT029919 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Feb 2010 01:29:27 +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; Wed, 17 Feb 2010 01:29:27 +0100 From: "DRAGE, Keith (Keith)" To: Dean Willis , Paul Kyzivat Date: Wed, 17 Feb 2010 01:29:26 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqup7J+oDxoCpw0TTOMDHvjg7xpegAuU6Wg Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <4B79EFB9.8000209@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 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 00:27:57 -0000 But here the registration we are talking about is not the registration of t= he handset. It is the registration of the next step on the process of how t= o get to the handset / terminal. This it is using register to create part o= f a route, sothing already done by SIP in the path and service route extens= ions. regards Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Tuesday, February 16, 2010 1:31 AM > To: Paul Kyzivat > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 >=20 > On Feb 15, 2010, at 7:07 PM, Paul Kyzivat wrote: >=20 > > Dean, > > > > In principle I agree with you. > > But this horse is already out of the barn with IMS implicit=20 > > registration. > > >=20 > Not really. IMS simply has a set of aliases for each=20 > registering AOR, =20 > and it explicitly reports those aliases back to the UAC in P-=20 > Associated-URI. >=20 > It doesn't really address the situation where each "alias" is=20 > actually =20 > supposed to ring a different handset. RFC 3455 comes close to =20 > providing a solution in P-Called-Party-ID, but that's really=20 > more for =20 > distinctive-ring than it is for sub-AOR call routing operations. We =20 > don't think of P-Called-Party-ID as a routing header. >=20 > --- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From keith.drage@alcatel-lucent.com Tue Feb 16 16:28: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 E70EA28C12B for ; Tue, 16 Feb 2010 16:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.775 X-Spam-Level: X-Spam-Status: No, score=-5.775 tagged_above=-999 required=5 tests=[AWL=0.474, 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 N7n-MSKlau7M for ; Tue, 16 Feb 2010 16:28:15 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id ACFD528C108 for ; Tue, 16 Feb 2010 16:28:14 -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 o1H0TNrQ029916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Feb 2010 01:29:23 +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; Wed, 17 Feb 2010 01:29:23 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Dean Willis Date: Wed, 17 Feb 2010 01:29:23 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqupF/Darq7lwowSei5SHGoXcRPngAu8u9Q Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <4B79EFB9.8000209@cisco.com> In-Reply-To: <4B79EFB9.8000209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 00:28:16 -0000 I would point out that all of the implicit registration stuff was brought t= o IETF, not as a standards track document, but there was an informational R= FC in RFC 4083 where the general intro says: "This document is advisory in nature. Its primary purpose is to help the IETF understand the IMS environment. Given this better understanding, we expect that the IETF can more effectively evolve the SIP protocol. The IETF will not respond to the requirements given in this document on a point-for-point basis. Some requirements have been and/or will be met by extensions to the SIP protocol. Others may be addressed by effectively using existing capabilities in SIP or other protocols, and we expect that individual members of the SIP community will work with 3GPP to achieve a better understanding of these mechanisms. Some of the requirements in this document may not be addressed at all by the IETF, although we believe that the act of documenting and discussing them is in itself helpful in achieving a better all-around understanding of the task at hand." It then goes on to document the implicit registration in 4.10.2.2 of that d= ocument: "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." I would point out that while is is not IETF sanction in saying this is the = IETF way of doing things, this document was used to discuss the mechanism i= nvolved in IMS, and based on IETF response, a significant number of changes= were made in the way IMS does things as a result of this. I would contend = that at least the participants at that time argued out the harmful things, = and what is left is at least not breaking the rules. regards Keith > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, February 16, 2010 1:07 AM > To: Dean Willis > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Dean, >=20 > In principle I agree with you. > But this horse is already out of the barn with IMS implicit=20 > registration. >=20 > It was never explicitly brought to the ietf, though things=20 > linked to it like P-Asserted-ID and P-Associated-URI were.=20 > While we could say that is not our problem, I think we=20 > already implicitly approved it via benign neglect. >=20 > Thanks, > Paul >=20 > Dean Willis wrote: > >=20 > > On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > >=20 > >> Speaking as co-chair, the non-registration aspects of DID number=20 > >> mobility are outside the scope of the current MARTINI WG charter. > >> > >> The question on the table (see > >>=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html )=20 > >> is whether the registration aspects represent a=20 > requirement or not. =20 > >> Feel free to respond and provide your opinion on that thread. > >=20 > > Explicit is its own reward. > >=20 > > Remember, the one thing that RFC 3261 REGISTER really does=20 > is bind an=20 > > AOR to a Contact. Both the AOR and the Contact involved are=20 > > explicitly encoded in the request. > >=20 > > I'm OKAY with extending REGISTER to bind multiple AORs to multiple=20 > > Contacts. This seems like a reasonable extension to=20 > simplify life for=20 > > a "multi user" SIP user agent. But I really think we should respect=20 > > the history of REGISTERs explicit encoding of the AORs and=20 > Contacts involved. > >=20 > > From a requirements perspective, I'd be happy with a requirement=20 > > along the lines of "must not preclude AOR mobility=20 > indicated by the=20 > > registration." I agree that we can't justify a requirement=20 > to produce=20 > > a mechanism at the time for the whole enchilada. > >=20 > > -- > > Dean > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From bernard_aboba@hotmail.com Tue Feb 16 16:57: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 EEE1D28C117 for ; Tue, 16 Feb 2010 16:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.622, 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 EkUrRFu8qlqE for ; Tue, 16 Feb 2010 16:57:44 -0800 (PST) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by core3.amsl.com (Postfix) with ESMTP id 102D63A7E2C for ; Tue, 16 Feb 2010 16:57:43 -0800 (PST) Received: from BLU137-DS2 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 16:59:20 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Adam Roach'" , "'Christer Holmberg'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> In-Reply-To: <4B7B2431.2070103@nostrum.com> Date: Tue, 16 Feb 2010 16:59:20 -0800 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: AcqvXDhOrhYWU5EGQYuz7r8IEsWmAQAD40hQ Content-Language: en-us X-OriginalArrivalTime: 17 Feb 2010 00:59:20.0275 (UTC) FILETIME=[6FEF1A30:01CAAF6C] Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 00:57:45 -0000 Adam said:=20 "If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in=20 fact, the format for reg event will be even more bulky than anything=20 anyone has in mind for REGISTER, so it makes the problem worse, not = better). So, while message size might be a valid topic of conversation, moving=20 the ranges of extensions from REGISTER to NOTIFY is simply reducing the=20 entire issue to a previously unsolved problem." [BA] Let me ask a (perhaps na=EFve) question about the expected behavior of reg-event with respect to MARTINI multiple AOR registrations.=20 Within RFC 3680, the contents of the NOTIFY depends on which AOR is = being subscribed to. =20 If you buy into the multiple AOR/multiple contact model, wouldn't a SUBSCRIBE for the=20 an AOR return only information relating to that specific AOR, not all = the AORs that were registered? If so, doesn't that make the size issue for NOTIFY = somewhat more tractable?=20 Note that RFC 3680 Section 4.3 refers to the inclusion of a body in the SUBSCRIBE, to enable filtering of subscriptions: A SUBSCRIBE for registration events MAY contain a body. This body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this specification. A SUBSCRIBE for the registration package MAY be sent without a body. This implies that the default registration filtering policy has been requested. The default policy is: o Notifications are generated every time there is any change in the state of any of the registered contacts for the resource being subscribed to. Those notifications only contain information on the contacts whose state has changed. o Notifications triggered from a SUBSCRIBE contain full state (the list of all contacts bound to the address-of-record). From adam@nostrum.com Tue Feb 16 18: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 D506128C13F for ; Tue, 16 Feb 2010 18:40:57 -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, 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 Fx8MRuZNuHOa for ; Tue, 16 Feb 2010 18: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 4478128C13A for ; Tue, 16 Feb 2010 18:40:56 -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 o1H2gREt091092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 20:42:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7B5793.5080401@nostrum.com> Date: Tue, 16 Feb 2010 20:42:27 -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: Bernard Aboba References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040401030800020007040406" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 02:40:57 -0000 This is a multi-part message in MIME format. --------------040401030800020007040406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2/16/10 18:59, Feb 16, Bernard Aboba wrote: > Adam said: > > "If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in > fact, the format for reg event will be even more bulky than anything > anyone has in mind for REGISTER, so it makes the problem worse, not better). > > So, while message size might be a valid topic of conversation, moving > the ranges of extensions from REGISTER to NOTIFY is simply reducing the > entire issue to a previously unsolved problem." > > [BA] Let me ask a (perhaps naïve) question about the expected behavior > of reg-event with respect to MARTINI multiple AOR registrations. > > Within RFC 3680, the contents of the NOTIFY depends on which AOR is being > subscribed to. > If you buy into the multiple AOR/multiple contact model, wouldn't a > SUBSCRIBE for the > an AOR return only information relating to that specific AOR, not all the > AORs that > were registered? If so, doesn't that make the size issue for NOTIFY somewhat > more > tractable? The GIN draft goes into how this works. The short version is: yes, if you subscribe to , you'll get registration information from the PBX about that one AOR. If you subscribe to the PBX's AOR -- the one it uses to identify itself to the SSP (e.g. ), then you'll get registration information from the SSP for all of the AORs. This is consistent with the behavior described in 3680: Note that the document format explicitly allows for conveying information on multiple addresses-of-record. This enables subscriptions to groups of registrations, where such a group is identified by some kind of URI. > Note that RFC 3680 Section 4.3 refers to the inclusion of a body in the > SUBSCRIBE, to enable filtering of subscriptions: > > A SUBSCRIBE for registration events MAY contain a body. This body > would serve the purpose of filtering the subscription. The > definition of such a body is outside the scope of this specification. > Outside the scope and still undefined. We can't wave our hands at an unspecified solution and say that it somehow solves the issue. And I doubt MARTINI needs to get in the business of defining RFC 3680 filters. /a --------------040401030800020007040406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/16/10 18:59, Feb 16, Bernard Aboba wrote: 
Adam said: 

"If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in 
fact, the format for reg event will be even more bulky than anything 
anyone has in mind for REGISTER, so it makes the problem worse, not better).

So, while message size might be a valid topic of conversation, moving 
the ranges of extensions from REGISTER to NOTIFY is simply reducing the 
entire issue to a previously unsolved problem."

[BA] Let me ask a (perhaps naïve) question about the expected behavior
of reg-event with respect to MARTINI multiple AOR registrations. 

Within RFC 3680, the contents of the NOTIFY depends on which AOR is being
subscribed to.  
If you buy into the multiple AOR/multiple contact model, wouldn't a
SUBSCRIBE for the 
an AOR return only information relating to that specific AOR, not all the
AORs that
were registered? If so, doesn't that make the size issue for NOTIFY somewhat
more
tractable?

The GIN draft goes into how this works. The short version is: yes, if you subscribe to <sip:+12145550105@ssp.com>, you'll get registration information from the PBX about that one AOR. If you subscribe to the PBX's AOR -- the one it uses to identify itself to the SSP (e.g. <sip:pbx@ssp.com>), then you'll get registration information from the SSP for all of the AORs. This is consistent with the behavior described in 3680:

   Note that the document format explicitly allows for conveying
   information on multiple addresses-of-record.  This enables
   subscriptions to groups of registrations, where such a group is
   identified by some kind of URI.

Note that RFC 3680 Section 4.3 refers to the inclusion of a body in the
SUBSCRIBE, to enable filtering of subscriptions:

   A SUBSCRIBE for registration events MAY contain a body.  This body
   would serve the purpose of filtering the subscription.  The
   definition of such a body is outside the scope of this specification.

Outside the scope and still undefined. We can't wave our hands at an unspecified solution and say that it somehow solves the issue. And I doubt MARTINI needs to get in the business of defining RFC 3680 filters.

/a
--------------040401030800020007040406-- From pkyzivat@cisco.com Tue Feb 16 18:49: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 63B6528C143 for ; Tue, 16 Feb 2010 18:49:49 -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 3Nd-Q4pc4+cW for ; Tue, 16 Feb 2010 18:49:48 -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 6FF3C28C141 for ; Tue, 16 Feb 2010 18:49:48 -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: AvsEACboektAZnwM/2dsb2JhbACaf3SlIpd9gkaCFQSDFA X-IronPort-AV: E=Sophos;i="4.49,487,1262563200"; d="scan'208";a="240523519" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2010 02:51:24 +0000 Received: from [10.86.255.227] ([10.86.255.227]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1H2pOCh019822; Wed, 17 Feb 2010 02:51:24 GMT Message-ID: <4B7B59AA.5080509@cisco.com> Date: Tue, 16 Feb 2010 21:51:22 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> <4B7B5793.5080401@nostrum.com> In-Reply-To: <4B7B5793.5080401@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 02:49:49 -0000 Interesting direction... IMS has set the precedent that a subscribe to one AOR can result in notification about associated AORs. But I suppose it could also be specified to limit its behavior in that regard somehow. And as Bernard hints, it would certainly be possible to define a (new) filter that explicitly constrains what is returned. Thanks, Paul Adam Roach wrote: > On 2/16/10 18:59, Feb 16, Bernard Aboba wrote: >> Adam said: >> >> "If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in >> fact, the format for reg event will be even more bulky than anything >> anyone has in mind for REGISTER, so it makes the problem worse, not better). >> >> So, while message size might be a valid topic of conversation, moving >> the ranges of extensions from REGISTER to NOTIFY is simply reducing the >> entire issue to a previously unsolved problem." >> >> [BA] Let me ask a (perhaps naïve) question about the expected behavior >> of reg-event with respect to MARTINI multiple AOR registrations. >> >> Within RFC 3680, the contents of the NOTIFY depends on which AOR is being >> subscribed to. >> If you buy into the multiple AOR/multiple contact model, wouldn't a >> SUBSCRIBE for the >> an AOR return only information relating to that specific AOR, not all the >> AORs that >> were registered? If so, doesn't that make the size issue for NOTIFY somewhat >> more >> tractable? > > The GIN draft goes into how this works. The short version is: yes, if > you subscribe to , you'll get registration > information from the PBX about that one AOR. If you subscribe to the > PBX's AOR -- the one it uses to identify itself to the SSP (e.g. > ), then you'll get registration information from the > SSP for all of the AORs. This is consistent with the behavior described > in 3680: > > Note that the document format explicitly allows for conveying > information on multiple addresses-of-record. This enables > subscriptions to groups of registrations, where such a group is > identified by some kind of URI. > > >> Note that RFC 3680 Section 4.3 refers to the inclusion of a body in the >> SUBSCRIBE, to enable filtering of subscriptions: >> >> A SUBSCRIBE for registration events MAY contain a body. This body >> would serve the purpose of filtering the subscription. The >> definition of such a body is outside the scope of this specification. >> > > Outside the scope and still undefined. We can't wave our hands at an > unspecified solution and say that it somehow solves the issue. And I > doubt MARTINI needs to get in the business of defining RFC 3680 filters. > > /a > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Tue Feb 16 20:11: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 329CF28C12E for ; Tue, 16 Feb 2010 20:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, 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 oK85UrOohyFs for ; Tue, 16 Feb 2010 20:11:06 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id C599028C10C for ; Tue, 16 Feb 2010 20:11:05 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MVvRA-1NAVVG0Lk0-00X0OU; Tue, 16 Feb 2010 23:11:59 -0500 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" , "Bernard Aboba" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> <4B7B5793.5080401@nostrum.com> Date: Tue, 16 Feb 2010 22:11:27 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0417_01CAAF54.FBE0AE40" 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/SXMVsPrhCIS7C+0GmcmAucyFOcqfWolOkuG4 pTPwA2sli1uLorBSlgT9+y8QyZci6MTzUaHqaqntmmqG8gG8f7 jjZpyfvFmyQeZ1q1VD1wNF9KcG2kS7sWBBy+bty80k= Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 04:11:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0417_01CAAF54.FBE0AE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Adam, OK, I agree with with you that we "can't handwave". I believe Dean that we need to think about request/response sizes, = especially response sizes, whether because we're running over UDP or = because SIP intermediaries may enforce limits on request/response sizes, = even using TCP. I understand your assertion that what GIN is doing is consistent with = RFC 3680, so I'm not suggesting that we change that (without a lot more = discussion). So I'm down to your assertion that we don't want to specify RFC 3680 = filters in MARTINI.=20 I'm not quite sure how we we limit request/response sizes without = filtering, but people have been doing pretty well at suggesting = alternatives I haven't thought of ... any clues on what I might be = missing here? Thanks, Spencer ----- Original Message -----=20 From: Adam Roach=20 To: Bernard Aboba=20 Cc: 'Christer Holmberg' ; 'Spencer Dawkins' ; 'MARTINI'=20 Sent: Tuesday, February 16, 2010 8:42 PM Subject: Re: [martini] DID Number Mobility and MARTINI On 2/16/10 18:59, Feb 16, Bernard Aboba wrote:=20 Note that RFC 3680 Section 4.3 refers to the inclusion of a body in = the SUBSCRIBE, to enable filtering of subscriptions: A SUBSCRIBE for registration events MAY contain a body. This = body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this = specification. =20 Outside the scope and still undefined. We can't wave our hands at an = unspecified solution and say that it somehow solves the issue. And I = doubt MARTINI needs to get in the business of defining RFC 3680 filters. /a ------=_NextPart_000_0417_01CAAF54.FBE0AE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Adam,
 
OK, I agree with with you that we "can't=20 handwave".
 
I believe Dean that we need to think about = request/response=20 sizes, especially response sizes, whether because we're running over UDP = or=20 because SIP intermediaries may enforce limits on request/response sizes, = even=20 using TCP.
 
I understand your assertion that what GIN is doing = is=20 consistent with RFC 3680, so I'm not suggesting that we change that = (without a=20 lot more discussion).
 
So I'm down to your assertion that we = don't want to=20 specify RFC 3680 filters in MARTINI.
 
I'm not quite sure how we we limit request/response = sizes=20 without filtering, but people have been doing pretty well at suggesting=20 alternatives I haven't thought of ... any clues on what I might be = missing=20 here?
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Adam = Roach
Cc: 'Christer Holmberg' = ; 'Spencer Dawkins' ; 'MARTINI'
Sent: Tuesday, February 16, = 2010 8:42=20 PM
Subject: Re: [martini] DID = Number=20 Mobility and MARTINI

On 2/16/10 18:59, Feb 16, Bernard Aboba wrote:=20
Note that RFC 3680 Section 4.3 refers to the inclusion = of a body=20 in the
SUBSCRIBE, to enable filtering of=20 subscriptions:

   A SUBSCRIBE for registration = events MAY=20 contain a body.  This body
   would serve the = purpose of=20 filtering the subscription.  The
   definition of = such a=20 body is outside the scope of this specification.
 =20

Outside the scope and still undefined. We can't wave = our=20 hands at an unspecified solution and say that it somehow solves the = issue. And=20 I doubt MARTINI needs to get in the business of defining RFC 3680=20 filters.

/a
------=_NextPart_000_0417_01CAAF54.FBE0AE40-- From john.elwell@siemens-enterprise.com Tue Feb 16 23:34: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 763F03A7937 for ; Tue, 16 Feb 2010 23:34:14 -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 SqgClzmlqAku for ; Tue, 16 Feb 2010 23:34:13 -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 B19BB3A7C1E for ; Tue, 16 Feb 2010 23:34:12 -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-911354; Wed, 17 Feb 2010 08:35:49 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 197E123F0278; Wed, 17 Feb 2010 08:35:49 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 17 Feb 2010 08:35:49 +0100 From: "Elwell, John" To: Spencer Dawkins , Brian Lindsay , Adam Roach , Paul Kyzivat Date: Wed, 17 Feb 2010 08:35:47 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfagg Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.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: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 07:34:14 -0000 So in trying to tease out whether there needs to be, as part of the MARTINI= mechanism (as opposed to provisioning) an explicit list of numbers and/or = contacts (I won't try to tie down which at present), I think it is importan= t to understand which direction this is needed in, because that will go som= e way towards determining the mechanism. Do people think: a) there is good reason for providing this information in the direction SIP= -PBX to SSP (in which case inclusion in a REGISTER request might be one sol= ution); or b) there is a good reason for providing this information in the direction S= SP to SIP-PBX (in which case reg-events might be one solution); or c) it doesn't matter which direction - either direction would be good enoug= h so that at least one side is able to detect a discrepancy; or d) there is a good reason for doing both; or e) there is no good reason to do either. My personal opinion is e), but I would like to hear other opinions, with re= asons. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 16 February 2010 22:23 > To: Brian Lindsay; Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Hi, Brian, >=20 > Speaking carefully as chair, and Bernard can correct me if I=20 > am saying=20 > things I should not be saying as chair, at this point... >=20 > I happen to agree with your reasoning, re: REGISTER. What I'm=20 > trying to=20 > tease out is whether we can just say "we're not providing=20 > that information=20 > in the REGISTER exchange, BUT you can get that information=20 > using regevents",=20 > so that we can move on - I haven't heard anyone propose that=20 > MARTINI would=20 > say "MUST NOT use regevents" :-) >=20 > I would be comfortable if our specifications were silent on=20 > this point, and=20 > might be more comfortable if we pointer out somewhere that=20 > the REGISTER=20 > exchange does not provide this information, but people who want the=20 > information can use regevents or whatever other method seems=20 > appropriate to=20 > get the information that they want. >=20 > But (Bernard and) I don't get to decide what working group=20 > consensus is - we=20 > only get to recognize what consensus is, and when it exists.=20 > For that, we=20 > need to hear from other participants (including you, of=20 > course - and "thank=20 > you" to participants who care, and have expressed opinions=20 > about this, in=20 > the current thread. >=20 > I hope this is helpful. >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message -----=20 > From: "Brian Lindsay" > To: "Spencer Dawkins" ; "Adam Roach"=20 > ; "Paul Kyzivat" > Cc: "Bernard Aboba" ; "MARTINI"=20 > > Sent: Tuesday, February 16, 2010 3:51 PM > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 >=20 > Hi Spencer, >=20 > So basically since the provisioning/sync of the E.164=20 > numbers/ranges > is out of scope I don't see a strong argument for including=20 > them in the > registration transaction. The Service Provider has a set of E.164 > numbers that, based on prior assignment/arrangement, it is responsible > to route to the SIP PBX. The SIP PBX is aware of these=20 > numbers already. > The registration process (using an AoR identifying the SIP PBX) is > intended to provide reachability information for the SIP PBX, in the > absence of static IP address configuration / DNS (hence the ranges are > not actually required in this transaction). >=20 > Thanks > Brian >=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Tuesday, February 16, 2010 4:37 PM > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Hi, Brian, >=20 > Just trying to stay synchronized here. >=20 > Speaking as an individual, I think you're right about=20 > provisioning being > out of scope, based on what I've been hearing on this list and in > telechats, etc. >=20 > What I thought Adam was talking about isn't quite=20 > provisioning (ignoring > the question direction - I've heard some people suggest each=20 > direction). > It was more like "I expect these numbers to be registered" and/or "I > registered these numbers on your behalf", with the question=20 > of how each > end knows what numbers "should" be registered being out of scope - > because "knowing" was provisioned. >=20 > At least, that's the context in which I was reading Adam's note below. >=20 > Thanks, >=20 > Spencer >=20 >=20 > > Hi, > > > > I think it's been stated many times in the threads that=20 > E.164 number >=20 > > provisioning between the enterprise and service provider is out of > > scope of MARTINI. So we're not using the register transaction to > > perform any syncronization on these numbers betweeen the enterprise > > and service provider. The registration is just being used to provide > > reachability info, to allow requests to a set of E.164 numbers to be > > routed to the SIP PBX. As such, I don't think the number ranges need > > to be part of the registration transaction. It'll just add extra > > complexity to the implementations. > > > > Regards > > Brian > > > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > > Behalf Of Adam Roach > > Sent: Tuesday, February 16, 2010 1:39 PM > > To: Paul Kyzivat > > Cc: Bernard Aboba; 'MARTINI' > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > So, here's what I don't understand: 3GPP at least defined a=20 > procedure > > -- through a questionable use of P-Associated-URI -- to=20 > indicate which >=20 > > URIs the registrar would be registering on behalf of the=20 > user. So even >=20 > > the original 3GPP implicit approach had an enumeration of the AORs > > associated with the registration process. > > > > We're proposing to be even more sparse than that. Rather than just > > "implicit with a list of AORs," we're proposing "implicit with *no* > > list of AORs." > > > > So, even if your assertion that our allowing the implicit=20 > mechanism to >=20 > > stand is somehow tacit approval, what's being proposed here is even > > one step more nebulous. > > > > /a > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > >> Dean, > >> > >> In principle I agree with you. > >> But this horse is already out of the barn with IMS implicit > > registration. > >> > >> It was never explicitly brought to the ietf, though things=20 > linked to > >> it like P-Asserted-ID and P-Associated-URI were. While we could say > >> that is not our problem, I think we already implicitly approved it > >> via > > > >> benign neglect. > >> > >> Thanks, > >> Paul > >> > >> Dean Willis wrote: > >>> > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > >>> > >>>> Speaking as co-chair, the non-registration aspects of DID number > >>>> mobility are outside the scope of the current MARTINI WG charter. > >>>> > >>>> The question on the table (see > >>>>=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > >>>> ) > > > >>>> is whether the registration aspects represent a=20 > requirement or not. > >>>> Feel free > >>>> to respond and provide your opinion on that thread. > >>> > >>> Explicit is its own reward. > >>> > >>> Remember, the one thing that RFC 3261 REGISTER really does is bind > >>> an > > > >>> AOR to a Contact. Both the AOR and the Contact involved are > >>> explicitly encoded in the request. > >>> > >>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple > >>> Contacts. This seems like a reasonable extension to simplify life > >>> for > > > >>> a "multi user" SIP user agent. But I really think we=20 > should respect > >>> the history of REGISTERs explicit encoding of the AORs=20 > and Contacts > >>> involved. > >>> > >>> From a requirements perspective, I'd be happy with a requirement > >>> along the lines of "must not preclude AOR mobility=20 > indicated by the >=20 > >>> registration." I agree that we can't justify a requirement to > >>> produce > > > >>> a mechanism at the time for the whole enchilada. > >>> > >>> -- > >>> 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 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From christer.holmberg@ericsson.com Wed Feb 17 01:47: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 6BF763A7C8B for ; Wed, 17 Feb 2010 01:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 fT3vZ17wFwqd for ; Wed, 17 Feb 2010 01:47:23 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3BA0828C1D4 for ; Wed, 17 Feb 2010 01:47:23 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-e1-4b7bbb8b7759 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 2C.55.02429.B8BBB7B4; Wed, 17 Feb 2010 10:48:59 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 17 Feb 2010 10:48:59 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Wed, 17 Feb 2010 10:48:59 +0100 Thread-Topic: [martini] Explicit DID indication in REGISTER Thread-Index: AcqvVHM1zP8/G9ngRXW+/y3WlG80MQAYXFJw Message-ID: References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com> <08FAA3A98AEF48828EA9B851F1FC22B7@china.huawei.com> <8AD40E1BA95447159ABB7115687403AE@china.huawei.com>, <4B7B1726.3090101@cisco.com> In-Reply-To: <4B7B1726.3090101@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" Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 17 Feb 2010 09:47:24 -0000 Hi Paul, I was simply replying to Dean, showing a mechanism where the PBX would not = need to be a B2BUA. My intention was not to re-open old discussions, so I appologize for that. Regards, Christer =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 17. helmikuuta 2010 0:08 To: Christer Holmberg Cc: Dean Willis; Spencer Dawkins; martini@ietf.org Subject: Re: [martini] Explicit DID indication in REGISTER Christer, Christer Holmberg wrote: > Hi, >=20 >> Not quite. Christer seems to think that a PBX has only one Contact,=20 >> independent of however many AORs it might have. This requires the=20 >> PBX to be a UA or SBC/B2BUA, >=20 > If you put the contact (which points to the PBX) in a Route header, and t= he called PBX number in the R-URI, I believe the PBX can act as a proxy. I'm getting deja vu (and not for the first time). You are looping back through the cases that have been discussed ad nauseum. That approach works well with "stirred", but problems were found with stirr= ed, so we dropped it. There have been issues raised using it with "shaken" = as well. AFAIK we were *closest* to a consensus when we were talking about the regis= tration actually (at least virtually) creates a registered contact for each= AOR. Thanks, Paul > For the rest of your e-mail, we would probably need to draw some=20 > pictures, to make sure we have a common understanding of "proxies",=20 > "real contacts" etc :) >=20 > Regards, >=20 > Christer >=20 >=20 >> and precludes upstream registration-based routing (And forking) to the A= ORs of the PBX. >> >> I, in general, presume that there is at least one Contact per AOR=20 >> currently "live". This allows the PBX to be a proxy if it wants to,=20 >> and allows for upstream routing logic to use the set of Contacts. >> >> For example, consider an AO that is bound to two PBX instances and=20 >> also to my PC. If all three instances REGISTER to my "service=20 >> provider" proxy, then said proxy can do things like fork incoming=20 >> INVITES to all three instances, without requiring any special tricky=20 >> logic to know reachability-state for the PBXes. It treats the PBX=20 >> Contacts no differently than the PC's Contact -- they're all just=20 >> ordinary contacts once they're in the location service. >> >> AS I understand it, Christer's model requires the proxy using the=20 >> location service to know that PBXes are somehow special, then go do a=20 >> Reg-Event on them, in order to find out what their current "real=20 >> Contact" set is and perform routing logic. This seems highly baroque,=20 >> probably even "broken". >=20 >=20 >=20 > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From christer.holmberg@ericsson.com Wed Feb 17 01:53: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 25C773A7C75 for ; Wed, 17 Feb 2010 01:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=-0.282, 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 GnHxiBPr2D7Z for ; Wed, 17 Feb 2010 01:53:55 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 29A303A7AD5 for ; Wed, 17 Feb 2010 01:53:54 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-c0-4b7bbd13e8e9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 77.04.31641.31DBB7B4; Wed, 17 Feb 2010 10:55:31 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 17 Feb 2010 10:55:31 +0100 From: Christer Holmberg To: 'Adam Roach' Date: Wed, 17 Feb 2010 10:55:30 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvXDl7AzZ79KJmT6uLpg3F2fLopgAWkpuw Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> In-Reply-To: <4B7B2431.2070103@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: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 09:53:56 -0000 Hi,=20 >>On 2/16/10 14:57, Feb 16, Christer Holmberg wrote: >>I was assuming (maybe this is a bad assumption) that we didn't have to=20 >>send back the entire list in one NOTIFY... >The first time it's sent, yeah, you do. After that, there are things you c= an do to make it smaller, but there's no getting around the fact that the f= irst NOTIFY ever sent will need to contain all the=20 >DID, and still fit in a single SIP message. > >If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in fact,= the format for reg event will be even more bulky than anything anyone has = in mind for REGISTER, so it makes the problem worse,=20 >not better). > >So, while message size might be a valid topic of conversation, moving the = ranges of extensions from REGISTER to NOTIFY is simply reducing the entire = issue to a previously unsolved problem. The text you commented was not written by me. But, in any case, when we talk about the message size, we need to be clear = about if we talk about requests and responses. As we know, creatomg a respo= nse which is larger than the associated request can cause fragmentation pro= blems if UDP was used. Sending a large request should not have that problem - you just use TCP to = start with. But, there may of course be other reasons why we want to avoid large messag= es. Regards, Christer From bruno.chatras@orange-ftgroup.com Wed Feb 17 04: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 DC0C23A7CE1 for ; Wed, 17 Feb 2010 04:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.033, 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 Dq8qFr5qrR-z for ; Wed, 17 Feb 2010 04:43: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 1B91F3A7B4D for ; Wed, 17 Feb 2010 04:43:17 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D89D31341AE; Wed, 17 Feb 2010 13:44:54 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B92F827C07D; Wed, 17 Feb 2010 13:44:54 +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, 17 Feb 2010 13:44:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Feb 2010 13:44:53 +0100 Message-ID: <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5A= References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> From: To: , , , , X-OriginalArrivalTime: 17 Feb 2010 12:44:54.0512 (UTC) FILETIME=[011B0700:01CAAFCF] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.17.120046 Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 12:43:19 -0000 My view is that there is no strong need need for carrying this information = accross the SIP-PBX - SSP interface. However this information needs to be p= rovided by the SSP's Registrar to the SSP's edge proxy so as to enable the = edge proxy to assert identities received from the PBX in a P-Preferred-Iden= tity header field. > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > Envoy=E9 : mercredi 17 f=E9vrier 2010 08:36 > =C0 : Spencer Dawkins; Brian Lindsay; Adam Roach; Paul Kyzivat > Cc : Bernard Aboba; MARTINI > Objet : Re: [martini] DID Number Mobility and MARTINI >=20 > So in trying to tease out whether there needs to be, as part=20 > of the MARTINI mechanism (as opposed to provisioning) an=20 > explicit list of numbers and/or contacts (I won't try to tie=20 > down which at present), I think it is important to understand=20 > which direction this is needed in, because that will go some=20 > way towards determining the mechanism. Do people think: >=20 > a) there is good reason for providing this information in the=20 > direction SIP-PBX to SSP (in which case inclusion in a=20 > REGISTER request might be one solution); or >=20 > b) there is a good reason for providing this information in=20 > the direction SSP to SIP-PBX (in which case reg-events might=20 > be one solution); or >=20 > c) it doesn't matter which direction - either direction would=20 > be good enough so that at least one side is able to detect a=20 > discrepancy; or >=20 > d) there is a good reason for doing both; or >=20 > e) there is no good reason to do either. >=20 > My personal opinion is e), but I would like to hear other=20 > opinions, with reasons. >=20 > John >=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > Sent: 16 February 2010 22:23 > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > Cc: Bernard Aboba; MARTINI > > Subject: Re: [martini] DID Number Mobility and MARTINI > >=20 > > Hi, Brian, > >=20 > > Speaking carefully as chair, and Bernard can correct me if=20 > I am saying=20 > > things I should not be saying as chair, at this point... > >=20 > > I happen to agree with your reasoning, re: REGISTER. What=20 > I'm trying=20 > > to tease out is whether we can just say "we're not providing that=20 > > information in the REGISTER exchange, BUT you can get that=20 > information=20 > > using regevents", so that we can move on - I haven't heard anyone=20 > > propose that MARTINI would say "MUST NOT use regevents" :-) > >=20 > > I would be comfortable if our specifications were silent on this=20 > > point, and might be more comfortable if we pointer out=20 > somewhere that=20 > > the REGISTER exchange does not provide this information, but people=20 > > who want the information can use regevents or whatever other method=20 > > seems appropriate to get the information that they want. > >=20 > > But (Bernard and) I don't get to decide what working group=20 > consensus=20 > > is - we only get to recognize what consensus is, and when it exists. > > For that, we > > need to hear from other participants (including you, of=20 > course - and=20 > > "thank you" to participants who care, and have expressed opinions=20 > > about this, in the current thread. > >=20 > > I hope this is helpful. > >=20 > > Thanks, > >=20 > > Spencer > >=20 > > ----- Original Message ----- > > From: "Brian Lindsay" > > To: "Spencer Dawkins" ; "Adam Roach"=20 > > ; "Paul Kyzivat" > > Cc: "Bernard Aboba" ; "MARTINI"=20 > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > Subject: RE: [martini] DID Number Mobility and MARTINI > >=20 > >=20 > > Hi Spencer, > >=20 > > So basically since the provisioning/sync of the E.164=20 > > numbers/ranges is out of scope I don't see a strong argument for=20 > > including them in the registration transaction. The Service=20 > Provider=20 > > has a set of E.164 numbers that, based on prior=20 > > assignment/arrangement, it is responsible to route to the=20 > SIP PBX. The=20 > > SIP PBX is aware of these numbers already. > > The registration process (using an AoR identifying the SIP PBX) is=20 > > intended to provide reachability information for the SIP=20 > PBX, in the=20 > > absence of static IP address configuration / DNS (hence the=20 > ranges are=20 > > not actually required in this transaction). > >=20 > > Thanks > > Brian > >=20 > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > Sent: Tuesday, February 16, 2010 4:37 PM > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > Cc: Bernard Aboba; MARTINI > > Subject: Re: [martini] DID Number Mobility and MARTINI > >=20 > > Hi, Brian, > >=20 > > Just trying to stay synchronized here. > >=20 > > Speaking as an individual, I think you're right about provisioning=20 > > being out of scope, based on what I've been hearing on this=20 > list and=20 > > in telechats, etc. > >=20 > > What I thought Adam was talking about isn't quite provisioning=20 > > (ignoring the question direction - I've heard some people=20 > suggest each=20 > > direction). > > It was more like "I expect these numbers to be registered"=20 > and/or "I=20 > > registered these numbers on your behalf", with the question of how=20 > > each end knows what numbers "should" be registered being=20 > out of scope=20 > > - because "knowing" was provisioned. > >=20 > > At least, that's the context in which I was reading Adam's=20 > note below. > >=20 > > Thanks, > >=20 > > Spencer > >=20 > >=20 > > > Hi, > > > > > > I think it's been stated many times in the threads that > > E.164 number > >=20 > > > provisioning between the enterprise and service provider=20 > is out of=20 > > > scope of MARTINI. So we're not using the register transaction to=20 > > > perform any syncronization on these numbers betweeen the=20 > enterprise=20 > > > and service provider. The registration is just being used=20 > to provide=20 > > > reachability info, to allow requests to a set of E.164=20 > numbers to be=20 > > > routed to the SIP PBX. As such, I don't think the number=20 > ranges need=20 > > > to be part of the registration transaction. It'll just add extra=20 > > > complexity to the implementations. > > > > > > Regards > > > Brian > > > > > > -----Original Message----- > > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On=20 > > > Behalf Of Adam Roach > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > To: Paul Kyzivat > > > Cc: Bernard Aboba; 'MARTINI' > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > So, here's what I don't understand: 3GPP at least defined a > > procedure > > > -- through a questionable use of P-Associated-URI -- to > > indicate which > >=20 > > > URIs the registrar would be registering on behalf of the > > user. So even > >=20 > > > the original 3GPP implicit approach had an enumeration of=20 > the AORs=20 > > > associated with the registration process. > > > > > > We're proposing to be even more sparse than that. Rather=20 > than just=20 > > > "implicit with a list of AORs," we're proposing "implicit=20 > with *no*=20 > > > list of AORs." > > > > > > So, even if your assertion that our allowing the implicit > > mechanism to > >=20 > > > stand is somehow tacit approval, what's being proposed=20 > here is even=20 > > > one step more nebulous. > > > > > > /a > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > >> Dean, > > >> > > >> In principle I agree with you. > > >> But this horse is already out of the barn with IMS implicit > > > registration. > > >> > > >> It was never explicitly brought to the ietf, though things > > linked to > > >> it like P-Asserted-ID and P-Associated-URI were. While=20 > we could say=20 > > >> that is not our problem, I think we already implicitly=20 > approved it=20 > > >> via > > > > > >> benign neglect. > > >> > > >> Thanks, > > >> Paul > > >> > > >> Dean Willis wrote: > > >>> > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > >>> > > >>>> Speaking as co-chair, the non-registration aspects of=20 > DID number=20 > > >>>> mobility are outside the scope of the current MARTINI=20 > WG charter. > > >>>> > > >>>> The question on the table (see > > >>>>=20 > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > >>>> ) > > > > > >>>> is whether the registration aspects represent a > > requirement or not. > > >>>> Feel free > > >>>> to respond and provide your opinion on that thread. > > >>> > > >>> Explicit is its own reward. > > >>> > > >>> Remember, the one thing that RFC 3261 REGISTER really=20 > does is bind=20 > > >>> an > > > > > >>> AOR to a Contact. Both the AOR and the Contact involved are=20 > > >>> explicitly encoded in the request. > > >>> > > >>> I'm OKAY with extending REGISTER to bind multiple AORs=20 > to multiple=20 > > >>> Contacts. This seems like a reasonable extension to=20 > simplify life=20 > > >>> for > > > > > >>> a "multi user" SIP user agent. But I really think we > > should respect > > >>> the history of REGISTERs explicit encoding of the AORs > > and Contacts > > >>> involved. > > >>> > > >>> From a requirements perspective, I'd be happy with a=20 > requirement=20 > > >>> along the lines of "must not preclude AOR mobility > > indicated by the > >=20 > > >>> registration." I agree that we can't justify a requirement to=20 > > >>> produce > > > > > >>> a mechanism at the time for the whole enchilada. > > >>> > > >>> -- > > >>> 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 > >=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 Wed Feb 17 05:35: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 9584D3A7CE1 for ; Wed, 17 Feb 2010 05:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnIcXakmYE9u for ; Wed, 17 Feb 2010 05:35:38 -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 815773A7CCC for ; Wed, 17 Feb 2010 05:35:37 -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-917294; Wed, 17 Feb 2010 14:37:14 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id AA1751EB82AB; Wed, 17 Feb 2010 14:37:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 17 Feb 2010 14:37:14 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "blindsay@nortel.com" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Wed, 17 Feb 2010 14:37:12 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0A== Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@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: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 13:35:39 -0000 Bruno, Thanks. However, this particular reason for a proxy needing this informatio= n is because of an architecture where the proxy is assigned responsibility = for asserting an identity for the source of a request. If the domain proxy = takes on this responsibility instead, problem solved. So it is a question o= f whether this particular architecture is common enough that we need a solu= tion that conveys registered identities to the edge proxy. IMS solves this = using PAU (ignoring issues of response size), so the question for others is= whether there are other architectures in practice where this is important.= I guess for this particular usage it doesn't matter whether the informatio= n is in the REGISTER request or the REGISTER response. John =20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: 17 February 2010 12:45 > To: Elwell, John; spencer@wonderhamster.org;=20 > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > My view is that there is no strong need need for carrying=20 > this information accross the SIP-PBX - SSP interface. However=20 > this information needs to be provided by the SSP's Registrar=20 > to the SSP's edge proxy so as to enable the edge proxy to=20 > assert identities received from the PBX in a=20 > P-Preferred-Identity header field. >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > > Envoy=E9 : mercredi 17 f=E9vrier 2010 08:36 > > =C0 : Spencer Dawkins; Brian Lindsay; Adam Roach; Paul Kyzivat > > Cc : Bernard Aboba; MARTINI > > Objet : Re: [martini] DID Number Mobility and MARTINI > >=20 > > So in trying to tease out whether there needs to be, as part=20 > > of the MARTINI mechanism (as opposed to provisioning) an=20 > > explicit list of numbers and/or contacts (I won't try to tie=20 > > down which at present), I think it is important to understand=20 > > which direction this is needed in, because that will go some=20 > > way towards determining the mechanism. Do people think: > >=20 > > a) there is good reason for providing this information in the=20 > > direction SIP-PBX to SSP (in which case inclusion in a=20 > > REGISTER request might be one solution); or > >=20 > > b) there is a good reason for providing this information in=20 > > the direction SSP to SIP-PBX (in which case reg-events might=20 > > be one solution); or > >=20 > > c) it doesn't matter which direction - either direction would=20 > > be good enough so that at least one side is able to detect a=20 > > discrepancy; or > >=20 > > d) there is a good reason for doing both; or > >=20 > > e) there is no good reason to do either. > >=20 > > My personal opinion is e), but I would like to hear other=20 > > opinions, with reasons. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > Sent: 16 February 2010 22:23 > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > Cc: Bernard Aboba; MARTINI > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > >=20 > > > Hi, Brian, > > >=20 > > > Speaking carefully as chair, and Bernard can correct me if=20 > > I am saying=20 > > > things I should not be saying as chair, at this point... > > >=20 > > > I happen to agree with your reasoning, re: REGISTER. What=20 > > I'm trying=20 > > > to tease out is whether we can just say "we're not providing that=20 > > > information in the REGISTER exchange, BUT you can get that=20 > > information=20 > > > using regevents", so that we can move on - I haven't heard anyone=20 > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > >=20 > > > I would be comfortable if our specifications were silent on this=20 > > > point, and might be more comfortable if we pointer out=20 > > somewhere that=20 > > > the REGISTER exchange does not provide this information,=20 > but people=20 > > > who want the information can use regevents or whatever=20 > other method=20 > > > seems appropriate to get the information that they want. > > >=20 > > > But (Bernard and) I don't get to decide what working group=20 > > consensus=20 > > > is - we only get to recognize what consensus is, and when=20 > it exists. > > > For that, we > > > need to hear from other participants (including you, of=20 > > course - and=20 > > > "thank you" to participants who care, and have expressed opinions=20 > > > about this, in the current thread. > > >=20 > > > I hope this is helpful. > > >=20 > > > Thanks, > > >=20 > > > Spencer > > >=20 > > > ----- Original Message ----- > > > From: "Brian Lindsay" > > > To: "Spencer Dawkins" ; "Adam Roach"=20 > > > ; "Paul Kyzivat" > > > Cc: "Bernard Aboba" ; "MARTINI"=20 > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > >=20 > > >=20 > > > Hi Spencer, > > >=20 > > > So basically since the provisioning/sync of the E.164=20 > > > numbers/ranges is out of scope I don't see a strong argument for=20 > > > including them in the registration transaction. The Service=20 > > Provider=20 > > > has a set of E.164 numbers that, based on prior=20 > > > assignment/arrangement, it is responsible to route to the=20 > > SIP PBX. The=20 > > > SIP PBX is aware of these numbers already. > > > The registration process (using an AoR identifying the=20 > SIP PBX) is=20 > > > intended to provide reachability information for the SIP=20 > > PBX, in the=20 > > > absence of static IP address configuration / DNS (hence the=20 > > ranges are=20 > > > not actually required in this transaction). > > >=20 > > > Thanks > > > Brian > > >=20 > > > -----Original Message----- > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > Cc: Bernard Aboba; MARTINI > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > >=20 > > > Hi, Brian, > > >=20 > > > Just trying to stay synchronized here. > > >=20 > > > Speaking as an individual, I think you're right about=20 > provisioning=20 > > > being out of scope, based on what I've been hearing on this=20 > > list and=20 > > > in telechats, etc. > > >=20 > > > What I thought Adam was talking about isn't quite provisioning=20 > > > (ignoring the question direction - I've heard some people=20 > > suggest each=20 > > > direction). > > > It was more like "I expect these numbers to be registered"=20 > > and/or "I=20 > > > registered these numbers on your behalf", with the=20 > question of how=20 > > > each end knows what numbers "should" be registered being=20 > > out of scope=20 > > > - because "knowing" was provisioned. > > >=20 > > > At least, that's the context in which I was reading Adam's=20 > > note below. > > >=20 > > > Thanks, > > >=20 > > > Spencer > > >=20 > > >=20 > > > > Hi, > > > > > > > > I think it's been stated many times in the threads that > > > E.164 number > > >=20 > > > > provisioning between the enterprise and service provider=20 > > is out of=20 > > > > scope of MARTINI. So we're not using the register=20 > transaction to=20 > > > > perform any syncronization on these numbers betweeen the=20 > > enterprise=20 > > > > and service provider. The registration is just being used=20 > > to provide=20 > > > > reachability info, to allow requests to a set of E.164=20 > > numbers to be=20 > > > > routed to the SIP PBX. As such, I don't think the number=20 > > ranges need=20 > > > > to be part of the registration transaction. It'll just=20 > add extra=20 > > > > complexity to the implementations. > > > > > > > > Regards > > > > Brian > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] On=20 > > > > Behalf Of Adam Roach > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > To: Paul Kyzivat > > > > Cc: Bernard Aboba; 'MARTINI' > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > procedure > > > > -- through a questionable use of P-Associated-URI -- to > > > indicate which > > >=20 > > > > URIs the registrar would be registering on behalf of the > > > user. So even > > >=20 > > > > the original 3GPP implicit approach had an enumeration of=20 > > the AORs=20 > > > > associated with the registration process. > > > > > > > > We're proposing to be even more sparse than that. Rather=20 > > than just=20 > > > > "implicit with a list of AORs," we're proposing "implicit=20 > > with *no*=20 > > > > list of AORs." > > > > > > > > So, even if your assertion that our allowing the implicit > > > mechanism to > > >=20 > > > > stand is somehow tacit approval, what's being proposed=20 > > here is even=20 > > > > one step more nebulous. > > > > > > > > /a > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > >> Dean, > > > >> > > > >> In principle I agree with you. > > > >> But this horse is already out of the barn with IMS implicit > > > > registration. > > > >> > > > >> It was never explicitly brought to the ietf, though things > > > linked to > > > >> it like P-Asserted-ID and P-Associated-URI were. While=20 > > we could say=20 > > > >> that is not our problem, I think we already implicitly=20 > > approved it=20 > > > >> via > > > > > > > >> benign neglect. > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >> Dean Willis wrote: > > > >>> > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > >>> > > > >>>> Speaking as co-chair, the non-registration aspects of=20 > > DID number=20 > > > >>>> mobility are outside the scope of the current MARTINI=20 > > WG charter. > > > >>>> > > > >>>> The question on the table (see > > > >>>>=20 > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > >>>> ) > > > > > > > >>>> is whether the registration aspects represent a > > > requirement or not. > > > >>>> Feel free > > > >>>> to respond and provide your opinion on that thread. > > > >>> > > > >>> Explicit is its own reward. > > > >>> > > > >>> Remember, the one thing that RFC 3261 REGISTER really=20 > > does is bind=20 > > > >>> an > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact involved are=20 > > > >>> explicitly encoded in the request. > > > >>> > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs=20 > > to multiple=20 > > > >>> Contacts. This seems like a reasonable extension to=20 > > simplify life=20 > > > >>> for > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > should respect > > > >>> the history of REGISTERs explicit encoding of the AORs > > > and Contacts > > > >>> involved. > > > >>> > > > >>> From a requirements perspective, I'd be happy with a=20 > > requirement=20 > > > >>> along the lines of "must not preclude AOR mobility > > > indicated by the > > >=20 > > > >>> registration." I agree that we can't justify a requirement to=20 > > > >>> produce > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > >>> > > > >>> -- > > > >>> 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 > > >=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 > = From christer.holmberg@ericsson.com Wed Feb 17 05:46: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 BA05228C0E3 for ; Wed, 17 Feb 2010 05:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.875 X-Spam-Level: X-Spam-Status: No, score=-2.875 tagged_above=-999 required=5 tests=[AWL=-0.276, 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 xyzGLTMKnxmX for ; Wed, 17 Feb 2010 05:46:04 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9AA283A7AEE for ; Wed, 17 Feb 2010 05:46:03 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-47-4b7bf37c3697 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5B.B3.02429.C73FB7B4; Wed, 17 Feb 2010 14:47:40 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 17 Feb 2010 14:47:37 +0100 From: Christer Holmberg To: "'Elwell, John'" , "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "blindsay@nortel.com" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Wed, 17 Feb 2010 14:47:36 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AAAXh1w Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 13:46:05 -0000 Hi, I don't really see what the problem is. Can't we simply say that P-AU is op= tional, and people can use it if required? Regards, Christer=20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Elwell, John Sent: 17. helmikuuta 2010 15:37 To: bruno.chatras@orange-ftgroup.com; spencer@wonderhamster.org; blindsay@n= ortel.com; adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] DID Number Mobility and MARTINI Bruno, Thanks. However, this particular reason for a proxy needing this informatio= n is because of an architecture where the proxy is assigned responsibility = for asserting an identity for the source of a request. If the domain proxy = takes on this responsibility instead, problem solved. So it is a question o= f whether this particular architecture is common enough that we need a solu= tion that conveys registered identities to the edge proxy. IMS solves this = using PAU (ignoring issues of response size), so the question for others is= whether there are other architectures in practice where this is important.= I guess for this particular usage it doesn't matter whether the informatio= n is in the REGISTER request or the REGISTER response. John =20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: 17 February 2010 12:45 > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com;=20 > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > My view is that there is no strong need need for carrying this=20 > information accross the SIP-PBX - SSP interface. However this=20 > information needs to be provided by the SSP's Registrar to the SSP's=20 > edge proxy so as to enable the edge proxy to assert identities=20 > received from the PBX in a P-Preferred-Identity header field. >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Elwell, John Envoy=E9=20 > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; Brian Lindsay= ;=20 > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re:=20 > > [martini] DID Number Mobility and MARTINI > >=20 > > So in trying to tease out whether there needs to be, as part of the=20 > > MARTINI mechanism (as opposed to provisioning) an explicit list of=20 > > numbers and/or contacts (I won't try to tie down which at present),=20 > > I think it is important to understand which direction this is needed=20 > > in, because that will go some way towards determining the mechanism.=20 > > Do people think: > >=20 > > a) there is good reason for providing this information in the=20 > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER=20 > > request might be one solution); or > >=20 > > b) there is a good reason for providing this information in the=20 > > direction SSP to SIP-PBX (in which case reg-events might be one=20 > > solution); or > >=20 > > c) it doesn't matter which direction - either direction would be=20 > > good enough so that at least one side is able to detect a=20 > > discrepancy; or > >=20 > > d) there is a good reason for doing both; or > >=20 > > e) there is no good reason to do either. > >=20 > > My personal opinion is e), but I would like to hear other opinions,=20 > > with reasons. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > Sent: 16 February 2010 22:23 > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > Cc: Bernard Aboba; MARTINI > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > >=20 > > > Hi, Brian, > > >=20 > > > Speaking carefully as chair, and Bernard can correct me if > > I am saying > > > things I should not be saying as chair, at this point... > > >=20 > > > I happen to agree with your reasoning, re: REGISTER. What > > I'm trying > > > to tease out is whether we can just say "we're not providing that=20 > > > information in the REGISTER exchange, BUT you can get that > > information > > > using regevents", so that we can move on - I haven't heard anyone=20 > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > >=20 > > > I would be comfortable if our specifications were silent on this=20 > > > point, and might be more comfortable if we pointer out > > somewhere that > > > the REGISTER exchange does not provide this information, > but people > > > who want the information can use regevents or whatever > other method > > > seems appropriate to get the information that they want. > > >=20 > > > But (Bernard and) I don't get to decide what working group > > consensus > > > is - we only get to recognize what consensus is, and when > it exists. > > > For that, we > > > need to hear from other participants (including you, of > > course - and > > > "thank you" to participants who care, and have expressed opinions=20 > > > about this, in the current thread. > > >=20 > > > I hope this is helpful. > > >=20 > > > Thanks, > > >=20 > > > Spencer > > >=20 > > > ----- Original Message ----- > > > From: "Brian Lindsay" > > > To: "Spencer Dawkins" ; "Adam Roach"=20 > > > ; "Paul Kyzivat" > > > Cc: "Bernard Aboba" ; "MARTINI"=20 > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > >=20 > > >=20 > > > Hi Spencer, > > >=20 > > > So basically since the provisioning/sync of the E.164=20 > > > numbers/ranges is out of scope I don't see a strong argument for=20 > > > including them in the registration transaction. The Service > > Provider > > > has a set of E.164 numbers that, based on prior=20 > > > assignment/arrangement, it is responsible to route to the > > SIP PBX. The > > > SIP PBX is aware of these numbers already. > > > The registration process (using an AoR identifying the > SIP PBX) is > > > intended to provide reachability information for the SIP > > PBX, in the > > > absence of static IP address configuration / DNS (hence the > > ranges are > > > not actually required in this transaction). > > >=20 > > > Thanks > > > Brian > > >=20 > > > -----Original Message----- > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > Cc: Bernard Aboba; MARTINI > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > >=20 > > > Hi, Brian, > > >=20 > > > Just trying to stay synchronized here. > > >=20 > > > Speaking as an individual, I think you're right about > provisioning > > > being out of scope, based on what I've been hearing on this > > list and > > > in telechats, etc. > > >=20 > > > What I thought Adam was talking about isn't quite provisioning=20 > > > (ignoring the question direction - I've heard some people > > suggest each > > > direction). > > > It was more like "I expect these numbers to be registered"=20 > > and/or "I > > > registered these numbers on your behalf", with the > question of how > > > each end knows what numbers "should" be registered being > > out of scope > > > - because "knowing" was provisioned. > > >=20 > > > At least, that's the context in which I was reading Adam's > > note below. > > >=20 > > > Thanks, > > >=20 > > > Spencer > > >=20 > > >=20 > > > > Hi, > > > > > > > > I think it's been stated many times in the threads that > > > E.164 number > > >=20 > > > > provisioning between the enterprise and service provider > > is out of > > > > scope of MARTINI. So we're not using the register > transaction to > > > > perform any syncronization on these numbers betweeen the > > enterprise > > > > and service provider. The registration is just being used > > to provide > > > > reachability info, to allow requests to a set of E.164 > > numbers to be > > > > routed to the SIP PBX. As such, I don't think the number > > ranges need > > > > to be part of the registration transaction. It'll just > add extra > > > > complexity to the implementations. > > > > > > > > Regards > > > > Brian > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On > > > > Behalf Of Adam Roach > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > To: Paul Kyzivat > > > > Cc: Bernard Aboba; 'MARTINI' > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > procedure > > > > -- through a questionable use of P-Associated-URI -- to > > > indicate which > > >=20 > > > > URIs the registrar would be registering on behalf of the > > > user. So even > > >=20 > > > > the original 3GPP implicit approach had an enumeration of > > the AORs > > > > associated with the registration process. > > > > > > > > We're proposing to be even more sparse than that. Rather > > than just > > > > "implicit with a list of AORs," we're proposing "implicit > > with *no* > > > > list of AORs." > > > > > > > > So, even if your assertion that our allowing the implicit > > > mechanism to > > >=20 > > > > stand is somehow tacit approval, what's being proposed > > here is even > > > > one step more nebulous. > > > > > > > > /a > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > >> Dean, > > > >> > > > >> In principle I agree with you. > > > >> But this horse is already out of the barn with IMS implicit > > > > registration. > > > >> > > > >> It was never explicitly brought to the ietf, though things > > > linked to > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > we could say > > > >> that is not our problem, I think we already implicitly > > approved it > > > >> via > > > > > > > >> benign neglect. > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >> Dean Willis wrote: > > > >>> > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > >>> > > > >>>> Speaking as co-chair, the non-registration aspects of > > DID number > > > >>>> mobility are outside the scope of the current MARTINI > > WG charter. > > > >>>> > > > >>>> The question on the table (see > > > >>>>=20 > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > >>>> ) > > > > > > > >>>> is whether the registration aspects represent a > > > requirement or not. > > > >>>> Feel free > > > >>>> to respond and provide your opinion on that thread. > > > >>> > > > >>> Explicit is its own reward. > > > >>> > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > does is bind > > > >>> an > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact involved are=20 > > > >>> explicitly encoded in the request. > > > >>> > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > to multiple > > > >>> Contacts. This seems like a reasonable extension to > > simplify life > > > >>> for > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > should respect > > > >>> the history of REGISTERs explicit encoding of the AORs > > > and Contacts > > > >>> involved. > > > >>> > > > >>> From a requirements perspective, I'd be happy with a > > requirement > > > >>> along the lines of "must not preclude AOR mobility > > > indicated by the > > >=20 > > > >>> registration." I agree that we can't justify a requirement to=20 > > > >>> produce > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > >>> > > > >>> -- > > > >>> 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 > > >=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 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 altered,=20 > changed or falsified. > If you are not the intended addressee of this message, please cancel=20 > it immediately and inform the sender. > ******************************** >=20 >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Wed Feb 17 05:53: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 14EA53A7CD7 for ; Wed, 17 Feb 2010 05:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsoYBAZ+uhT8 for ; Wed, 17 Feb 2010 05:53:06 -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 C9F3B3A7649 for ; Wed, 17 Feb 2010 05:53:05 -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-917879; Wed, 17 Feb 2010 14:54:42 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A67841EB82AB; Wed, 17 Feb 2010 14:54:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 17 Feb 2010 14:54:42 +0100 From: "Elwell, John" To: Christer Holmberg , "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "blindsay@nortel.com" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Wed, 17 Feb 2010 14:54:40 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AAAXh1wAABVOuA= Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 13:53:08 -0000 Christer, Yes, that was what I was intending to imply. However, if MARTINI decides th= at there are compelling reasons why this information needs somehow to be co= nveyed (other than for IMS, which claims already to have a solution), I am = not sure that sending the information in a response would be acceptable, gi= ven the issue of the response size, and assuming we retain the requirement = for operation over UDP. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 17 February 2010 13:48 > To: Elwell, John; bruno.chatras@orange-ftgroup.com; > spencer@wonderhamster.org; blindsay@nortel.com; > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI > > > Hi, > > I don't really see what the problem is. Can't we simply say > that P-AU is optional, and people can use it if required? > > Regards, > > Christer > > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 17. helmikuuta 2010 15:37 > To: bruno.chatras@orange-ftgroup.com; > spencer@wonderhamster.org; blindsay@nortel.com; > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: Re: [martini] DID Number Mobility and MARTINI > > Bruno, > > Thanks. However, this particular reason for a proxy needing > this information is because of an architecture where the > proxy is assigned responsibility for asserting an identity > for the source of a request. If the domain proxy takes on > this responsibility instead, problem solved. So it is a > question of whether this particular architecture is common > enough that we need a solution that conveys registered > identities to the edge proxy. IMS solves this using PAU > (ignoring issues of response size), so the question for > others is whether there are other architectures in practice > where this is important. I guess for this particular usage it > doesn't matter whether the information is in the REGISTER > request or the REGISTER response. > > John > > > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: 17 February 2010 12:45 > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com; > > adam@nostrum.com; pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > My view is that there is no strong need need for carrying this > > information accross the SIP-PBX - SSP interface. However this > > information needs to be provided by the SSP's Registrar to > the SSP's > > edge proxy so as to enable the edge proxy to assert identities > > received from the PBX in a P-Preferred-Identity header field. > > > > > -----Message d'origine----- > > > De : martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > John Envoy=E9 > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > Brian Lindsay; > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re: > > > [martini] DID Number Mobility and MARTINI > > > > > > So in trying to tease out whether there needs to be, as > part of the > > > MARTINI mechanism (as opposed to provisioning) an > explicit list of > > > numbers and/or contacts (I won't try to tie down which at > present), > > > I think it is important to understand which direction > this is needed > > > in, because that will go some way towards determining the > mechanism. > > > Do people think: > > > > > > a) there is good reason for providing this information in the > > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER > > > request might be one solution); or > > > > > > b) there is a good reason for providing this information in the > > > direction SSP to SIP-PBX (in which case reg-events might be one > > > solution); or > > > > > > c) it doesn't matter which direction - either direction would be > > > good enough so that at least one side is able to detect a > > > discrepancy; or > > > > > > d) there is a good reason for doing both; or > > > > > > e) there is no good reason to do either. > > > > > > My personal opinion is e), but I would like to hear other > opinions, > > > with reasons. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > > Sent: 16 February 2010 22:23 > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > Cc: Bernard Aboba; MARTINI > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > Hi, Brian, > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > I am saying > > > > things I should not be saying as chair, at this point... > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > I'm trying > > > > to tease out is whether we can just say "we're not > providing that > > > > information in the REGISTER exchange, BUT you can get that > > > information > > > > using regevents", so that we can move on - I haven't > heard anyone > > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > > > > > > I would be comfortable if our specifications were > silent on this > > > > point, and might be more comfortable if we pointer out > > > somewhere that > > > > the REGISTER exchange does not provide this information, > > but people > > > > who want the information can use regevents or whatever > > other method > > > > seems appropriate to get the information that they want. > > > > > > > > But (Bernard and) I don't get to decide what working group > > > consensus > > > > is - we only get to recognize what consensus is, and when > > it exists. > > > > For that, we > > > > need to hear from other participants (including you, of > > > course - and > > > > "thank you" to participants who care, and have > expressed opinions > > > > about this, in the current thread. > > > > > > > > I hope this is helpful. > > > > > > > > Thanks, > > > > > > > > Spencer > > > > > > > > ----- Original Message ----- > > > > From: "Brian Lindsay" > > > > To: "Spencer Dawkins" ; "Adam Roach" > > > > ; "Paul Kyzivat" > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > Hi Spencer, > > > > > > > > So basically since the provisioning/sync of the E.164 > > > > numbers/ranges is out of scope I don't see a strong > argument for > > > > including them in the registration transaction. The Service > > > Provider > > > > has a set of E.164 numbers that, based on prior > > > > assignment/arrangement, it is responsible to route to the > > > SIP PBX. The > > > > SIP PBX is aware of these numbers already. > > > > The registration process (using an AoR identifying the > > SIP PBX) is > > > > intended to provide reachability information for the SIP > > > PBX, in the > > > > absence of static IP address configuration / DNS (hence the > > > ranges are > > > > not actually required in this transaction). > > > > > > > > Thanks > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > Cc: Bernard Aboba; MARTINI > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > Hi, Brian, > > > > > > > > Just trying to stay synchronized here. > > > > > > > > Speaking as an individual, I think you're right about > > provisioning > > > > being out of scope, based on what I've been hearing on this > > > list and > > > > in telechats, etc. > > > > > > > > What I thought Adam was talking about isn't quite provisioning > > > > (ignoring the question direction - I've heard some people > > > suggest each > > > > direction). > > > > It was more like "I expect these numbers to be registered" > > > and/or "I > > > > registered these numbers on your behalf", with the > > question of how > > > > each end knows what numbers "should" be registered being > > > out of scope > > > > - because "knowing" was provisioned. > > > > > > > > At least, that's the context in which I was reading Adam's > > > note below. > > > > > > > > Thanks, > > > > > > > > Spencer > > > > > > > > > > > > > Hi, > > > > > > > > > > I think it's been stated many times in the threads that > > > > E.164 number > > > > > > > > > provisioning between the enterprise and service provider > > > is out of > > > > > scope of MARTINI. So we're not using the register > > transaction to > > > > > perform any syncronization on these numbers betweeen the > > > enterprise > > > > > and service provider. The registration is just being used > > > to provide > > > > > reachability info, to allow requests to a set of E.164 > > > numbers to be > > > > > routed to the SIP PBX. As such, I don't think the number > > > ranges need > > > > > to be part of the registration transaction. It'll just > > add extra > > > > > complexity to the implementations. > > > > > > > > > > Regards > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On > > > > > Behalf Of Adam Roach > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > To: Paul Kyzivat > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > > procedure > > > > > -- through a questionable use of P-Associated-URI -- to > > > > indicate which > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > user. So even > > > > > > > > > the original 3GPP implicit approach had an enumeration of > > > the AORs > > > > > associated with the registration process. > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > than just > > > > > "implicit with a list of AORs," we're proposing "implicit > > > with *no* > > > > > list of AORs." > > > > > > > > > > So, even if your assertion that our allowing the implicit > > > > mechanism to > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > here is even > > > > > one step more nebulous. > > > > > > > > > > /a > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > >> Dean, > > > > >> > > > > >> In principle I agree with you. > > > > >> But this horse is already out of the barn with IMS implicit > > > > > registration. > > > > >> > > > > >> It was never explicitly brought to the ietf, though things > > > > linked to > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > we could say > > > > >> that is not our problem, I think we already implicitly > > > approved it > > > > >> via > > > > > > > > > >> benign neglect. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >> Dean Willis wrote: > > > > >>> > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > >>> > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > DID number > > > > >>>> mobility are outside the scope of the current MARTINI > > > WG charter. > > > > >>>> > > > > >>>> The question on the table (see > > > > >>>> > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > >>>> ) > > > > > > > > > >>>> is whether the registration aspects represent a > > > > requirement or not. > > > > >>>> Feel free > > > > >>>> to respond and provide your opinion on that thread. > > > > >>> > > > > >>> Explicit is its own reward. > > > > >>> > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > does is bind > > > > >>> an > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > involved are > > > > >>> explicitly encoded in the request. > > > > >>> > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > to multiple > > > > >>> Contacts. This seems like a reasonable extension to > > > simplify life > > > > >>> for > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > should respect > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > and Contacts > > > > >>> involved. > > > > >>> > > > > >>> From a requirements perspective, I'd be happy with a > > > requirement > > > > >>> along the lines of "must not preclude AOR mobility > > > > indicated by the > > > > > > > > >>> registration." I agree that we can't justify a > requirement to > > > > >>> produce > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > >>> > > > > >>> -- > > > > >>> 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 > > > > > > > _______________________________________________ > > > 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 christer.holmberg@ericsson.com Wed Feb 17 06:07: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 1A02E3A7EBC for ; Wed, 17 Feb 2010 06:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=-0.270, 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 pEYNjTcGblx4 for ; Wed, 17 Feb 2010 06:07:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B706828C0E3 for ; Wed, 17 Feb 2010 06:07:07 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-f3-4b7bf86d8037 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CE.75.31641.D68FB7B4; Wed, 17 Feb 2010 15:08:45 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 17 Feb 2010 15:08:44 +0100 From: Christer Holmberg To: "'Elwell, John'" , "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "blindsay@nortel.com" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Wed, 17 Feb 2010 15:08:44 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AAAXh1wAABVOuAAAF0G8A== Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 14:07:10 -0000 Hi, People who use P-AU have to take the message size issue into consideration. I am pretty sure this is not the only SIP scenario where you can get a resp= onse that is larger than the associated request... In addition, unless I've= missed it, we don't even know how the REGISTER request will look like yet = :) Regards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: 17. helmikuuta 2010 15:55 To: Christer Holmberg; bruno.chatras@orange-ftgroup.com; spencer@wonderhams= ter.org; blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: RE: [martini] DID Number Mobility and MARTINI Christer, Yes, that was what I was intending to imply. However, if MARTINI decides th= at there are compelling reasons why this information needs somehow to be co= nveyed (other than for IMS, which claims already to have a solution), I am = not sure that sending the information in a response would be acceptable, gi= ven the issue of the response size, and assuming we retain the requirement = for operation over UDP. John > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 17 February 2010 13:48 > To: Elwell, John; bruno.chatras@orange-ftgroup.com; > spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com; > pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI > > > Hi, > > I don't really see what the problem is. Can't we simply say that P-AU > is optional, and people can use it if required? > > Regards, > > Christer > > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 17. helmikuuta 2010 15:37 > To: bruno.chatras@orange-ftgroup.com; > spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com; > pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: Re: [martini] DID Number Mobility and MARTINI > > Bruno, > > Thanks. However, this particular reason for a proxy needing this > information is because of an architecture where the proxy is assigned > responsibility for asserting an identity for the source of a request. > If the domain proxy takes on this responsibility instead, problem > solved. So it is a question of whether this particular architecture is > common enough that we need a solution that conveys registered > identities to the edge proxy. IMS solves this using PAU (ignoring > issues of response size), so the question for others is whether there > are other architectures in practice where this is important. I guess > for this particular usage it doesn't matter whether the information is > in the REGISTER request or the REGISTER response. > > John > > > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: 17 February 2010 12:45 > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com; > > adam@nostrum.com; pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > My view is that there is no strong need need for carrying this > > information accross the SIP-PBX - SSP interface. However this > > information needs to be provided by the SSP's Registrar to > the SSP's > > edge proxy so as to enable the edge proxy to assert identities > > received from the PBX in a P-Preferred-Identity header field. > > > > > -----Message d'origine----- > > > De : martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > John Envoy=E9 > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > Brian Lindsay; > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re: > > > [martini] DID Number Mobility and MARTINI > > > > > > So in trying to tease out whether there needs to be, as > part of the > > > MARTINI mechanism (as opposed to provisioning) an > explicit list of > > > numbers and/or contacts (I won't try to tie down which at > present), > > > I think it is important to understand which direction > this is needed > > > in, because that will go some way towards determining the > mechanism. > > > Do people think: > > > > > > a) there is good reason for providing this information in the > > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER > > > request might be one solution); or > > > > > > b) there is a good reason for providing this information in the > > > direction SSP to SIP-PBX (in which case reg-events might be one > > > solution); or > > > > > > c) it doesn't matter which direction - either direction would be > > > good enough so that at least one side is able to detect a > > > discrepancy; or > > > > > > d) there is a good reason for doing both; or > > > > > > e) there is no good reason to do either. > > > > > > My personal opinion is e), but I would like to hear other > opinions, > > > with reasons. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > > Sent: 16 February 2010 22:23 > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > Cc: Bernard Aboba; MARTINI > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > Hi, Brian, > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > I am saying > > > > things I should not be saying as chair, at this point... > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > I'm trying > > > > to tease out is whether we can just say "we're not > providing that > > > > information in the REGISTER exchange, BUT you can get that > > > information > > > > using regevents", so that we can move on - I haven't > heard anyone > > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > > > > > > I would be comfortable if our specifications were > silent on this > > > > point, and might be more comfortable if we pointer out > > > somewhere that > > > > the REGISTER exchange does not provide this information, > > but people > > > > who want the information can use regevents or whatever > > other method > > > > seems appropriate to get the information that they want. > > > > > > > > But (Bernard and) I don't get to decide what working group > > > consensus > > > > is - we only get to recognize what consensus is, and when > > it exists. > > > > For that, we > > > > need to hear from other participants (including you, of > > > course - and > > > > "thank you" to participants who care, and have > expressed opinions > > > > about this, in the current thread. > > > > > > > > I hope this is helpful. > > > > > > > > Thanks, > > > > > > > > Spencer > > > > > > > > ----- Original Message ----- > > > > From: "Brian Lindsay" > > > > To: "Spencer Dawkins" ; "Adam Roach" > > > > ; "Paul Kyzivat" > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > Hi Spencer, > > > > > > > > So basically since the provisioning/sync of the E.164 > > > > numbers/ranges is out of scope I don't see a strong > argument for > > > > including them in the registration transaction. The Service > > > Provider > > > > has a set of E.164 numbers that, based on prior > > > > assignment/arrangement, it is responsible to route to the > > > SIP PBX. The > > > > SIP PBX is aware of these numbers already. > > > > The registration process (using an AoR identifying the > > SIP PBX) is > > > > intended to provide reachability information for the SIP > > > PBX, in the > > > > absence of static IP address configuration / DNS (hence the > > > ranges are > > > > not actually required in this transaction). > > > > > > > > Thanks > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > Cc: Bernard Aboba; MARTINI > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > Hi, Brian, > > > > > > > > Just trying to stay synchronized here. > > > > > > > > Speaking as an individual, I think you're right about > > provisioning > > > > being out of scope, based on what I've been hearing on this > > > list and > > > > in telechats, etc. > > > > > > > > What I thought Adam was talking about isn't quite provisioning > > > > (ignoring the question direction - I've heard some people > > > suggest each > > > > direction). > > > > It was more like "I expect these numbers to be registered" > > > and/or "I > > > > registered these numbers on your behalf", with the > > question of how > > > > each end knows what numbers "should" be registered being > > > out of scope > > > > - because "knowing" was provisioned. > > > > > > > > At least, that's the context in which I was reading Adam's > > > note below. > > > > > > > > Thanks, > > > > > > > > Spencer > > > > > > > > > > > > > Hi, > > > > > > > > > > I think it's been stated many times in the threads that > > > > E.164 number > > > > > > > > > provisioning between the enterprise and service provider > > > is out of > > > > > scope of MARTINI. So we're not using the register > > transaction to > > > > > perform any syncronization on these numbers betweeen the > > > enterprise > > > > > and service provider. The registration is just being used > > > to provide > > > > > reachability info, to allow requests to a set of E.164 > > > numbers to be > > > > > routed to the SIP PBX. As such, I don't think the number > > > ranges need > > > > > to be part of the registration transaction. It'll just > > add extra > > > > > complexity to the implementations. > > > > > > > > > > Regards > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On > > > > > Behalf Of Adam Roach > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > To: Paul Kyzivat > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > > procedure > > > > > -- through a questionable use of P-Associated-URI -- to > > > > indicate which > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > user. So even > > > > > > > > > the original 3GPP implicit approach had an enumeration of > > > the AORs > > > > > associated with the registration process. > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > than just > > > > > "implicit with a list of AORs," we're proposing "implicit > > > with *no* > > > > > list of AORs." > > > > > > > > > > So, even if your assertion that our allowing the implicit > > > > mechanism to > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > here is even > > > > > one step more nebulous. > > > > > > > > > > /a > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > >> Dean, > > > > >> > > > > >> In principle I agree with you. > > > > >> But this horse is already out of the barn with IMS implicit > > > > > registration. > > > > >> > > > > >> It was never explicitly brought to the ietf, though things > > > > linked to > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > we could say > > > > >> that is not our problem, I think we already implicitly > > > approved it > > > > >> via > > > > > > > > > >> benign neglect. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >> Dean Willis wrote: > > > > >>> > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > >>> > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > DID number > > > > >>>> mobility are outside the scope of the current MARTINI > > > WG charter. > > > > >>>> > > > > >>>> The question on the table (see > > > > >>>> > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > >>>> ) > > > > > > > > > >>>> is whether the registration aspects represent a > > > > requirement or not. > > > > >>>> Feel free > > > > >>>> to respond and provide your opinion on that thread. > > > > >>> > > > > >>> Explicit is its own reward. > > > > >>> > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > does is bind > > > > >>> an > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > involved are > > > > >>> explicitly encoded in the request. > > > > >>> > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > to multiple > > > > >>> Contacts. This seems like a reasonable extension to > > > simplify life > > > > >>> for > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > should respect > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > and Contacts > > > > >>> involved. > > > > >>> > > > > >>> From a requirements perspective, I'd be happy with a > > > requirement > > > > >>> along the lines of "must not preclude AOR mobility > > > > indicated by the > > > > > > > > >>> registration." I agree that we can't justify a > requirement to > > > > >>> produce > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > >>> > > > > >>> -- > > > > >>> 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 > > > > > > > _______________________________________________ > > > 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 bruno.chatras@orange-ftgroup.com Wed Feb 17 06:25: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 CDF743A7508 for ; Wed, 17 Feb 2010 06:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.030, 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 PO3AIx5J+bqs for ; Wed, 17 Feb 2010 06:25:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 2BDD23A7243 for ; Wed, 17 Feb 2010 06:25:28 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 4E1049C522; Wed, 17 Feb 2010 15:27:05 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8A1AE35C016; Wed, 17 Feb 2010 15:27: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); Wed, 17 Feb 2010 15:27: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: Wed, 17 Feb 2010 15:26:57 +0100 Message-ID: <32412_1266416825_4B7BFCB9_32412_23905_1_9ECCF01B52E7AB408A7EB85352642141011D844E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AAAXh1wAABVOuAAAF0G8AAArsyQ References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com><8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> From: To: , , , , , X-OriginalArrivalTime: 17 Feb 2010 14:27:03.0713 (UTC) FILETIME=[4664E110:01CAAFDD] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.17.135416 Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 14:25:30 -0000 Use of wildcarded identities in P-AU provides a solution to shorten the mes= sage. Does this discussion means that the MARTINI group has already discard= ed this solution? I remember someone stating that the use of wildcards was = not permitted by RFC3455. If this is confirmed, a revision of RFC3455 might= be more appropriate than just discarding the solution. > -----Message d'origine----- > De : Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Envoy=E9 : mercredi 17 f=E9vrier 2010 15:09 > =C0 : 'Elwell, John'; CHATRAS Bruno RD-CORE-ISS;=20 > spencer@wonderhamster.org; blindsay@nortel.com;=20 > adam@nostrum.com; pkyzivat@cisco.com > Cc : bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] DID Number Mobility and MARTINI >=20 >=20 > Hi, >=20 > People who use P-AU have to take the message size issue into=20 > consideration. >=20 > I am pretty sure this is not the only SIP scenario where you=20 > can get a response that is larger than the associated=20 > request... In addition, unless I've missed it, we don't even=20 > know how the REGISTER request will look like yet :) >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: 17. helmikuuta 2010 15:55 > To: Christer Holmberg; bruno.chatras@orange-ftgroup.com;=20 > spencer@wonderhamster.org; blindsay@nortel.com;=20 > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > Christer, >=20 > Yes, that was what I was intending to imply. However, if=20 > MARTINI decides that there are compelling reasons why this=20 > information needs somehow to be conveyed (other than for IMS,=20 > which claims already to have a solution), I am not sure that=20 > sending the information in a response would be acceptable,=20 > given the issue of the response size, and assuming we retain=20 > the requirement for operation over UDP. >=20 > John >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 17 February 2010 13:48 > > To: Elwell, John; bruno.chatras@orange-ftgroup.com;=20 > > spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com;=20 > > pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > Hi, > > > > I don't really see what the problem is. Can't we simply say=20 > that P-AU=20 > > is optional, and people can use it if required? > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 17. helmikuuta 2010 15:37 > > To: bruno.chatras@orange-ftgroup.com; > > spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com;=20 > > pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > Bruno, > > > > Thanks. However, this particular reason for a proxy needing this=20 > > information is because of an architecture where the proxy=20 > is assigned=20 > > responsibility for asserting an identity for the source of=20 > a request. > > If the domain proxy takes on this responsibility instead, problem=20 > > solved. So it is a question of whether this particular=20 > architecture is=20 > > common enough that we need a solution that conveys registered=20 > > identities to the edge proxy. IMS solves this using PAU (ignoring=20 > > issues of response size), so the question for others is=20 > whether there=20 > > are other architectures in practice where this is=20 > important. I guess=20 > > for this particular usage it doesn't matter whether the=20 > information is=20 > > in the REGISTER request or the REGISTER response. > > > > John > > > > > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com=20 > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 17 February 2010 12:45 > > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > > adam@nostrum.com; pkyzivat@cisco.com > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > My view is that there is no strong need need for carrying this=20 > > > information accross the SIP-PBX - SSP interface. However this=20 > > > information needs to be provided by the SSP's Registrar to > > the SSP's > > > edge proxy so as to enable the edge proxy to assert identities=20 > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > -----Message d'origine----- > > > > De : martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > John Envoy=E9 > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > Brian Lindsay; > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re: > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > So in trying to tease out whether there needs to be, as > > part of the > > > > MARTINI mechanism (as opposed to provisioning) an > > explicit list of > > > > numbers and/or contacts (I won't try to tie down which at > > present), > > > > I think it is important to understand which direction > > this is needed > > > > in, because that will go some way towards determining the > > mechanism. > > > > Do people think: > > > > > > > > a) there is good reason for providing this information in the=20 > > > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER=20 > > > > request might be one solution); or > > > > > > > > b) there is a good reason for providing this information in the=20 > > > > direction SSP to SIP-PBX (in which case reg-events might be one=20 > > > > solution); or > > > > > > > > c) it doesn't matter which direction - either direction=20 > would be=20 > > > > good enough so that at least one side is able to detect a=20 > > > > discrepancy; or > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > e) there is no good reason to do either. > > > > > > > > My personal opinion is e), but I would like to hear other > > opinions, > > > > with reasons. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: martini-bounces@ietf.org > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > > > Sent: 16 February 2010 22:23 > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > Cc: Bernard Aboba; MARTINI > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > Hi, Brian, > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > I am saying > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > I'm trying > > > > > to tease out is whether we can just say "we're not > > providing that > > > > > information in the REGISTER exchange, BUT you can get that > > > > information > > > > > using regevents", so that we can move on - I haven't > > heard anyone > > > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > > > > > > > > I would be comfortable if our specifications were > > silent on this > > > > > point, and might be more comfortable if we pointer out > > > > somewhere that > > > > > the REGISTER exchange does not provide this information, > > > but people > > > > > who want the information can use regevents or whatever > > > other method > > > > > seems appropriate to get the information that they want. > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > consensus > > > > > is - we only get to recognize what consensus is, and when > > > it exists. > > > > > For that, we > > > > > need to hear from other participants (including you, of > > > > course - and > > > > > "thank you" to participants who care, and have > > expressed opinions > > > > > about this, in the current thread. > > > > > > > > > > I hope this is helpful. > > > > > > > > > > Thanks, > > > > > > > > > > Spencer > > > > > > > > > > ----- Original Message ----- > > > > > From: "Brian Lindsay" > > > > > To: "Spencer Dawkins" ;=20 > "Adam Roach" > > > > > ; "Paul Kyzivat" > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > So basically since the provisioning/sync of the E.164=20 > > > > > numbers/ranges is out of scope I don't see a strong > > argument for > > > > > including them in the registration transaction. The Service > > > > Provider > > > > > has a set of E.164 numbers that, based on prior=20 > > > > > assignment/arrangement, it is responsible to route to the > > > > SIP PBX. The > > > > > SIP PBX is aware of these numbers already. > > > > > The registration process (using an AoR identifying the > > > SIP PBX) is > > > > > intended to provide reachability information for the SIP > > > > PBX, in the > > > > > absence of static IP address configuration / DNS (hence the > > > > ranges are > > > > > not actually required in this transaction). > > > > > > > > > > Thanks > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > Cc: Bernard Aboba; MARTINI > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > Hi, Brian, > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > Speaking as an individual, I think you're right about > > > provisioning > > > > > being out of scope, based on what I've been hearing on this > > > > list and > > > > > in telechats, etc. > > > > > > > > > > What I thought Adam was talking about isn't quite=20 > provisioning=20 > > > > > (ignoring the question direction - I've heard some people > > > > suggest each > > > > > direction). > > > > > It was more like "I expect these numbers to be registered" > > > > and/or "I > > > > > registered these numbers on your behalf", with the > > > question of how > > > > > each end knows what numbers "should" be registered being > > > > out of scope > > > > > - because "knowing" was provisioned. > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > note below. > > > > > > > > > > Thanks, > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I think it's been stated many times in the threads that > > > > > E.164 number > > > > > > > > > > > provisioning between the enterprise and service provider > > > > is out of > > > > > > scope of MARTINI. So we're not using the register > > > transaction to > > > > > > perform any syncronization on these numbers betweeen the > > > > enterprise > > > > > > and service provider. The registration is just being used > > > > to provide > > > > > > reachability info, to allow requests to a set of E.164 > > > > numbers to be > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > ranges need > > > > > > to be part of the registration transaction. It'll just > > > add extra > > > > > > complexity to the implementations. > > > > > > > > > > > > Regards > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] On > > > > > > Behalf Of Adam Roach > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > To: Paul Kyzivat > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > > > procedure > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > indicate which > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > user. So even > > > > > > > > > > > the original 3GPP implicit approach had an enumeration of > > > > the AORs > > > > > > associated with the registration process. > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > than just > > > > > > "implicit with a list of AORs," we're proposing "implicit > > > > with *no* > > > > > > list of AORs." > > > > > > > > > > > > So, even if your assertion that our allowing the implicit > > > > > mechanism to > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > here is even > > > > > > one step more nebulous. > > > > > > > > > > > > /a > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > >> Dean, > > > > > >> > > > > > >> In principle I agree with you. > > > > > >> But this horse is already out of the barn with IMS implicit > > > > > > registration. > > > > > >> > > > > > >> It was never explicitly brought to the ietf, though things > > > > > linked to > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > we could say > > > > > >> that is not our problem, I think we already implicitly > > > > approved it > > > > > >> via > > > > > > > > > > > >> benign neglect. > > > > > >> > > > > > >> Thanks, > > > > > >> Paul > > > > > >> > > > > > >> Dean Willis wrote: > > > > > >>> > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > >>> > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > DID number > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > WG charter. > > > > > >>>> > > > > > >>>> The question on the table (see > > > > > >>>> > > > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > >>>> ) > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > requirement or not. > > > > > >>>> Feel free > > > > > >>>> to respond and provide your opinion on that thread. > > > > > >>> > > > > > >>> Explicit is its own reward. > > > > > >>> > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > does is bind > > > > > >>> an > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > involved are > > > > > >>> explicitly encoded in the request. > > > > > >>> > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > to multiple > > > > > >>> Contacts. This seems like a reasonable extension to > > > > simplify life > > > > > >>> for > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > should respect > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > and Contacts > > > > > >>> involved. > > > > > >>> > > > > > >>> From a requirements perspective, I'd be happy with a > > > > requirement > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > indicated by the > > > > > > > > > > >>> registration." I agree that we can't justify a > > requirement to > > > > > >>> produce > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > >>> > > > > > >>> -- > > > > > >>> 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 > > > > > > > > > _______________________________________________ > > > > 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 > > >=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 BLINDSAY@nortel.com Wed Feb 17 06:33: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 262A83A7D09 for ; Wed, 17 Feb 2010 06:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 I5L1FrtzDFtE for ; Wed, 17 Feb 2010 06:33:31 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 523123A7D0F for ; Wed, 17 Feb 2010 06:33:31 -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 o1HEYT929752; Wed, 17 Feb 2010 14:34:29 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Feb 2010 09:34:26 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C8F0B59@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AAAXh1wAAHMQgA= References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com><8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> From: "Brian Lindsay" To: "Christer Holmberg" , "Elwell, John" , , , , Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 14:33:33 -0000 Hi, I would suggest keeping P-AU out of the draft(s). If there is a = service provider architecture, like IMS, that wants to use it, that's = fine, but it doesn't need to be included in the mechanism described by = the draft. Regards Brian -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Wednesday, February 17, 2010 8:48 AM To: 'Elwell, John'; bruno.chatras@orange-ftgroup.com; = spencer@wonderhamster.org; Lindsay, Brian (CAR:AR00); adam@nostrum.com; = pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: RE: [martini] DID Number Mobility and MARTINI Hi, I don't really see what the problem is. Can't we simply say that P-AU is = optional, and people can use it if required? Regards, Christer=20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Elwell, John Sent: 17. helmikuuta 2010 15:37 To: bruno.chatras@orange-ftgroup.com; spencer@wonderhamster.org; = blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] DID Number Mobility and MARTINI Bruno, Thanks. However, this particular reason for a proxy needing this = information is because of an architecture where the proxy is assigned = responsibility for asserting an identity for the source of a request. If = the domain proxy takes on this responsibility instead, problem solved. = So it is a question of whether this particular architecture is common = enough that we need a solution that conveys registered identities to the = edge proxy. IMS solves this using PAU (ignoring issues of response = size), so the question for others is whether there are other = architectures in practice where this is important. I guess for this = particular usage it doesn't matter whether the information is in the = REGISTER request or the REGISTER response. John =20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: 17 February 2010 12:45 > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com;=20 > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > My view is that there is no strong need need for carrying this=20 > information accross the SIP-PBX - SSP interface. However this=20 > information needs to be provided by the SSP's Registrar to the SSP's=20 > edge proxy so as to enable the edge proxy to assert identities=20 > received from the PBX in a P-Preferred-Identity header field. >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Elwell, John = Envoy=E9 > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; Brian = Lindsay;=20 > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re: > > [martini] DID Number Mobility and MARTINI > >=20 > > So in trying to tease out whether there needs to be, as part of the=20 > > MARTINI mechanism (as opposed to provisioning) an explicit list of=20 > > numbers and/or contacts (I won't try to tie down which at present),=20 > > I think it is important to understand which direction this is needed = > > in, because that will go some way towards determining the mechanism. > > Do people think: > >=20 > > a) there is good reason for providing this information in the=20 > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER=20 > > request might be one solution); or > >=20 > > b) there is a good reason for providing this information in the=20 > > direction SSP to SIP-PBX (in which case reg-events might be one=20 > > solution); or > >=20 > > c) it doesn't matter which direction - either direction would be=20 > > good enough so that at least one side is able to detect a=20 > > discrepancy; or > >=20 > > d) there is a good reason for doing both; or > >=20 > > e) there is no good reason to do either. > >=20 > > My personal opinion is e), but I would like to hear other opinions,=20 > > with reasons. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > Sent: 16 February 2010 22:23 > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > Cc: Bernard Aboba; MARTINI > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > >=20 > > > Hi, Brian, > > >=20 > > > Speaking carefully as chair, and Bernard can correct me if > > I am saying > > > things I should not be saying as chair, at this point... > > >=20 > > > I happen to agree with your reasoning, re: REGISTER. What > > I'm trying > > > to tease out is whether we can just say "we're not providing that=20 > > > information in the REGISTER exchange, BUT you can get that > > information > > > using regevents", so that we can move on - I haven't heard anyone=20 > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > >=20 > > > I would be comfortable if our specifications were silent on this=20 > > > point, and might be more comfortable if we pointer out > > somewhere that > > > the REGISTER exchange does not provide this information, > but people > > > who want the information can use regevents or whatever > other method > > > seems appropriate to get the information that they want. > > >=20 > > > But (Bernard and) I don't get to decide what working group > > consensus > > > is - we only get to recognize what consensus is, and when > it exists. > > > For that, we > > > need to hear from other participants (including you, of > > course - and > > > "thank you" to participants who care, and have expressed opinions=20 > > > about this, in the current thread. > > >=20 > > > I hope this is helpful. > > >=20 > > > Thanks, > > >=20 > > > Spencer > > >=20 > > > ----- Original Message ----- > > > From: "Brian Lindsay" > > > To: "Spencer Dawkins" ; "Adam Roach"=20 > > > ; "Paul Kyzivat" > > > Cc: "Bernard Aboba" ; "MARTINI"=20 > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > >=20 > > >=20 > > > Hi Spencer, > > >=20 > > > So basically since the provisioning/sync of the E.164=20 > > > numbers/ranges is out of scope I don't see a strong argument for=20 > > > including them in the registration transaction. The Service > > Provider > > > has a set of E.164 numbers that, based on prior=20 > > > assignment/arrangement, it is responsible to route to the > > SIP PBX. The > > > SIP PBX is aware of these numbers already. > > > The registration process (using an AoR identifying the > SIP PBX) is > > > intended to provide reachability information for the SIP > > PBX, in the > > > absence of static IP address configuration / DNS (hence the > > ranges are > > > not actually required in this transaction). > > >=20 > > > Thanks > > > Brian > > >=20 > > > -----Original Message----- > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > Cc: Bernard Aboba; MARTINI > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > >=20 > > > Hi, Brian, > > >=20 > > > Just trying to stay synchronized here. > > >=20 > > > Speaking as an individual, I think you're right about > provisioning > > > being out of scope, based on what I've been hearing on this > > list and > > > in telechats, etc. > > >=20 > > > What I thought Adam was talking about isn't quite provisioning=20 > > > (ignoring the question direction - I've heard some people > > suggest each > > > direction). > > > It was more like "I expect these numbers to be registered"=20 > > and/or "I > > > registered these numbers on your behalf", with the > question of how > > > each end knows what numbers "should" be registered being > > out of scope > > > - because "knowing" was provisioned. > > >=20 > > > At least, that's the context in which I was reading Adam's > > note below. > > >=20 > > > Thanks, > > >=20 > > > Spencer > > >=20 > > >=20 > > > > Hi, > > > > > > > > I think it's been stated many times in the threads that > > > E.164 number > > >=20 > > > > provisioning between the enterprise and service provider > > is out of > > > > scope of MARTINI. So we're not using the register > transaction to > > > > perform any syncronization on these numbers betweeen the > > enterprise > > > > and service provider. The registration is just being used > > to provide > > > > reachability info, to allow requests to a set of E.164 > > numbers to be > > > > routed to the SIP PBX. As such, I don't think the number > > ranges need > > > > to be part of the registration transaction. It'll just > add extra > > > > complexity to the implementations. > > > > > > > > Regards > > > > Brian > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On > > > > Behalf Of Adam Roach > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > To: Paul Kyzivat > > > > Cc: Bernard Aboba; 'MARTINI' > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > procedure > > > > -- through a questionable use of P-Associated-URI -- to > > > indicate which > > >=20 > > > > URIs the registrar would be registering on behalf of the > > > user. So even > > >=20 > > > > the original 3GPP implicit approach had an enumeration of > > the AORs > > > > associated with the registration process. > > > > > > > > We're proposing to be even more sparse than that. Rather > > than just > > > > "implicit with a list of AORs," we're proposing "implicit > > with *no* > > > > list of AORs." > > > > > > > > So, even if your assertion that our allowing the implicit > > > mechanism to > > >=20 > > > > stand is somehow tacit approval, what's being proposed > > here is even > > > > one step more nebulous. > > > > > > > > /a > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > >> Dean, > > > >> > > > >> In principle I agree with you. > > > >> But this horse is already out of the barn with IMS implicit > > > > registration. > > > >> > > > >> It was never explicitly brought to the ietf, though things > > > linked to > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > we could say > > > >> that is not our problem, I think we already implicitly > > approved it > > > >> via > > > > > > > >> benign neglect. > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >> Dean Willis wrote: > > > >>> > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > >>> > > > >>>> Speaking as co-chair, the non-registration aspects of > > DID number > > > >>>> mobility are outside the scope of the current MARTINI > > WG charter. > > > >>>> > > > >>>> The question on the table (see > > > >>>>=20 > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > >>>> ) > > > > > > > >>>> is whether the registration aspects represent a > > > requirement or not. > > > >>>> Feel free > > > >>>> to respond and provide your opinion on that thread. > > > >>> > > > >>> Explicit is its own reward. > > > >>> > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > does is bind > > > >>> an > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact involved are=20 > > > >>> explicitly encoded in the request. > > > >>> > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > to multiple > > > >>> Contacts. This seems like a reasonable extension to > > simplify life > > > >>> for > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > should respect > > > >>> the history of REGISTERs explicit encoding of the AORs > > > and Contacts > > > >>> involved. > > > >>> > > > >>> From a requirements perspective, I'd be happy with a > > requirement > > > >>> along the lines of "must not preclude AOR mobility > > > indicated by the > > >=20 > > > >>> registration." I agree that we can't justify a requirement to=20 > > > >>> produce > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > >>> > > > >>> -- > > > >>> 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 > > >=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 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 altered,=20 > changed or falsified. > If you are not the intended addressee of this message, please cancel=20 > it immediately and inform the sender. > ******************************** >=20 >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From BLINDSAY@nortel.com Wed Feb 17 06:39: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 AF5C828C12F for ; Wed, 17 Feb 2010 06:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 vUubdZpjRdR4 for ; Wed, 17 Feb 2010 06:39:38 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 84C443A78B6 for ; Wed, 17 Feb 2010 06:39:37 -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 o1HEeEb06999; Wed, 17 Feb 2010 14:40:14 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Feb 2010 09:38:51 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C8F0B77@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAA9/rIA= References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> From: "Brian Lindsay" To: "Elwell, John" , "Spencer Dawkins" , "Adam Roach" , "Paul Kyzivat" Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 14:39:40 -0000 Hi John, Per my previous posts, I agree with you on e). Thanks -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, February 17, 2010 2:36 AM To: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat Cc: Bernard Aboba; MARTINI Subject: RE: [martini] DID Number Mobility and MARTINI So in trying to tease out whether there needs to be, as part of the MARTINI mechanism (as opposed to provisioning) an explicit list of numbers and/or contacts (I won't try to tie down which at present), I think it is important to understand which direction this is needed in, because that will go some way towards determining the mechanism. Do people think: a) there is good reason for providing this information in the direction SIP-PBX to SSP (in which case inclusion in a REGISTER request might be one solution); or b) there is a good reason for providing this information in the direction SSP to SIP-PBX (in which case reg-events might be one solution); or c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or d) there is a good reason for doing both; or e) there is no good reason to do either. My personal opinion is e), but I would like to hear other opinions, with reasons. John > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 16 February 2010 22:23 > To: Brian Lindsay; Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Hi, Brian, >=20 > Speaking carefully as chair, and Bernard can correct me if I am saying > things I should not be saying as chair, at this point... >=20 > I happen to agree with your reasoning, re: REGISTER. What I'm trying=20 > to tease out is whether we can just say "we're not providing that=20 > information in the REGISTER exchange, BUT you can get that information > using regevents", so that we can move on - I haven't heard anyone=20 > propose that MARTINI would say "MUST NOT use regevents" :-) >=20 > I would be comfortable if our specifications were silent on this=20 > point, and might be more comfortable if we pointer out somewhere that=20 > the REGISTER exchange does not provide this information, but people=20 > who want the information can use regevents or whatever other method=20 > seems appropriate to get the information that they want. >=20 > But (Bernard and) I don't get to decide what working group consensus=20 > is - we only get to recognize what consensus is, and when it exists. > For that, we > need to hear from other participants (including you, of course - and=20 > "thank you" to participants who care, and have expressed opinions=20 > about this, in the current thread. >=20 > I hope this is helpful. >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message ----- > From: "Brian Lindsay" > To: "Spencer Dawkins" ; "Adam Roach"=20 > ; "Paul Kyzivat" > Cc: "Bernard Aboba" ; "MARTINI"=20 > > Sent: Tuesday, February 16, 2010 3:51 PM > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 >=20 > Hi Spencer, >=20 > So basically since the provisioning/sync of the E.164=20 > numbers/ranges is out of scope I don't see a strong argument for=20 > including them in the registration transaction. The Service Provider=20 > has a set of E.164 numbers that, based on prior=20 > assignment/arrangement, it is responsible to route to the SIP PBX. The > SIP PBX is aware of these numbers already. > The registration process (using an AoR identifying the SIP PBX) is=20 > intended to provide reachability information for the SIP PBX, in the=20 > absence of static IP address configuration / DNS (hence the ranges are > not actually required in this transaction). >=20 > Thanks > Brian >=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Tuesday, February 16, 2010 4:37 PM > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Hi, Brian, >=20 > Just trying to stay synchronized here. >=20 > Speaking as an individual, I think you're right about provisioning=20 > being out of scope, based on what I've been hearing on this list and=20 > in telechats, etc. >=20 > What I thought Adam was talking about isn't quite provisioning=20 > (ignoring the question direction - I've heard some people suggest each > direction). > It was more like "I expect these numbers to be registered" and/or "I=20 > registered these numbers on your behalf", with the question of how=20 > each end knows what numbers "should" be registered being out of scope=20 > - because "knowing" was provisioned. >=20 > At least, that's the context in which I was reading Adam's note below. >=20 > Thanks, >=20 > Spencer >=20 >=20 > > Hi, > > > > I think it's been stated many times in the threads that > E.164 number >=20 > > provisioning between the enterprise and service provider is out of=20 > > scope of MARTINI. So we're not using the register transaction to=20 > > perform any syncronization on these numbers betweeen the enterprise=20 > > and service provider. The registration is just being used to provide > > reachability info, to allow requests to a set of E.164 numbers to be > > routed to the SIP PBX. As such, I don't think the number ranges need > > to be part of the registration transaction. It'll just add extra=20 > > complexity to the implementations. > > > > Regards > > Brian > > > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of Adam Roach > > Sent: Tuesday, February 16, 2010 1:39 PM > > To: Paul Kyzivat > > Cc: Bernard Aboba; 'MARTINI' > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > So, here's what I don't understand: 3GPP at least defined a > procedure > > -- through a questionable use of P-Associated-URI -- to > indicate which >=20 > > URIs the registrar would be registering on behalf of the > user. So even >=20 > > the original 3GPP implicit approach had an enumeration of the AORs=20 > > associated with the registration process. > > > > We're proposing to be even more sparse than that. Rather than just=20 > > "implicit with a list of AORs," we're proposing "implicit with *no*=20 > > list of AORs." > > > > So, even if your assertion that our allowing the implicit > mechanism to >=20 > > stand is somehow tacit approval, what's being proposed here is even=20 > > one step more nebulous. > > > > /a > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > >> Dean, > >> > >> In principle I agree with you. > >> But this horse is already out of the barn with IMS implicit > > registration. > >> > >> It was never explicitly brought to the ietf, though things > linked to > >> it like P-Asserted-ID and P-Associated-URI were. While we could say > >> that is not our problem, I think we already implicitly approved it=20 > >> via > > > >> benign neglect. > >> > >> Thanks, > >> Paul > >> > >> Dean Willis wrote: > >>> > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > >>> > >>>> Speaking as co-chair, the non-registration aspects of DID number=20 > >>>> mobility are outside the scope of the current MARTINI WG charter. > >>>> > >>>> The question on the table (see > >>>>=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > >>>> ) > > > >>>> is whether the registration aspects represent a > requirement or not. > >>>> Feel free > >>>> to respond and provide your opinion on that thread. > >>> > >>> Explicit is its own reward. > >>> > >>> Remember, the one thing that RFC 3261 REGISTER really does is bind > >>> an > > > >>> AOR to a Contact. Both the AOR and the Contact involved are=20 > >>> explicitly encoded in the request. > >>> > >>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple > >>> Contacts. This seems like a reasonable extension to simplify life=20 > >>> for > > > >>> a "multi user" SIP user agent. But I really think we > should respect > >>> the history of REGISTERs explicit encoding of the AORs > and Contacts > >>> involved. > >>> > >>> From a requirements perspective, I'd be happy with a requirement=20 > >>> along the lines of "must not preclude AOR mobility > indicated by the >=20 > >>> registration." I agree that we can't justify a requirement to=20 > >>> produce > > > >>> a mechanism at the time for the whole enchilada. > >>> > >>> -- > >>> 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 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From christer.holmberg@ericsson.com Wed Feb 17 06:40: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 507C828C11E for ; Wed, 17 Feb 2010 06:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=-0.265, 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 6Ao9becMq9y0 for ; Wed, 17 Feb 2010 06:40:29 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E2FFE3A78B6 for ; Wed, 17 Feb 2010 06:40:28 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-65-4b7c003d92d3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 10.89.31641.D300C7B4; Wed, 17 Feb 2010 15:42:05 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 17 Feb 2010 15:42:05 +0100 From: Christer Holmberg To: 'Brian Lindsay' , "Elwell, John" , "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Wed, 17 Feb 2010 15:42:04 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AAAXh1wAAHMQgAAADmKwA== Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com><8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C8F0B59@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C8F0B59@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 14:40:31 -0000 Hi, I guess it's ok to leave it out, as long as we don't forbid the usage of it= . However, *IF* we will end up with a solution/requirement where the register= ed AoRs for whatever other ("non-IMS") reason need to be sent from the SSP = to the PBX, I see no reason why P-AU can't be listed as an option... Regards, Christer -----Original Message----- From: Brian Lindsay [mailto:blindsay@nortel.com] Sent: 17. helmikuuta 2010 16:34 To: Christer Holmberg; Elwell, John; bruno.chatras@orange-ftgroup.com; spen= cer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: RE: [martini] DID Number Mobility and MARTINI Hi, I would suggest keeping P-AU out of the draft(s). If there is a service = provider architecture, like IMS, that wants to use it, that's fine, but it = doesn't need to be included in the mechanism described by the draft. Regards Brian -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, February 17, 2010 8:48 AM To: 'Elwell, John'; bruno.chatras@orange-ftgroup.com; spencer@wonderhamster= .org; Lindsay, Brian (CAR:AR00); adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: RE: [martini] DID Number Mobility and MARTINI Hi, I don't really see what the problem is. Can't we simply say that P-AU is op= tional, and people can use it if required? Regards, Christer -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Elwell, John Sent: 17. helmikuuta 2010 15:37 To: bruno.chatras@orange-ftgroup.com; spencer@wonderhamster.org; blindsay@n= ortel.com; adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] DID Number Mobility and MARTINI Bruno, Thanks. However, this particular reason for a proxy needing this informatio= n is because of an architecture where the proxy is assigned responsibility = for asserting an identity for the source of a request. If the domain proxy = takes on this responsibility instead, problem solved. So it is a question o= f whether this particular architecture is common enough that we need a solu= tion that conveys registered identities to the edge proxy. IMS solves this = using PAU (ignoring issues of response size), so the question for others is= whether there are other architectures in practice where this is important.= I guess for this particular usage it doesn't matter whether the informatio= n is in the REGISTER request or the REGISTER response. John > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: 17 February 2010 12:45 > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com; > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI > > My view is that there is no strong need need for carrying this > information accross the SIP-PBX - SSP interface. However this > information needs to be provided by the SSP's Registrar to the SSP's > edge proxy so as to enable the edge proxy to assert identities > received from the PBX in a P-Preferred-Identity header field. > > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Elwell, John Envoy=E9 > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; Brian Lindsay= ; > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re: > > [martini] DID Number Mobility and MARTINI > > > > So in trying to tease out whether there needs to be, as part of the > > MARTINI mechanism (as opposed to provisioning) an explicit list of > > numbers and/or contacts (I won't try to tie down which at present), > > I think it is important to understand which direction this is needed > > in, because that will go some way towards determining the mechanism. > > Do people think: > > > > a) there is good reason for providing this information in the > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER > > request might be one solution); or > > > > b) there is a good reason for providing this information in the > > direction SSP to SIP-PBX (in which case reg-events might be one > > solution); or > > > > c) it doesn't matter which direction - either direction would be > > good enough so that at least one side is able to detect a > > discrepancy; or > > > > d) there is a good reason for doing both; or > > > > e) there is no good reason to do either. > > > > My personal opinion is e), but I would like to hear other opinions, > > with reasons. > > > > John > > > > > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > Sent: 16 February 2010 22:23 > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > Cc: Bernard Aboba; MARTINI > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > Hi, Brian, > > > > > > Speaking carefully as chair, and Bernard can correct me if > > I am saying > > > things I should not be saying as chair, at this point... > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > I'm trying > > > to tease out is whether we can just say "we're not providing that > > > information in the REGISTER exchange, BUT you can get that > > information > > > using regevents", so that we can move on - I haven't heard anyone > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > > > > I would be comfortable if our specifications were silent on this > > > point, and might be more comfortable if we pointer out > > somewhere that > > > the REGISTER exchange does not provide this information, > but people > > > who want the information can use regevents or whatever > other method > > > seems appropriate to get the information that they want. > > > > > > But (Bernard and) I don't get to decide what working group > > consensus > > > is - we only get to recognize what consensus is, and when > it exists. > > > For that, we > > > need to hear from other participants (including you, of > > course - and > > > "thank you" to participants who care, and have expressed opinions > > > about this, in the current thread. > > > > > > I hope this is helpful. > > > > > > Thanks, > > > > > > Spencer > > > > > > ----- Original Message ----- > > > From: "Brian Lindsay" > > > To: "Spencer Dawkins" ; "Adam Roach" > > > ; "Paul Kyzivat" > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > Hi Spencer, > > > > > > So basically since the provisioning/sync of the E.164 > > > numbers/ranges is out of scope I don't see a strong argument for > > > including them in the registration transaction. The Service > > Provider > > > has a set of E.164 numbers that, based on prior > > > assignment/arrangement, it is responsible to route to the > > SIP PBX. The > > > SIP PBX is aware of these numbers already. > > > The registration process (using an AoR identifying the > SIP PBX) is > > > intended to provide reachability information for the SIP > > PBX, in the > > > absence of static IP address configuration / DNS (hence the > > ranges are > > > not actually required in this transaction). > > > > > > Thanks > > > Brian > > > > > > -----Original Message----- > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > Cc: Bernard Aboba; MARTINI > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > Hi, Brian, > > > > > > Just trying to stay synchronized here. > > > > > > Speaking as an individual, I think you're right about > provisioning > > > being out of scope, based on what I've been hearing on this > > list and > > > in telechats, etc. > > > > > > What I thought Adam was talking about isn't quite provisioning > > > (ignoring the question direction - I've heard some people > > suggest each > > > direction). > > > It was more like "I expect these numbers to be registered" > > and/or "I > > > registered these numbers on your behalf", with the > question of how > > > each end knows what numbers "should" be registered being > > out of scope > > > - because "knowing" was provisioned. > > > > > > At least, that's the context in which I was reading Adam's > > note below. > > > > > > Thanks, > > > > > > Spencer > > > > > > > > > > Hi, > > > > > > > > I think it's been stated many times in the threads that > > > E.164 number > > > > > > > provisioning between the enterprise and service provider > > is out of > > > > scope of MARTINI. So we're not using the register > transaction to > > > > perform any syncronization on these numbers betweeen the > > enterprise > > > > and service provider. The registration is just being used > > to provide > > > > reachability info, to allow requests to a set of E.164 > > numbers to be > > > > routed to the SIP PBX. As such, I don't think the number > > ranges need > > > > to be part of the registration transaction. It'll just > add extra > > > > complexity to the implementations. > > > > > > > > Regards > > > > Brian > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On > > > > Behalf Of Adam Roach > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > To: Paul Kyzivat > > > > Cc: Bernard Aboba; 'MARTINI' > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > procedure > > > > -- through a questionable use of P-Associated-URI -- to > > > indicate which > > > > > > > URIs the registrar would be registering on behalf of the > > > user. So even > > > > > > > the original 3GPP implicit approach had an enumeration of > > the AORs > > > > associated with the registration process. > > > > > > > > We're proposing to be even more sparse than that. Rather > > than just > > > > "implicit with a list of AORs," we're proposing "implicit > > with *no* > > > > list of AORs." > > > > > > > > So, even if your assertion that our allowing the implicit > > > mechanism to > > > > > > > stand is somehow tacit approval, what's being proposed > > here is even > > > > one step more nebulous. > > > > > > > > /a > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > >> Dean, > > > >> > > > >> In principle I agree with you. > > > >> But this horse is already out of the barn with IMS implicit > > > > registration. > > > >> > > > >> It was never explicitly brought to the ietf, though things > > > linked to > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > we could say > > > >> that is not our problem, I think we already implicitly > > approved it > > > >> via > > > > > > > >> benign neglect. > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >> Dean Willis wrote: > > > >>> > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > >>> > > > >>>> Speaking as co-chair, the non-registration aspects of > > DID number > > > >>>> mobility are outside the scope of the current MARTINI > > WG charter. > > > >>>> > > > >>>> The question on the table (see > > > >>>> > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > >>>> ) > > > > > > > >>>> is whether the registration aspects represent a > > > requirement or not. > > > >>>> Feel free > > > >>>> to respond and provide your opinion on that thread. > > > >>> > > > >>> Explicit is its own reward. > > > >>> > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > does is bind > > > >>> an > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact involved are > > > >>> explicitly encoded in the request. > > > >>> > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > to multiple > > > >>> Contacts. This seems like a reasonable extension to > > simplify life > > > >>> for > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > should respect > > > >>> the history of REGISTERs explicit encoding of the AORs > > > and Contacts > > > >>> involved. > > > >>> > > > >>> From a requirements perspective, I'd be happy with a > > requirement > > > >>> along the lines of "must not preclude AOR mobility > > > indicated by the > > > > > > >>> registration." I agree that we can't justify a requirement to > > > >>> produce > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > >>> > > > >>> -- > > > >>> 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 > > > > > _______________________________________________ > > 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 bernard_aboba@hotmail.com Wed Feb 17 06:55: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 DDCE13A797A for ; Wed, 17 Feb 2010 06:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.589, 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 KOYNAKW+btgm for ; Wed, 17 Feb 2010 06:55:00 -0800 (PST) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by core3.amsl.com (Postfix) with ESMTP id 519EC3A7710 for ; Wed, 17 Feb 2010 06:55:00 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.71]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 06:56:38 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Elwell, John'" , "'Adam Roach'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> In-Reply-To: Date: Wed, 17 Feb 2010 06:57:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAA9vuqA= Content-Language: en-us X-OriginalArrivalTime: 17 Feb 2010 14:56:38.0975 (UTC) FILETIME=[68885CF0:01CAAFE1] Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 14:55:01 -0000 A comment -- One might answer the question differently, depending on whether we're referring to: a. The common case (a successful REGISTER request/response) b. An error condition One might have a different answer depending on whether we're talking about REGISTER or reg-event. For example: For the REGISTER common case (where we'd like to optimize), my personal preference would be e). In the case of REGISTER response indicating an error, it would be useful to get some indication of what went wrong. In this situation, the information that is most useful is the list of numbers that were found to be in error (which might be a smaller set). Since those numbers might not be registerable even in single AOR registration, they can't enter the ACTIVE state and thus won't generate a reg-event. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Tuesday, February 16, 2010 11:36 PM To: Spencer Dawkins; Brian Lindsay; Adam Roach; Paul Kyzivat Cc: Bernard Aboba; MARTINI Subject: RE: [martini] DID Number Mobility and MARTINI So in trying to tease out whether there needs to be, as part of the MARTINI mechanism (as opposed to provisioning) an explicit list of numbers and/or contacts (I won't try to tie down which at present), I think it is important to understand which direction this is needed in, because that will go some way towards determining the mechanism. Do people think: a) there is good reason for providing this information in the direction SIP-PBX to SSP (in which case inclusion in a REGISTER request might be one solution); or b) there is a good reason for providing this information in the direction SSP to SIP-PBX (in which case reg-events might be one solution); or c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or d) there is a good reason for doing both; or e) there is no good reason to do either. My personal opinion is e), but I would like to hear other opinions, with reasons. John > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 16 February 2010 22:23 > To: Brian Lindsay; Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI > > Hi, Brian, > > Speaking carefully as chair, and Bernard can correct me if I > am saying > things I should not be saying as chair, at this point... > > I happen to agree with your reasoning, re: REGISTER. What I'm > trying to > tease out is whether we can just say "we're not providing > that information > in the REGISTER exchange, BUT you can get that information > using regevents", > so that we can move on - I haven't heard anyone propose that > MARTINI would > say "MUST NOT use regevents" :-) > > I would be comfortable if our specifications were silent on > this point, and > might be more comfortable if we pointer out somewhere that > the REGISTER > exchange does not provide this information, but people who want the > information can use regevents or whatever other method seems > appropriate to > get the information that they want. > > But (Bernard and) I don't get to decide what working group > consensus is - we > only get to recognize what consensus is, and when it exists. > For that, we > need to hear from other participants (including you, of > course - and "thank > you" to participants who care, and have expressed opinions > about this, in > the current thread. > > I hope this is helpful. > > Thanks, > > Spencer > > ----- Original Message ----- > From: "Brian Lindsay" > To: "Spencer Dawkins" ; "Adam Roach" > ; "Paul Kyzivat" > Cc: "Bernard Aboba" ; "MARTINI" > > Sent: Tuesday, February 16, 2010 3:51 PM > Subject: RE: [martini] DID Number Mobility and MARTINI > > > Hi Spencer, > > So basically since the provisioning/sync of the E.164 > numbers/ranges > is out of scope I don't see a strong argument for including > them in the > registration transaction. The Service Provider has a set of E.164 > numbers that, based on prior assignment/arrangement, it is responsible > to route to the SIP PBX. The SIP PBX is aware of these > numbers already. > The registration process (using an AoR identifying the SIP PBX) is > intended to provide reachability information for the SIP PBX, in the > absence of static IP address configuration / DNS (hence the ranges are > not actually required in this transaction). > > Thanks > Brian > > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Tuesday, February 16, 2010 4:37 PM > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI > > Hi, Brian, > > Just trying to stay synchronized here. > > Speaking as an individual, I think you're right about > provisioning being > out of scope, based on what I've been hearing on this list and in > telechats, etc. > > What I thought Adam was talking about isn't quite > provisioning (ignoring > the question direction - I've heard some people suggest each > direction). > It was more like "I expect these numbers to be registered" and/or "I > registered these numbers on your behalf", with the question > of how each > end knows what numbers "should" be registered being out of scope - > because "knowing" was provisioned. > > At least, that's the context in which I was reading Adam's note below. > > Thanks, > > Spencer > > > > Hi, > > > > I think it's been stated many times in the threads that > E.164 number > > > provisioning between the enterprise and service provider is out of > > scope of MARTINI. So we're not using the register transaction to > > perform any syncronization on these numbers betweeen the enterprise > > and service provider. The registration is just being used to provide > > reachability info, to allow requests to a set of E.164 numbers to be > > routed to the SIP PBX. As such, I don't think the number ranges need > > to be part of the registration transaction. It'll just add extra > > complexity to the implementations. > > > > Regards > > Brian > > > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > > Behalf Of Adam Roach > > Sent: Tuesday, February 16, 2010 1:39 PM > > To: Paul Kyzivat > > Cc: Bernard Aboba; 'MARTINI' > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > So, here's what I don't understand: 3GPP at least defined a > procedure > > -- through a questionable use of P-Associated-URI -- to > indicate which > > > URIs the registrar would be registering on behalf of the > user. So even > > > the original 3GPP implicit approach had an enumeration of the AORs > > associated with the registration process. > > > > We're proposing to be even more sparse than that. Rather than just > > "implicit with a list of AORs," we're proposing "implicit with *no* > > list of AORs." > > > > So, even if your assertion that our allowing the implicit > mechanism to > > > stand is somehow tacit approval, what's being proposed here is even > > one step more nebulous. > > > > /a > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > >> Dean, > >> > >> In principle I agree with you. > >> But this horse is already out of the barn with IMS implicit > > registration. > >> > >> It was never explicitly brought to the ietf, though things > linked to > >> it like P-Asserted-ID and P-Associated-URI were. While we could say > >> that is not our problem, I think we already implicitly approved it > >> via > > > >> benign neglect. > >> > >> Thanks, > >> Paul > >> > >> Dean Willis wrote: > >>> > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > >>> > >>>> Speaking as co-chair, the non-registration aspects of DID number > >>>> mobility are outside the scope of the current MARTINI WG charter. > >>>> > >>>> The question on the table (see > >>>> > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > >>>> ) > > > >>>> is whether the registration aspects represent a > requirement or not. > >>>> Feel free > >>>> to respond and provide your opinion on that thread. > >>> > >>> Explicit is its own reward. > >>> > >>> Remember, the one thing that RFC 3261 REGISTER really does is bind > >>> an > > > >>> AOR to a Contact. Both the AOR and the Contact involved are > >>> explicitly encoded in the request. > >>> > >>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple > >>> Contacts. This seems like a reasonable extension to simplify life > >>> for > > > >>> a "multi user" SIP user agent. But I really think we > should respect > >>> the history of REGISTERs explicit encoding of the AORs > and Contacts > >>> involved. > >>> > >>> From a requirements perspective, I'd be happy with a requirement > >>> along the lines of "must not preclude AOR mobility > indicated by the > > >>> registration." I agree that we can't justify a requirement to > >>> produce > > > >>> a mechanism at the time for the whole enchilada. > >>> > >>> -- > >>> 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 Wed Feb 17 07:05: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 D4C1E3A797A for ; Wed, 17 Feb 2010 07:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 BW74bFtaMBRv for ; Wed, 17 Feb 2010 07:05:34 -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 2C1263A773A for ; Wed, 17 Feb 2010 07:05:34 -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: Av0EAOOUe0tAZnwN/2dsb2JhbACPK4tXdKU7mAuEXQSDFQ X-IronPort-AV: E=Sophos;i="4.49,491,1262563200"; d="scan'208";a="86751009" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Feb 2010 15:07:12 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1HF7Cj9022746; Wed, 17 Feb 2010 15:07:12 GMT Message-ID: <4B7C061F.7060305@cisco.com> Date: Wed, 17 Feb 2010 10:07:11 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 15:05:36 -0000 John, I'm still not entirely decided on this. My inclination is (c), but I don't find the need to be compelling. I just share Dean and Adam's concern that implicit behavior is likely to come back and bite us. Thanks, Paul Elwell, John wrote: > So in trying to tease out whether there needs to be, as part of the MARTINI mechanism (as opposed to provisioning) an explicit list of numbers and/or contacts (I won't try to tie down which at present), I think it is important to understand which direction this is needed in, because that will go some way towards determining the mechanism. Do people think: > > a) there is good reason for providing this information in the direction SIP-PBX to SSP (in which case inclusion in a REGISTER request might be one solution); or > > b) there is a good reason for providing this information in the direction SSP to SIP-PBX (in which case reg-events might be one solution); or > > c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or > > d) there is a good reason for doing both; or > > e) there is no good reason to do either. > > My personal opinion is e), but I would like to hear other opinions, with reasons. > > John > > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins >> Sent: 16 February 2010 22:23 >> To: Brian Lindsay; Adam Roach; Paul Kyzivat >> Cc: Bernard Aboba; MARTINI >> Subject: Re: [martini] DID Number Mobility and MARTINI >> >> Hi, Brian, >> >> Speaking carefully as chair, and Bernard can correct me if I >> am saying >> things I should not be saying as chair, at this point... >> >> I happen to agree with your reasoning, re: REGISTER. What I'm >> trying to >> tease out is whether we can just say "we're not providing >> that information >> in the REGISTER exchange, BUT you can get that information >> using regevents", >> so that we can move on - I haven't heard anyone propose that >> MARTINI would >> say "MUST NOT use regevents" :-) >> >> I would be comfortable if our specifications were silent on >> this point, and >> might be more comfortable if we pointer out somewhere that >> the REGISTER >> exchange does not provide this information, but people who want the >> information can use regevents or whatever other method seems >> appropriate to >> get the information that they want. >> >> But (Bernard and) I don't get to decide what working group >> consensus is - we >> only get to recognize what consensus is, and when it exists. >> For that, we >> need to hear from other participants (including you, of >> course - and "thank >> you" to participants who care, and have expressed opinions >> about this, in >> the current thread. >> >> I hope this is helpful. >> >> Thanks, >> >> Spencer >> >> ----- Original Message ----- >> From: "Brian Lindsay" >> To: "Spencer Dawkins" ; "Adam Roach" >> ; "Paul Kyzivat" >> Cc: "Bernard Aboba" ; "MARTINI" >> >> Sent: Tuesday, February 16, 2010 3:51 PM >> Subject: RE: [martini] DID Number Mobility and MARTINI >> >> >> Hi Spencer, >> >> So basically since the provisioning/sync of the E.164 >> numbers/ranges >> is out of scope I don't see a strong argument for including >> them in the >> registration transaction. The Service Provider has a set of E.164 >> numbers that, based on prior assignment/arrangement, it is responsible >> to route to the SIP PBX. The SIP PBX is aware of these >> numbers already. >> The registration process (using an AoR identifying the SIP PBX) is >> intended to provide reachability information for the SIP PBX, in the >> absence of static IP address configuration / DNS (hence the ranges are >> not actually required in this transaction). >> >> Thanks >> Brian >> >> -----Original Message----- >> From: Spencer Dawkins [mailto:spencer@wonderhamster.org] >> Sent: Tuesday, February 16, 2010 4:37 PM >> To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat >> Cc: Bernard Aboba; MARTINI >> Subject: Re: [martini] DID Number Mobility and MARTINI >> >> Hi, Brian, >> >> Just trying to stay synchronized here. >> >> Speaking as an individual, I think you're right about >> provisioning being >> out of scope, based on what I've been hearing on this list and in >> telechats, etc. >> >> What I thought Adam was talking about isn't quite >> provisioning (ignoring >> the question direction - I've heard some people suggest each >> direction). >> It was more like "I expect these numbers to be registered" and/or "I >> registered these numbers on your behalf", with the question >> of how each >> end knows what numbers "should" be registered being out of scope - >> because "knowing" was provisioned. >> >> At least, that's the context in which I was reading Adam's note below. >> >> Thanks, >> >> Spencer >> >> >>> Hi, >>> >>> I think it's been stated many times in the threads that >> E.164 number >> >>> provisioning between the enterprise and service provider is out of >>> scope of MARTINI. So we're not using the register transaction to >>> perform any syncronization on these numbers betweeen the enterprise >>> and service provider. The registration is just being used to provide >>> reachability info, to allow requests to a set of E.164 numbers to be >>> routed to the SIP PBX. As such, I don't think the number ranges need >>> to be part of the registration transaction. It'll just add extra >>> complexity to the implementations. >>> >>> Regards >>> Brian >>> >>> -----Original Message----- >>> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >>> Behalf Of Adam Roach >>> Sent: Tuesday, February 16, 2010 1:39 PM >>> To: Paul Kyzivat >>> Cc: Bernard Aboba; 'MARTINI' >>> Subject: Re: [martini] DID Number Mobility and MARTINI >>> >>> So, here's what I don't understand: 3GPP at least defined a >> procedure >>> -- through a questionable use of P-Associated-URI -- to >> indicate which >> >>> URIs the registrar would be registering on behalf of the >> user. So even >> >>> the original 3GPP implicit approach had an enumeration of the AORs >>> associated with the registration process. >>> >>> We're proposing to be even more sparse than that. Rather than just >>> "implicit with a list of AORs," we're proposing "implicit with *no* >>> list of AORs." >>> >>> So, even if your assertion that our allowing the implicit >> mechanism to >> >>> stand is somehow tacit approval, what's being proposed here is even >>> one step more nebulous. >>> >>> /a >>> >>> On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: >>>> Dean, >>>> >>>> In principle I agree with you. >>>> But this horse is already out of the barn with IMS implicit >>> registration. >>>> It was never explicitly brought to the ietf, though things >> linked to >>>> it like P-Asserted-ID and P-Associated-URI were. While we could say >>>> that is not our problem, I think we already implicitly approved it >>>> via >>>> benign neglect. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Dean Willis wrote: >>>>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: >>>>> >>>>>> Speaking as co-chair, the non-registration aspects of DID number >>>>>> mobility are outside the scope of the current MARTINI WG charter. >>>>>> >>>>>> The question on the table (see >>>>>> >> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html >>>>>> ) >>>>>> is whether the registration aspects represent a >> requirement or not. >>>>>> Feel free >>>>>> to respond and provide your opinion on that thread. >>>>> Explicit is its own reward. >>>>> >>>>> Remember, the one thing that RFC 3261 REGISTER really does is bind >>>>> an >>>>> AOR to a Contact. Both the AOR and the Contact involved are >>>>> explicitly encoded in the request. >>>>> >>>>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple >>>>> Contacts. This seems like a reasonable extension to simplify life >>>>> for >>>>> a "multi user" SIP user agent. But I really think we >> should respect >>>>> the history of REGISTERs explicit encoding of the AORs >> and Contacts >>>>> involved. >>>>> >>>>> From a requirements perspective, I'd be happy with a requirement >>>>> along the lines of "must not preclude AOR mobility >> indicated by the >> >>>>> registration." I agree that we can't justify a requirement to >>>>> produce >>>>> a mechanism at the time for the whole enchilada. >>>>> >>>>> -- >>>>> 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 john.elwell@siemens-enterprise.com Wed Feb 17 07: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 8822128C0D8 for ; Wed, 17 Feb 2010 07:27:44 -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 J+qeszhI9k26 for ; Wed, 17 Feb 2010 07:27:43 -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 7231628B56A for ; Wed, 17 Feb 2010 07:27:42 -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-919762; Wed, 17 Feb 2010 16:29:20 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8A5661EB82AB; Wed, 17 Feb 2010 16:29:20 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 17 Feb 2010 16:29:20 +0100 From: "Elwell, John" To: Bernard Aboba , 'Adam Roach' Date: Wed, 17 Feb 2010 16:29:19 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAA9vuqAAAajSkA== Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.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' Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 15:27:44 -0000 =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: 17 February 2010 14:57 > To: Elwell, John; 'Adam Roach' > Cc: 'MARTINI' > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > A comment -- >=20 > One might answer the question differently, depending on whether we're > referring to: >=20 > a. The common case (a successful REGISTER request/response) > b. An error condition >=20 > One might have a different answer depending on whether we're=20 > talking about > REGISTER or reg-event.=20 >=20 > For example: >=20 > For the REGISTER common case (where we'd like to optimize),=20 > my personal > preference would be e). =20 >=20 > In the case of REGISTER response indicating an error, it=20 > would be useful to > get some indication of what went wrong. In this situation,=20 > the information > that is most useful is the list of numbers that were found to=20 > be in error > (which might be a smaller set).=20 [JRE] That pre-supposes an explicit list in the request, some numbers in th= e list being found to be in error. If the list is implicit, it seems likely= that the whole registration would either succeed or fail. I don't see why = an SSP, having been provisioned with a set of numbers assigned to the PBX, = would successfully register some and not others when the request has simply= asked for implicit registration of the whole lot. So my intention, when asking the question, was for an explicit list in the = successful case. Depending on what we agree on for that, we might then wish= to consider unsuccessful cases. John > Since those numbers might not be > registerable even in single AOR registration, they can't=20 > enter the ACTIVE > state and thus won't generate a reg-event.=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, February 16, 2010 11:36 PM > To: Spencer Dawkins; Brian Lindsay; Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > So in trying to tease out whether there needs to be, as part=20 > of the MARTINI > mechanism (as opposed to provisioning) an explicit list of=20 > numbers and/or > contacts (I won't try to tie down which at present), I think=20 > it is important > to understand which direction this is needed in, because that=20 > will go some > way towards determining the mechanism. Do people think: >=20 > a) there is good reason for providing this information in the=20 > direction > SIP-PBX to SSP (in which case inclusion in a REGISTER request=20 > might be one > solution); or >=20 > b) there is a good reason for providing this information in=20 > the direction > SSP to SIP-PBX (in which case reg-events might be one solution); or >=20 > c) it doesn't matter which direction - either direction would=20 > be good enough > so that at least one side is able to detect a discrepancy; or >=20 > d) there is a good reason for doing both; or >=20 > e) there is no good reason to do either. >=20 > My personal opinion is e), but I would like to hear other=20 > opinions, with > reasons. >=20 > John >=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > Sent: 16 February 2010 22:23 > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > Cc: Bernard Aboba; MARTINI > > Subject: Re: [martini] DID Number Mobility and MARTINI > >=20 > > Hi, Brian, > >=20 > > Speaking carefully as chair, and Bernard can correct me if I=20 > > am saying=20 > > things I should not be saying as chair, at this point... > >=20 > > I happen to agree with your reasoning, re: REGISTER. What I'm=20 > > trying to=20 > > tease out is whether we can just say "we're not providing=20 > > that information=20 > > in the REGISTER exchange, BUT you can get that information=20 > > using regevents",=20 > > so that we can move on - I haven't heard anyone propose that=20 > > MARTINI would=20 > > say "MUST NOT use regevents" :-) > >=20 > > I would be comfortable if our specifications were silent on=20 > > this point, and=20 > > might be more comfortable if we pointer out somewhere that=20 > > the REGISTER=20 > > exchange does not provide this information, but people who want the=20 > > information can use regevents or whatever other method seems=20 > > appropriate to=20 > > get the information that they want. > >=20 > > But (Bernard and) I don't get to decide what working group=20 > > consensus is - we=20 > > only get to recognize what consensus is, and when it exists.=20 > > For that, we=20 > > need to hear from other participants (including you, of=20 > > course - and "thank=20 > > you" to participants who care, and have expressed opinions=20 > > about this, in=20 > > the current thread. > >=20 > > I hope this is helpful. > >=20 > > Thanks, > >=20 > > Spencer > >=20 > > ----- Original Message -----=20 > > From: "Brian Lindsay" > > To: "Spencer Dawkins" ; "Adam Roach"=20 > > ; "Paul Kyzivat" > > Cc: "Bernard Aboba" ; "MARTINI"=20 > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > Subject: RE: [martini] DID Number Mobility and MARTINI > >=20 > >=20 > > Hi Spencer, > >=20 > > So basically since the provisioning/sync of the E.164=20 > > numbers/ranges > > is out of scope I don't see a strong argument for including=20 > > them in the > > registration transaction. The Service Provider has a set of E.164 > > numbers that, based on prior assignment/arrangement, it is=20 > responsible > > to route to the SIP PBX. The SIP PBX is aware of these=20 > > numbers already. > > The registration process (using an AoR identifying the SIP PBX) is > > intended to provide reachability information for the SIP PBX, in the > > absence of static IP address configuration / DNS (hence the=20 > ranges are > > not actually required in this transaction). > >=20 > > Thanks > > Brian > >=20 > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > Sent: Tuesday, February 16, 2010 4:37 PM > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > Cc: Bernard Aboba; MARTINI > > Subject: Re: [martini] DID Number Mobility and MARTINI > >=20 > > Hi, Brian, > >=20 > > Just trying to stay synchronized here. > >=20 > > Speaking as an individual, I think you're right about=20 > > provisioning being > > out of scope, based on what I've been hearing on this list and in > > telechats, etc. > >=20 > > What I thought Adam was talking about isn't quite=20 > > provisioning (ignoring > > the question direction - I've heard some people suggest each=20 > > direction). > > It was more like "I expect these numbers to be registered" and/or "I > > registered these numbers on your behalf", with the question=20 > > of how each > > end knows what numbers "should" be registered being out of scope - > > because "knowing" was provisioned. > >=20 > > At least, that's the context in which I was reading Adam's=20 > note below. > >=20 > > Thanks, > >=20 > > Spencer > >=20 > >=20 > > > Hi, > > > > > > I think it's been stated many times in the threads that=20 > > E.164 number > >=20 > > > provisioning between the enterprise and service provider is out of > > > scope of MARTINI. So we're not using the register transaction to > > > perform any syncronization on these numbers betweeen the=20 > enterprise > > > and service provider. The registration is just being used=20 > to provide > > > reachability info, to allow requests to a set of E.164=20 > numbers to be > > > routed to the SIP PBX. As such, I don't think the number=20 > ranges need > > > to be part of the registration transaction. It'll just add extra > > > complexity to the implementations. > > > > > > Regards > > > Brian > > > > > > -----Original Message----- > > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On > > > Behalf Of Adam Roach > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > To: Paul Kyzivat > > > Cc: Bernard Aboba; 'MARTINI' > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > So, here's what I don't understand: 3GPP at least defined a=20 > > procedure > > > -- through a questionable use of P-Associated-URI -- to=20 > > indicate which > >=20 > > > URIs the registrar would be registering on behalf of the=20 > > user. So even > >=20 > > > the original 3GPP implicit approach had an enumeration of the AORs > > > associated with the registration process. > > > > > > We're proposing to be even more sparse than that. Rather than just > > > "implicit with a list of AORs," we're proposing "implicit=20 > with *no* > > > list of AORs." > > > > > > So, even if your assertion that our allowing the implicit=20 > > mechanism to > >=20 > > > stand is somehow tacit approval, what's being proposed=20 > here is even > > > one step more nebulous. > > > > > > /a > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > >> Dean, > > >> > > >> In principle I agree with you. > > >> But this horse is already out of the barn with IMS implicit > > > registration. > > >> > > >> It was never explicitly brought to the ietf, though things=20 > > linked to > > >> it like P-Asserted-ID and P-Associated-URI were. While=20 > we could say > > >> that is not our problem, I think we already implicitly=20 > approved it > > >> via > > > > > >> benign neglect. > > >> > > >> Thanks, > > >> Paul > > >> > > >> Dean Willis wrote: > > >>> > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > >>> > > >>>> Speaking as co-chair, the non-registration aspects of=20 > DID number > > >>>> mobility are outside the scope of the current MARTINI=20 > WG charter. > > >>>> > > >>>> The question on the table (see > > >>>>=20 > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > >>>> ) > > > > > >>>> is whether the registration aspects represent a=20 > > requirement or not. > > >>>> Feel free > > >>>> to respond and provide your opinion on that thread. > > >>> > > >>> Explicit is its own reward. > > >>> > > >>> Remember, the one thing that RFC 3261 REGISTER really=20 > does is bind > > >>> an > > > > > >>> AOR to a Contact. Both the AOR and the Contact involved are > > >>> explicitly encoded in the request. > > >>> > > >>> I'm OKAY with extending REGISTER to bind multiple AORs=20 > to multiple > > >>> Contacts. This seems like a reasonable extension to=20 > simplify life > > >>> for > > > > > >>> a "multi user" SIP user agent. But I really think we=20 > > should respect > > >>> the history of REGISTERs explicit encoding of the AORs=20 > > and Contacts > > >>> involved. > > >>> > > >>> From a requirements perspective, I'd be happy with a=20 > requirement > > >>> along the lines of "must not preclude AOR mobility=20 > > indicated by the > >=20 > > >>> registration." I agree that we can't justify a requirement to > > >>> produce > > > > > >>> a mechanism at the time for the whole enchilada. > > >>> > > >>> -- > > >>> 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 > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 > = From john.elwell@siemens-enterprise.com Wed Feb 17 07:33: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 A2FA028B56A for ; Wed, 17 Feb 2010 07:33:13 -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 z446VLTdz1d0 for ; Wed, 17 Feb 2010 07:33: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 8C9183A797A for ; Wed, 17 Feb 2010 07:33: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-919514; Wed, 17 Feb 2010 16:34:49 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 887BD1EB82AB; Wed, 17 Feb 2010 16:34:49 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 17 Feb 2010 16:34:49 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Wed, 17 Feb 2010 16:34:47 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqv4uL8Q5YzXIuPReiGd1j/Gk8FwAAAyL8w Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C061F.7060305@cisco.com> In-Reply-To: <4B7C061F.7060305@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 Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 15:33:13 -0000 Paul, And if the need is not compelling, my concern is that we might introduce in= to the specification unnecessarily complications and unnecessary difference= s from the types of implementation already existing today, thereby imposing= greater costs on vendors and service providers considering upgrading their= equipment to be MARTINI (and SIPconnect 1.1) compliant. As you know, I vie= w things from the PBX side, and there (depending of course on the exact sol= ution adopted), the increment in implementation effort might not be so grea= t. Therefore I am somewhat neutral, but concerned to have something that ca= n easily be adopted by service providers. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 17 February 2010 15:07 > To: Elwell, John > Cc: Spencer Dawkins; Brian Lindsay; Adam Roach; Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > John, >=20 > I'm still not entirely decided on this. My inclination is (c), but I=20 > don't find the need to be compelling. I just share Dean and Adam's=20 > concern that implicit behavior is likely to come back and bite us. >=20 > Thanks, > Paul >=20 > Elwell, John wrote: > > So in trying to tease out whether there needs to be, as=20 > part of the MARTINI mechanism (as opposed to provisioning) an=20 > explicit list of numbers and/or contacts (I won't try to tie=20 > down which at present), I think it is important to understand=20 > which direction this is needed in, because that will go some=20 > way towards determining the mechanism. Do people think: > >=20 > > a) there is good reason for providing this information in=20 > the direction SIP-PBX to SSP (in which case inclusion in a=20 > REGISTER request might be one solution); or > >=20 > > b) there is a good reason for providing this information in=20 > the direction SSP to SIP-PBX (in which case reg-events might=20 > be one solution); or > >=20 > > c) it doesn't matter which direction - either direction=20 > would be good enough so that at least one side is able to=20 > detect a discrepancy; or > >=20 > > d) there is a good reason for doing both; or > >=20 > > e) there is no good reason to do either. > >=20 > > My personal opinion is e), but I would like to hear other=20 > opinions, with reasons. > >=20 > > John > >=20 > >=20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org=20 > >> [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > >> Sent: 16 February 2010 22:23 > >> To: Brian Lindsay; Adam Roach; Paul Kyzivat > >> Cc: Bernard Aboba; MARTINI > >> Subject: Re: [martini] DID Number Mobility and MARTINI > >> > >> Hi, Brian, > >> > >> Speaking carefully as chair, and Bernard can correct me if I=20 > >> am saying=20 > >> things I should not be saying as chair, at this point... > >> > >> I happen to agree with your reasoning, re: REGISTER. What I'm=20 > >> trying to=20 > >> tease out is whether we can just say "we're not providing=20 > >> that information=20 > >> in the REGISTER exchange, BUT you can get that information=20 > >> using regevents",=20 > >> so that we can move on - I haven't heard anyone propose that=20 > >> MARTINI would=20 > >> say "MUST NOT use regevents" :-) > >> > >> I would be comfortable if our specifications were silent on=20 > >> this point, and=20 > >> might be more comfortable if we pointer out somewhere that=20 > >> the REGISTER=20 > >> exchange does not provide this information, but people who=20 > want the=20 > >> information can use regevents or whatever other method seems=20 > >> appropriate to=20 > >> get the information that they want. > >> > >> But (Bernard and) I don't get to decide what working group=20 > >> consensus is - we=20 > >> only get to recognize what consensus is, and when it exists.=20 > >> For that, we=20 > >> need to hear from other participants (including you, of=20 > >> course - and "thank=20 > >> you" to participants who care, and have expressed opinions=20 > >> about this, in=20 > >> the current thread. > >> > >> I hope this is helpful. > >> > >> Thanks, > >> > >> Spencer > >> > >> ----- Original Message -----=20 > >> From: "Brian Lindsay" > >> To: "Spencer Dawkins" ; "Adam Roach"=20 > >> ; "Paul Kyzivat" > >> Cc: "Bernard Aboba" ; "MARTINI"=20 > >> > >> Sent: Tuesday, February 16, 2010 3:51 PM > >> Subject: RE: [martini] DID Number Mobility and MARTINI > >> > >> > >> Hi Spencer, > >> > >> So basically since the provisioning/sync of the E.164=20 > >> numbers/ranges > >> is out of scope I don't see a strong argument for including=20 > >> them in the > >> registration transaction. The Service Provider has a set of E.164 > >> numbers that, based on prior assignment/arrangement, it is=20 > responsible > >> to route to the SIP PBX. The SIP PBX is aware of these=20 > >> numbers already. > >> The registration process (using an AoR identifying the SIP PBX) is > >> intended to provide reachability information for the SIP=20 > PBX, in the > >> absence of static IP address configuration / DNS (hence=20 > the ranges are > >> not actually required in this transaction). > >> > >> Thanks > >> Brian > >> > >> -----Original Message----- > >> From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > >> Sent: Tuesday, February 16, 2010 4:37 PM > >> To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > >> Cc: Bernard Aboba; MARTINI > >> Subject: Re: [martini] DID Number Mobility and MARTINI > >> > >> Hi, Brian, > >> > >> Just trying to stay synchronized here. > >> > >> Speaking as an individual, I think you're right about=20 > >> provisioning being > >> out of scope, based on what I've been hearing on this list and in > >> telechats, etc. > >> > >> What I thought Adam was talking about isn't quite=20 > >> provisioning (ignoring > >> the question direction - I've heard some people suggest each=20 > >> direction). > >> It was more like "I expect these numbers to be registered"=20 > and/or "I > >> registered these numbers on your behalf", with the question=20 > >> of how each > >> end knows what numbers "should" be registered being out of scope - > >> because "knowing" was provisioned. > >> > >> At least, that's the context in which I was reading Adam's=20 > note below. > >> > >> Thanks, > >> > >> Spencer > >> > >> > >>> Hi, > >>> > >>> I think it's been stated many times in the threads that=20 > >> E.164 number > >> > >>> provisioning between the enterprise and service provider is out of > >>> scope of MARTINI. So we're not using the register transaction to > >>> perform any syncronization on these numbers betweeen the=20 > enterprise > >>> and service provider. The registration is just being used=20 > to provide > >>> reachability info, to allow requests to a set of E.164=20 > numbers to be > >>> routed to the SIP PBX. As such, I don't think the number=20 > ranges need > >>> to be part of the registration transaction. It'll just add extra > >>> complexity to the implementations. > >>> > >>> Regards > >>> Brian > >>> > >>> -----Original Message----- > >>> From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On > >>> Behalf Of Adam Roach > >>> Sent: Tuesday, February 16, 2010 1:39 PM > >>> To: Paul Kyzivat > >>> Cc: Bernard Aboba; 'MARTINI' > >>> Subject: Re: [martini] DID Number Mobility and MARTINI > >>> > >>> So, here's what I don't understand: 3GPP at least defined a=20 > >> procedure > >>> -- through a questionable use of P-Associated-URI -- to=20 > >> indicate which > >> > >>> URIs the registrar would be registering on behalf of the=20 > >> user. So even > >> > >>> the original 3GPP implicit approach had an enumeration of the AORs > >>> associated with the registration process. > >>> > >>> We're proposing to be even more sparse than that. Rather than just > >>> "implicit with a list of AORs," we're proposing "implicit=20 > with *no* > >>> list of AORs." > >>> > >>> So, even if your assertion that our allowing the implicit=20 > >> mechanism to > >> > >>> stand is somehow tacit approval, what's being proposed=20 > here is even > >>> one step more nebulous. > >>> > >>> /a > >>> > >>> On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > >>>> Dean, > >>>> > >>>> In principle I agree with you. > >>>> But this horse is already out of the barn with IMS implicit > >>> registration. > >>>> It was never explicitly brought to the ietf, though things=20 > >> linked to > >>>> it like P-Asserted-ID and P-Associated-URI were. While=20 > we could say > >>>> that is not our problem, I think we already implicitly=20 > approved it > >>>> via > >>>> benign neglect. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> Dean Willis wrote: > >>>>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > >>>>> > >>>>>> Speaking as co-chair, the non-registration aspects of=20 > DID number > >>>>>> mobility are outside the scope of the current MARTINI=20 > WG charter. > >>>>>> > >>>>>> The question on the table (see > >>>>>> > >> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > >>>>>> ) > >>>>>> is whether the registration aspects represent a=20 > >> requirement or not. > >>>>>> Feel free > >>>>>> to respond and provide your opinion on that thread. > >>>>> Explicit is its own reward. > >>>>> > >>>>> Remember, the one thing that RFC 3261 REGISTER really=20 > does is bind > >>>>> an > >>>>> AOR to a Contact. Both the AOR and the Contact involved are > >>>>> explicitly encoded in the request. > >>>>> > >>>>> I'm OKAY with extending REGISTER to bind multiple AORs=20 > to multiple > >>>>> Contacts. This seems like a reasonable extension to=20 > simplify life > >>>>> for > >>>>> a "multi user" SIP user agent. But I really think we=20 > >> should respect > >>>>> the history of REGISTERs explicit encoding of the AORs=20 > >> and Contacts > >>>>> involved. > >>>>> > >>>>> From a requirements perspective, I'd be happy with a=20 > requirement > >>>>> along the lines of "must not preclude AOR mobility=20 > >> indicated by the > >> > >>>>> registration." I agree that we can't justify a requirement to > >>>>> produce > >>>>> a mechanism at the time for the whole enchilada. > >>>>> > >>>>> -- > >>>>> 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 christer.holmberg@ericsson.com Wed Feb 17 08:24: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 EC7013A7D28 for ; Wed, 17 Feb 2010 08:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 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 bddSxByWe4La for ; Wed, 17 Feb 2010 08:24:04 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 36D8F28C105 for ; Wed, 17 Feb 2010 08:24:03 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-0c-4b7c188579ef Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 41.46.02429.5881C7B4; Wed, 17 Feb 2010 17:25:41 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 17 Feb 2010 17:25:41 +0100 From: Christer Holmberg To: "'Elwell, John'" , Spencer Dawkins , Brian Lindsay , Adam Roach , Paul Kyzivat Date: Wed, 17 Feb 2010 17:25:41 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggABMWZfA= Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.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: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 16:24:06 -0000 Hi John, When you say "explicit", do you exclude wildcarded values? Because, one may= think that we don't need explicit, but still wildcarded, or one may think = that we need neither. I really appretiate your questionairy, but to me it seems that we are discu= ssing protocol details when we aren't (at least I'm not) clear on the regis= tration structure itself :) For example, I think the answer one gives depends on whether one will use i= mplicit registrations or not. It may also depend on whether a PBX will be o= ne contact or many. I think we need to be clear on those issues first. Or, am I completely out = of line? :) Regards, Christer=20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Elwell, John Sent: 17. helmikuuta 2010 9:36 To: Spencer Dawkins; Brian Lindsay; Adam Roach; Paul Kyzivat Cc: Bernard Aboba; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI So in trying to tease out whether there needs to be, as part of the MARTINI= mechanism (as opposed to provisioning) an explicit list of numbers and/or = contacts (I won't try to tie down which at present), I think it is importan= t to understand which direction this is needed in, because that will go som= e way towards determining the mechanism. Do people think: a) there is good reason for providing this information in the direction SIP= -PBX to SSP (in which case inclusion in a REGISTER request might be one sol= ution); or b) there is a good reason for providing this information in the direction S= SP to SIP-PBX (in which case reg-events might be one solution); or c) it doesn't matter which direction - either direction would be good enoug= h so that at least one side is able to detect a discrepancy; or d) there is a good reason for doing both; or e) there is no good reason to do either. My personal opinion is e), but I would like to hear other opinions, with re= asons. John > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 16 February 2010 22:23 > To: Brian Lindsay; Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Hi, Brian, >=20 > Speaking carefully as chair, and Bernard can correct me if I am saying=20 > things I should not be saying as chair, at this point... >=20 > I happen to agree with your reasoning, re: REGISTER. What I'm trying=20 > to tease out is whether we can just say "we're not providing that=20 > information in the REGISTER exchange, BUT you can get that information=20 > using regevents", so that we can move on - I haven't heard anyone=20 > propose that MARTINI would say "MUST NOT use regevents" :-) >=20 > I would be comfortable if our specifications were silent on this=20 > point, and might be more comfortable if we pointer out somewhere that=20 > the REGISTER exchange does not provide this information, but people=20 > who want the information can use regevents or whatever other method=20 > seems appropriate to get the information that they want. >=20 > But (Bernard and) I don't get to decide what working group consensus=20 > is - we only get to recognize what consensus is, and when it exists. > For that, we > need to hear from other participants (including you, of course - and=20 > "thank you" to participants who care, and have expressed opinions=20 > about this, in the current thread. >=20 > I hope this is helpful. >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message ----- > From: "Brian Lindsay" > To: "Spencer Dawkins" ; "Adam Roach"=20 > ; "Paul Kyzivat" > Cc: "Bernard Aboba" ; "MARTINI"=20 > > Sent: Tuesday, February 16, 2010 3:51 PM > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 >=20 > Hi Spencer, >=20 > So basically since the provisioning/sync of the E.164=20 > numbers/ranges is out of scope I don't see a strong argument for=20 > including them in the registration transaction. The Service Provider=20 > has a set of E.164 numbers that, based on prior=20 > assignment/arrangement, it is responsible to route to the SIP PBX. The=20 > SIP PBX is aware of these numbers already. > The registration process (using an AoR identifying the SIP PBX) is=20 > intended to provide reachability information for the SIP PBX, in the=20 > absence of static IP address configuration / DNS (hence the ranges are=20 > not actually required in this transaction). >=20 > Thanks > Brian >=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Tuesday, February 16, 2010 4:37 PM > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Hi, Brian, >=20 > Just trying to stay synchronized here. >=20 > Speaking as an individual, I think you're right about provisioning=20 > being out of scope, based on what I've been hearing on this list and=20 > in telechats, etc. >=20 > What I thought Adam was talking about isn't quite provisioning=20 > (ignoring the question direction - I've heard some people suggest each=20 > direction). > It was more like "I expect these numbers to be registered" and/or "I=20 > registered these numbers on your behalf", with the question of how=20 > each end knows what numbers "should" be registered being out of scope=20 > - because "knowing" was provisioned. >=20 > At least, that's the context in which I was reading Adam's note below. >=20 > Thanks, >=20 > Spencer >=20 >=20 > > Hi, > > > > I think it's been stated many times in the threads that > E.164 number >=20 > > provisioning between the enterprise and service provider is out of=20 > > scope of MARTINI. So we're not using the register transaction to=20 > > perform any syncronization on these numbers betweeen the enterprise=20 > > and service provider. The registration is just being used to provide=20 > > reachability info, to allow requests to a set of E.164 numbers to be=20 > > routed to the SIP PBX. As such, I don't think the number ranges need=20 > > to be part of the registration transaction. It'll just add extra=20 > > complexity to the implementations. > > > > Regards > > Brian > > > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of Adam Roach > > Sent: Tuesday, February 16, 2010 1:39 PM > > To: Paul Kyzivat > > Cc: Bernard Aboba; 'MARTINI' > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > So, here's what I don't understand: 3GPP at least defined a > procedure > > -- through a questionable use of P-Associated-URI -- to > indicate which >=20 > > URIs the registrar would be registering on behalf of the > user. So even >=20 > > the original 3GPP implicit approach had an enumeration of the AORs=20 > > associated with the registration process. > > > > We're proposing to be even more sparse than that. Rather than just=20 > > "implicit with a list of AORs," we're proposing "implicit with *no*=20 > > list of AORs." > > > > So, even if your assertion that our allowing the implicit > mechanism to >=20 > > stand is somehow tacit approval, what's being proposed here is even=20 > > one step more nebulous. > > > > /a > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > >> Dean, > >> > >> In principle I agree with you. > >> But this horse is already out of the barn with IMS implicit > > registration. > >> > >> It was never explicitly brought to the ietf, though things > linked to > >> it like P-Asserted-ID and P-Associated-URI were. While we could say=20 > >> that is not our problem, I think we already implicitly approved it=20 > >> via > > > >> benign neglect. > >> > >> Thanks, > >> Paul > >> > >> Dean Willis wrote: > >>> > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > >>> > >>>> Speaking as co-chair, the non-registration aspects of DID number=20 > >>>> mobility are outside the scope of the current MARTINI WG charter. > >>>> > >>>> The question on the table (see > >>>>=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > >>>> ) > > > >>>> is whether the registration aspects represent a > requirement or not. > >>>> Feel free > >>>> to respond and provide your opinion on that thread. > >>> > >>> Explicit is its own reward. > >>> > >>> Remember, the one thing that RFC 3261 REGISTER really does is bind=20 > >>> an > > > >>> AOR to a Contact. Both the AOR and the Contact involved are=20 > >>> explicitly encoded in the request. > >>> > >>> I'm OKAY with extending REGISTER to bind multiple AORs to multiple=20 > >>> Contacts. This seems like a reasonable extension to simplify life=20 > >>> for > > > >>> a "multi user" SIP user agent. But I really think we > should respect > >>> the history of REGISTERs explicit encoding of the AORs > and Contacts > >>> involved. > >>> > >>> From a requirements perspective, I'd be happy with a requirement=20 > >>> along the lines of "must not preclude AOR mobility > indicated by the >=20 > >>> registration." I agree that we can't justify a requirement to=20 > >>> produce > > > >>> a mechanism at the time for the whole enchilada. > >>> > >>> -- > >>> 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 >=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 Wed Feb 17 08:25: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 E2FAB3A7D1C for ; Wed, 17 Feb 2010 08:25:19 -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 m156vjaEZrfH for ; Wed, 17 Feb 2010 08:25:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id AEAA63A7B5D for ; Wed, 17 Feb 2010 08:25:17 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C646D2AC9B0; Wed, 17 Feb 2010 17:26:55 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id BB7931801D1; Wed, 17 Feb 2010 15: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); Wed, 17 Feb 2010 15: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: Wed, 17 Feb 2010 15:29:08 +0100 Message-ID: <9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1g References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> From: To: , , , , X-OriginalArrivalTime: 17 Feb 2010 14:29:14.0674 (UTC) FILETIME=[9473F120:01CAAFDD] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.17.135416 Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 16:25:20 -0000 A good solution should work irrespective of which proxy is responsibile for= asserting identities, including the case where this is the edge proxy. > -----Message d'origine----- > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 > =C0 : CHATRAS Bruno RD-CORE-ISS; spencer@wonderhamster.org;=20 > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > Cc : bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] DID Number Mobility and MARTINI >=20 > Bruno, >=20 > Thanks. However, this particular reason for a proxy needing=20 > this information is because of an architecture where the=20 > proxy is assigned responsibility for asserting an identity=20 > for the source of a request. If the domain proxy takes on=20 > this responsibility instead, problem solved. So it is a=20 > question of whether this particular architecture is common=20 > enough that we need a solution that conveys registered=20 > identities to the edge proxy. IMS solves this using PAU=20 > (ignoring issues of response size), so the question for=20 > others is whether there are other architectures in practice=20 > where this is important. I guess for this particular usage it=20 > doesn't matter whether the information is in the REGISTER=20 > request or the REGISTER response. >=20 > John >=20=20 >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com=20 > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: 17 February 2010 12:45 > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > adam@nostrum.com; pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > >=20 > > My view is that there is no strong need need for carrying this=20 > > information accross the SIP-PBX - SSP interface. However this=20 > > information needs to be provided by the SSP's Registrar to=20 > the SSP's=20 > > edge proxy so as to enable the edge proxy to assert identities=20 > > received from the PBX in a P-Preferred-Identity header field. > >=20 > > > -----Message d'origine----- > > > De : martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] De la part de Elwell,=20 > John Envoy=E9=20 > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins;=20 > Brian Lindsay;=20 > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re:=20 > > > [martini] DID Number Mobility and MARTINI > > >=20 > > > So in trying to tease out whether there needs to be, as=20 > part of the=20 > > > MARTINI mechanism (as opposed to provisioning) an=20 > explicit list of=20 > > > numbers and/or contacts (I won't try to tie down which at=20 > present),=20 > > > I think it is important to understand which direction=20 > this is needed=20 > > > in, because that will go some way towards determining the=20 > mechanism.=20 > > > Do people think: > > >=20 > > > a) there is good reason for providing this information in the=20 > > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER=20 > > > request might be one solution); or > > >=20 > > > b) there is a good reason for providing this information in the=20 > > > direction SSP to SIP-PBX (in which case reg-events might be one=20 > > > solution); or > > >=20 > > > c) it doesn't matter which direction - either direction would be=20 > > > good enough so that at least one side is able to detect a=20 > > > discrepancy; or > > >=20 > > > d) there is a good reason for doing both; or > > >=20 > > > e) there is no good reason to do either. > > >=20 > > > My personal opinion is e), but I would like to hear other=20 > opinions,=20 > > > with reasons. > > >=20 > > > John > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > > Sent: 16 February 2010 22:23 > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > Cc: Bernard Aboba; MARTINI > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > >=20 > > > > Hi, Brian, > > > >=20 > > > > Speaking carefully as chair, and Bernard can correct me if > > > I am saying > > > > things I should not be saying as chair, at this point... > > > >=20 > > > > I happen to agree with your reasoning, re: REGISTER. What > > > I'm trying > > > > to tease out is whether we can just say "we're not=20 > providing that=20 > > > > information in the REGISTER exchange, BUT you can get that > > > information > > > > using regevents", so that we can move on - I haven't=20 > heard anyone=20 > > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > >=20 > > > > I would be comfortable if our specifications were=20 > silent on this=20 > > > > point, and might be more comfortable if we pointer out > > > somewhere that > > > > the REGISTER exchange does not provide this information, > > but people > > > > who want the information can use regevents or whatever > > other method > > > > seems appropriate to get the information that they want. > > > >=20 > > > > But (Bernard and) I don't get to decide what working group > > > consensus > > > > is - we only get to recognize what consensus is, and when > > it exists. > > > > For that, we > > > > need to hear from other participants (including you, of > > > course - and > > > > "thank you" to participants who care, and have=20 > expressed opinions=20 > > > > about this, in the current thread. > > > >=20 > > > > I hope this is helpful. > > > >=20 > > > > Thanks, > > > >=20 > > > > Spencer > > > >=20 > > > > ----- Original Message ----- > > > > From: "Brian Lindsay" > > > > To: "Spencer Dawkins" ; "Adam Roach"=20 > > > > ; "Paul Kyzivat" > > > > Cc: "Bernard Aboba" ; "MARTINI"=20 > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > >=20 > > > >=20 > > > > Hi Spencer, > > > >=20 > > > > So basically since the provisioning/sync of the E.164=20 > > > > numbers/ranges is out of scope I don't see a strong=20 > argument for=20 > > > > including them in the registration transaction. The Service > > > Provider > > > > has a set of E.164 numbers that, based on prior=20 > > > > assignment/arrangement, it is responsible to route to the > > > SIP PBX. The > > > > SIP PBX is aware of these numbers already. > > > > The registration process (using an AoR identifying the > > SIP PBX) is > > > > intended to provide reachability information for the SIP > > > PBX, in the > > > > absence of static IP address configuration / DNS (hence the > > > ranges are > > > > not actually required in this transaction). > > > >=20 > > > > Thanks > > > > Brian > > > >=20 > > > > -----Original Message----- > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > Cc: Bernard Aboba; MARTINI > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > >=20 > > > > Hi, Brian, > > > >=20 > > > > Just trying to stay synchronized here. > > > >=20 > > > > Speaking as an individual, I think you're right about > > provisioning > > > > being out of scope, based on what I've been hearing on this > > > list and > > > > in telechats, etc. > > > >=20 > > > > What I thought Adam was talking about isn't quite provisioning=20 > > > > (ignoring the question direction - I've heard some people > > > suggest each > > > > direction). > > > > It was more like "I expect these numbers to be registered"=20 > > > and/or "I > > > > registered these numbers on your behalf", with the > > question of how > > > > each end knows what numbers "should" be registered being > > > out of scope > > > > - because "knowing" was provisioned. > > > >=20 > > > > At least, that's the context in which I was reading Adam's > > > note below. > > > >=20 > > > > Thanks, > > > >=20 > > > > Spencer > > > >=20 > > > >=20 > > > > > Hi, > > > > > > > > > > I think it's been stated many times in the threads that > > > > E.164 number > > > >=20 > > > > > provisioning between the enterprise and service provider > > > is out of > > > > > scope of MARTINI. So we're not using the register > > transaction to > > > > > perform any syncronization on these numbers betweeen the > > > enterprise > > > > > and service provider. The registration is just being used > > > to provide > > > > > reachability info, to allow requests to a set of E.164 > > > numbers to be > > > > > routed to the SIP PBX. As such, I don't think the number > > > ranges need > > > > > to be part of the registration transaction. It'll just > > add extra > > > > > complexity to the implementations. > > > > > > > > > > Regards > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On > > > > > Behalf Of Adam Roach > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > To: Paul Kyzivat > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > > procedure > > > > > -- through a questionable use of P-Associated-URI -- to > > > > indicate which > > > >=20 > > > > > URIs the registrar would be registering on behalf of the > > > > user. So even > > > >=20 > > > > > the original 3GPP implicit approach had an enumeration of > > > the AORs > > > > > associated with the registration process. > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > than just > > > > > "implicit with a list of AORs," we're proposing "implicit > > > with *no* > > > > > list of AORs." > > > > > > > > > > So, even if your assertion that our allowing the implicit > > > > mechanism to > > > >=20 > > > > > stand is somehow tacit approval, what's being proposed > > > here is even > > > > > one step more nebulous. > > > > > > > > > > /a > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > >> Dean, > > > > >> > > > > >> In principle I agree with you. > > > > >> But this horse is already out of the barn with IMS implicit > > > > > registration. > > > > >> > > > > >> It was never explicitly brought to the ietf, though things > > > > linked to > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > we could say > > > > >> that is not our problem, I think we already implicitly > > > approved it > > > > >> via > > > > > > > > > >> benign neglect. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >> Dean Willis wrote: > > > > >>> > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > >>> > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > DID number > > > > >>>> mobility are outside the scope of the current MARTINI > > > WG charter. > > > > >>>> > > > > >>>> The question on the table (see > > > > >>>>=20 > > > >=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > >>>> ) > > > > > > > > > >>>> is whether the registration aspects represent a > > > > requirement or not. > > > > >>>> Feel free > > > > >>>> to respond and provide your opinion on that thread. > > > > >>> > > > > >>> Explicit is its own reward. > > > > >>> > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > does is bind > > > > >>> an > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact=20 > involved are=20 > > > > >>> explicitly encoded in the request. > > > > >>> > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > to multiple > > > > >>> Contacts. This seems like a reasonable extension to > > > simplify life > > > > >>> for > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > should respect > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > and Contacts > > > > >>> involved. > > > > >>> > > > > >>> From a requirements perspective, I'd be happy with a > > > requirement > > > > >>> along the lines of "must not preclude AOR mobility > > > > indicated by the > > > >=20 > > > > >>> registration." I agree that we can't justify a=20 > requirement to=20 > > > > >>> produce > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > >>> > > > > >>> -- > > > > >>> 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 > > > >=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=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 > >=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 Wed Feb 17 08:26: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 AE64128C105 for ; Wed, 17 Feb 2010 08:26:45 -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, 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 HJ9U9vpOIiS0 for ; Wed, 17 Feb 2010 08:26: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 77E2828C0D8 for ; Wed, 17 Feb 2010 08:26:44 -0800 (PST) Received: from dn3-211.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o1HGSJkJ057607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Feb 2010 10:28:19 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7C1923.2020506@nostrum.com> Date: Wed, 17 Feb 2010 10:28: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: "Elwell, John" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050301070100000902070807" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 16:26:45 -0000 This is a multi-part message in MIME format. --------------050301070100000902070807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/17/10 1:35 AM, Elwell, John wrote: > c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or > I think you overspecified this option. I'm happy with the assertion that "it doesn't matter which direction," but the additional text implies that this is only being done for discrepancy detection. Which tells me that you aren't following the entire conversation. But you're clearly not the only one. There are at least three /very different/ reasons people have raised (and a fourth, completely fallacious red herring that the opposition has been using as a strawman to tear apart) for including this information: 1. Specification, by the PBX, of the (sub)set of E.164 numbers it wants this registration to apply to, 2. Indication to the intermediaries of which E.164 numbers the registration applies to, and 3. Detection of mismatched provisioning between the PBX and the SSP. The fourth thing, which no one has proposed, but which many detractors have set up as a wholly bogus strawman, is using this information to provision the PBX. No one wants that. No one has proposed that. We can stop arguing against it because no one is defending it. We all agree that this is not done in SIP. /a --------------050301070100000902070807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/17/10 1:35 AM, Elwell, John wrote: 
c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or

I think you overspecified this option. I'm happy with the assertion that "it doesn't matter which direction," but the additional text implies that this is only being done for discrepancy detection.

Which tells me that you aren't following the entire conversation. But you're clearly not the only one.

There are at least three very different reasons people have raised (and a fourth, completely fallacious red herring that the opposition has been using as a strawman to tear apart) for including this information:

  1. Specification, by the PBX, of the (sub)set of E.164 numbers it wants this registration to apply to,
  2. Indication to the intermediaries of which E.164 numbers the registration applies to, and
  3. Detection of mismatched provisioning between the PBX and the SSP.
The fourth thing, which no one has proposed, but which many detractors have set up as a wholly bogus strawman, is using this information to provision the PBX. No one wants that. No one has proposed that. We can stop arguing against it because no one is defending it. We all agree that this is not done in SIP.

/a
--------------050301070100000902070807-- From john.elwell@siemens-enterprise.com Wed Feb 17 09:03: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 0725528C0E7 for ; Wed, 17 Feb 2010 09:03:21 -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.043, 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 ci9prqGYzIt0 for ; Wed, 17 Feb 2010 09:03:20 -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 BEC3028C102 for ; Wed, 17 Feb 2010 09:03:19 -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-921460; Wed, 17 Feb 2010 18:04:57 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8C6B623F028E; Wed, 17 Feb 2010 18:04:57 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 17 Feb 2010 18:04:57 +0100 From: "Elwell, John" To: Christer Holmberg , Spencer Dawkins , Brian Lindsay , Adam Roach , Paul Kyzivat Date: Wed, 17 Feb 2010 18:04:56 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggABMWZfAAAUESYA== Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.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: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 17:03:21 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 17 February 2010 16:26 > To: Elwell, John; Spencer Dawkins; Brian Lindsay; Adam Roach;=20 > Paul Kyzivat > Cc: Bernard Aboba; MARTINI > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 >=20 > Hi John, >=20 > When you say "explicit", do you exclude wildcarded values?=20 > Because, one may think that we don't need explicit, but still=20 > wildcarded, or one may think that we need neither. [JRE] Wildcarded is still explicit - just a different syntax. This assumes = of course that the intention is to register EVERY number in a wildcarded ra= nge (not just an implicit subset that the SSP is expected to know in advanc= e). >=20 > I really appretiate your questionairy, but to me it seems=20 > that we are discussing protocol details when we aren't (at=20 > least I'm not) clear on the registration structure itself :) >=20 > For example, I think the answer one gives depends on whether=20 > one will use implicit registrations or not. It may also=20 > depend on whether a PBX will be one contact or many. >=20 > I think we need to be clear on those issues first. Or, am I=20 > completely out of line? :) [JRE] My attempt was to try to bring us back to requirements before discuss= ion of protocol details, so the questions are pretty much agnostic to which= messages are used (e.g., whether REGISTER, NOTIFY or PUBLISH, or whether r= equest or response). Instead I am trying to focus on direction, i.e., is th= ere a compelling reason why the PBX needs to receive an explicit list, is t= here a compelling reason why the SSP needs to receive an explicit list, is = there a compelling reason why an intermediary (edge proxy) needs to receive= an explicit list? John From john.elwell@siemens-enterprise.com Wed Feb 17 09:03: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 02F7628C0E7 for ; Wed, 17 Feb 2010 09:03:46 -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 W5kLiRGn974d for ; Wed, 17 Feb 2010 09:03:44 -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 6F15328C102 for ; Wed, 17 Feb 2010 09:03:43 -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-921467; Wed, 17 Feb 2010 18:05:22 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 8DC0E23F028E; Wed, 17 Feb 2010 18:05:22 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 17 Feb 2010 18:05:22 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "blindsay@nortel.com" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Wed, 17 Feb 2010 18:05:20 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTA= Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@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: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 17:03:46 -0000 Bruno, This depends whether we have a requirement for an edge proxy to be able to = base identity assertions for outbound (non-REGISTER) requests on whether th= e identity concerned has been registered. We don't have such a requirement = at present, so if you think we need such a requirement, please propose text= for the requirements document. John > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: 17 February 2010 14:29 > To: Elwell, John; spencer@wonderhamster.org; > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI > > A good solution should work irrespective of which proxy is > responsibile for asserting identities, including the case > where this is the edge proxy. > > > -----Message d'origine----- > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 > > =C0 : CHATRAS Bruno RD-CORE-ISS; spencer@wonderhamster.org; > > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > > Cc : bernard_aboba@hotmail.com; martini@ietf.org > > Objet : RE: [martini] DID Number Mobility and MARTINI > > > > Bruno, > > > > Thanks. However, this particular reason for a proxy needing > > this information is because of an architecture where the > > proxy is assigned responsibility for asserting an identity > > for the source of a request. If the domain proxy takes on > > this responsibility instead, problem solved. So it is a > > question of whether this particular architecture is common > > enough that we need a solution that conveys registered > > identities to the edge proxy. IMS solves this using PAU > > (ignoring issues of response size), so the question for > > others is whether there are other architectures in practice > > where this is important. I guess for this particular usage it > > doesn't matter whether the information is in the REGISTER > > request or the REGISTER response. > > > > John > > > > > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 17 February 2010 12:45 > > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com; > > > adam@nostrum.com; pkyzivat@cisco.com > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > My view is that there is no strong need need for carrying this > > > information accross the SIP-PBX - SSP interface. However this > > > information needs to be provided by the SSP's Registrar to > > the SSP's > > > edge proxy so as to enable the edge proxy to assert identities > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > -----Message d'origine----- > > > > De : martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > John Envoy=E9 > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > Brian Lindsay; > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > Objet : Re: > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > So in trying to tease out whether there needs to be, as > > part of the > > > > MARTINI mechanism (as opposed to provisioning) an > > explicit list of > > > > numbers and/or contacts (I won't try to tie down which at > > present), > > > > I think it is important to understand which direction > > this is needed > > > > in, because that will go some way towards determining the > > mechanism. > > > > Do people think: > > > > > > > > a) there is good reason for providing this information in the > > > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER > > > > request might be one solution); or > > > > > > > > b) there is a good reason for providing this information in the > > > > direction SSP to SIP-PBX (in which case reg-events might be one > > > > solution); or > > > > > > > > c) it doesn't matter which direction - either direction > would be > > > > good enough so that at least one side is able to detect a > > > > discrepancy; or > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > e) there is no good reason to do either. > > > > > > > > My personal opinion is e), but I would like to hear other > > opinions, > > > > with reasons. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: martini-bounces@ietf.org > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > > > Sent: 16 February 2010 22:23 > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > Cc: Bernard Aboba; MARTINI > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > Hi, Brian, > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > I am saying > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > I'm trying > > > > > to tease out is whether we can just say "we're not > > providing that > > > > > information in the REGISTER exchange, BUT you can get that > > > > information > > > > > using regevents", so that we can move on - I haven't > > heard anyone > > > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > > > > > > > > I would be comfortable if our specifications were > > silent on this > > > > > point, and might be more comfortable if we pointer out > > > > somewhere that > > > > > the REGISTER exchange does not provide this information, > > > but people > > > > > who want the information can use regevents or whatever > > > other method > > > > > seems appropriate to get the information that they want. > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > consensus > > > > > is - we only get to recognize what consensus is, and when > > > it exists. > > > > > For that, we > > > > > need to hear from other participants (including you, of > > > > course - and > > > > > "thank you" to participants who care, and have > > expressed opinions > > > > > about this, in the current thread. > > > > > > > > > > I hope this is helpful. > > > > > > > > > > Thanks, > > > > > > > > > > Spencer > > > > > > > > > > ----- Original Message ----- > > > > > From: "Brian Lindsay" > > > > > To: "Spencer Dawkins" ; > "Adam Roach" > > > > > ; "Paul Kyzivat" > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > So basically since the provisioning/sync of the E.164 > > > > > numbers/ranges is out of scope I don't see a strong > > argument for > > > > > including them in the registration transaction. The Service > > > > Provider > > > > > has a set of E.164 numbers that, based on prior > > > > > assignment/arrangement, it is responsible to route to the > > > > SIP PBX. The > > > > > SIP PBX is aware of these numbers already. > > > > > The registration process (using an AoR identifying the > > > SIP PBX) is > > > > > intended to provide reachability information for the SIP > > > > PBX, in the > > > > > absence of static IP address configuration / DNS (hence the > > > > ranges are > > > > > not actually required in this transaction). > > > > > > > > > > Thanks > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > Cc: Bernard Aboba; MARTINI > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > Hi, Brian, > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > Speaking as an individual, I think you're right about > > > provisioning > > > > > being out of scope, based on what I've been hearing on this > > > > list and > > > > > in telechats, etc. > > > > > > > > > > What I thought Adam was talking about isn't quite > provisioning > > > > > (ignoring the question direction - I've heard some people > > > > suggest each > > > > > direction). > > > > > It was more like "I expect these numbers to be registered" > > > > and/or "I > > > > > registered these numbers on your behalf", with the > > > question of how > > > > > each end knows what numbers "should" be registered being > > > > out of scope > > > > > - because "knowing" was provisioned. > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > note below. > > > > > > > > > > Thanks, > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I think it's been stated many times in the threads that > > > > > E.164 number > > > > > > > > > > > provisioning between the enterprise and service provider > > > > is out of > > > > > > scope of MARTINI. So we're not using the register > > > transaction to > > > > > > perform any syncronization on these numbers betweeen the > > > > enterprise > > > > > > and service provider. The registration is just being used > > > > to provide > > > > > > reachability info, to allow requests to a set of E.164 > > > > numbers to be > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > ranges need > > > > > > to be part of the registration transaction. It'll just > > > add extra > > > > > > complexity to the implementations. > > > > > > > > > > > > Regards > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] On > > > > > > Behalf Of Adam Roach > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > To: Paul Kyzivat > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > > > procedure > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > indicate which > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > user. So even > > > > > > > > > > > the original 3GPP implicit approach had an enumeration of > > > > the AORs > > > > > > associated with the registration process. > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > than just > > > > > > "implicit with a list of AORs," we're proposing "implicit > > > > with *no* > > > > > > list of AORs." > > > > > > > > > > > > So, even if your assertion that our allowing the implicit > > > > > mechanism to > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > here is even > > > > > > one step more nebulous. > > > > > > > > > > > > /a > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > >> Dean, > > > > > >> > > > > > >> In principle I agree with you. > > > > > >> But this horse is already out of the barn with IMS implicit > > > > > > registration. > > > > > >> > > > > > >> It was never explicitly brought to the ietf, though things > > > > > linked to > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > we could say > > > > > >> that is not our problem, I think we already implicitly > > > > approved it > > > > > >> via > > > > > > > > > > > >> benign neglect. > > > > > >> > > > > > >> Thanks, > > > > > >> Paul > > > > > >> > > > > > >> Dean Willis wrote: > > > > > >>> > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > >>> > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > DID number > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > WG charter. > > > > > >>>> > > > > > >>>> The question on the table (see > > > > > >>>> > > > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > >>>> ) > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > requirement or not. > > > > > >>>> Feel free > > > > > >>>> to respond and provide your opinion on that thread. > > > > > >>> > > > > > >>> Explicit is its own reward. > > > > > >>> > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > does is bind > > > > > >>> an > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > involved are > > > > > >>> explicitly encoded in the request. > > > > > >>> > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > to multiple > > > > > >>> Contacts. This seems like a reasonable extension to > > > > simplify life > > > > > >>> for > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > should respect > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > and Contacts > > > > > >>> involved. > > > > > >>> > > > > > >>> From a requirements perspective, I'd be happy with a > > > > requirement > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > indicated by the > > > > > > > > > > >>> registration." I agree that we can't justify a > > requirement to > > > > > >>> produce > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > >>> > > > > > >>> -- > > > > > >>> 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 > > > > > > > > > _______________________________________________ > > > > 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. > ******************************** > > From john.elwell@siemens-enterprise.com Wed Feb 17 09:12: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 ED1D43A79AD for ; Wed, 17 Feb 2010 09:12:29 -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 xxN2yF2PdjUv for ; Wed, 17 Feb 2010 09:12:28 -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 0CF563A71A6 for ; Wed, 17 Feb 2010 09:12:27 -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-921343; Wed, 17 Feb 2010 18:14:06 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 9BB4A23F0278; Wed, 17 Feb 2010 18:14:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 17 Feb 2010 18:14:06 +0100 From: "Elwell, John" To: Adam Roach Date: Wed, 17 Feb 2010 18:14:05 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqv7j/v0gvfJ1v1S2GYG8RexJX/fwABS7Iw Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> In-Reply-To: <4B7C1923.2020506@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 Subject: Re: [martini] DID Number Mobility and 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: Wed, 17 Feb 2010 17:12:30 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 17 February 2010 16:28 > To: Elwell, John > Cc: Spencer Dawkins; Brian Lindsay; Paul Kyzivat; Bernard=20 > Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > On 2/17/10 1:35 AM, Elwell, John wrote:=20 >=20 > c) it doesn't matter which direction - either direction=20 > would be good enough so that at least one side is able to=20 > detect a discrepancy; or > =20 >=20 >=20 > I think you overspecified this option. I'm happy with the=20 > assertion that "it doesn't matter which direction," but the=20 > additional text implies that this is only being done for=20 > discrepancy detection. [JRE] I agree. >=20 > Which tells me that you aren't following the entire=20 > conversation. But you're clearly not the only one. [JRE] It was a mistake to add that to c). >=20 > There are at least three very different reasons people have=20 > raised (and a fourth, completely fallacious red herring that=20 > the opposition has been using as a strawman to tear apart)=20 > for including this information: >=20 >=20 >=20 > 1. Specification, by the PBX, of the (sub)set of E.164=20 > numbers it wants this registration to apply to,=20 > 2. Indication to the intermediaries of which E.164 numbers=20 > the registration applies to, and > =09 > 3. Detection of mismatched provisioning between the PBX=20 > and the SSP.=20 [JRE] Some people are saying they are just uncomfortable with "implicit", s= o I am trying to determine in what direction they are trying to be "explici= t". So true, I guess I was focusing on 3, and whether such mismatches need = to be detected at the SIP-PBX or at the SSP. Clearly 1 would lead people to= answer that they need the explicit indication in the direction PBX to SSP= , whereas 2 would work with an explicit indication in either direction. May= be my way of trying to tease out requirements wasn't the best, and thanks f= or re-iterating the issues discussed. John >=20 > The fourth thing, which no one has proposed, but which many=20 > detractors have set up as a wholly bogus strawman, is using=20 > this information to provision the PBX. No one wants that. No=20 > one has proposed that. We can stop arguing against it because=20 > no one is defending it. We all agree that this is not done in SIP. >=20 > /a >=20 > = From keith.drage@alcatel-lucent.com Wed Feb 17 18:07: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 A7BDB28C2B8 for ; Wed, 17 Feb 2010 18:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-1.605, 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 uxlviKqz2wDF for ; Wed, 17 Feb 2010 18:07:13 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id C27C328C2B0 for ; Wed, 17 Feb 2010 18:07:12 -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.14.3/8.14.3/ICT) with ESMTP id o1I28eV8031833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Feb 2010 03:08:40 +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, 18 Feb 2010 03:08:40 +0100 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "blindsay@nortel.com" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Thu, 18 Feb 2010 03:08:38 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AAX0NXg Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 02:07:14 -0000 Correction: IMS solves this using a combination of P-Associated-URI and reg= event. This is because registered values can be deregistered by the SSP du= e to internal causes, and therefore when there is not a response to send to= a REGISTER request. But I do agree that the only interesting part of the problem is if it needs= to go outside the SSP domain. regards Keith > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Wednesday, February 17, 2010 1:37 PM > To: bruno.chatras@orange-ftgroup.com; > spencer@wonderhamster.org; blindsay@nortel.com; > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: Re: [martini] DID Number Mobility and MARTINI > > Bruno, > > Thanks. However, this particular reason for a proxy needing > this information is because of an architecture where the > proxy is assigned responsibility for asserting an identity > for the source of a request. If the domain proxy takes on > this responsibility instead, problem solved. So it is a > question of whether this particular architecture is common > enough that we need a solution that conveys registered > identities to the edge proxy. IMS solves this using PAU > (ignoring issues of response size), so the question for > others is whether there are other architectures in practice > where this is important. I guess for this particular usage it > doesn't matter whether the information is in the REGISTER > request or the REGISTER response. > > John > > > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: 17 February 2010 12:45 > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com; > > adam@nostrum.com; pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > My view is that there is no strong need need for carrying this > > information accross the SIP-PBX - SSP interface. However this > > information needs to be provided by the SSP's Registrar to > the SSP's > > edge proxy so as to enable the edge proxy to assert identities > > received from the PBX in a P-Preferred-Identity header field. > > > > > -----Message d'origine----- > > > De : martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > John Envoy=E9 > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > Brian Lindsay; > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re: > > > [martini] DID Number Mobility and MARTINI > > > > > > So in trying to tease out whether there needs to be, as > part of the > > > MARTINI mechanism (as opposed to provisioning) an > explicit list of > > > numbers and/or contacts (I won't try to tie down which at > present), > > > I think it is important to understand which direction > this is needed > > > in, because that will go some way towards determining the > mechanism. > > > Do people think: > > > > > > a) there is good reason for providing this information in the > > > direction SIP-PBX to SSP (in which case inclusion in a REGISTER > > > request might be one solution); or > > > > > > b) there is a good reason for providing this information in the > > > direction SSP to SIP-PBX (in which case reg-events might be one > > > solution); or > > > > > > c) it doesn't matter which direction - either direction would be > > > good enough so that at least one side is able to detect a > > > discrepancy; or > > > > > > d) there is a good reason for doing both; or > > > > > > e) there is no good reason to do either. > > > > > > My personal opinion is e), but I would like to hear other > opinions, > > > with reasons. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > > > Sent: 16 February 2010 22:23 > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > Cc: Bernard Aboba; MARTINI > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > Hi, Brian, > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > I am saying > > > > things I should not be saying as chair, at this point... > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > I'm trying > > > > to tease out is whether we can just say "we're not > providing that > > > > information in the REGISTER exchange, BUT you can get that > > > information > > > > using regevents", so that we can move on - I haven't > heard anyone > > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > > > > > > I would be comfortable if our specifications were > silent on this > > > > point, and might be more comfortable if we pointer out > > > somewhere that > > > > the REGISTER exchange does not provide this information, > > but people > > > > who want the information can use regevents or whatever > > other method > > > > seems appropriate to get the information that they want. > > > > > > > > But (Bernard and) I don't get to decide what working group > > > consensus > > > > is - we only get to recognize what consensus is, and when > > it exists. > > > > For that, we > > > > need to hear from other participants (including you, of > > > course - and > > > > "thank you" to participants who care, and have > expressed opinions > > > > about this, in the current thread. > > > > > > > > I hope this is helpful. > > > > > > > > Thanks, > > > > > > > > Spencer > > > > > > > > ----- Original Message ----- > > > > From: "Brian Lindsay" > > > > To: "Spencer Dawkins" ; "Adam Roach" > > > > ; "Paul Kyzivat" > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > Hi Spencer, > > > > > > > > So basically since the provisioning/sync of the E.164 > > > > numbers/ranges is out of scope I don't see a strong > argument for > > > > including them in the registration transaction. The Service > > > Provider > > > > has a set of E.164 numbers that, based on prior > > > > assignment/arrangement, it is responsible to route to the > > > SIP PBX. The > > > > SIP PBX is aware of these numbers already. > > > > The registration process (using an AoR identifying the > > SIP PBX) is > > > > intended to provide reachability information for the SIP > > > PBX, in the > > > > absence of static IP address configuration / DNS (hence the > > > ranges are > > > > not actually required in this transaction). > > > > > > > > Thanks > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > Cc: Bernard Aboba; MARTINI > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > Hi, Brian, > > > > > > > > Just trying to stay synchronized here. > > > > > > > > Speaking as an individual, I think you're right about > > provisioning > > > > being out of scope, based on what I've been hearing on this > > > list and > > > > in telechats, etc. > > > > > > > > What I thought Adam was talking about isn't quite provisioning > > > > (ignoring the question direction - I've heard some people > > > suggest each > > > > direction). > > > > It was more like "I expect these numbers to be registered" > > > and/or "I > > > > registered these numbers on your behalf", with the > > question of how > > > > each end knows what numbers "should" be registered being > > > out of scope > > > > - because "knowing" was provisioned. > > > > > > > > At least, that's the context in which I was reading Adam's > > > note below. > > > > > > > > Thanks, > > > > > > > > Spencer > > > > > > > > > > > > > Hi, > > > > > > > > > > I think it's been stated many times in the threads that > > > > E.164 number > > > > > > > > > provisioning between the enterprise and service provider > > > is out of > > > > > scope of MARTINI. So we're not using the register > > transaction to > > > > > perform any syncronization on these numbers betweeen the > > > enterprise > > > > > and service provider. The registration is just being used > > > to provide > > > > > reachability info, to allow requests to a set of E.164 > > > numbers to be > > > > > routed to the SIP PBX. As such, I don't think the number > > > ranges need > > > > > to be part of the registration transaction. It'll just > > add extra > > > > > complexity to the implementations. > > > > > > > > > > Regards > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On > > > > > Behalf Of Adam Roach > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > To: Paul Kyzivat > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > So, here's what I don't understand: 3GPP at least defined a > > > > procedure > > > > > -- through a questionable use of P-Associated-URI -- to > > > > indicate which > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > user. So even > > > > > > > > > the original 3GPP implicit approach had an enumeration of > > > the AORs > > > > > associated with the registration process. > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > than just > > > > > "implicit with a list of AORs," we're proposing "implicit > > > with *no* > > > > > list of AORs." > > > > > > > > > > So, even if your assertion that our allowing the implicit > > > > mechanism to > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > here is even > > > > > one step more nebulous. > > > > > > > > > > /a > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > >> Dean, > > > > >> > > > > >> In principle I agree with you. > > > > >> But this horse is already out of the barn with IMS implicit > > > > > registration. > > > > >> > > > > >> It was never explicitly brought to the ietf, though things > > > > linked to > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > we could say > > > > >> that is not our problem, I think we already implicitly > > > approved it > > > > >> via > > > > > > > > > >> benign neglect. > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >> Dean Willis wrote: > > > > >>> > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > >>> > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > DID number > > > > >>>> mobility are outside the scope of the current MARTINI > > > WG charter. > > > > >>>> > > > > >>>> The question on the table (see > > > > >>>> > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > >>>> ) > > > > > > > > > >>>> is whether the registration aspects represent a > > > > requirement or not. > > > > >>>> Feel free > > > > >>>> to respond and provide your opinion on that thread. > > > > >>> > > > > >>> Explicit is its own reward. > > > > >>> > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > does is bind > > > > >>> an > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > involved are > > > > >>> explicitly encoded in the request. > > > > >>> > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > to multiple > > > > >>> Contacts. This seems like a reasonable extension to > > > simplify life > > > > >>> for > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > should respect > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > and Contacts > > > > >>> involved. > > > > >>> > > > > >>> From a requirements perspective, I'd be happy with a > > > requirement > > > > >>> along the lines of "must not preclude AOR mobility > > > > indicated by the > > > > > > > > >>> registration." I agree that we can't justify a > requirement to > > > > >>> produce > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > >>> > > > > >>> -- > > > > >>> 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 > > > > > > > _______________________________________________ > > > 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 BLINDSAY@nortel.com Wed Feb 17 18:34: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 41AC528C152 for ; Wed, 17 Feb 2010 18:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 ONc041JHXq+0 for ; Wed, 17 Feb 2010 18:34:49 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0F88C28C140 for ; Wed, 17 Feb 2010 18:34:48 -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 o1I2ZrR18165; Thu, 18 Feb 2010 02:35:53 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_01CAB043.0269EA9D" Date: Wed, 17 Feb 2010 21:35:16 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> In-Reply-To: <4B7C1923.2020506@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqv7j+n8oBRJ4sqTOKUUp00jxbnhwADAHJA References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> From: "Brian Lindsay" To: "Adam Roach" , "Elwell, John" Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 02:34:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB043.0269EA9D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Regarding the 3 reasons outlined below, I'm wondering if we can take a couple of these off the table:=20 =20 Regarding #1, one of the suggested drivers for this (that spawned this and another thread) appeared to be mobility. There was at least some set of people suggesting there were alternate mechanisms to support mobility and that the mobility topic should be out of scope. Are we at the point where mobility has been determined to be out of scope, and can this reason then be removed? =20 Regarding #3, detection of provisioning mismatches using the MARTINI mechanism would seem to be out of scope since the provisioning mechanism itself is out of scope. (why would we need the MARTINI mechanism to detect mismatches associated with an out of scope capability?) =20 Thanks Brian ________________________________ From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Wednesday, February 17, 2010 11:28 AM To: Elwell, John Cc: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Paul Kyzivat; Bernard Aboba; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI On 2/17/10 1:35 AM, Elwell, John wrote:=20 c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or =20 I think you overspecified this option. I'm happy with the assertion that "it doesn't matter which direction," but the additional text implies that this is only being done for discrepancy detection. Which tells me that you aren't following the entire conversation. But you're clearly not the only one. There are at least three very different reasons people have raised (and a fourth, completely fallacious red herring that the opposition has been using as a strawman to tear apart) for including this information: 1. Specification, by the PBX, of the (sub)set of E.164 numbers it wants this registration to apply to,=20 2. Indication to the intermediaries of which E.164 numbers the registration applies to, and=20 3. Detection of mismatched provisioning between the PBX and the SSP.=20 =09 The fourth thing, which no one has proposed, but which many detractors have set up as a wholly bogus strawman, is using this information to provision the PBX. No one wants that. No one has proposed that. We can stop arguing against it because no one is defending it. We all agree that this is not done in SIP. /a ------_=_NextPart_001_01CAB043.0269EA9D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
    Regarding the 3 reasons outlined below, I'm = wondering=20 if we can take a couple of these off the table:
 
    Regarding #1, one of the suggested drivers = for=20 this (that spawned this and another thread) appeared to be = mobility. There=20 was at least some set of people suggesting there were alternate = mechanisms to=20 support mobility and that the mobility topic should be out of scope. Are = we at=20 the point where mobility has been determined to be out of scope, and can = this=20 reason then be removed?
 
    Regarding #3, detection of provisioning = mismatches=20 using the MARTINI mechanism would seem to be out of scope since the = provisioning mechanism itself is out of scope. (why would we need = the=20 MARTINI mechanism to detect mismatches associated with an out of scope=20 capability?)
 
     Thanks
         =20 Brian

From: Adam Roach = [mailto:adam@nostrum.com]=20
Sent: Wednesday, February 17, 2010 11:28 AM
To: = Elwell,=20 John
Cc: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Paul = Kyzivat;=20 Bernard Aboba; MARTINI
Subject: Re: [martini] DID Number = Mobility and=20 MARTINI

On 2/17/10 1:35 AM, Elwell, John wrote:=20 
c) it doesn't matter which direction - =
either direction would be good enough so that at least one side is able =
to detect a discrepancy; or

I think you overspecified this option. I'm = happy with=20 the assertion that "it doesn't matter which direction," but the = additional text=20 implies that this is only being done for discrepancy = detection.

Which=20 tells me that you aren't following the entire conversation. But you're = clearly=20 not the only one.

There are at least three very different = reasons=20 people have raised (and a fourth, completely fallacious red herring that = the=20 opposition has been using as a strawman to tear apart) for including = this=20 information:

  1. Specification, by the PBX, of the (sub)set of E.164 numbers it = wants this=20 registration to apply to,=20
  2. Indication to the intermediaries of which E.164 numbers the = registration=20 applies to, and
  3. Detection of mismatched provisioning between the PBX and the SSP.=20
The fourth thing, which no one has proposed, but which = many=20 detractors have set up as a wholly bogus strawman, is using this = information to=20 provision the PBX. No one wants that. No one has proposed that. We can = stop=20 arguing against it because no one is defending it. We all agree that = this is not=20 done in SIP.

/a
------_=_NextPart_001_01CAB043.0269EA9D-- From bernard_aboba@hotmail.com Wed Feb 17 21:18: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 BAFC728C0DE for ; Wed, 17 Feb 2010 21:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.582, 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 3a3D2KxKjQC2 for ; Wed, 17 Feb 2010 21:17:58 -0800 (PST) Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by core3.amsl.com (Postfix) with ESMTP id E47253A682F for ; Wed, 17 Feb 2010 21:17:57 -0800 (PST) Received: from BLU137-DS7 ([65.55.116.73]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 21:19:38 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Brian Lindsay'" , "'Adam Roach'" , "'Elwell, John'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> Date: Wed, 17 Feb 2010 21:19:37 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CAB016.E90BE380" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqv7j+n8oBRJ4sqTOKUUp00jxbnhwADAHJAABdl9GA= Content-Language: en-us X-OriginalArrivalTime: 18 Feb 2010 05:19:38.0886 (UTC) FILETIME=[F7C3C260:01CAB059] Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 05:18:04 -0000 ------=_NextPart_000_0016_01CAB016.E90BE380 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Brian Lindsay said: "Regarding #3, detection of provisioning mismatches using the MARTINI mechanism would seem to be out of scope since the provisioning mechanism itself is out of scope. (why would we need the MARTINI mechanism to detect mismatches associated with an out of scope capability?)" [BA] In thinking of how we can consistently answer this and other questions about what should be in/out of scope for multiple AOR registration it might help to have some general principles to hang our hat on. We've got a bunch of these questions to plow through between now and (ideally) yesterday, and we have had to put considerable effort into answering them one at a time. One principle that might help us in answering a bunch of them at once is to ask whether a multiple AOR registration should provide similar functionality to many single AOR registrations. The arguments for contact routing and support for many AOR/many contact explicit registration follow from this principle. If we believe this (not sure that we do, but work with me) then we can use it to answer questions about whether certain functionality should be in or out of scope. For example, to answer the question "is detection of provisioning mismatches using multiple AOR registration out of scope?" we can ask the question "can many single AOR registrations provide for detection of provisioning mismatches?" If you attempt to register an AOR with a conventional REGISTER that the SSP doesn't know about, you would get an error for that AOR, but not for other AORs that were registered successfully. So that level of functionality is provided by REGISTER as defined in RFC 3261, and I believe that Dean has made a similar argument with respect to multiple AOR functionality. _____ From: Adam Roach [mailto:adam@nostrum.com] Sent: Wednesday, February 17, 2010 11:28 AM To: Elwell, John Cc: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Paul Kyzivat; Bernard Aboba; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI On 2/17/10 1:35 AM, Elwell, John wrote: c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or I think you overspecified this option. I'm happy with the assertion that "it doesn't matter which direction," but the additional text implies that this is only being done for discrepancy detection. Which tells me that you aren't following the entire conversation. But you're clearly not the only one. There are at least three very different reasons people have raised (and a fourth, completely fallacious red herring that the opposition has been using as a strawman to tear apart) for including this information: 1. Specification, by the PBX, of the (sub)set of E.164 numbers it wants this registration to apply to, 2. Indication to the intermediaries of which E.164 numbers the registration applies to, and 3. Detection of mismatched provisioning between the PBX and the SSP. The fourth thing, which no one has proposed, but which many detractors have set up as a wholly bogus strawman, is using this information to provision the PBX. No one wants that. No one has proposed that. We can stop arguing against it because no one is defending it. We all agree that this is not done in SIP. /a ------=_NextPart_000_0016_01CAB016.E90BE380 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Brian Lindsay said:

 

“Regarding #3, detection of provisioning mismatches using = the MARTINI mechanism would seem to be out of scope since the = provisioning mechanism itself is out of scope. (why would we need the MARTINI = mechanism to detect mismatches associated with an out of scope = capability?)”=

 

[BA] In thinking of how we can consistently answer this = and other questions about what should be in/out of scope for multiple AOR registration it might help to have some general principles to hang our = hat on.   We’ve got a bunch of these questions to plow through between now = and (ideally) yesterday, and we have had to put considerable effort into = answering them one at a time.  

 

One principle that might help us in answering a bunch of = them at once is to ask whether a multiple AOR registration should provide = similar functionality to many single AOR registrations.   The = arguments for contact routing and support for many AOR/many contact explicit = registration follow from this principle.

 

If we believe this (not sure that we do, but work with = me)  then we can use it to answer questions about whether certain = functionality should be in or out of scope. 

 

For example, to answer the question “is detection = of provisioning mismatches using multiple AOR registration out of = scope?” we can ask the question “can many single AOR registrations provide = for detection of provisioning mismatches?”   If you attempt = to register an AOR with a conventional REGISTER that the SSP doesn’t = know about, you would get an error for that AOR, but not for other AORs that = were registered successfully.  So that level of functionality is = provided by REGISTER as defined in RFC 3261, and I believe that Dean has made a = similar argument with respect to multiple AOR functionality. =

 

From: Adam Roach [mailto:adam@nostrum.com] =
Sent: Wednesday, February 17, 2010 11:28 AM
To: Elwell, John
Cc: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Paul Kyzivat; = Bernard Aboba; MARTINI
Subject: Re: [martini] DID Number Mobility and = MARTINI

On 2/17/10 1:35 AM, Elwell, John wrote: = 

c) it doesn't matter which direction - either direction would be =
good enough so that at least one side is able to detect a discrepancy; =
or
 


I think you overspecified this option. I'm happy with the assertion that "it doesn't matter which direction," but the additional text = implies that this is only being done for discrepancy detection.

Which tells me that you aren't following the entire conversation. But = you're clearly not the only one.

There are at least three very different reasons people have = raised (and a fourth, completely fallacious red herring that the opposition has been = using as a strawman to tear apart) for including this = information:

  1. Specification, by the PBX, of the (sub)set = of E.164 numbers it wants this registration to apply to, =
  2. Indication to the intermediaries of which = E.164 numbers the registration applies to, and
  3. Detection of mismatched provisioning = between the PBX and the SSP.

The fourth thing, which no one has proposed, but = which many detractors have set up as a wholly bogus strawman, is using this = information to provision the PBX. No one wants that. No one has proposed that. We can = stop arguing against it because no one is defending it. We all agree that = this is not done in SIP.

/a

------=_NextPart_000_0016_01CAB016.E90BE380-- From christer.holmberg@ericsson.com Wed Feb 17 22: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 6A1483A7E07 for ; Wed, 17 Feb 2010 22:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.255, 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 SlukyDyPsTja for ; Wed, 17 Feb 2010 22:03:37 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 47CA23A7E33 for ; Wed, 17 Feb 2010 22:03:36 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-91-4b7cd89cfc58 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F8.CF.02429.C98DC7B4; Thu, 18 Feb 2010 07:05:16 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 18 Feb 2010 07:05:16 +0100 From: Christer Holmberg To: "Elwell, John" , Spencer Dawkins , Brian Lindsay , Adam Roach , Paul Kyzivat Date: Thu, 18 Feb 2010 07:05:15 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggABMWZfAAAUESYAAbXAHQ Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.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: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 06:03:38 -0000 Hi,=20 >>When you say "explicit", do you exclude wildcarded values?=20 >>Because, one may think that we don't need explicit, but still=20 >>wildcarded, or one may think that we need neither. >[JRE] Wildcarded is still explicit - just a different syntax.=20 >This assumes of course that the intention is to register=20 >EVERY number in a wildcarded range (not just an implicit=20 >subset that the SSP is expected to know in advance). And, it applies to both AORs and contact? For example, do you consider the = "bnc" mechanism in the gin draft as wildcarding? Regards, Christer From spencer@wonderhamster.org Wed Feb 17 22:27: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 2834F3A7C1D for ; Wed, 17 Feb 2010 22:27:37 -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.050, 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 3wnZI5aswTVE for ; Wed, 17 Feb 2010 22:27:35 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 6CAC53A7C20 for ; Wed, 17 Feb 2010 22:27:35 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M0Q2H-1NwM093xjJ-00uxPj; Thu, 18 Feb 2010 01:29:14 -0500 Message-ID: From: "Spencer Dawkins" To: "Bernard Aboba" , "'Brian Lindsay'" , "'Adam Roach'" , "'Elwell, John'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> Date: Thu, 18 Feb 2010 00:28:52 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0799_01CAB031.58E61440" 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+h3L8WADS/EU8E8FibbCbJhLZtumNsQRD1uy3 tnLgGzxvC3mtpHFIv/M4t3E9oSQjCLBQ6wQ9DGPa3jssCxiEco C+TCrjTGvQpxxx4NdnXDWHSnxX5SXKPQgtSfMtNN1Q= Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 06:27:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0799_01CAB031.58E61440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking STRICTLY as a participant... I think Bernard's suggestion is helpful in looking at (3) on Adam's = list. On (1) and (2) -=20 - (1) doesn't actually make sense to me, because I'm reading it as = saying "an SP AND a SIP-PBX might both be provisioned with one or more = AoRs that COULD be registered successfully, but the SIP-PBX might choose = not to register these AoRs". Is that what we're saying here? If so - why = would the SIP-PBX need to do that? - (2) if we're saying that provisioning AoRs at the SP AND at the = SIP-PBX is required (and is out of scope for MARTINI - right?), I'm not = sure why the additional effort to provision middleboxes with these AoRs = justifies explicit signaling. Please don't read either of these as a strong position against either = justification - I don't understand why people are saying these things, = and might just need educating... Thanks, Spencer ----- Original Message -----=20 From: Bernard Aboba=20 To: 'Brian Lindsay' ; 'Adam Roach' ; 'Elwell, John'=20 Cc: 'Spencer Dawkins' ; 'Paul Kyzivat' ; 'MARTINI'=20 Sent: Wednesday, February 17, 2010 11:19 PM Subject: RE: [martini] DID Number Mobility and MARTINI Brian Lindsay said: =20 "Regarding #3, detection of provisioning mismatches using the MARTINI = mechanism would seem to be out of scope since the provisioning mechanism = itself is out of scope. (why would we need the MARTINI mechanism to = detect mismatches associated with an out of scope capability?)" =20 [BA] In thinking of how we can consistently answer this and other = questions about what should be in/out of scope for multiple AOR = registration it might help to have some general principles to hang our = hat on. We've got a bunch of these questions to plow through between = now and (ideally) yesterday, and we have had to put considerable effort = into answering them one at a time. =20 =20 One principle that might help us in answering a bunch of them at once = is to ask whether a multiple AOR registration should provide similar = functionality to many single AOR registrations. The arguments for = contact routing and support for many AOR/many contact explicit = registration follow from this principle.=20 =20 If we believe this (not sure that we do, but work with me) then we = can use it to answer questions about whether certain functionality = should be in or out of scope. =20 =20 For example, to answer the question "is detection of provisioning = mismatches using multiple AOR registration out of scope?" we can ask the = question "can many single AOR registrations provide for detection of = provisioning mismatches?" If you attempt to register an AOR with a = conventional REGISTER that the SSP doesn't know about, you would get an = error for that AOR, but not for other AORs that were registered = successfully. So that level of functionality is provided by REGISTER as = defined in RFC 3261, and I believe that Dean has made a similar argument = with respect to multiple AOR functionality.=20 =20 -------------------------------------------------------------------------= ----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Wednesday, February 17, 2010 11:28 AM To: Elwell, John Cc: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Paul Kyzivat; Bernard = Aboba; MARTINI Subject: Re: [martini] DID Number Mobility and MARTINI On 2/17/10 1:35 AM, Elwell, John wrote:=20 c) it doesn't matter which direction - either direction would be good = enough so that at least one side is able to detect a discrepancy; or =20 I think you overspecified this option. I'm happy with the assertion = that "it doesn't matter which direction," but the additional text = implies that this is only being done for discrepancy detection. Which tells me that you aren't following the entire conversation. But = you're clearly not the only one. There are at least three very different reasons people have raised = (and a fourth, completely fallacious red herring that the opposition has = been using as a strawman to tear apart) for including this information: 1.. Specification, by the PBX, of the (sub)set of E.164 numbers it = wants this registration to apply to,=20 2.. Indication to the intermediaries of which E.164 numbers the = registration applies to, and=20 3.. Detection of mismatched provisioning between the PBX and the = SSP.=20 The fourth thing, which no one has proposed, but which many detractors = have set up as a wholly bogus strawman, is using this information to = provision the PBX. No one wants that. No one has proposed that. We can = stop arguing against it because no one is defending it. We all agree = that this is not done in SIP. /a ------=_NextPart_000_0799_01CAB031.58E61440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Speaking STRICTLY as a participant...
 
I think Bernard's suggestion is helpful in looking = at (3) on=20 Adam's list.
 
On (1) and (2) -
 
- (1) doesn't actually make sense to me, because I'm = reading=20 it as saying "an SP AND a SIP-PBX might both be provisioned with one or = more=20 AoRs that COULD be registered successfully, but the SIP-PBX might choose = not to=20 register these AoRs". Is that what we're saying here? If so - why would = the=20 SIP-PBX need to do that?
 
- (2) if we're saying that provisioning AoRs at the = SP AND at=20 the SIP-PBX is required (and is out of scope for MARTINI - right?), I'm = not sure=20 why the additional effort to provision middleboxes with these AoRs = justifies=20 explicit signaling.
 
Please don't read either of these as a strong = position against=20 either justification - I don't understand why people are saying these = things,=20 and might just need educating...
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Bernard Aboba
To: 'Brian Lindsay' ; 'Adam = Roach' ; 'Elwell, John' =
Cc: 'Spencer Dawkins' ; 'Paul = Kyzivat' ;=20 'MARTINI'
Sent: Wednesday, February 17, = 2010 11:19=20 PM
Subject: RE: [martini] DID = Number=20 Mobility and MARTINI

Brian=20 Lindsay said:

 

=93Regarding=20 #3, detection of provisioning mismatches using the MARTINI mechanism = would=20 seem to be out of scope since the provisioning mechanism = itself is=20 out of scope. (why would we need the MARTINI mechanism to detect = mismatches=20 associated with an out of scope capability?)=94

 

[BA]=20 In thinking of how we can consistently answer this and other questions = about=20 what should be in/out of scope for multiple AOR registration it might = help to=20 have some general principles to hang our hat on.   We=92ve = got a bunch=20 of these questions to plow through between now and (ideally) = yesterday, and we=20 have had to put considerable effort into answering them one at a time. =  

 

One=20 principle that might help us in answering a bunch of them at once is = to ask=20 whether a multiple AOR registration should provide similar = functionality to=20 many single AOR registrations.   The arguments for contact = routing=20 and support for many AOR/many contact explicit registration follow = from this=20 principle.

 

If=20 we believe this (not sure that we do, but work with me)  then we = can use=20 it to answer questions about whether certain functionality should be = in or out=20 of scope. 

 

For=20 example, to answer the question =93is detection of provisioning = mismatches using=20 multiple AOR registration out of scope?=94 we can ask the question = =93can many=20 single AOR registrations provide for detection of provisioning = mismatches?=94=20   If you attempt to register an AOR with a conventional = REGISTER=20 that the SSP doesn=92t know about, you would get an error for that = AOR, but not=20 for other AORs that were registered successfully.  So that level = of=20 functionality is provided by REGISTER as defined in RFC 3261, and I = believe=20 that Dean has made a similar argument with respect to multiple AOR=20 functionality.

 

From: Adam = Roach=20 [mailto:adam@nostrum.com]
Sent: Wednesday, February 17, = 2010 11:28=20 AM
To: Elwell, John
Cc: Spencer Dawkins; Lindsay, = Brian=20 (CAR:AR00); Paul Kyzivat; Bernard Aboba; MARTINI
Subject: = Re:=20 [martini] DID Number Mobility and MARTINI

On 2/17/10 1:35 AM, Elwell, John wrote: = 

c) it doesn't matter which direction - either =
direction would be good enough so that at least one side is able to =
detect a discrepancy; or
 


I think you = overspecified=20 this option. I'm happy with the assertion that "it doesn't matter = which=20 direction," but the additional text implies that this is only being = done for=20 discrepancy detection.

Which tells me that you aren't following = the=20 entire conversation. But you're clearly not the only one.

There = are at=20 least three very different reasons people have raised (and a = fourth,=20 completely fallacious red herring that the opposition has been using = as a=20 strawman to tear apart) for including this information:

    Specification, by the PBX, of the (sub)set of = E.164 numbers=20 it wants this registration to apply to, Indication to the intermediaries of which E.164 = numbers the=20 registration applies to, and Detection of mismatched provisioning between the = PBX and the=20 SSP.

The fourth thing, which no one has proposed, but = which many=20 detractors have set up as a wholly bogus strawman, is using this = information=20 to provision the PBX. No one wants that. No one has proposed that. We = can stop=20 arguing against it because no one is defending it. We all agree that = this is=20 not done in = SIP.

/a

------=_NextPart_000_0799_01CAB031.58E61440-- From dean.willis@softarmor.com Thu Feb 18 05:51: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 46B033A7EA8 for ; Thu, 18 Feb 2010 05:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 WbknjItlC0xy for ; Thu, 18 Feb 2010 05:51:43 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4385C3A7EA2 for ; Thu, 18 Feb 2010 05:51:43 -0800 (PST) Received: from [10.58.96.138] (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 o1IDrNb0025176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 07:53:25 -0600 Message-ID: <4B7D464E.6060801@softarmor.com> Date: Thu, 18 Feb 2010 07:53:18 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Brian Lindsay References: <4B71AC22.3040805@nostrum.com><005e01caa9bf$f6fa7fe0$e4ef7fa0$@us><4B71D6BB.4080304@nostrum.com><4B75C1FD.1080300@cisco.com><9C91E78253724086BA827FEA0501524A@china.huawei.com><9E07E21E-E425-4BD4-B8B2-E170D7ACB214@softarmor.com><0E0FCD5A0D5D4495B55D95D3234A8019@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876312@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C876312@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MARTINI Subject: Re: [martini] Explicit DID indication in REGISTER X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 18 Feb 2010 13:51:44 -0000 Brian Lindsay wrote: > But otherwise this should at a high level work the same way (and > support the same types of capabilities) as if the Service Provider had a > static IP address for the enterprise, and there was no registration > transaction between the enterprise and the Service Provider. > > Then what you're wanting just isn't REGISTER. It doesn't specify an AOR to be registered. It produces no AOR->Contact bindings. It doesn't result in contact-routing at the proxy/registrar. It doesn't return a set of Contacts in a 200 OK response. It doesn't result in a AAA check for the AORs being requested. As Adams might say, what you seem to want is almost but not quite entirely different from REGISTER. And you've pushed back on every approach we've suggested to make a solution that actually works like REGISTER. So why do you want to call your solution REGISTER? Are you just trying to make SIP even more confusing than it already is? -- Dean From dean.willis@softarmor.com Thu Feb 18 05:58: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 8FD683A7F70 for ; Thu, 18 Feb 2010 05:58:19 -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 QqTJ2hE+8Fml for ; Thu, 18 Feb 2010 05:58:18 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D59963A7F6F for ; Thu, 18 Feb 2010 05:58:18 -0800 (PST) Received: from [10.58.96.138] (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 o1IDxvTU025239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 08:00:00 -0600 Message-ID: <4B7D47D8.50603@softarmor.com> Date: Thu, 18 Feb 2010 07:59:52 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Adam Roach References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com> In-Reply-To: <4B7AE54D.3010708@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 13:58:19 -0000 Adam Roach wrote: > > > The REGISTER will be too big if we include a list of extensions in it, > but the NOTIFY won't? What kind of magic is this? > The power of magical thinking and willful logic avoidance? The underlying but unstated assumption behind the REGISTER-based solution is that there is only one AOR (the identity of the PBX) and only one Contact. The phone numbers are just provisioned aliases for the PBX. Given this approach, one might as well adopt IMS in its entirety, as they've already gotten this thought out. Except perhaps for some of the subtleties of GRUU and Outbound, which AFAIK don't actually work in this environment. -- Dean -- Dean From christer.holmberg@ericsson.com Thu Feb 18 06:04: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 BC8843A7F79 for ; Thu, 18 Feb 2010 06:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.246, 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 eZ7-uBasD2Kk for ; Thu, 18 Feb 2010 06:04:01 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BF9203A7F77 for ; Thu, 18 Feb 2010 06:04:00 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-c5-4b7d4936e9a4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C0.C9.02429.6394D7B4; Thu, 18 Feb 2010 15:05:42 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 18 Feb 2010 15:04:56 +0100 From: Christer Holmberg To: Dean Willis , Adam Roach Date: Thu, 18 Feb 2010 15:04:55 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqworJGb1EvGDGQRSS8FdBw1SaiTwAAFiQg Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com> <4B7D47D8.50603@softarmor.com> In-Reply-To: <4B7D47D8.50603@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:04:01 -0000 Hi,=20 >>The REGISTER will be too big if we include a list of=20 >>extensions in it, but the NOTIFY won't? What kind of magic is this? >> >=20 >The power of magical thinking and willful logic avoidance? >=20 >The underlying but unstated assumption behind the=20 >REGISTER-based solution is that there is only one AOR (the=20 >identity of the PBX) and only one Contact. The phone numbers=20 >are just provisioned aliases for the PBX. Given this=20 >approach, one might as well adopt IMS in its entirety, as=20 >they've already gotten this thought out. Except perhaps for=20 >some of the subtleties of GRUU and Outbound, which AFAIK=20 >don't actually work in this environment. Why don't you think Outbound will work? Regards, Christer From dean.willis@softarmor.com Thu Feb 18 06:08: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 3F1BB28C209 for ; Thu, 18 Feb 2010 06:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 m2tIolXUVB3T for ; Thu, 18 Feb 2010 06:08:20 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 577F828C206 for ; Thu, 18 Feb 2010 06:08:20 -0800 (PST) Received: from [10.58.96.138] (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 o1IE8YF0025395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 08:08:36 -0600 Message-ID: <4B7D49DC.70506@softarmor.com> Date: Thu, 18 Feb 2010 08:08:28 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <4B79EFB9.8000209@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:08:21 -0000 DRAGE, Keith (Keith) wrote: > But here the registration we are talking about is not the registration of the handset. It is the registration of the next step on the process of how to get to the handset / terminal. This it is using register to create part of a route, sothing already done by SIP in the path and service route extensions. > Yes, BUT: The registration using path and service-route still results in a "real registration" wherein an AOR is bound to a Contact, and where a proxy uses that binding for contact-routing of requests sent to the AOR. There are a number of other AORs that are essentially aliases for the registered AOR that are separately provisioned, but the core operation of REGISTER is still being used. Using REGISTER exclusively to insert a routing intermediate is something entirely different. It's going to have all sorts of unfortunate side-effects unless EVERYBODY (and I mean that literally) involved has a clear understanding of the difference. And even then, it's going to confuse a lot of people whi are trying to learn this already obfuscated protocol. -- dean -- Dean From dean.willis@softarmor.com Thu Feb 18 06:14: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 CC6063A7CFD for ; Thu, 18 Feb 2010 06:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 6PGqh0WM3PwZ for ; Thu, 18 Feb 2010 06:14:31 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 58FF93A7B19 for ; Thu, 18 Feb 2010 06:14:31 -0800 (PST) Received: from [10.58.96.138] (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 o1IEGAjK025445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 08:16:11 -0600 Message-ID: <4B7D4BA4.8010307@softarmor.com> Date: Thu, 18 Feb 2010 08:16:04 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Elwell, John" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MARTINI , Bernard Aboba Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:14:32 -0000 Elwell, John wrote: > So in trying to tease out whether there needs to be, as part of the MARTINI mechanism (as opposed to provisioning) an explicit list of numbers and/or contacts (I won't try to tie down which at present), I think it is important to understand which direction this is needed in, because that will go some way towards determining the mechanism. Do people think: > > a) there is good reason for providing this information in the direction SIP-PBX to SSP (in which case inclusion in a REGISTER request might be one solution); or > > b) there is a good reason for providing this information in the direction SSP to SIP-PBX (in which case reg-events might be one solution); or > > c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or > > d) there is a good reason for doing both; or > > e) there is no good reason to do either. > > My personal opinion is e), but I would like to hear other opinions, with reasons. > If the phone number is used in the R-URI of a request headed to the PBX, and we have SBC-style intermediaries that block incoming requests for unknown R-URIs, and we expect those intermediaries to learn about the R-URIs during the REGISTER transaction, then we MUST include the full list of possible R-URIs in at least one direction of the REGISTER transaction. That statement allows for several alternatives that could eliminate the requirement. We could, for example, not have such SBCs (but people have said we MUST support them). We could not use the phone number in the R-URI (but we haven't agreed on a extension to the SIP routing model to make this work). We could find some other mechanism than REGISTER for informing the intermediaries (for example, force them to use reg-info, which has even more severe size limitations). But for now, we have what are in effect absolutely contradictory requirements. -- Dean From dean.willis@softarmor.com Thu Feb 18 06:21: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 DE8763A7CFD for ; Thu, 18 Feb 2010 06:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 pSrR7oGv3d-8 for ; Thu, 18 Feb 2010 06:21:31 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 240533A7B19 for ; Thu, 18 Feb 2010 06:21:31 -0800 (PST) Received: from [10.58.96.138] (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 o1IEN8BN025539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 08:23:10 -0600 Message-ID: <4B7D4D46.3070300@softarmor.com> Date: Thu, 18 Feb 2010 08:23:02 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christer Holmberg References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:21:32 -0000 Christer Holmberg wrote: > > But, in any case, when we talk about the message size, we need to be clear about if we talk about requests and responses. As we know, creatomg a response which is larger than the associated request can cause fragmentation problems if UDP was used. > > Sending a large request should not have that problem - you just use TCP to start with. > Intermediary proxies can switch between TCP and UDP at will. The only mechanism we have that requires TLS all the way through is sips: (and even that potentially breaks down depending on what you believe about DTLS and sips:). So, unless we have a Proxy-Require for this extension, and this extension also forces uses of TCP, then we don't have a solution here. -- Dean From dean.willis@softarmor.com Thu Feb 18 06:27: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 30CA628C0E8 for ; Thu, 18 Feb 2010 06:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Yehtajrpuc7m for ; Thu, 18 Feb 2010 06:27:17 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 609EB3A7CFD for ; Thu, 18 Feb 2010 06:27:17 -0800 (PST) Received: from [10.58.96.138] (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 o1IESXx6025584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 08:28:34 -0600 Message-ID: <4B7D4E8B.9090504@softarmor.com> Date: Thu, 18 Feb 2010 08:28:27 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christer Holmberg References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:27:18 -0000 Christer Holmberg wrote: > Hi John, > > When you say "explicit", do you exclude wildcarded values? Because, one may think that we don't need explicit, but still wildcarded, or one may think that we need neither. > Wildcards in the request/response are explicit. They're just a different syntax that conveys the same literal meaning. However, in what I've been calling "Shockey fragmentation" (since he always brings it up), sufficiently complex number ranges receive little or no benefit from wildcarding. -- Dean From christer.holmberg@ericsson.com Thu Feb 18 06:29: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 0A9A73A7EBB for ; Thu, 18 Feb 2010 06:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=-0.241, 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 SB0on5blW15O for ; Thu, 18 Feb 2010 06:29:50 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1859B3A72B4 for ; Thu, 18 Feb 2010 06:29:49 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-cf-4b7d4f43e053 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 76.BA.31641.34F4D7B4; Thu, 18 Feb 2010 15:31:31 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 18 Feb 2010 15:31:16 +0100 From: Christer Holmberg To: Dean Willis Date: Thu, 18 Feb 2010 15:31:15 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqwpeh56Evo0ivxRaqLAdCc8y8nnwAADe7A Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> <4B7D4D46.3070300@softarmor.com> In-Reply-To: <4B7D4D46.3070300@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:29:51 -0000 Hi,=20 >>But, in any case, when we talk about the message size, we=20 >>need to be clear about if we talk about requests and=20 >>responses. As we know, creatomg a response which is larger=20 >>than the associated request can cause fragmentation problems=20 >>if UDP was used. >> >>Sending a large request should not have that problem - you=20 >>just use TCP to start with. >> =20 >=20 >Intermediary proxies can switch between TCP and UDP at will.=20 Sure, but that is a generic SIP problem. There are other cases where you ca= n get a response which is bigger than the request. Regards, Christer From pkyzivat@cisco.com Thu Feb 18 06: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 52F5B3A72B4 for ; Thu, 18 Feb 2010 06:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 9-35rNrKvPAc for ; Thu, 18 Feb 2010 06:30:51 -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 E15663A711D for ; Thu, 18 Feb 2010 06:30:50 -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: AvsEAP3dfEtAZnwN/2dsb2JhbACbCHSmQJgDhGcEgxU X-IronPort-AV: E=Sophos;i="4.49,497,1262563200"; d="scan'208";a="89556476" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-4.cisco.com with ESMTP; 18 Feb 2010 14:31:56 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1IEVtjb006801; Thu, 18 Feb 2010 14:31:55 GMT Message-ID: <4B7D4F58.7010703@cisco.com> Date: Thu, 18 Feb 2010 09:31:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> <4B7D4D46.3070300@softarmor.com> In-Reply-To: <4B7D4D46.3070300@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:30:52 -0000 Dean, I don't follow you on this comment. While intermediaries can indeed switch frm TCP to UDP, they can only do so if the request they are forwarding can be sent using UDP. If the intermediary receives a request over TCP that is too big to send via UDP, then it has no (conforming) choice but to forward it on via TCP. Thanks, Paul Dean Willis wrote: > Christer Holmberg wrote: >> But, in any case, when we talk about the message size, we need to be clear about if we talk about requests and responses. As we know, creatomg a response which is larger than the associated request can cause fragmentation problems if UDP was used. >> >> Sending a large request should not have that problem - you just use TCP to start with. >> > > Intermediary proxies can switch between TCP and UDP at will. The only > mechanism we have that requires TLS all the way through is sips: (and > even that potentially breaks down depending on what you believe about > DTLS and sips:). > > So, unless we have a Proxy-Require for this extension, and this > extension also forces uses of TCP, then we don't have a solution here. > > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From dean.willis@softarmor.com Thu Feb 18 06:34: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 C034528C119 for ; Thu, 18 Feb 2010 06:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 cH+CcmL7AHfr for ; Thu, 18 Feb 2010 06:34:53 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 00E5028C111 for ; Thu, 18 Feb 2010 06:34:52 -0800 (PST) Received: from [10.58.96.138] (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 o1IEaTCo025679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 08:36:32 -0600 Message-ID: <4B7D5068.80800@softarmor.com> Date: Thu, 18 Feb 2010 08:36:24 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christer Holmberg References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com> <4B7D47D8.50603@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:34:53 -0000 Christer Holmberg wrote: > Why don't you think Outbound will work? It was not part of the repertoire at the time that 3GPP chose their particular aliasing and registration model. It MIGHT work, but as far as I know, hasn't been thought completely through, and given our track record, I am not inclined to assume something like this is just going to work. Remember the "multiple simultaneous registrations with divergent paths" part of Outbound? -- Dean From christer.holmberg@ericsson.com Thu Feb 18 06:36: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 B484D28C11D for ; Thu, 18 Feb 2010 06:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=-0.237, 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 LDEuriJ3rENk for ; Thu, 18 Feb 2010 06:36:52 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B7B4C28C111 for ; Thu, 18 Feb 2010 06:36:51 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-4a-4b7d50e86741 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B6.AB.31641.9E05D7B4; Thu, 18 Feb 2010 15:38:33 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 18 Feb 2010 15:38:32 +0100 From: Christer Holmberg To: Dean Willis Date: Thu, 18 Feb 2010 15:38:31 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqwprwnigBEnIWzQ8y2tAxksoFiCgAAIWDA Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4E8B.9090504@softarmor.com> In-Reply-To: <4B7D4E8B.9090504@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:36:52 -0000 Hi,=20 >>When you say "explicit", do you exclude wildcarded values?=20 >>Because, one may think that we don't need explicit, but still=20 >>wildcarded, or one may think that we need neither. >> =20 >Wildcards in the request/response are explicit. They're just=20 >a different syntax that conveys the same literal meaning. >=20 >However, in what I've been calling "Shockey fragmentation"=20 >(since he always brings it up), sufficiently complex number=20 >ranges receive little or no benefit from wildcarding. Could someone give some input of what kind of complex number ranges we woul= d expect? Are there cases where we would not be able to use wildcarding at = all? Regards, Christer From dean.willis@softarmor.com Thu Feb 18 06:39: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 520B53A7243 for ; Thu, 18 Feb 2010 06:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 Hq4AZO6VMY1M for ; Thu, 18 Feb 2010 06:39:55 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 88D7C3A711D for ; Thu, 18 Feb 2010 06:39:55 -0800 (PST) Received: from [10.58.96.138] (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 o1IEfWng025757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 08:41:34 -0600 Message-ID: <4B7D5197.9000001@softarmor.com> Date: Thu, 18 Feb 2010 08:41:27 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christer Holmberg References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> <4B7D4D46.3070300@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:39:56 -0000 Christer Holmberg wrote: > > Sure, but that is a generic SIP problem. There are other cases where you can get a response which is bigger than the request. > > Right. And size is also a problem on requests. For oversized requests, we have a mechanism for failing gracefully (BUT THE REQUEST STILL FAILS!). For oversized responses, we can't even fail gracefully; about all we can do is hope that the Overload provisions kick in and prevent a cascading overload failure. The response size flaw in SIP is something like having a chest wound with lung penetration. As long as we keep a finger stuck in the wound, the lung is unlikely to collapse. But it still hurts and is likely to result in bleeding out. And we're starting to run out of fingers, so perhaps we should stop shooting ourselves in the chest? -- dean From christer.holmberg@ericsson.com Thu Feb 18 06:40: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 DE29C3A711D for ; Thu, 18 Feb 2010 06:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 rWoAHUo-qqHu for ; Thu, 18 Feb 2010 06:40:41 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D8F953A69DA for ; Thu, 18 Feb 2010 06:40:40 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-28-4b7d51ce6daf Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 04.9E.02429.EC15D7B4; Thu, 18 Feb 2010 15:42:22 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 18 Feb 2010 15:42:18 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Thu, 18 Feb 2010 15:42:01 +0100 From: Christer Holmberg To: Dean Willis Date: Thu, 18 Feb 2010 15:42:00 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: Acqwp8cG7ikXIWf7SeaL+1mDHT1eRgAAHKQg Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com> <4B7D47D8.50603@softarmor.com> <4B7D5068.80800@softarmor.com> In-Reply-To: <4B7D5068.80800@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:40:42 -0000 Hi, 3GPP has adopted Outbound for their multiple registration mechanism. Regards, Christer=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 18. helmikuuta 2010 16:36 > To: Christer Holmberg > Cc: Adam Roach; Bernard Aboba; 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Christer Holmberg wrote: > > Why don't you think Outbound will work? > It was not part of the repertoire at the time that 3GPP chose=20 > their particular aliasing and registration model. It MIGHT=20 > work, but as far as I know, hasn't been thought completely=20 > through, and given our track record, I am not inclined to=20 > assume something like this is just going to work. >=20 > Remember the "multiple simultaneous registrations with=20 > divergent paths" > part of Outbound? >=20 > -- > Dean > = From christer.holmberg@ericsson.com Thu Feb 18 06:44: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 DC52A3A6EEB for ; Thu, 18 Feb 2010 06:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 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 OkylcfXiVOBw for ; Thu, 18 Feb 2010 06:44:33 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DF1763A69DA for ; Thu, 18 Feb 2010 06:44:32 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-6e-4b7d52b64b59 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 9A.EE.02429.6B25D7B4; Thu, 18 Feb 2010 15:46:14 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 18 Feb 2010 15:46:13 +0100 From: Christer Holmberg To: Dean Willis Date: Thu, 18 Feb 2010 15:46:12 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqwqHxK25VxeYx9TK6jzz+ca+o50gAAIJfA Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> <4B7D4D46.3070300@softarmor.com> <4B7D5197.9000001@softarmor.com> In-Reply-To: <4B7D5197.9000001@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:44:33 -0000 >>Sure, but that is a generic SIP problem. There are other=20 >>cases where you can get a response which is bigger than the request. >> >> =20 >=20 >Right. And size is also a problem on requests. For oversized=20 >requests, we have a mechanism for failing gracefully (BUT THE=20 >REQUEST STILL FAILS!). For oversized responses, we can't even=20 >fail gracefully; about all we can do is hope that the=20 >Overload provisions kick in and prevent a cascading overload failure. >=20 >The response size flaw in SIP is something like having a=20 >chest wound with lung penetration. As long as we keep a=20 >finger stuck in the wound, the lung is unlikely to collapse.=20 >But it still hurts and is likely to result in bleeding out.=20 >And we're starting to run out of fingers, so perhaps we=20 >should stop shooting ourselves in the chest? ...or, we can just hope that people will configure their proxies so that th= ings work :) Regards, Christer From dean.willis@softarmor.com Thu Feb 18 06:46: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 8A7AC3A69DA for ; Thu, 18 Feb 2010 06:46:45 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBElrB0ZFXol for ; Thu, 18 Feb 2010 06:46:44 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A44B63A72EC for ; Thu, 18 Feb 2010 06:46:44 -0800 (PST) Received: from [10.58.96.138] (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 o1IEmL9d025847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 08:48:22 -0600 Message-ID: <4B7D532F.9010502@softarmor.com> Date: Thu, 18 Feb 2010 08:48:15 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Kyzivat References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> <4B7D4D46.3070300@softarmor.com> <4B7D4F58.7010703@cisco.com> In-Reply-To: <4B7D4F58.7010703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 14:46:45 -0000 Paul Kyzivat wrote: > Dean, > > I don't follow you on this comment. > > While intermediaries can indeed switch frm TCP to UDP, they can only > do so if the request they are forwarding can be sent using UDP. If the > intermediary receives a request over TCP that is too big to send via > UDP, then it has no (conforming) choice but to forward it on via TCP. > The size-conforming node can also reject the oversized request. We have a response code for that (413?). If this happens, the request fails. It's a "graceful fail" in that the sender is informed of the problem, but it still fails. >From a practical perspective, we cannot currently anticipate that TCP will actually be available on every hop. Yes, the proxies have to support it, but that doesn't mean it works with the current network topology. We could certainly define an extension to require bidirectional TCP (and discussed doing so back during the "diagnostic response" discussion). -- Dean From bruno.chatras@orange-ftgroup.com Thu Feb 18 07:58: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 994FC3A6B45 for ; Thu, 18 Feb 2010 07:58: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=[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 Ck2+XBi3sPNb for ; Thu, 18 Feb 2010 07:58:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 58E9E3A797A for ; Thu, 18 Feb 2010 07:58:34 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id A0745C04C3; Thu, 18 Feb 2010 17:00:15 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 7339415805C; Thu, 18 Feb 2010 17:00: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, 18 Feb 2010 17:00: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, 18 Feb 2010 16:59:55 +0100 Message-ID: <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMA== References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770 _1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> From: To: , , , , X-OriginalArrivalTime: 18 Feb 2010 16:00:15.0368 (UTC) FILETIME=[75B17880:01CAB0B3] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.18.153043 Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 15:58:36 -0000 Hi John, You almost wrote the text for such a requirement. "An edge proxy shall be able to base identity assertions for outbound (non-= REGISTER) requests received from a PBX on whether the identity concerned ha= s been registered."=20 Are you looking for a more formal comment on the requirements document? Bruno > -----Message d'origine----- > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 > =C0 : CHATRAS Bruno RD-CORE-ISS; spencer@wonderhamster.org;=20 > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > Cc : bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] DID Number Mobility and MARTINI >=20 > Bruno, >=20 > This depends whether we have a requirement for an edge proxy=20 > to be able to base identity assertions for outbound=20 > (non-REGISTER) requests on whether the identity concerned has=20 > been registered. We don't have such a requirement at present,=20 > so if you think we need such a requirement, please propose=20 > text for the requirements document. >=20 > John >=20 >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com=20 > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: 17 February 2010 14:29 > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > adam@nostrum.com; pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > A good solution should work irrespective of which proxy is=20 > > responsibile for asserting identities, including the case=20 > where this=20 > > is the edge proxy. > > > > > -----Message d'origine----- > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno=20 > > > RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > > adam@nostrum.com; pkyzivat@cisco.com Cc :=20 > bernard_aboba@hotmail.com;=20 > > > martini@ietf.org Objet : RE: [martini] DID Number Mobility and=20 > > > MARTINI > > > > > > Bruno, > > > > > > Thanks. However, this particular reason for a proxy needing this=20 > > > information is because of an architecture where the proxy is=20 > > > assigned responsibility for asserting an identity for the=20 > source of=20 > > > a request. If the domain proxy takes on this=20 > responsibility instead,=20 > > > problem solved. So it is a question of whether this particular=20 > > > architecture is common enough that we need a solution=20 > that conveys=20 > > > registered identities to the edge proxy. IMS solves this=20 > using PAU=20 > > > (ignoring issues of response size), so the question for others is=20 > > > whether there are other architectures in practice where this is=20 > > > important. I guess for this particular usage it doesn't matter=20 > > > whether the information is in the REGISTER request or the=20 > REGISTER=20 > > > response. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: bruno.chatras@orange-ftgroup.com=20 > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > Sent: 17 February 2010 12:45 > > > > To: Elwell, John; spencer@wonderhamster.org;=20 > blindsay@nortel.com;=20 > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > My view is that there is no strong need need for carrying this=20 > > > > information accross the SIP-PBX - SSP interface. However this=20 > > > > information needs to be provided by the SSP's Registrar to > > > the SSP's > > > > edge proxy so as to enable the edge proxy to assert identities=20 > > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > > > -----Message d'origine----- > > > > > De : martini-bounces@ietf.org > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > John Envoy=E9 > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > Brian Lindsay; > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > Objet : Re: > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > part of the > > > > > MARTINI mechanism (as opposed to provisioning) an > > > explicit list of > > > > > numbers and/or contacts (I won't try to tie down which at > > > present), > > > > > I think it is important to understand which direction > > > this is needed > > > > > in, because that will go some way towards determining the > > > mechanism. > > > > > Do people think: > > > > > > > > > > a) there is good reason for providing this information in the=20 > > > > > direction SIP-PBX to SSP (in which case inclusion in=20 > a REGISTER=20 > > > > > request might be one solution); or > > > > > > > > > > b) there is a good reason for providing this=20 > information in the=20 > > > > > direction SSP to SIP-PBX (in which case reg-events=20 > might be one=20 > > > > > solution); or > > > > > > > > > > c) it doesn't matter which direction - either direction > > would be > > > > > good enough so that at least one side is able to detect a=20 > > > > > discrepancy; or > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > My personal opinion is e), but I would like to hear other > > > opinions, > > > > > with reasons. > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: martini-bounces@ietf.org=20 > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > Spencer Dawkins > > > > > > Sent: 16 February 2010 22:23 > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > > I am saying > > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > > I'm trying > > > > > > to tease out is whether we can just say "we're not > > > providing that > > > > > > information in the REGISTER exchange, BUT you can get that > > > > > information > > > > > > using regevents", so that we can move on - I haven't > > > heard anyone > > > > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > > > > > > > > > > I would be comfortable if our specifications were > > > silent on this > > > > > > point, and might be more comfortable if we pointer out > > > > > somewhere that > > > > > > the REGISTER exchange does not provide this information, > > > > but people > > > > > > who want the information can use regevents or whatever > > > > other method > > > > > > seems appropriate to get the information that they want. > > > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > > consensus > > > > > > is - we only get to recognize what consensus is, and when > > > > it exists. > > > > > > For that, we > > > > > > need to hear from other participants (including you, of > > > > > course - and > > > > > > "thank you" to participants who care, and have > > > expressed opinions > > > > > > about this, in the current thread. > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Spencer > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Brian Lindsay" > > > > > > To: "Spencer Dawkins" ; > > "Adam Roach" > > > > > > ; "Paul Kyzivat" > > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > So basically since the provisioning/sync of the E.164=20 > > > > > > numbers/ranges is out of scope I don't see a strong > > > argument for > > > > > > including them in the registration transaction. The Service > > > > > Provider > > > > > > has a set of E.164 numbers that, based on prior=20 > > > > > > assignment/arrangement, it is responsible to route to the > > > > > SIP PBX. The > > > > > > SIP PBX is aware of these numbers already. > > > > > > The registration process (using an AoR identifying the > > > > SIP PBX) is > > > > > > intended to provide reachability information for the SIP > > > > > PBX, in the > > > > > > absence of static IP address configuration / DNS (hence the > > > > > ranges are > > > > > > not actually required in this transaction). > > > > > > > > > > > > Thanks > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > provisioning > > > > > > being out of scope, based on what I've been hearing on this > > > > > list and > > > > > > in telechats, etc. > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > provisioning > > > > > > (ignoring the question direction - I've heard some people > > > > > suggest each > > > > > > direction). > > > > > > It was more like "I expect these numbers to be registered" > > > > > and/or "I > > > > > > registered these numbers on your behalf", with the > > > > question of how > > > > > > each end knows what numbers "should" be registered being > > > > > out of scope > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > > note below. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I think it's been stated many times in the threads that > > > > > > E.164 number > > > > > > > > > > > > > provisioning between the enterprise and service provider > > > > > is out of > > > > > > > scope of MARTINI. So we're not using the register > > > > transaction to > > > > > > > perform any syncronization on these numbers betweeen the > > > > > enterprise > > > > > > > and service provider. The registration is just being used > > > > > to provide > > > > > > > reachability info, to allow requests to a set of E.164 > > > > > numbers to be > > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > > ranges need > > > > > > > to be part of the registration transaction. It'll just > > > > add extra > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > Regards > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: martini-bounces@ietf.org > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > Behalf Of Adam Roach > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > To: Paul Kyzivat > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least=20 > defined a > > > > > > procedure > > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > > indicate which > > > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > > user. So even > > > > > > > > > > > > > the original 3GPP implicit approach had an enumeration of > > > > > the AORs > > > > > > > associated with the registration process. > > > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > > than just > > > > > > > "implicit with a list of AORs," we're proposing "implicit > > > > > with *no* > > > > > > > list of AORs." > > > > > > > > > > > > > > So, even if your assertion that our allowing the implicit > > > > > > mechanism to > > > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > > here is even > > > > > > > one step more nebulous. > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > >> Dean, > > > > > > >> > > > > > > >> In principle I agree with you. > > > > > > >> But this horse is already out of the barn with=20 > IMS implicit > > > > > > > registration. > > > > > > >> > > > > > > >> It was never explicitly brought to the ietf,=20 > though things > > > > > > linked to > > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > > we could say > > > > > > >> that is not our problem, I think we already implicitly > > > > > approved it > > > > > > >> via > > > > > > > > > > > > > >> benign neglect. > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Paul > > > > > > >> > > > > > > >> Dean Willis wrote: > > > > > > >>> > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > >>> > > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > > DID number > > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > > WG charter. > > > > > > >>>> > > > > > > >>>> The question on the table (see > > > > > > >>>> > > > > > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > >>>> ) > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > requirement or not. > > > > > > >>>> Feel free > > > > > > >>>> to respond and provide your opinion on that thread. > > > > > > >>> > > > > > > >>> Explicit is its own reward. > > > > > > >>> > > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > > does is bind > > > > > > >>> an > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > involved are > > > > > > >>> explicitly encoded in the request. > > > > > > >>> > > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > > to multiple > > > > > > >>> Contacts. This seems like a reasonable extension to > > > > > simplify life > > > > > > >>> for > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > > should respect > > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > > and Contacts > > > > > > >>> involved. > > > > > > >>> > > > > > > >>> From a requirements perspective, I'd be happy with a > > > > > requirement > > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > > indicated by the > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > requirement to > > > > > > >>> produce > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > >>> > > > > > > >>> -- > > > > > > >>> 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 > > > > > > > > > > > _______________________________________________ > > > > > 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=20 > confidential and=20 > > 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 > > 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 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 Thu Feb 18 08:18: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 435B33A7ED1 for ; Thu, 18 Feb 2010 08:18:09 -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.047, 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 dWIkwTRMKYnH for ; Thu, 18 Feb 2010 08:18:08 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4090A28C202 for ; Thu, 18 Feb 2010 08:18:08 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MSciy-1NGY6Z1lB6-00RjT0; Thu, 18 Feb 2010 11:19:29 -0500 Message-ID: <06A22373AA6542D58EB7B5C9A8C298C2@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" , "Christer Holmberg" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>, <4B7B2431.2070103@nostrum.com> <4B7D4D46.3070300@softarmor.com> Date: Thu, 18 Feb 2010 10:19:14 -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+3ypHmRsR6sm8Mk/+u5QPJxIb4hD389lsvcBM oiCDiRgsyE3ZJ/Ke5Vt71ZboT1GIddojIfp68uLBBfF9z3FbtE qTjdInqS/thUBSfnJpcy4TtD55vS+puCGoevAld/Z4= Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 16:18:09 -0000 Speaking as chair, >> But, in any case, when we talk about the message size, we need to be >> clear about if we talk about requests and responses. As we know, creatomg >> a response which is larger than the associated request can cause >> fragmentation problems if UDP was used. >> >> Sending a large request should not have that problem - you just use TCP >> to start with. >> > > Intermediary proxies can switch between TCP and UDP at will. The only > mechanism we have that requires TLS all the way through is sips: (and > even that potentially breaks down depending on what you believe about > DTLS and sips:). > > So, unless we have a Proxy-Require for this extension, and this > extension also forces uses of TCP, then we don't have a solution here. I believe that I have seen general acceptance of Proxy-Require to support whatever MARTINI ends up with, if that's necessary, and I haven't seen anyone saying on-list that Proxy-Require is unacceptable. Unless Bernard wants to drag me into a corner for a chair-to-chair meeting of the minds, I think we can declare that question closed, assume that we will have Proxy-Require for this extension if it is necessary, and move on to the next technical issue. Thanks, Spencer From spencer@wonderhamster.org Thu Feb 18 08:43: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 5638428C2A6 for ; Thu, 18 Feb 2010 08:43:28 -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.046, 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 o7JxRf92xClB for ; Thu, 18 Feb 2010 08:43:27 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 6B11728C298 for ; Thu, 18 Feb 2010 08:43:27 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MFLxc-1NTpbh0C4C-00EUt1; Thu, 18 Feb 2010 11:44:26 -0500 Message-ID: From: "Spencer Dawkins" To: "Dean Willis" , "Elwell, John" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> Date: Thu, 18 Feb 2010 10:44:05 -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: V01U2FsdGVkX19sfc9h9a4rUgSOEmUFLJGwG61SEwRJyo4h2Fu Gy0hzFUj3acrMVBjVKr9CmVKTP5Zor2+ggl+I+GEdOzlQZpfKt juiFgnvsxiIm6Ghz8j6ydMG8rkLijnTVLCKrZwbhvI= Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 16:43:28 -0000 Hi, Dean, > If the phone number is used in the R-URI of a request headed to the PBX, > and we have SBC-style intermediaries that block incoming requests for > unknown R-URIs, and we expect those intermediaries to learn about the > R-URIs during the REGISTER transaction, then we MUST include the full > list of possible R-URIs in at least one direction of the REGISTER > transaction. I sent a note last night to the list (http://www.ietf.org/mail-archive/web/martini/current/msg00765.html) that you might not have seen when you sent your note, and it included this text: "- (2) if we're saying that provisioning AoRs at the SP AND at the SIP-PBX is required (and is out of scope for MARTINI - right?), I'm not sure why the additional effort to provision middleboxes with these AoRs justifies explicit signaling." I sent that note as an individual, but I think it's now appropriate for me to ask, as co-chair, that someone explain why - the SIP-PBX can't use MARTINI to provision the SP, AND - the SP can't use MARTINI to provision the SIP-PBX, AND - we have to explicitly include the list of AoRs in signaling because there are middleboxes that neither end can provision Please note the "AND"s - I'm not asking for reasons why any one of these statements are true, I'm asking for reasons why all three statements are true. ... (brief pause to change hats) Speaking as an individual (in the same e-mail as I have been speaking as co-chair - and that's always dangerous), I don't LIKE the idea that we have to provision each end of the REGISTER relationship independently, but I'm not seeing any danger that we can come to consensus on which end of the REGISTER relationship should always be provisioning the other end, so I think that's where we are - with two independent provisioning actions. Given that we have two independent provisioning actions in the process now, I'm clueless as to why we can't include middlebox provisioning as part of the provisioning action on whichever end is in the same administrative domain as the middlebox, and (still speaking as an individual), I haven't seen anyone arguing that there will be middleboxes in a MARTINI SP/SIP-PBX REGISTER path that aren't controlled by the same administrative entity that controls at least one end of the path. The chairs are in the process of declaring that we have consensus on using Proxy-Require if we need it, so saying that we expect people to stick an independent administrative domain in the middle of the path would change the dynamics of that discussion pretty drastically. Speaking as an individual, I think this is a great time for anyone who is planning to make that argument, to make it. Thanks, Spencer From john.elwell@siemens-enterprise.com Thu Feb 18 08:51: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 DAA9628C2C2 for ; Thu, 18 Feb 2010 08:51:45 -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.041, 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 HOiWX1Nw+zaL for ; Thu, 18 Feb 2010 08:51:44 -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 6A07728C2A8 for ; Thu, 18 Feb 2010 08:51:43 -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-935828; Thu, 18 Feb 2010 17:53:25 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 49D5D1EB82BA; Thu, 18 Feb 2010 17:53:25 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 18 Feb 2010 17:53:25 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "blindsay@nortel.com" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Thu, 18 Feb 2010 17:53:23 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMAAB2ASw Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770 _1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@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: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 16:51:45 -0000 Bruno, Yes, I thought that was what you were asking for. Let's see whether the WG = agrees with that requirement. Comments? John > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: 18 February 2010 16:00 > To: Elwell, John; spencer@wonderhamster.org; > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI > > Hi John, > > You almost wrote the text for such a requirement. > > "An edge proxy shall be able to base identity assertions for > outbound (non-REGISTER) requests received from a PBX on > whether the identity concerned has been registered." > > Are you looking for a more formal comment on the requirements > document? > > Bruno > > > -----Message d'origine----- > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 > > =C0 : CHATRAS Bruno RD-CORE-ISS; spencer@wonderhamster.org; > > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > > Cc : bernard_aboba@hotmail.com; martini@ietf.org > > Objet : RE: [martini] DID Number Mobility and MARTINI > > > > Bruno, > > > > This depends whether we have a requirement for an edge proxy > > to be able to base identity assertions for outbound > > (non-REGISTER) requests on whether the identity concerned has > > been registered. We don't have such a requirement at present, > > so if you think we need such a requirement, please propose > > text for the requirements document. > > > > John > > > > > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 17 February 2010 14:29 > > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com; > > > adam@nostrum.com; pkyzivat@cisco.com > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > A good solution should work irrespective of which proxy is > > > responsibile for asserting identities, including the case > > where this > > > is the edge proxy. > > > > > > > -----Message d'origine----- > > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno > > > > RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com; > > > > adam@nostrum.com; pkyzivat@cisco.com Cc : > > bernard_aboba@hotmail.com; > > > > martini@ietf.org Objet : RE: [martini] DID Number Mobility and > > > > MARTINI > > > > > > > > Bruno, > > > > > > > > Thanks. However, this particular reason for a proxy > needing this > > > > information is because of an architecture where the proxy is > > > > assigned responsibility for asserting an identity for the > > source of > > > > a request. If the domain proxy takes on this > > responsibility instead, > > > > problem solved. So it is a question of whether this particular > > > > architecture is common enough that we need a solution > > that conveys > > > > registered identities to the edge proxy. IMS solves this > > using PAU > > > > (ignoring issues of response size), so the question for > others is > > > > whether there are other architectures in practice where this is > > > > important. I guess for this particular usage it doesn't matter > > > > whether the information is in the REGISTER request or the > > REGISTER > > > > response. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: bruno.chatras@orange-ftgroup.com > > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > > Sent: 17 February 2010 12:45 > > > > > To: Elwell, John; spencer@wonderhamster.org; > > blindsay@nortel.com; > > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > My view is that there is no strong need need for > carrying this > > > > > information accross the SIP-PBX - SSP interface. However this > > > > > information needs to be provided by the SSP's Registrar to > > > > the SSP's > > > > > edge proxy so as to enable the edge proxy to assert > identities > > > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > > > > > -----Message d'origine----- > > > > > > De : martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > > John Envoy=E9 > > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > > Brian Lindsay; > > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > > Objet : Re: > > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > > part of the > > > > > > MARTINI mechanism (as opposed to provisioning) an > > > > explicit list of > > > > > > numbers and/or contacts (I won't try to tie down which at > > > > present), > > > > > > I think it is important to understand which direction > > > > this is needed > > > > > > in, because that will go some way towards determining the > > > > mechanism. > > > > > > Do people think: > > > > > > > > > > > > a) there is good reason for providing this > information in the > > > > > > direction SIP-PBX to SSP (in which case inclusion in > > a REGISTER > > > > > > request might be one solution); or > > > > > > > > > > > > b) there is a good reason for providing this > > information in the > > > > > > direction SSP to SIP-PBX (in which case reg-events > > might be one > > > > > > solution); or > > > > > > > > > > > > c) it doesn't matter which direction - either direction > > > would be > > > > > > good enough so that at least one side is able to detect a > > > > > > discrepancy; or > > > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > > > My personal opinion is e), but I would like to hear other > > > > opinions, > > > > > > with reasons. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: martini-bounces@ietf.org > > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of > > Spencer Dawkins > > > > > > > Sent: 16 February 2010 22:23 > > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > > > I am saying > > > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > > > I'm trying > > > > > > > to tease out is whether we can just say "we're not > > > > providing that > > > > > > > information in the REGISTER exchange, BUT you can get that > > > > > > information > > > > > > > using regevents", so that we can move on - I haven't > > > > heard anyone > > > > > > > propose that MARTINI would say "MUST NOT use > regevents" :-) > > > > > > > > > > > > > > I would be comfortable if our specifications were > > > > silent on this > > > > > > > point, and might be more comfortable if we pointer out > > > > > > somewhere that > > > > > > > the REGISTER exchange does not provide this information, > > > > > but people > > > > > > > who want the information can use regevents or whatever > > > > > other method > > > > > > > seems appropriate to get the information that they want. > > > > > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > > > consensus > > > > > > > is - we only get to recognize what consensus is, and when > > > > > it exists. > > > > > > > For that, we > > > > > > > need to hear from other participants (including you, of > > > > > > course - and > > > > > > > "thank you" to participants who care, and have > > > > expressed opinions > > > > > > > about this, in the current thread. > > > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Brian Lindsay" > > > > > > > To: "Spencer Dawkins" ; > > > "Adam Roach" > > > > > > > ; "Paul Kyzivat" > > > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > > > So basically since the provisioning/sync of the E.164 > > > > > > > numbers/ranges is out of scope I don't see a strong > > > > argument for > > > > > > > including them in the registration transaction. > The Service > > > > > > Provider > > > > > > > has a set of E.164 numbers that, based on prior > > > > > > > assignment/arrangement, it is responsible to route to the > > > > > > SIP PBX. The > > > > > > > SIP PBX is aware of these numbers already. > > > > > > > The registration process (using an AoR identifying the > > > > > SIP PBX) is > > > > > > > intended to provide reachability information for the SIP > > > > > > PBX, in the > > > > > > > absence of static IP address configuration / DNS > (hence the > > > > > > ranges are > > > > > > > not actually required in this transaction). > > > > > > > > > > > > > > Thanks > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > > provisioning > > > > > > > being out of scope, based on what I've been > hearing on this > > > > > > list and > > > > > > > in telechats, etc. > > > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > > provisioning > > > > > > > (ignoring the question direction - I've heard some people > > > > > > suggest each > > > > > > > direction). > > > > > > > It was more like "I expect these numbers to be registered" > > > > > > and/or "I > > > > > > > registered these numbers on your behalf", with the > > > > > question of how > > > > > > > each end knows what numbers "should" be registered being > > > > > > out of scope > > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > > > note below. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I think it's been stated many times in the > threads that > > > > > > > E.164 number > > > > > > > > > > > > > > > provisioning between the enterprise and service provider > > > > > > is out of > > > > > > > > scope of MARTINI. So we're not using the register > > > > > transaction to > > > > > > > > perform any syncronization on these numbers betweeen the > > > > > > enterprise > > > > > > > > and service provider. The registration is just > being used > > > > > > to provide > > > > > > > > reachability info, to allow requests to a set of E.164 > > > > > > numbers to be > > > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > > > ranges need > > > > > > > > to be part of the registration transaction. It'll just > > > > > add extra > > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > > > Regards > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > > Behalf Of Adam Roach > > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > > To: Paul Kyzivat > > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least > > defined a > > > > > > > procedure > > > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > > > indicate which > > > > > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > > > user. So even > > > > > > > > > > > > > > > the original 3GPP implicit approach had an > enumeration of > > > > > > the AORs > > > > > > > > associated with the registration process. > > > > > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > > > than just > > > > > > > > "implicit with a list of AORs," we're proposing > "implicit > > > > > > with *no* > > > > > > > > list of AORs." > > > > > > > > > > > > > > > > So, even if your assertion that our allowing > the implicit > > > > > > > mechanism to > > > > > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > > > here is even > > > > > > > > one step more nebulous. > > > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > > >> Dean, > > > > > > > >> > > > > > > > >> In principle I agree with you. > > > > > > > >> But this horse is already out of the barn with > > IMS implicit > > > > > > > > registration. > > > > > > > >> > > > > > > > >> It was never explicitly brought to the ietf, > > though things > > > > > > > linked to > > > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > > > we could say > > > > > > > >> that is not our problem, I think we already implicitly > > > > > > approved it > > > > > > > >> via > > > > > > > > > > > > > > > >> benign neglect. > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > >> Paul > > > > > > > >> > > > > > > > >> Dean Willis wrote: > > > > > > > >>> > > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > > >>> > > > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > > > DID number > > > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > > > WG charter. > > > > > > > >>>> > > > > > > > >>>> The question on the table (see > > > > > > > >>>> > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > > >>>> ) > > > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > > requirement or not. > > > > > > > >>>> Feel free > > > > > > > >>>> to respond and provide your opinion on that thread. > > > > > > > >>> > > > > > > > >>> Explicit is its own reward. > > > > > > > >>> > > > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > > > does is bind > > > > > > > >>> an > > > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > > involved are > > > > > > > >>> explicitly encoded in the request. > > > > > > > >>> > > > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > > > to multiple > > > > > > > >>> Contacts. This seems like a reasonable extension to > > > > > > simplify life > > > > > > > >>> for > > > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > > > should respect > > > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > > > and Contacts > > > > > > > >>> involved. > > > > > > > >>> > > > > > > > >>> From a requirements perspective, I'd be happy with a > > > > > > requirement > > > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > > > indicated by the > > > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > > requirement to > > > > > > > >>> produce > > > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > > >>> > > > > > > > >>> -- > > > > > > > >>> 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 > > > > > > > > > > > > > _______________________________________________ > > > > > > 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. > > > ******************************** > > > > > > > > > > ********************************* > 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 bernard_aboba@hotmail.com Thu Feb 18 09:13: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 967B53A7EE3 for ; Thu, 18 Feb 2010 09:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.577, 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 dtKbTmOLmf9v for ; Thu, 18 Feb 2010 09:13:08 -0800 (PST) Received: from blu0-omc1-s29.blu0.hotmail.com (blu0-omc1-s29.blu0.hotmail.com [65.55.116.40]) by core3.amsl.com (Postfix) with ESMTP id CE4E33A7FC0 for ; Thu, 18 Feb 2010 09:13:07 -0800 (PST) Received: from BLU137-DS5 ([65.55.116.7]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 09:14:50 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Spencer Dawkins'" , "'Dean Willis'" , "'Elwell, John'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> In-Reply-To: Date: Thu, 18 Feb 2010 09:15: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: Acqwubg+ZNtZ5HcjQ+af0aUI94G1IAAA+JLQ Content-Language: en-us X-OriginalArrivalTime: 18 Feb 2010 17:14:50.0988 (UTC) FILETIME=[E15EE2C0:01CAB0BD] Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 17:13:09 -0000 Spencer said: " I sent that note as an individual, but I think it's now appropriate for me to ask, as co-chair, that someone explain why - the SIP-PBX can't use MARTINI to provision the SP, AND - the SP can't use MARTINI to provision the SIP-PBX, AND - we have to explicitly include the list of AoRs in signaling because there are middleboxes that neither end can provision Please note the "AND"s - I'm not asking for reasons why any one of these statements are true, I'm asking for reasons why all three statements are true." [BA] And while we're asking for that explanation, I'd also like to understand what assumptions we are making about the middleboxes in question. For example: a. Is there an assumption that the middlebox wouldn't be updated to support MARTINI? b. If it could be updated, is there an assumption about what kinds of information the middle box can understand/parse? From christer.holmberg@ericsson.com Thu Feb 18 09:56: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 C9AE428C2EF for ; Thu, 18 Feb 2010 09:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.824 X-Spam-Level: X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 MQy+S9pJ4z1U for ; Thu, 18 Feb 2010 09:56:59 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DA94028C2EC for ; Thu, 18 Feb 2010 09:56:58 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-bb-4b7d7fd004e7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CB.AF.02429.0DF7D7B4; Thu, 18 Feb 2010 18:58:41 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 18 Feb 2010 18:58:40 +0100 From: Christer Holmberg To: Dean Willis , Adam Roach Date: Thu, 18 Feb 2010 18:55:09 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqworJGb1EvGDGQRSS8FdBw1SaiTwAINCne Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com> <1271C5B8A1AC4F4AAC1E4C1FEDC1BF8A@china.huawei.com> <4B7AE54D.3010708@nostrum.com>,<4B7D47D8.50603@softarmor.com> In-Reply-To: <4B7D47D8.50603@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 17:56:59 -0000 Hi, >The underlying but unstated assumption behind the REGISTER-based >solution is that there is only one AOR (the identity of the PBX) and >only one Contact. The phone numbers are just provisioned aliases for the >PBX. Given this approach, one might as well adopt IMS in its entirety, >as they've already gotten this thought out. Yes, one might. There is nothing wrong with adopting an existing solution. People have been talking about the "bad history of implicit". I may have mi= ssed something, but I am not really sure what that "bad history" is... Regards, Christer= From christer.holmberg@ericsson.com Thu Feb 18 10:09: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 7D1C93A7FE7 for ; Thu, 18 Feb 2010 10:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 WFD6S69jgnYX for ; Thu, 18 Feb 2010 10:09:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DF5B23A7FE1 for ; Thu, 18 Feb 2010 10:08:58 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-c0-4b7d82a02f3c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 8C.4E.31641.0A28D7B4; Thu, 18 Feb 2010 19:10:41 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 18 Feb 2010 19:10:40 +0100 From: Christer Holmberg To: "Elwell, John" , "bruno.chatras@orange-ftgroup.com" , "spencer@wonderhamster.org" , "blindsay@nortel.com" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Thu, 18 Feb 2010 19:05:53 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMAAB2ASwAAKe2u8= Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770 _1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 18:09:02 -0000 Hi, I think that is a good requirement. It doesn't necessarily mean that the functionality needs be enabled at all = time, in all deployments (as someone said, the assertion can also be done b= y the registrar, or by some other entity), but I think it would be very goo= d if the solution would provide such functionality. Regards, Christer ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Elwe= ll, John [john.elwell@siemens-enterprise.com] Sent: Thursday, February 18, 2010 6:53 PM To: bruno.chatras@orange-ftgroup.com; spencer@wonderhamster.org; blindsay@n= ortel.com; adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] DID Number Mobility and MARTINI Bruno, Yes, I thought that was what you were asking for. Let's see whether the WG = agrees with that requirement. Comments? John > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: 18 February 2010 16:00 > To: Elwell, John; spencer@wonderhamster.org; > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI > > Hi John, > > You almost wrote the text for such a requirement. > > "An edge proxy shall be able to base identity assertions for > outbound (non-REGISTER) requests received from a PBX on > whether the identity concerned has been registered." > > Are you looking for a more formal comment on the requirements > document? > > Bruno > > > -----Message d'origine----- > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 > > =C0 : CHATRAS Bruno RD-CORE-ISS; spencer@wonderhamster.org; > > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > > Cc : bernard_aboba@hotmail.com; martini@ietf.org > > Objet : RE: [martini] DID Number Mobility and MARTINI > > > > Bruno, > > > > This depends whether we have a requirement for an edge proxy > > to be able to base identity assertions for outbound > > (non-REGISTER) requests on whether the identity concerned has > > been registered. We don't have such a requirement at present, > > so if you think we need such a requirement, please propose > > text for the requirements document. > > > > John > > > > > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 17 February 2010 14:29 > > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com; > > > adam@nostrum.com; pkyzivat@cisco.com > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > A good solution should work irrespective of which proxy is > > > responsibile for asserting identities, including the case > > where this > > > is the edge proxy. > > > > > > > -----Message d'origine----- > > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno > > > > RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com; > > > > adam@nostrum.com; pkyzivat@cisco.com Cc : > > bernard_aboba@hotmail.com; > > > > martini@ietf.org Objet : RE: [martini] DID Number Mobility and > > > > MARTINI > > > > > > > > Bruno, > > > > > > > > Thanks. However, this particular reason for a proxy > needing this > > > > information is because of an architecture where the proxy is > > > > assigned responsibility for asserting an identity for the > > source of > > > > a request. If the domain proxy takes on this > > responsibility instead, > > > > problem solved. So it is a question of whether this particular > > > > architecture is common enough that we need a solution > > that conveys > > > > registered identities to the edge proxy. IMS solves this > > using PAU > > > > (ignoring issues of response size), so the question for > others is > > > > whether there are other architectures in practice where this is > > > > important. I guess for this particular usage it doesn't matter > > > > whether the information is in the REGISTER request or the > > REGISTER > > > > response. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: bruno.chatras@orange-ftgroup.com > > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > > Sent: 17 February 2010 12:45 > > > > > To: Elwell, John; spencer@wonderhamster.org; > > blindsay@nortel.com; > > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > My view is that there is no strong need need for > carrying this > > > > > information accross the SIP-PBX - SSP interface. However this > > > > > information needs to be provided by the SSP's Registrar to > > > > the SSP's > > > > > edge proxy so as to enable the edge proxy to assert > identities > > > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > > > > > -----Message d'origine----- > > > > > > De : martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > > John Envoy=E9 > > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > > Brian Lindsay; > > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > > Objet : Re: > > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > > part of the > > > > > > MARTINI mechanism (as opposed to provisioning) an > > > > explicit list of > > > > > > numbers and/or contacts (I won't try to tie down which at > > > > present), > > > > > > I think it is important to understand which direction > > > > this is needed > > > > > > in, because that will go some way towards determining the > > > > mechanism. > > > > > > Do people think: > > > > > > > > > > > > a) there is good reason for providing this > information in the > > > > > > direction SIP-PBX to SSP (in which case inclusion in > > a REGISTER > > > > > > request might be one solution); or > > > > > > > > > > > > b) there is a good reason for providing this > > information in the > > > > > > direction SSP to SIP-PBX (in which case reg-events > > might be one > > > > > > solution); or > > > > > > > > > > > > c) it doesn't matter which direction - either direction > > > would be > > > > > > good enough so that at least one side is able to detect a > > > > > > discrepancy; or > > > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > > > My personal opinion is e), but I would like to hear other > > > > opinions, > > > > > > with reasons. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: martini-bounces@ietf.org > > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of > > Spencer Dawkins > > > > > > > Sent: 16 February 2010 22:23 > > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > > > I am saying > > > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > > > I'm trying > > > > > > > to tease out is whether we can just say "we're not > > > > providing that > > > > > > > information in the REGISTER exchange, BUT you can get that > > > > > > information > > > > > > > using regevents", so that we can move on - I haven't > > > > heard anyone > > > > > > > propose that MARTINI would say "MUST NOT use > regevents" :-) > > > > > > > > > > > > > > I would be comfortable if our specifications were > > > > silent on this > > > > > > > point, and might be more comfortable if we pointer out > > > > > > somewhere that > > > > > > > the REGISTER exchange does not provide this information, > > > > > but people > > > > > > > who want the information can use regevents or whatever > > > > > other method > > > > > > > seems appropriate to get the information that they want. > > > > > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > > > consensus > > > > > > > is - we only get to recognize what consensus is, and when > > > > > it exists. > > > > > > > For that, we > > > > > > > need to hear from other participants (including you, of > > > > > > course - and > > > > > > > "thank you" to participants who care, and have > > > > expressed opinions > > > > > > > about this, in the current thread. > > > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Brian Lindsay" > > > > > > > To: "Spencer Dawkins" ; > > > "Adam Roach" > > > > > > > ; "Paul Kyzivat" > > > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > > > So basically since the provisioning/sync of the E.164 > > > > > > > numbers/ranges is out of scope I don't see a strong > > > > argument for > > > > > > > including them in the registration transaction. > The Service > > > > > > Provider > > > > > > > has a set of E.164 numbers that, based on prior > > > > > > > assignment/arrangement, it is responsible to route to the > > > > > > SIP PBX. The > > > > > > > SIP PBX is aware of these numbers already. > > > > > > > The registration process (using an AoR identifying the > > > > > SIP PBX) is > > > > > > > intended to provide reachability information for the SIP > > > > > > PBX, in the > > > > > > > absence of static IP address configuration / DNS > (hence the > > > > > > ranges are > > > > > > > not actually required in this transaction). > > > > > > > > > > > > > > Thanks > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > > provisioning > > > > > > > being out of scope, based on what I've been > hearing on this > > > > > > list and > > > > > > > in telechats, etc. > > > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > > provisioning > > > > > > > (ignoring the question direction - I've heard some people > > > > > > suggest each > > > > > > > direction). > > > > > > > It was more like "I expect these numbers to be registered" > > > > > > and/or "I > > > > > > > registered these numbers on your behalf", with the > > > > > question of how > > > > > > > each end knows what numbers "should" be registered being > > > > > > out of scope > > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > > > note below. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I think it's been stated many times in the > threads that > > > > > > > E.164 number > > > > > > > > > > > > > > > provisioning between the enterprise and service provider > > > > > > is out of > > > > > > > > scope of MARTINI. So we're not using the register > > > > > transaction to > > > > > > > > perform any syncronization on these numbers betweeen the > > > > > > enterprise > > > > > > > > and service provider. The registration is just > being used > > > > > > to provide > > > > > > > > reachability info, to allow requests to a set of E.164 > > > > > > numbers to be > > > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > > > ranges need > > > > > > > > to be part of the registration transaction. It'll just > > > > > add extra > > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > > > Regards > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > > Behalf Of Adam Roach > > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > > To: Paul Kyzivat > > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least > > defined a > > > > > > > procedure > > > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > > > indicate which > > > > > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > > > user. So even > > > > > > > > > > > > > > > the original 3GPP implicit approach had an > enumeration of > > > > > > the AORs > > > > > > > > associated with the registration process. > > > > > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > > > than just > > > > > > > > "implicit with a list of AORs," we're proposing > "implicit > > > > > > with *no* > > > > > > > > list of AORs." > > > > > > > > > > > > > > > > So, even if your assertion that our allowing > the implicit > > > > > > > mechanism to > > > > > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > > > here is even > > > > > > > > one step more nebulous. > > > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > > >> Dean, > > > > > > > >> > > > > > > > >> In principle I agree with you. > > > > > > > >> But this horse is already out of the barn with > > IMS implicit > > > > > > > > registration. > > > > > > > >> > > > > > > > >> It was never explicitly brought to the ietf, > > though things > > > > > > > linked to > > > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > > > we could say > > > > > > > >> that is not our problem, I think we already implicitly > > > > > > approved it > > > > > > > >> via > > > > > > > > > > > > > > > >> benign neglect. > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > >> Paul > > > > > > > >> > > > > > > > >> Dean Willis wrote: > > > > > > > >>> > > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > > >>> > > > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > > > DID number > > > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > > > WG charter. > > > > > > > >>>> > > > > > > > >>>> The question on the table (see > > > > > > > >>>> > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > > >>>> ) > > > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > > requirement or not. > > > > > > > >>>> Feel free > > > > > > > >>>> to respond and provide your opinion on that thread. > > > > > > > >>> > > > > > > > >>> Explicit is its own reward. > > > > > > > >>> > > > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > > > does is bind > > > > > > > >>> an > > > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > > involved are > > > > > > > >>> explicitly encoded in the request. > > > > > > > >>> > > > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > > > to multiple > > > > > > > >>> Contacts. This seems like a reasonable extension to > > > > > > simplify life > > > > > > > >>> for > > > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > > > should respect > > > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > > > and Contacts > > > > > > > >>> involved. > > > > > > > >>> > > > > > > > >>> From a requirements perspective, I'd be happy with a > > > > > > requirement > > > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > > > indicated by the > > > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > > requirement to > > > > > > > >>> produce > > > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > > >>> > > > > > > > >>> -- > > > > > > > >>> 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 > > > > > > > > > > > > > _______________________________________________ > > > > > > 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. > > > ******************************** > > > > > > > > > > ********************************* > 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 md3135@att.com Thu Feb 18 10:14: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 E5B353A7FE9 for ; Thu, 18 Feb 2010 10:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPRhAfAc3pj0 for ; Thu, 18 Feb 2010 10:14:38 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 6A8D43A7FC0 for ; Thu, 18 Feb 2010 10:14:38 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1266516764!18851869!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 30608 invoked from network); 18 Feb 2010 18:12:45 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Feb 2010 18:12:45 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1IICfuT029604; Thu, 18 Feb 2010 13:12:42 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1IICcbj029548; Thu, 18 Feb 2010 13:12:38 -0500 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, 18 Feb 2010 13:12:42 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA05AE934D@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMAAB2ASwAALYoGA= References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com><8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr><9770_12 66416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr><4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> From: "DOLLY, MARTIN C (ATTLABS)" To: "Elwell, John" , , , , , Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 18:14:42 -0000 +1, agree with the requirement -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Elwell, John Sent: Thursday, February 18, 2010 11:53 AM To: bruno.chatras@orange-ftgroup.com; spencer@wonderhamster.org; = blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] DID Number Mobility and MARTINI Bruno, Yes, I thought that was what you were asking for. Let's see whether the = WG agrees with that requirement. Comments? John > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: 18 February 2010 16:00 > To: Elwell, John; spencer@wonderhamster.org; > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI > > Hi John, > > You almost wrote the text for such a requirement. > > "An edge proxy shall be able to base identity assertions for > outbound (non-REGISTER) requests received from a PBX on > whether the identity concerned has been registered." > > Are you looking for a more formal comment on the requirements > document? > > Bruno > > > -----Message d'origine----- > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 > > =C0 : CHATRAS Bruno RD-CORE-ISS; spencer@wonderhamster.org; > > blindsay@nortel.com; adam@nostrum.com; pkyzivat@cisco.com > > Cc : bernard_aboba@hotmail.com; martini@ietf.org > > Objet : RE: [martini] DID Number Mobility and MARTINI > > > > Bruno, > > > > This depends whether we have a requirement for an edge proxy > > to be able to base identity assertions for outbound > > (non-REGISTER) requests on whether the identity concerned has > > been registered. We don't have such a requirement at present, > > so if you think we need such a requirement, please propose > > text for the requirements document. > > > > John > > > > > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 17 February 2010 14:29 > > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com; > > > adam@nostrum.com; pkyzivat@cisco.com > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > A good solution should work irrespective of which proxy is > > > responsibile for asserting identities, including the case > > where this > > > is the edge proxy. > > > > > > > -----Message d'origine----- > > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno > > > > RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com; > > > > adam@nostrum.com; pkyzivat@cisco.com Cc : > > bernard_aboba@hotmail.com; > > > > martini@ietf.org Objet : RE: [martini] DID Number Mobility and > > > > MARTINI > > > > > > > > Bruno, > > > > > > > > Thanks. However, this particular reason for a proxy > needing this > > > > information is because of an architecture where the proxy is > > > > assigned responsibility for asserting an identity for the > > source of > > > > a request. If the domain proxy takes on this > > responsibility instead, > > > > problem solved. So it is a question of whether this particular > > > > architecture is common enough that we need a solution > > that conveys > > > > registered identities to the edge proxy. IMS solves this > > using PAU > > > > (ignoring issues of response size), so the question for > others is > > > > whether there are other architectures in practice where this is > > > > important. I guess for this particular usage it doesn't matter > > > > whether the information is in the REGISTER request or the > > REGISTER > > > > response. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: bruno.chatras@orange-ftgroup.com > > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > > Sent: 17 February 2010 12:45 > > > > > To: Elwell, John; spencer@wonderhamster.org; > > blindsay@nortel.com; > > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > My view is that there is no strong need need for > carrying this > > > > > information accross the SIP-PBX - SSP interface. However this > > > > > information needs to be provided by the SSP's Registrar to > > > > the SSP's > > > > > edge proxy so as to enable the edge proxy to assert > identities > > > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > > > > > -----Message d'origine----- > > > > > > De : martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > > John Envoy=E9 > > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > > Brian Lindsay; > > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > > Objet : Re: > > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > > part of the > > > > > > MARTINI mechanism (as opposed to provisioning) an > > > > explicit list of > > > > > > numbers and/or contacts (I won't try to tie down which at > > > > present), > > > > > > I think it is important to understand which direction > > > > this is needed > > > > > > in, because that will go some way towards determining the > > > > mechanism. > > > > > > Do people think: > > > > > > > > > > > > a) there is good reason for providing this > information in the > > > > > > direction SIP-PBX to SSP (in which case inclusion in > > a REGISTER > > > > > > request might be one solution); or > > > > > > > > > > > > b) there is a good reason for providing this > > information in the > > > > > > direction SSP to SIP-PBX (in which case reg-events > > might be one > > > > > > solution); or > > > > > > > > > > > > c) it doesn't matter which direction - either direction > > > would be > > > > > > good enough so that at least one side is able to detect a > > > > > > discrepancy; or > > > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > > > My personal opinion is e), but I would like to hear other > > > > opinions, > > > > > > with reasons. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: martini-bounces@ietf.org > > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of > > Spencer Dawkins > > > > > > > Sent: 16 February 2010 22:23 > > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > > > I am saying > > > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > > > I'm trying > > > > > > > to tease out is whether we can just say "we're not > > > > providing that > > > > > > > information in the REGISTER exchange, BUT you can get that > > > > > > information > > > > > > > using regevents", so that we can move on - I haven't > > > > heard anyone > > > > > > > propose that MARTINI would say "MUST NOT use > regevents" :-) > > > > > > > > > > > > > > I would be comfortable if our specifications were > > > > silent on this > > > > > > > point, and might be more comfortable if we pointer out > > > > > > somewhere that > > > > > > > the REGISTER exchange does not provide this information, > > > > > but people > > > > > > > who want the information can use regevents or whatever > > > > > other method > > > > > > > seems appropriate to get the information that they want. > > > > > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > > > consensus > > > > > > > is - we only get to recognize what consensus is, and when > > > > > it exists. > > > > > > > For that, we > > > > > > > need to hear from other participants (including you, of > > > > > > course - and > > > > > > > "thank you" to participants who care, and have > > > > expressed opinions > > > > > > > about this, in the current thread. > > > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Brian Lindsay" > > > > > > > To: "Spencer Dawkins" ; > > > "Adam Roach" > > > > > > > ; "Paul Kyzivat" > > > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > > > So basically since the provisioning/sync of the E.164 > > > > > > > numbers/ranges is out of scope I don't see a strong > > > > argument for > > > > > > > including them in the registration transaction. > The Service > > > > > > Provider > > > > > > > has a set of E.164 numbers that, based on prior > > > > > > > assignment/arrangement, it is responsible to route to the > > > > > > SIP PBX. The > > > > > > > SIP PBX is aware of these numbers already. > > > > > > > The registration process (using an AoR identifying the > > > > > SIP PBX) is > > > > > > > intended to provide reachability information for the SIP > > > > > > PBX, in the > > > > > > > absence of static IP address configuration / DNS > (hence the > > > > > > ranges are > > > > > > > not actually required in this transaction). > > > > > > > > > > > > > > Thanks > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > > provisioning > > > > > > > being out of scope, based on what I've been > hearing on this > > > > > > list and > > > > > > > in telechats, etc. > > > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > > provisioning > > > > > > > (ignoring the question direction - I've heard some people > > > > > > suggest each > > > > > > > direction). > > > > > > > It was more like "I expect these numbers to be registered" > > > > > > and/or "I > > > > > > > registered these numbers on your behalf", with the > > > > > question of how > > > > > > > each end knows what numbers "should" be registered being > > > > > > out of scope > > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > > > note below. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I think it's been stated many times in the > threads that > > > > > > > E.164 number > > > > > > > > > > > > > > > provisioning between the enterprise and service provider > > > > > > is out of > > > > > > > > scope of MARTINI. So we're not using the register > > > > > transaction to > > > > > > > > perform any syncronization on these numbers betweeen the > > > > > > enterprise > > > > > > > > and service provider. The registration is just > being used > > > > > > to provide > > > > > > > > reachability info, to allow requests to a set of E.164 > > > > > > numbers to be > > > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > > > ranges need > > > > > > > > to be part of the registration transaction. It'll just > > > > > add extra > > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > > > Regards > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > > Behalf Of Adam Roach > > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > > To: Paul Kyzivat > > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least > > defined a > > > > > > > procedure > > > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > > > indicate which > > > > > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > > > user. So even > > > > > > > > > > > > > > > the original 3GPP implicit approach had an > enumeration of > > > > > > the AORs > > > > > > > > associated with the registration process. > > > > > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > > > than just > > > > > > > > "implicit with a list of AORs," we're proposing > "implicit > > > > > > with *no* > > > > > > > > list of AORs." > > > > > > > > > > > > > > > > So, even if your assertion that our allowing > the implicit > > > > > > > mechanism to > > > > > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > > > here is even > > > > > > > > one step more nebulous. > > > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > > >> Dean, > > > > > > > >> > > > > > > > >> In principle I agree with you. > > > > > > > >> But this horse is already out of the barn with > > IMS implicit > > > > > > > > registration. > > > > > > > >> > > > > > > > >> It was never explicitly brought to the ietf, > > though things > > > > > > > linked to > > > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > > > we could say > > > > > > > >> that is not our problem, I think we already implicitly > > > > > > approved it > > > > > > > >> via > > > > > > > > > > > > > > > >> benign neglect. > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > >> Paul > > > > > > > >> > > > > > > > >> Dean Willis wrote: > > > > > > > >>> > > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > > >>> > > > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > > > DID number > > > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > > > WG charter. > > > > > > > >>>> > > > > > > > >>>> The question on the table (see > > > > > > > >>>> > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > > >>>> ) > > > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > > requirement or not. > > > > > > > >>>> Feel free > > > > > > > >>>> to respond and provide your opinion on that thread. > > > > > > > >>> > > > > > > > >>> Explicit is its own reward. > > > > > > > >>> > > > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > > > does is bind > > > > > > > >>> an > > > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > > involved are > > > > > > > >>> explicitly encoded in the request. > > > > > > > >>> > > > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > > > to multiple > > > > > > > >>> Contacts. This seems like a reasonable extension to > > > > > > simplify life > > > > > > > >>> for > > > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > > > should respect > > > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > > > and Contacts > > > > > > > >>> involved. > > > > > > > >>> > > > > > > > >>> From a requirements perspective, I'd be happy with a > > > > > > requirement > > > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > > > indicated by the > > > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > > requirement to > > > > > > > >>> produce > > > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > > >>> > > > > > > > >>> -- > > > > > > > >>> 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 > > > > > > > > > > > > > _______________________________________________ > > > > > > 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. > > > ******************************** > > > > > > > > > > ********************************* > 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 BLINDSAY@nortel.com Thu Feb 18 11: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 5574928C16C for ; Thu, 18 Feb 2010 11:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 Obp1e1Rvczvz for ; Thu, 18 Feb 2010 11:07:22 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3D23228C0E9 for ; Thu, 18 Feb 2010 11:07:22 -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 o1IJ8MX03960; Thu, 18 Feb 2010 19:08: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Feb 2010 14:08:15 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> In-Reply-To: <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMAAGg3dQ References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <977 0_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> From: "Brian Lindsay" To: , , , , Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 19:07:24 -0000 Hi Bruno, I'm just curious about this works for cases where SIP PBXs don't = actually register (e.g. have a static IP address, DNS is used, etc). Thanks Brian -----Original Message----- From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Thursday, February 18, 2010 11:00 AM To: john.elwell@siemens-enterprise.com; spencer@wonderhamster.org; = Lindsay, Brian (CAR:AR00); adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: RE: [martini] DID Number Mobility and MARTINI Hi John, You almost wrote the text for such a requirement. "An edge proxy shall be able to base identity assertions for outbound = (non-REGISTER) requests received from a PBX on whether the identity = concerned has been registered."=20 Are you looking for a more formal comment on the requirements document? Bruno > -----Message d'origine----- > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 =C0 : CHATRAS Bruno = RD-CORE-ISS;=20 > spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com;=20 > pkyzivat@cisco.com Cc : bernard_aboba@hotmail.com; martini@ietf.org=20 > Objet : RE: [martini] DID Number Mobility and MARTINI >=20 > Bruno, >=20 > This depends whether we have a requirement for an edge proxy to be=20 > able to base identity assertions for outbound > (non-REGISTER) requests on whether the identity concerned has been=20 > registered. We don't have such a requirement at present, so if you=20 > think we need such a requirement, please propose text for the=20 > requirements document. >=20 > John >=20 >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com=20 > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: 17 February 2010 14:29 > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > adam@nostrum.com; pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > A good solution should work irrespective of which proxy is=20 > > responsibile for asserting identities, including the case > where this > > is the edge proxy. > > > > > -----Message d'origine----- > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno=20 > > > RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > > adam@nostrum.com; pkyzivat@cisco.com Cc : > bernard_aboba@hotmail.com; > > > martini@ietf.org Objet : RE: [martini] DID Number Mobility and=20 > > > MARTINI > > > > > > Bruno, > > > > > > Thanks. However, this particular reason for a proxy needing this=20 > > > information is because of an architecture where the proxy is=20 > > > assigned responsibility for asserting an identity for the > source of > > > a request. If the domain proxy takes on this > responsibility instead, > > > problem solved. So it is a question of whether this particular=20 > > > architecture is common enough that we need a solution > that conveys > > > registered identities to the edge proxy. IMS solves this > using PAU > > > (ignoring issues of response size), so the question for others is=20 > > > whether there are other architectures in practice where this is=20 > > > important. I guess for this particular usage it doesn't matter=20 > > > whether the information is in the REGISTER request or the > REGISTER > > > response. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: bruno.chatras@orange-ftgroup.com=20 > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > Sent: 17 February 2010 12:45 > > > > To: Elwell, John; spencer@wonderhamster.org; > blindsay@nortel.com; > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > My view is that there is no strong need need for carrying this=20 > > > > information accross the SIP-PBX - SSP interface. However this=20 > > > > information needs to be provided by the SSP's Registrar to > > > the SSP's > > > > edge proxy so as to enable the edge proxy to assert identities=20 > > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > > > -----Message d'origine----- > > > > > De : martini-bounces@ietf.org > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > John Envoy=E9 > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > Brian Lindsay; > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > Objet : Re: > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > part of the > > > > > MARTINI mechanism (as opposed to provisioning) an > > > explicit list of > > > > > numbers and/or contacts (I won't try to tie down which at > > > present), > > > > > I think it is important to understand which direction > > > this is needed > > > > > in, because that will go some way towards determining the > > > mechanism. > > > > > Do people think: > > > > > > > > > > a) there is good reason for providing this information in the=20 > > > > > direction SIP-PBX to SSP (in which case inclusion in > a REGISTER > > > > > request might be one solution); or > > > > > > > > > > b) there is a good reason for providing this > information in the > > > > > direction SSP to SIP-PBX (in which case reg-events > might be one > > > > > solution); or > > > > > > > > > > c) it doesn't matter which direction - either direction > > would be > > > > > good enough so that at least one side is able to detect a=20 > > > > > discrepancy; or > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > My personal opinion is e), but I would like to hear other > > > opinions, > > > > > with reasons. > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: martini-bounces@ietf.org=20 > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of > Spencer Dawkins > > > > > > Sent: 16 February 2010 22:23 > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > > I am saying > > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > > I'm trying > > > > > > to tease out is whether we can just say "we're not > > > providing that > > > > > > information in the REGISTER exchange, BUT you can get that > > > > > information > > > > > > using regevents", so that we can move on - I haven't > > > heard anyone > > > > > > propose that MARTINI would say "MUST NOT use regevents" :-) > > > > > > > > > > > > I would be comfortable if our specifications were > > > silent on this > > > > > > point, and might be more comfortable if we pointer out > > > > > somewhere that > > > > > > the REGISTER exchange does not provide this information, > > > > but people > > > > > > who want the information can use regevents or whatever > > > > other method > > > > > > seems appropriate to get the information that they want. > > > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > > consensus > > > > > > is - we only get to recognize what consensus is, and when > > > > it exists. > > > > > > For that, we > > > > > > need to hear from other participants (including you, of > > > > > course - and > > > > > > "thank you" to participants who care, and have > > > expressed opinions > > > > > > about this, in the current thread. > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Spencer > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Brian Lindsay" > > > > > > To: "Spencer Dawkins" ; > > "Adam Roach" > > > > > > ; "Paul Kyzivat" > > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > So basically since the provisioning/sync of the E.164=20 > > > > > > numbers/ranges is out of scope I don't see a strong > > > argument for > > > > > > including them in the registration transaction. The Service > > > > > Provider > > > > > > has a set of E.164 numbers that, based on prior=20 > > > > > > assignment/arrangement, it is responsible to route to the > > > > > SIP PBX. The > > > > > > SIP PBX is aware of these numbers already. > > > > > > The registration process (using an AoR identifying the > > > > SIP PBX) is > > > > > > intended to provide reachability information for the SIP > > > > > PBX, in the > > > > > > absence of static IP address configuration / DNS (hence the > > > > > ranges are > > > > > > not actually required in this transaction). > > > > > > > > > > > > Thanks > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > provisioning > > > > > > being out of scope, based on what I've been hearing on this > > > > > list and > > > > > > in telechats, etc. > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > provisioning > > > > > > (ignoring the question direction - I've heard some people > > > > > suggest each > > > > > > direction). > > > > > > It was more like "I expect these numbers to be registered" > > > > > and/or "I > > > > > > registered these numbers on your behalf", with the > > > > question of how > > > > > > each end knows what numbers "should" be registered being > > > > > out of scope > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > > note below. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I think it's been stated many times in the threads that > > > > > > E.164 number > > > > > > > > > > > > > provisioning between the enterprise and service provider > > > > > is out of > > > > > > > scope of MARTINI. So we're not using the register > > > > transaction to > > > > > > > perform any syncronization on these numbers betweeen the > > > > > enterprise > > > > > > > and service provider. The registration is just being used > > > > > to provide > > > > > > > reachability info, to allow requests to a set of E.164 > > > > > numbers to be > > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > > ranges need > > > > > > > to be part of the registration transaction. It'll just > > > > add extra > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > Regards > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: martini-bounces@ietf.org > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > Behalf Of Adam Roach > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > To: Paul Kyzivat > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least > defined a > > > > > > procedure > > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > > indicate which > > > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > > user. So even > > > > > > > > > > > > > the original 3GPP implicit approach had an enumeration of > > > > > the AORs > > > > > > > associated with the registration process. > > > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > > than just > > > > > > > "implicit with a list of AORs," we're proposing "implicit > > > > > with *no* > > > > > > > list of AORs." > > > > > > > > > > > > > > So, even if your assertion that our allowing the implicit > > > > > > mechanism to > > > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > > here is even > > > > > > > one step more nebulous. > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > >> Dean, > > > > > > >> > > > > > > >> In principle I agree with you. > > > > > > >> But this horse is already out of the barn with > IMS implicit > > > > > > > registration. > > > > > > >> > > > > > > >> It was never explicitly brought to the ietf, > though things > > > > > > linked to > > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > > we could say > > > > > > >> that is not our problem, I think we already implicitly > > > > > approved it > > > > > > >> via > > > > > > > > > > > > > >> benign neglect. > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Paul > > > > > > >> > > > > > > >> Dean Willis wrote: > > > > > > >>> > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > >>> > > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > > DID number > > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > > WG charter. > > > > > > >>>> > > > > > > >>>> The question on the table (see > > > > > > >>>> > > > > > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > >>>> ) > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > requirement or not. > > > > > > >>>> Feel free > > > > > > >>>> to respond and provide your opinion on that thread. > > > > > > >>> > > > > > > >>> Explicit is its own reward. > > > > > > >>> > > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > > does is bind > > > > > > >>> an > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > involved are > > > > > > >>> explicitly encoded in the request. > > > > > > >>> > > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > > to multiple > > > > > > >>> Contacts. This seems like a reasonable extension to > > > > > simplify life > > > > > > >>> for > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > > should respect > > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > > and Contacts > > > > > > >>> involved. > > > > > > >>> > > > > > > >>> From a requirements perspective, I'd be happy with a > > > > > requirement > > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > > indicated by the > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > requirement to > > > > > > >>> produce > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > >>> > > > > > > >>> -- > > > > > > >>> 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 > > > > > > > > > > > _______________________________________________ > > > > > martini mailing list > > > > > martini@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/martini > > > > > > > > > > > > > ********************************* This message and any=20 > > > > 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. > > ******************************** > > > > >=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 bruno.chatras@orange-ftgroup.com Thu Feb 18 11:15: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 B0C763A71BD for ; Thu, 18 Feb 2010 11:15:49 -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 uE7gHKF0szd2 for ; Thu, 18 Feb 2010 11:15:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 38C543A7EDF for ; Thu, 18 Feb 2010 11:15:46 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 580A9374536; Thu, 18 Feb 2010 20:17:28 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 3BB94180056; Thu, 18 Feb 2010 20:17: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, 18 Feb 2010 20:17:28 +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, 18 Feb 2010 20:17:17 +0100 Message-ID: <31048_1266520648_4B7D9248_31048_10997_1_9ECCF01B52E7AB408A7EB85352642141011D8D05@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMAAGg3dQAAApNoA= References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9 770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> From: To: , , , , X-OriginalArrivalTime: 18 Feb 2010 19:17:28.0559 (UTC) FILETIME=[02D31FF0:01CAB0CF] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.18.171229 Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 19:15:49 -0000 In this case you need a work-around of course... One option consists in ins= erting an adaptor between the PBX and the edge proxy. The adaptor sneds th= e REGISTER request on behalf of the PBX. Another option consists in sending= an O&M command to the edge proxy that triggers the sending a REGISTER requ= est with appropriate parameters to the registrar... > -----Message d'origine----- > De : Brian Lindsay [mailto:blindsay@nortel.com]=20 > Envoy=E9 : jeudi 18 f=E9vrier 2010 20:08 > =C0 : CHATRAS Bruno RD-CORE-ISS;=20 > john.elwell@siemens-enterprise.com;=20 > spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com > Cc : bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] DID Number Mobility and MARTINI >=20 > Hi Bruno, >=20 > I'm just curious about this works for cases where SIP PBXs=20 > don't actually register (e.g. have a static IP address, DNS=20 > is used, etc). >=20 > Thanks > Brian >=20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: Thursday, February 18, 2010 11:00 AM > To: john.elwell@siemens-enterprise.com;=20 > spencer@wonderhamster.org; Lindsay, Brian (CAR:AR00);=20 > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > Hi John, >=20 > You almost wrote the text for such a requirement. >=20 > "An edge proxy shall be able to base identity assertions for=20 > outbound (non-REGISTER) requests received from a PBX on=20 > whether the identity concerned has been registered."=20 >=20 > Are you looking for a more formal comment on the requirements=20 > document? >=20 > Bruno >=20 > > -----Message d'origine----- > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 =C0 : CHATRAS Bruno=20 > RD-CORE-ISS;=20 > > spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com;=20 > > pkyzivat@cisco.com Cc : bernard_aboba@hotmail.com; martini@ietf.org=20 > > Objet : RE: [martini] DID Number Mobility and MARTINI > >=20 > > Bruno, > >=20 > > This depends whether we have a requirement for an edge proxy to be=20 > > able to base identity assertions for outbound > > (non-REGISTER) requests on whether the identity concerned has been=20 > > registered. We don't have such a requirement at present, so if you=20 > > think we need such a requirement, please propose text for the=20 > > requirements document. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com=20 > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 17 February 2010 14:29 > > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > > adam@nostrum.com; pkyzivat@cisco.com > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > A good solution should work irrespective of which proxy is=20 > > > responsibile for asserting identities, including the case > > where this > > > is the edge proxy. > > > > > > > -----Message d'origine----- > > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno=20 > > > > RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > > > adam@nostrum.com; pkyzivat@cisco.com Cc : > > bernard_aboba@hotmail.com; > > > > martini@ietf.org Objet : RE: [martini] DID Number Mobility and=20 > > > > MARTINI > > > > > > > > Bruno, > > > > > > > > Thanks. However, this particular reason for a proxy=20 > needing this=20 > > > > information is because of an architecture where the proxy is=20 > > > > assigned responsibility for asserting an identity for the > > source of > > > > a request. If the domain proxy takes on this > > responsibility instead, > > > > problem solved. So it is a question of whether this particular=20 > > > > architecture is common enough that we need a solution > > that conveys > > > > registered identities to the edge proxy. IMS solves this > > using PAU > > > > (ignoring issues of response size), so the question for=20 > others is=20 > > > > whether there are other architectures in practice where this is=20 > > > > important. I guess for this particular usage it doesn't matter=20 > > > > whether the information is in the REGISTER request or the > > REGISTER > > > > response. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: bruno.chatras@orange-ftgroup.com=20 > > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > > Sent: 17 February 2010 12:45 > > > > > To: Elwell, John; spencer@wonderhamster.org; > > blindsay@nortel.com; > > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > My view is that there is no strong need need for=20 > carrying this=20 > > > > > information accross the SIP-PBX - SSP interface. However this=20 > > > > > information needs to be provided by the SSP's Registrar to > > > > the SSP's > > > > > edge proxy so as to enable the edge proxy to assert=20 > identities=20 > > > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > > > > > -----Message d'origine----- > > > > > > De : martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > > John Envoy=E9 > > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > > Brian Lindsay; > > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > > Objet : Re: > > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > > part of the > > > > > > MARTINI mechanism (as opposed to provisioning) an > > > > explicit list of > > > > > > numbers and/or contacts (I won't try to tie down which at > > > > present), > > > > > > I think it is important to understand which direction > > > > this is needed > > > > > > in, because that will go some way towards determining the > > > > mechanism. > > > > > > Do people think: > > > > > > > > > > > > a) there is good reason for providing this=20 > information in the=20 > > > > > > direction SIP-PBX to SSP (in which case inclusion in > > a REGISTER > > > > > > request might be one solution); or > > > > > > > > > > > > b) there is a good reason for providing this > > information in the > > > > > > direction SSP to SIP-PBX (in which case reg-events > > might be one > > > > > > solution); or > > > > > > > > > > > > c) it doesn't matter which direction - either direction > > > would be > > > > > > good enough so that at least one side is able to detect a=20 > > > > > > discrepancy; or > > > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > > > My personal opinion is e), but I would like to hear other > > > > opinions, > > > > > > with reasons. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: martini-bounces@ietf.org=20 > > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of > > Spencer Dawkins > > > > > > > Sent: 16 February 2010 22:23 > > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > > > I am saying > > > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > > > I'm trying > > > > > > > to tease out is whether we can just say "we're not > > > > providing that > > > > > > > information in the REGISTER exchange, BUT you can get that > > > > > > information > > > > > > > using regevents", so that we can move on - I haven't > > > > heard anyone > > > > > > > propose that MARTINI would say "MUST NOT use=20 > regevents" :-) > > > > > > > > > > > > > > I would be comfortable if our specifications were > > > > silent on this > > > > > > > point, and might be more comfortable if we pointer out > > > > > > somewhere that > > > > > > > the REGISTER exchange does not provide this information, > > > > > but people > > > > > > > who want the information can use regevents or whatever > > > > > other method > > > > > > > seems appropriate to get the information that they want. > > > > > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > > > consensus > > > > > > > is - we only get to recognize what consensus is, and when > > > > > it exists. > > > > > > > For that, we > > > > > > > need to hear from other participants (including you, of > > > > > > course - and > > > > > > > "thank you" to participants who care, and have > > > > expressed opinions > > > > > > > about this, in the current thread. > > > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Brian Lindsay" > > > > > > > To: "Spencer Dawkins" ; > > > "Adam Roach" > > > > > > > ; "Paul Kyzivat" > > > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > > > So basically since the provisioning/sync of the E.164=20 > > > > > > > numbers/ranges is out of scope I don't see a strong > > > > argument for > > > > > > > including them in the registration transaction.=20 > The Service > > > > > > Provider > > > > > > > has a set of E.164 numbers that, based on prior=20 > > > > > > > assignment/arrangement, it is responsible to route to the > > > > > > SIP PBX. The > > > > > > > SIP PBX is aware of these numbers already. > > > > > > > The registration process (using an AoR identifying the > > > > > SIP PBX) is > > > > > > > intended to provide reachability information for the SIP > > > > > > PBX, in the > > > > > > > absence of static IP address configuration / DNS=20 > (hence the > > > > > > ranges are > > > > > > > not actually required in this transaction). > > > > > > > > > > > > > > Thanks > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > > provisioning > > > > > > > being out of scope, based on what I've been=20 > hearing on this > > > > > > list and > > > > > > > in telechats, etc. > > > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > > provisioning > > > > > > > (ignoring the question direction - I've heard some people > > > > > > suggest each > > > > > > > direction). > > > > > > > It was more like "I expect these numbers to be registered" > > > > > > and/or "I > > > > > > > registered these numbers on your behalf", with the > > > > > question of how > > > > > > > each end knows what numbers "should" be registered being > > > > > > out of scope > > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > > > note below. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I think it's been stated many times in the=20 > threads that > > > > > > > E.164 number > > > > > > > > > > > > > > > provisioning between the enterprise and service provider > > > > > > is out of > > > > > > > > scope of MARTINI. So we're not using the register > > > > > transaction to > > > > > > > > perform any syncronization on these numbers betweeen the > > > > > > enterprise > > > > > > > > and service provider. The registration is just=20 > being used > > > > > > to provide > > > > > > > > reachability info, to allow requests to a set of E.164 > > > > > > numbers to be > > > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > > > ranges need > > > > > > > > to be part of the registration transaction. It'll just > > > > > add extra > > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > > > Regards > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > > Behalf Of Adam Roach > > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > > To: Paul Kyzivat > > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least > > defined a > > > > > > > procedure > > > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > > > indicate which > > > > > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > > > user. So even > > > > > > > > > > > > > > > the original 3GPP implicit approach had an=20 > enumeration of > > > > > > the AORs > > > > > > > > associated with the registration process. > > > > > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > > > than just > > > > > > > > "implicit with a list of AORs," we're proposing=20 > "implicit > > > > > > with *no* > > > > > > > > list of AORs." > > > > > > > > > > > > > > > > So, even if your assertion that our allowing=20 > the implicit > > > > > > > mechanism to > > > > > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > > > here is even > > > > > > > > one step more nebulous. > > > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > > >> Dean, > > > > > > > >> > > > > > > > >> In principle I agree with you. > > > > > > > >> But this horse is already out of the barn with > > IMS implicit > > > > > > > > registration. > > > > > > > >> > > > > > > > >> It was never explicitly brought to the ietf, > > though things > > > > > > > linked to > > > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > > > we could say > > > > > > > >> that is not our problem, I think we already implicitly > > > > > > approved it > > > > > > > >> via > > > > > > > > > > > > > > > >> benign neglect. > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > >> Paul > > > > > > > >> > > > > > > > >> Dean Willis wrote: > > > > > > > >>> > > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > > >>> > > > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > > > DID number > > > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > > > WG charter. > > > > > > > >>>> > > > > > > > >>>> The question on the table (see > > > > > > > >>>> > > > > > > > > > > >=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > > >>>> ) > > > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > > requirement or not. > > > > > > > >>>> Feel free > > > > > > > >>>> to respond and provide your opinion on that thread. > > > > > > > >>> > > > > > > > >>> Explicit is its own reward. > > > > > > > >>> > > > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > > > does is bind > > > > > > > >>> an > > > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > > involved are > > > > > > > >>> explicitly encoded in the request. > > > > > > > >>> > > > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > > > to multiple > > > > > > > >>> Contacts. This seems like a reasonable extension to > > > > > > simplify life > > > > > > > >>> for > > > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > > > should respect > > > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > > > and Contacts > > > > > > > >>> involved. > > > > > > > >>> > > > > > > > >>> From a requirements perspective, I'd be happy with a > > > > > > requirement > > > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > > > indicated by the > > > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > > requirement to > > > > > > > >>> produce > > > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > > >>> > > > > > > > >>> -- > > > > > > > >>> 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 > > > > > > > > > > > > > _______________________________________________ > > > > > > martini mailing list > > > > > > martini@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/martini > > > > > > > > > > > > > > > > ********************************* This message and any=20 > > > > > 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. > > > ******************************** > > > > > > > >=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 BLINDSAY@nortel.com Thu Feb 18 12:16: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 6E5833A75C6 for ; Thu, 18 Feb 2010 12:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 dlXpank6OTTP for ; Thu, 18 Feb 2010 12:16:25 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 087493A6EAE for ; Thu, 18 Feb 2010 12:16:24 -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 o1IKHQl28982; Thu, 18 Feb 2010 20:17:26 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Feb 2010 15:16:41 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C94A12B@zcarhxm1.corp.nortel.com> In-Reply-To: <31048_1266520648_4B7D9248_31048_10997_1_9ECCF01B52E7AB408A7EB85352642141011D8D05@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMAAGg3dQAAApNoAAAePfUA== References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> < 9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> <31048_1266520648_4B7D9248_31048_10997_1_9ECCF01B52E7AB408A7EB85352642141011D8D05@ftrdmel0.rd.francetelecom.fr> From: "Brian Lindsay" To: , , , , Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 20:16:28 -0000 Hi Bruno, Thanks. So there are cases where edge proxies perform a surrogate = registration. I was wondering about cases where the "core" network itself isn't = using a registration-based approach for a SIP PBX, but just uses a = static IP or dns for routing towards the SIP PBX.=20 How do edge proxies operate in that context? Would they still manage = identify assertion and would they they typically be provisioned with = address info to do so? Just wondering what the existing baseline = solutions are for this. Thanks Brian -----Original Message----- From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Thursday, February 18, 2010 2:17 PM To: Lindsay, Brian (CAR:AR00); john.elwell@siemens-enterprise.com; = spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: RE: [martini] DID Number Mobility and MARTINI In this case you need a work-around of course... One option consists in = inserting an adaptor between the PBX and the edge proxy. The adaptor = sneds the REGISTER request on behalf of the PBX. Another option consists = in sending an O&M command to the edge proxy that triggers the sending a = REGISTER request with appropriate parameters to the registrar... > -----Message d'origine----- > De : Brian Lindsay [mailto:blindsay@nortel.com] Envoy=E9 : jeudi 18=20 > f=E9vrier 2010 20:08 =C0 : CHATRAS Bruno RD-CORE-ISS;=20 > john.elwell@siemens-enterprise.com; > spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com Cc :=20 > bernard_aboba@hotmail.com; martini@ietf.org Objet : RE: [martini] DID=20 > Number Mobility and MARTINI >=20 > Hi Bruno, >=20 > I'm just curious about this works for cases where SIP PBXs don't=20 > actually register (e.g. have a static IP address, DNS is used, etc). >=20 > Thanks > Brian >=20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: Thursday, February 18, 2010 11:00 AM > To: john.elwell@siemens-enterprise.com; > spencer@wonderhamster.org; Lindsay, Brian (CAR:AR00);=20 > adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > Hi John, >=20 > You almost wrote the text for such a requirement. >=20 > "An edge proxy shall be able to base identity assertions for outbound=20 > (non-REGISTER) requests received from a PBX on whether the identity=20 > concerned has been registered." >=20 > Are you looking for a more formal comment on the requirements=20 > document? >=20 > Bruno >=20 > > -----Message d'origine----- > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 =C0 : CHATRAS Bruno > RD-CORE-ISS; > > spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com;=20 > > pkyzivat@cisco.com Cc : bernard_aboba@hotmail.com; martini@ietf.org=20 > > Objet : RE: [martini] DID Number Mobility and MARTINI > >=20 > > Bruno, > >=20 > > This depends whether we have a requirement for an edge proxy to be=20 > > able to base identity assertions for outbound > > (non-REGISTER) requests on whether the identity concerned has been=20 > > registered. We don't have such a requirement at present, so if you=20 > > think we need such a requirement, please propose text for the=20 > > requirements document. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com=20 > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 17 February 2010 14:29 > > > To: Elwell, John; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > > adam@nostrum.com; pkyzivat@cisco.com > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > A good solution should work irrespective of which proxy is=20 > > > responsibile for asserting identities, including the case > > where this > > > is the edge proxy. > > > > > > > -----Message d'origine----- > > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno=20 > > > > RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > > > adam@nostrum.com; pkyzivat@cisco.com Cc : > > bernard_aboba@hotmail.com; > > > > martini@ietf.org Objet : RE: [martini] DID Number Mobility and=20 > > > > MARTINI > > > > > > > > Bruno, > > > > > > > > Thanks. However, this particular reason for a proxy > needing this > > > > information is because of an architecture where the proxy is=20 > > > > assigned responsibility for asserting an identity for the > > source of > > > > a request. If the domain proxy takes on this > > responsibility instead, > > > > problem solved. So it is a question of whether this particular=20 > > > > architecture is common enough that we need a solution > > that conveys > > > > registered identities to the edge proxy. IMS solves this > > using PAU > > > > (ignoring issues of response size), so the question for > others is > > > > whether there are other architectures in practice where this is=20 > > > > important. I guess for this particular usage it doesn't matter=20 > > > > whether the information is in the REGISTER request or the > > REGISTER > > > > response. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: bruno.chatras@orange-ftgroup.com=20 > > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > > Sent: 17 February 2010 12:45 > > > > > To: Elwell, John; spencer@wonderhamster.org; > > blindsay@nortel.com; > > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > My view is that there is no strong need need for > carrying this > > > > > information accross the SIP-PBX - SSP interface. However this=20 > > > > > information needs to be provided by the SSP's Registrar to > > > > the SSP's > > > > > edge proxy so as to enable the edge proxy to assert > identities > > > > > received from the PBX in a P-Preferred-Identity header field. > > > > > > > > > > > -----Message d'origine----- > > > > > > De : martini-bounces@ietf.org=20 > > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > > John Envoy=E9 > > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > > Brian Lindsay; > > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > > Objet : Re: > > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > > part of the > > > > > > MARTINI mechanism (as opposed to provisioning) an > > > > explicit list of > > > > > > numbers and/or contacts (I won't try to tie down which at > > > > present), > > > > > > I think it is important to understand which direction > > > > this is needed > > > > > > in, because that will go some way towards determining the > > > > mechanism. > > > > > > Do people think: > > > > > > > > > > > > a) there is good reason for providing this > information in the > > > > > > direction SIP-PBX to SSP (in which case inclusion in > > a REGISTER > > > > > > request might be one solution); or > > > > > > > > > > > > b) there is a good reason for providing this > > information in the > > > > > > direction SSP to SIP-PBX (in which case reg-events > > might be one > > > > > > solution); or > > > > > > > > > > > > c) it doesn't matter which direction - either direction > > > would be > > > > > > good enough so that at least one side is able to detect a=20 > > > > > > discrepancy; or > > > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > > > My personal opinion is e), but I would like to hear other > > > > opinions, > > > > > > with reasons. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: martini-bounces@ietf.org=20 > > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of > > Spencer Dawkins > > > > > > > Sent: 16 February 2010 22:23 > > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Speaking carefully as chair, and Bernard can correct me if > > > > > > I am saying > > > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > > > > > I happen to agree with your reasoning, re: REGISTER. What > > > > > > I'm trying > > > > > > > to tease out is whether we can just say "we're not > > > > providing that > > > > > > > information in the REGISTER exchange, BUT you can get that > > > > > > information > > > > > > > using regevents", so that we can move on - I haven't > > > > heard anyone > > > > > > > propose that MARTINI would say "MUST NOT use > regevents" :-) > > > > > > > > > > > > > > I would be comfortable if our specifications were > > > > silent on this > > > > > > > point, and might be more comfortable if we pointer out > > > > > > somewhere that > > > > > > > the REGISTER exchange does not provide this information, > > > > > but people > > > > > > > who want the information can use regevents or whatever > > > > > other method > > > > > > > seems appropriate to get the information that they want. > > > > > > > > > > > > > > But (Bernard and) I don't get to decide what working group > > > > > > consensus > > > > > > > is - we only get to recognize what consensus is, and when > > > > > it exists. > > > > > > > For that, we > > > > > > > need to hear from other participants (including you, of > > > > > > course - and > > > > > > > "thank you" to participants who care, and have > > > > expressed opinions > > > > > > > about this, in the current thread. > > > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Brian Lindsay" > > > > > > > To: "Spencer Dawkins" ; > > > "Adam Roach" > > > > > > > ; "Paul Kyzivat" > > > > > > > Cc: "Bernard Aboba" ; "MARTINI" > > > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > > > So basically since the provisioning/sync of the E.164=20 > > > > > > > numbers/ranges is out of scope I don't see a strong > > > > argument for > > > > > > > including them in the registration transaction.=20 > The Service > > > > > > Provider > > > > > > > has a set of E.164 numbers that, based on prior=20 > > > > > > > assignment/arrangement, it is responsible to route to the > > > > > > SIP PBX. The > > > > > > > SIP PBX is aware of these numbers already. > > > > > > > The registration process (using an AoR identifying the > > > > > SIP PBX) is > > > > > > > intended to provide reachability information for the SIP > > > > > > PBX, in the > > > > > > > absence of static IP address configuration / DNS > (hence the > > > > > > ranges are > > > > > > > not actually required in this transaction). > > > > > > > > > > > > > > Thanks > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > > provisioning > > > > > > > being out of scope, based on what I've been > hearing on this > > > > > > list and > > > > > > > in telechats, etc. > > > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > > provisioning > > > > > > > (ignoring the question direction - I've heard some people > > > > > > suggest each > > > > > > > direction). > > > > > > > It was more like "I expect these numbers to be registered" > > > > > > and/or "I > > > > > > > registered these numbers on your behalf", with the > > > > > question of how > > > > > > > each end knows what numbers "should" be registered being > > > > > > out of scope > > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > > > At least, that's the context in which I was reading Adam's > > > > > > note below. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I think it's been stated many times in the > threads that > > > > > > > E.164 number > > > > > > > > > > > > > > > provisioning between the enterprise and service provider > > > > > > is out of > > > > > > > > scope of MARTINI. So we're not using the register > > > > > transaction to > > > > > > > > perform any syncronization on these numbers betweeen the > > > > > > enterprise > > > > > > > > and service provider. The registration is just > being used > > > > > > to provide > > > > > > > > reachability info, to allow requests to a set of E.164 > > > > > > numbers to be > > > > > > > > routed to the SIP PBX. As such, I don't think the number > > > > > > ranges need > > > > > > > > to be part of the registration transaction. It'll just > > > > > add extra > > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > > > Regards > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: martini-bounces@ietf.org > > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > > Behalf Of Adam Roach > > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > > To: Paul Kyzivat > > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least > > defined a > > > > > > > procedure > > > > > > > > -- through a questionable use of P-Associated-URI -- to > > > > > > > indicate which > > > > > > > > > > > > > > > URIs the registrar would be registering on behalf of the > > > > > > > user. So even > > > > > > > > > > > > > > > the original 3GPP implicit approach had an > enumeration of > > > > > > the AORs > > > > > > > > associated with the registration process. > > > > > > > > > > > > > > > > We're proposing to be even more sparse than that. Rather > > > > > > than just > > > > > > > > "implicit with a list of AORs," we're proposing > "implicit > > > > > > with *no* > > > > > > > > list of AORs." > > > > > > > > > > > > > > > > So, even if your assertion that our allowing > the implicit > > > > > > > mechanism to > > > > > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > > > here is even > > > > > > > > one step more nebulous. > > > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > > >> Dean, > > > > > > > >> > > > > > > > >> In principle I agree with you. > > > > > > > >> But this horse is already out of the barn with > > IMS implicit > > > > > > > > registration. > > > > > > > >> > > > > > > > >> It was never explicitly brought to the ietf, > > though things > > > > > > > linked to > > > > > > > >> it like P-Asserted-ID and P-Associated-URI were. While > > > > > > we could say > > > > > > > >> that is not our problem, I think we already implicitly > > > > > > approved it > > > > > > > >> via > > > > > > > > > > > > > > > >> benign neglect. > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > >> Paul > > > > > > > >> > > > > > > > >> Dean Willis wrote: > > > > > > > >>> > > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > > >>> > > > > > > > >>>> Speaking as co-chair, the non-registration aspects of > > > > > > DID number > > > > > > > >>>> mobility are outside the scope of the current MARTINI > > > > > > WG charter. > > > > > > > >>>> > > > > > > > >>>> The question on the table (see > > > > > > > >>>> > > > > > > > > > > >=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > > >>>> ) > > > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > > requirement or not. > > > > > > > >>>> Feel free > > > > > > > >>>> to respond and provide your opinion on that thread. > > > > > > > >>> > > > > > > > >>> Explicit is its own reward. > > > > > > > >>> > > > > > > > >>> Remember, the one thing that RFC 3261 REGISTER really > > > > > > does is bind > > > > > > > >>> an > > > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > > involved are > > > > > > > >>> explicitly encoded in the request. > > > > > > > >>> > > > > > > > >>> I'm OKAY with extending REGISTER to bind multiple AORs > > > > > > to multiple > > > > > > > >>> Contacts. This seems like a reasonable extension to > > > > > > simplify life > > > > > > > >>> for > > > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > > > should respect > > > > > > > >>> the history of REGISTERs explicit encoding of the AORs > > > > > > > and Contacts > > > > > > > >>> involved. > > > > > > > >>> > > > > > > > >>> From a requirements perspective, I'd be happy with a > > > > > > requirement > > > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > > > indicated by the > > > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > > requirement to > > > > > > > >>> produce > > > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > > >>> > > > > > > > >>> -- > > > > > > > >>> 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 > > > > > > > > > > > > > _______________________________________________ > > > > > > martini mailing list > > > > > > martini@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/martini > > > > > > > > > > > > > > > > ********************************* This message and any=20 > > > > > 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. > > > ******************************** > > > > > > > >=20 >=20 > ********************************* > This message and any attachments (the "message") are 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 altered,=20 > changed or falsified. > If you are not the intended addressee of this message, please cancel=20 > it immediately and inform the sender. > ******************************** >=20 >=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 bruno.chatras@orange-ftgroup.com Thu Feb 18 12:25: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 2DD7928C16F for ; Thu, 18 Feb 2010 12:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=0.027, 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 IveTT5dMvyq2 for ; Thu, 18 Feb 2010 12:25: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 557E428C18A for ; Thu, 18 Feb 2010 12:25:36 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 888AF248AAF; Thu, 18 Feb 2010 21:27:18 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6A8EC238041; Thu, 18 Feb 2010 21:27:18 +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, 18 Feb 2010 21:27:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Feb 2010 21:27:15 +0100 Message-ID: <4563_1266524838_4B7DA2A6_4563_27332_1_9ECCF01B52E7AB408A7EB85352642141011D8D0C@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C94A12B@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMAAGg3dQAAApNoAAAePfUAAAvNLQ References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> <31048_1266520648_4B7D9248_31048_10997_1_9ECCF01B52E7AB408A7EB85352642141011D8D05@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C94A12B@zcarhxm1.corp.nortel.com> From: To: , , , , X-OriginalArrivalTime: 18 Feb 2010 20:27:18.0557 (UTC) FILETIME=[C44214D0:01CAB0D8] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.18.193921 Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 20:25:39 -0000 This sounds like you are referring to what ETSI calls the "peering-based" a= pproach. In this case the edge proxy does not assert identities. It receive= s a P-Asserted-Identity header field from the PBX rather than a P-Preferred= -Identity. The SSP has to trust the enterprise network. > -----Message d'origine----- > De : Brian Lindsay [mailto:blindsay@nortel.com]=20 > Envoy=E9 : jeudi 18 f=E9vrier 2010 21:17 > =C0 : CHATRAS Bruno RD-CORE-ISS;=20 > john.elwell@siemens-enterprise.com;=20 > spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com > Cc : bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] DID Number Mobility and MARTINI >=20 >=20 > Hi Bruno, >=20 > Thanks. So there are cases where edge proxies perform a=20 > surrogate registration. >=20 > I was wondering about cases where the "core" network=20 > itself isn't using a registration-based approach for a SIP=20 > PBX, but just uses a static IP or dns for routing towards the=20 > SIP PBX.=20 >=20 > How do edge proxies operate in that context? Would they=20 > still manage identify assertion and would they they typically=20 > be provisioned with address info to do so? Just wondering=20 > what the existing baseline solutions are for this. >=20 > Thanks > Brian >=20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: Thursday, February 18, 2010 2:17 PM > To: Lindsay, Brian (CAR:AR00);=20 > john.elwell@siemens-enterprise.com;=20 > spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI >=20 > In this case you need a work-around of course... One option=20 > consists in inserting an adaptor between the PBX and the=20 > edge proxy. The adaptor sneds the REGISTER request on behalf=20 > of the PBX. Another option consists in sending an O&M command=20 > to the edge proxy that triggers the sending a REGISTER=20 > request with appropriate parameters to the registrar... >=20 > > -----Message d'origine----- > > De : Brian Lindsay [mailto:blindsay@nortel.com] Envoy=E9 : jeudi 18=20 > > f=E9vrier 2010 20:08 =C0 : CHATRAS Bruno RD-CORE-ISS;=20 > > john.elwell@siemens-enterprise.com; > > spencer@wonderhamster.org; adam@nostrum.com;=20 > pkyzivat@cisco.com Cc :=20 > > bernard_aboba@hotmail.com; martini@ietf.org Objet : RE:=20 > [martini] DID=20 > > Number Mobility and MARTINI > >=20 > > Hi Bruno, > >=20 > > I'm just curious about this works for cases where SIP PBXs don't=20 > > actually register (e.g. have a static IP address, DNS is used, etc). > >=20 > > Thanks > > Brian > >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com=20 > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: Thursday, February 18, 2010 11:00 AM > > To: john.elwell@siemens-enterprise.com; > > spencer@wonderhamster.org; Lindsay, Brian (CAR:AR00);=20 > > adam@nostrum.com; pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > >=20 > > Hi John, > >=20 > > You almost wrote the text for such a requirement. > >=20 > > "An edge proxy shall be able to base identity assertions=20 > for outbound > > (non-REGISTER) requests received from a PBX on whether the identity=20 > > concerned has been registered." > >=20 > > Are you looking for a more formal comment on the requirements=20 > > document? > >=20 > > Bruno > >=20 > > > -----Message d'origine----- > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 =C0 : CHATRAS Bruno > > RD-CORE-ISS; > > > spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com;=20 > > > pkyzivat@cisco.com Cc : bernard_aboba@hotmail.com;=20 > martini@ietf.org=20 > > > Objet : RE: [martini] DID Number Mobility and MARTINI > > >=20 > > > Bruno, > > >=20 > > > This depends whether we have a requirement for an edge=20 > proxy to be=20 > > > able to base identity assertions for outbound > > > (non-REGISTER) requests on whether the identity concerned=20 > has been=20 > > > registered. We don't have such a requirement at present,=20 > so if you=20 > > > think we need such a requirement, please propose text for the=20 > > > requirements document. > > >=20 > > > John > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: bruno.chatras@orange-ftgroup.com=20 > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > Sent: 17 February 2010 14:29 > > > > To: Elwell, John; spencer@wonderhamster.org;=20 > blindsay@nortel.com;=20 > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > A good solution should work irrespective of which proxy is=20 > > > > responsibile for asserting identities, including the case > > > where this > > > > is the edge proxy. > > > > > > > > > -----Message d'origine----- > > > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno= =20 > > > > > RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com;=20 > > > > > adam@nostrum.com; pkyzivat@cisco.com Cc : > > > bernard_aboba@hotmail.com; > > > > > martini@ietf.org Objet : RE: [martini] DID Number=20 > Mobility and=20 > > > > > MARTINI > > > > > > > > > > Bruno, > > > > > > > > > > Thanks. However, this particular reason for a proxy > > needing this > > > > > information is because of an architecture where the proxy is=20 > > > > > assigned responsibility for asserting an identity for the > > > source of > > > > > a request. If the domain proxy takes on this > > > responsibility instead, > > > > > problem solved. So it is a question of whether this=20 > particular=20 > > > > > architecture is common enough that we need a solution > > > that conveys > > > > > registered identities to the edge proxy. IMS solves this > > > using PAU > > > > > (ignoring issues of response size), so the question for > > others is > > > > > whether there are other architectures in practice=20 > where this is=20 > > > > > important. I guess for this particular usage it=20 > doesn't matter=20 > > > > > whether the information is in the REGISTER request or the > > > REGISTER > > > > > response. > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: bruno.chatras@orange-ftgroup.com=20 > > > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > > > Sent: 17 February 2010 12:45 > > > > > > To: Elwell, John; spencer@wonderhamster.org; > > > blindsay@nortel.com; > > > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > My view is that there is no strong need need for > > carrying this > > > > > > information accross the SIP-PBX - SSP interface.=20 > However this=20 > > > > > > information needs to be provided by the SSP's Registrar to > > > > > the SSP's > > > > > > edge proxy so as to enable the edge proxy to assert > > identities > > > > > > received from the PBX in a P-Preferred-Identity=20 > header field. > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De : martini-bounces@ietf.org=20 > > > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > > > John Envoy=E9 > > > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > > > Brian Lindsay; > > > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > > > Objet : Re: > > > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > > > part of the > > > > > > > MARTINI mechanism (as opposed to provisioning) an > > > > > explicit list of > > > > > > > numbers and/or contacts (I won't try to tie down which at > > > > > present), > > > > > > > I think it is important to understand which direction > > > > > this is needed > > > > > > > in, because that will go some way towards determining the > > > > > mechanism. > > > > > > > Do people think: > > > > > > > > > > > > > > a) there is good reason for providing this > > information in the > > > > > > > direction SIP-PBX to SSP (in which case inclusion in > > > a REGISTER > > > > > > > request might be one solution); or > > > > > > > > > > > > > > b) there is a good reason for providing this > > > information in the > > > > > > > direction SSP to SIP-PBX (in which case reg-events > > > might be one > > > > > > > solution); or > > > > > > > > > > > > > > c) it doesn't matter which direction - either direction > > > > would be > > > > > > > good enough so that at least one side is able to detect a=20 > > > > > > > discrepancy; or > > > > > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > > > > > My personal opinion is e), but I would like to hear other > > > > > opinions, > > > > > > > with reasons. > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: martini-bounces@ietf.org=20 > > > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of > > > Spencer Dawkins > > > > > > > > Sent: 16 February 2010 22:23 > > > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > > > Speaking carefully as chair, and Bernard can=20 > correct me if > > > > > > > I am saying > > > > > > > > things I should not be saying as chair, at this point... > > > > > > > > > > > > > > > > I happen to agree with your reasoning, re:=20 > REGISTER. What > > > > > > > I'm trying > > > > > > > > to tease out is whether we can just say "we're not > > > > > providing that > > > > > > > > information in the REGISTER exchange, BUT you=20 > can get that > > > > > > > information > > > > > > > > using regevents", so that we can move on - I haven't > > > > > heard anyone > > > > > > > > propose that MARTINI would say "MUST NOT use > > regevents" :-) > > > > > > > > > > > > > > > > I would be comfortable if our specifications were > > > > > silent on this > > > > > > > > point, and might be more comfortable if we pointer out > > > > > > > somewhere that > > > > > > > > the REGISTER exchange does not provide this information, > > > > > > but people > > > > > > > > who want the information can use regevents or whatever > > > > > > other method > > > > > > > > seems appropriate to get the information that they want. > > > > > > > > > > > > > > > > But (Bernard and) I don't get to decide what=20 > working group > > > > > > > consensus > > > > > > > > is - we only get to recognize what consensus=20 > is, and when > > > > > > it exists. > > > > > > > > For that, we > > > > > > > > need to hear from other participants (including you, of > > > > > > > course - and > > > > > > > > "thank you" to participants who care, and have > > > > > expressed opinions > > > > > > > > about this, in the current thread. > > > > > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Brian Lindsay" > > > > > > > > To: "Spencer Dawkins" ; > > > > "Adam Roach" > > > > > > > > ; "Paul Kyzivat" > > > > > > > > Cc: "Bernard Aboba"=20 > ; "MARTINI" > > > > > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > > > > > So basically since the provisioning/sync of=20 > the E.164=20 > > > > > > > > numbers/ranges is out of scope I don't see a strong > > > > > argument for > > > > > > > > including them in the registration transaction.=20 > > The Service > > > > > > > Provider > > > > > > > > has a set of E.164 numbers that, based on prior=20 > > > > > > > > assignment/arrangement, it is responsible to=20 > route to the > > > > > > > SIP PBX. The > > > > > > > > SIP PBX is aware of these numbers already. > > > > > > > > The registration process (using an AoR identifying the > > > > > > SIP PBX) is > > > > > > > > intended to provide reachability information for the SIP > > > > > > > PBX, in the > > > > > > > > absence of static IP address configuration / DNS > > (hence the > > > > > > > ranges are > > > > > > > > not actually required in this transaction). > > > > > > > > > > > > > > > > Thanks > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat > > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > > > provisioning > > > > > > > > being out of scope, based on what I've been > > hearing on this > > > > > > > list and > > > > > > > > in telechats, etc. > > > > > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > > > provisioning > > > > > > > > (ignoring the question direction - I've heard=20 > some people > > > > > > > suggest each > > > > > > > > direction). > > > > > > > > It was more like "I expect these numbers to be=20 > registered" > > > > > > > and/or "I > > > > > > > > registered these numbers on your behalf", with the > > > > > > question of how > > > > > > > > each end knows what numbers "should" be registered being > > > > > > > out of scope > > > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > > > > > At least, that's the context in which I was=20 > reading Adam's > > > > > > > note below. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I think it's been stated many times in the > > threads that > > > > > > > > E.164 number > > > > > > > > > > > > > > > > > provisioning between the enterprise and=20 > service provider > > > > > > > is out of > > > > > > > > > scope of MARTINI. So we're not using the register > > > > > > transaction to > > > > > > > > > perform any syncronization on these numbers=20 > betweeen the > > > > > > > enterprise > > > > > > > > > and service provider. The registration is just > > being used > > > > > > > to provide > > > > > > > > > reachability info, to allow requests to a set of E.164 > > > > > > > numbers to be > > > > > > > > > routed to the SIP PBX. As such, I don't think=20 > the number > > > > > > > ranges need > > > > > > > > > to be part of the registration transaction. It'll just > > > > > > add extra > > > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: martini-bounces@ietf.org > > > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > > > Behalf Of Adam Roach > > > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > > > To: Paul Kyzivat > > > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least > > > defined a > > > > > > > > procedure > > > > > > > > > -- through a questionable use of=20 > P-Associated-URI -- to > > > > > > > > indicate which > > > > > > > > > > > > > > > > > URIs the registrar would be registering on=20 > behalf of the > > > > > > > > user. So even > > > > > > > > > > > > > > > > > the original 3GPP implicit approach had an > > enumeration of > > > > > > > the AORs > > > > > > > > > associated with the registration process. > > > > > > > > > > > > > > > > > > We're proposing to be even more sparse than=20 > that. Rather > > > > > > > than just > > > > > > > > > "implicit with a list of AORs," we're proposing > > "implicit > > > > > > > with *no* > > > > > > > > > list of AORs." > > > > > > > > > > > > > > > > > > So, even if your assertion that our allowing > > the implicit > > > > > > > > mechanism to > > > > > > > > > > > > > > > > > stand is somehow tacit approval, what's being proposed > > > > > > > here is even > > > > > > > > > one step more nebulous. > > > > > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > > > >> Dean, > > > > > > > > >> > > > > > > > > >> In principle I agree with you. > > > > > > > > >> But this horse is already out of the barn with > > > IMS implicit > > > > > > > > > registration. > > > > > > > > >> > > > > > > > > >> It was never explicitly brought to the ietf, > > > though things > > > > > > > > linked to > > > > > > > > >> it like P-Asserted-ID and P-Associated-URI=20 > were. While > > > > > > > we could say > > > > > > > > >> that is not our problem, I think we already=20 > implicitly > > > > > > > approved it > > > > > > > > >> via > > > > > > > > > > > > > > > > > >> benign neglect. > > > > > > > > >> > > > > > > > > >> Thanks, > > > > > > > > >> Paul > > > > > > > > >> > > > > > > > > >> Dean Willis wrote: > > > > > > > > >>> > > > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > > > >>> > > > > > > > > >>>> Speaking as co-chair, the non-registration=20 > aspects of > > > > > > > DID number > > > > > > > > >>>> mobility are outside the scope of the=20 > current MARTINI > > > > > > > WG charter. > > > > > > > > >>>> > > > > > > > > >>>> The question on the table (see > > > > > > > > >>>> > > > > > > > > > > > > >=20 > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > > > >>>> ) > > > > > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > > > requirement or not. > > > > > > > > >>>> Feel free > > > > > > > > >>>> to respond and provide your opinion on that thread. > > > > > > > > >>> > > > > > > > > >>> Explicit is its own reward. > > > > > > > > >>> > > > > > > > > >>> Remember, the one thing that RFC 3261=20 > REGISTER really > > > > > > > does is bind > > > > > > > > >>> an > > > > > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > > > involved are > > > > > > > > >>> explicitly encoded in the request. > > > > > > > > >>> > > > > > > > > >>> I'm OKAY with extending REGISTER to bind=20 > multiple AORs > > > > > > > to multiple > > > > > > > > >>> Contacts. This seems like a reasonable extension to > > > > > > > simplify life > > > > > > > > >>> for > > > > > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I really think we > > > > > > > > should respect > > > > > > > > >>> the history of REGISTERs explicit encoding=20 > of the AORs > > > > > > > > and Contacts > > > > > > > > >>> involved. > > > > > > > > >>> > > > > > > > > >>> From a requirements perspective, I'd be=20 > happy with a > > > > > > > requirement > > > > > > > > >>> along the lines of "must not preclude AOR mobility > > > > > > > > indicated by the > > > > > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > > > requirement to > > > > > > > > >>> produce > > > > > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > > > >>> > > > > > > > > >>> -- > > > > > > > > >>> 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 > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > martini mailing list > > > > > > > martini@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/martini > > > > > > > > > > > > > > > > > > > ********************************* This message and any=20 > > > > > > 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. > > > > ******************************** > > > > > > > > > > >=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 > >=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 pkyzivat@cisco.com Thu Feb 18 13:08: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 5EC4E3A7FE9 for ; Thu, 18 Feb 2010 13:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 iKw05iFPfJwP for ; Thu, 18 Feb 2010 13:08:25 -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 D77CE3A8023 for ; Thu, 18 Feb 2010 13:08:24 -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: Av0EAO47fUtAZnwM/2dsb2JhbACPL4tZdKVRmASCSAGCHgSDFYs/ X-IronPort-AV: E=Sophos;i="4.49,499,1262563200"; d="scan'208";a="87170184" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2010 21:10:07 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1ILA6AZ006049; Thu, 18 Feb 2010 21:10:06 GMT Message-ID: <4B7DACEA.1030101@cisco.com> Date: Thu, 18 Feb 2010 16:11:06 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> <31048_1266520648_4B7D9248_31048_10997_1_9ECCF01B52E7AB408A7EB85352642141011D8D05@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C94A12B@zcarhxm1.corp.nortel.com> <4563_1266524838_4B7DA2A6_4563_27332_1_9ECCF01B52E7AB408A7EB85352642141011D8D0C@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4563_1266524838_4B7DA2A6_4563_27332_1_9ECCF01B52E7AB408A7EB85352642141011D8D0C@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: martini@ietf.org, bernard_aboba@hotmail.com Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 21:08:27 -0000 Why would using DNS rather than registration have anything to do with trust, or lack of trust, in the PBX? Registration is not the only form of authentication. Thanks, Paul bruno.chatras@orange-ftgroup.com wrote: > This sounds like you are referring to what ETSI calls the "peering-based" approach. In this case the edge proxy does not assert identities. It receives a P-Asserted-Identity header field from the PBX rather than a P-Preferred-Identity. The SSP has to trust the enterprise network. > >> -----Message d'origine----- >> De : Brian Lindsay [mailto:blindsay@nortel.com] >> Envoyé : jeudi 18 février 2010 21:17 >> À : CHATRAS Bruno RD-CORE-ISS; >> john.elwell@siemens-enterprise.com; >> spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com >> Cc : bernard_aboba@hotmail.com; martini@ietf.org >> Objet : RE: [martini] DID Number Mobility and MARTINI >> >> >> Hi Bruno, >> >> Thanks. So there are cases where edge proxies perform a >> surrogate registration. >> >> I was wondering about cases where the "core" network >> itself isn't using a registration-based approach for a SIP >> PBX, but just uses a static IP or dns for routing towards the >> SIP PBX. >> >> How do edge proxies operate in that context? Would they >> still manage identify assertion and would they they typically >> be provisioned with address info to do so? Just wondering >> what the existing baseline solutions are for this. >> >> Thanks >> Brian >> >> -----Original Message----- >> From: bruno.chatras@orange-ftgroup.com >> [mailto:bruno.chatras@orange-ftgroup.com] >> Sent: Thursday, February 18, 2010 2:17 PM >> To: Lindsay, Brian (CAR:AR00); >> john.elwell@siemens-enterprise.com; >> spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com >> Cc: bernard_aboba@hotmail.com; martini@ietf.org >> Subject: RE: [martini] DID Number Mobility and MARTINI >> >> In this case you need a work-around of course... One option >> consists in inserting an adaptor between the PBX and the >> edge proxy. The adaptor sneds the REGISTER request on behalf >> of the PBX. Another option consists in sending an O&M command >> to the edge proxy that triggers the sending a REGISTER >> request with appropriate parameters to the registrar... >> >>> -----Message d'origine----- >>> De : Brian Lindsay [mailto:blindsay@nortel.com] Envoyé : jeudi 18 >>> février 2010 20:08 À : CHATRAS Bruno RD-CORE-ISS; >>> john.elwell@siemens-enterprise.com; >>> spencer@wonderhamster.org; adam@nostrum.com; >> pkyzivat@cisco.com Cc : >>> bernard_aboba@hotmail.com; martini@ietf.org Objet : RE: >> [martini] DID >>> Number Mobility and MARTINI >>> >>> Hi Bruno, >>> >>> I'm just curious about this works for cases where SIP PBXs don't >>> actually register (e.g. have a static IP address, DNS is used, etc). >>> >>> Thanks >>> Brian >>> >>> -----Original Message----- >>> From: bruno.chatras@orange-ftgroup.com >>> [mailto:bruno.chatras@orange-ftgroup.com] >>> Sent: Thursday, February 18, 2010 11:00 AM >>> To: john.elwell@siemens-enterprise.com; >>> spencer@wonderhamster.org; Lindsay, Brian (CAR:AR00); >>> adam@nostrum.com; pkyzivat@cisco.com >>> Cc: bernard_aboba@hotmail.com; martini@ietf.org >>> Subject: RE: [martini] DID Number Mobility and MARTINI >>> >>> Hi John, >>> >>> You almost wrote the text for such a requirement. >>> >>> "An edge proxy shall be able to base identity assertions >> for outbound >>> (non-REGISTER) requests received from a PBX on whether the identity >>> concerned has been registered." >>> >>> Are you looking for a more formal comment on the requirements >>> document? >>> >>> Bruno >>> >>>> -----Message d'origine----- >>>> De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Envoyé : mercredi 17 février 2010 18:05 À : CHATRAS Bruno >>> RD-CORE-ISS; >>>> spencer@wonderhamster.org; blindsay@nortel.com; adam@nostrum.com; >>>> pkyzivat@cisco.com Cc : bernard_aboba@hotmail.com; >> martini@ietf.org >>>> Objet : RE: [martini] DID Number Mobility and MARTINI >>>> >>>> Bruno, >>>> >>>> This depends whether we have a requirement for an edge >> proxy to be >>>> able to base identity assertions for outbound >>>> (non-REGISTER) requests on whether the identity concerned >> has been >>>> registered. We don't have such a requirement at present, >> so if you >>>> think we need such a requirement, please propose text for the >>>> requirements document. >>>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: bruno.chatras@orange-ftgroup.com >>>>> [mailto:bruno.chatras@orange-ftgroup.com] >>>>> Sent: 17 February 2010 14:29 >>>>> To: Elwell, John; spencer@wonderhamster.org; >> blindsay@nortel.com; >>>>> adam@nostrum.com; pkyzivat@cisco.com >>>>> Cc: bernard_aboba@hotmail.com; martini@ietf.org >>>>> Subject: RE: [martini] DID Number Mobility and MARTINI >>>>> >>>>> A good solution should work irrespective of which proxy is >>>>> responsibile for asserting identities, including the case >>>> where this >>>>> is the edge proxy. >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Envoyé : mercredi 17 février 2010 14:37 À : CHATRAS Bruno >>>>>> RD-CORE-ISS; spencer@wonderhamster.org; blindsay@nortel.com; >>>>>> adam@nostrum.com; pkyzivat@cisco.com Cc : >>>> bernard_aboba@hotmail.com; >>>>>> martini@ietf.org Objet : RE: [martini] DID Number >> Mobility and >>>>>> MARTINI >>>>>> >>>>>> Bruno, >>>>>> >>>>>> Thanks. However, this particular reason for a proxy >>> needing this >>>>>> information is because of an architecture where the proxy is >>>>>> assigned responsibility for asserting an identity for the >>>> source of >>>>>> a request. If the domain proxy takes on this >>>> responsibility instead, >>>>>> problem solved. So it is a question of whether this >> particular >>>>>> architecture is common enough that we need a solution >>>> that conveys >>>>>> registered identities to the edge proxy. IMS solves this >>>> using PAU >>>>>> (ignoring issues of response size), so the question for >>> others is >>>>>> whether there are other architectures in practice >> where this is >>>>>> important. I guess for this particular usage it >> doesn't matter >>>>>> whether the information is in the REGISTER request or the >>>> REGISTER >>>>>> response. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: bruno.chatras@orange-ftgroup.com >>>>>>> [mailto:bruno.chatras@orange-ftgroup.com] >>>>>>> Sent: 17 February 2010 12:45 >>>>>>> To: Elwell, John; spencer@wonderhamster.org; >>>> blindsay@nortel.com; >>>>>>> adam@nostrum.com; pkyzivat@cisco.com >>>>>>> Cc: bernard_aboba@hotmail.com; martini@ietf.org >>>>>>> Subject: RE: [martini] DID Number Mobility and MARTINI >>>>>>> >>>>>>> My view is that there is no strong need need for >>> carrying this >>>>>>> information accross the SIP-PBX - SSP interface. >> However this >>>>>>> information needs to be provided by the SSP's Registrar to >>>>>> the SSP's >>>>>>> edge proxy so as to enable the edge proxy to assert >>> identities >>>>>>> received from the PBX in a P-Preferred-Identity >> header field. >>>>>>>> -----Message d'origine----- >>>>>>>> De : martini-bounces@ietf.org >>>>>>>> [mailto:martini-bounces@ietf.org] De la part de Elwell, >>>>>> John Envoyé >>>>>>>> : mercredi 17 février 2010 08:36 À : Spencer Dawkins; >>>>>> Brian Lindsay; >>>>>>>> Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI >>>>> Objet : Re: >>>>>>>> [martini] DID Number Mobility and MARTINI >>>>>>>> >>>>>>>> So in trying to tease out whether there needs to be, as >>>>>> part of the >>>>>>>> MARTINI mechanism (as opposed to provisioning) an >>>>>> explicit list of >>>>>>>> numbers and/or contacts (I won't try to tie down which at >>>>>> present), >>>>>>>> I think it is important to understand which direction >>>>>> this is needed >>>>>>>> in, because that will go some way towards determining the >>>>>> mechanism. >>>>>>>> Do people think: >>>>>>>> >>>>>>>> a) there is good reason for providing this >>> information in the >>>>>>>> direction SIP-PBX to SSP (in which case inclusion in >>>> a REGISTER >>>>>>>> request might be one solution); or >>>>>>>> >>>>>>>> b) there is a good reason for providing this >>>> information in the >>>>>>>> direction SSP to SIP-PBX (in which case reg-events >>>> might be one >>>>>>>> solution); or >>>>>>>> >>>>>>>> c) it doesn't matter which direction - either direction >>>>> would be >>>>>>>> good enough so that at least one side is able to detect a >>>>>>>> discrepancy; or >>>>>>>> >>>>>>>> d) there is a good reason for doing both; or >>>>>>>> >>>>>>>> e) there is no good reason to do either. >>>>>>>> >>>>>>>> My personal opinion is e), but I would like to hear other >>>>>> opinions, >>>>>>>> with reasons. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: martini-bounces@ietf.org >>>>>>>>> [mailto:martini-bounces@ietf.org] On Behalf Of >>>> Spencer Dawkins >>>>>>>>> Sent: 16 February 2010 22:23 >>>>>>>>> To: Brian Lindsay; Adam Roach; Paul Kyzivat >>>>>>>>> Cc: Bernard Aboba; MARTINI >>>>>>>>> Subject: Re: [martini] DID Number Mobility and MARTINI >>>>>>>>> >>>>>>>>> Hi, Brian, >>>>>>>>> >>>>>>>>> Speaking carefully as chair, and Bernard can >> correct me if >>>>>>>> I am saying >>>>>>>>> things I should not be saying as chair, at this point... >>>>>>>>> >>>>>>>>> I happen to agree with your reasoning, re: >> REGISTER. What >>>>>>>> I'm trying >>>>>>>>> to tease out is whether we can just say "we're not >>>>>> providing that >>>>>>>>> information in the REGISTER exchange, BUT you >> can get that >>>>>>>> information >>>>>>>>> using regevents", so that we can move on - I haven't >>>>>> heard anyone >>>>>>>>> propose that MARTINI would say "MUST NOT use >>> regevents" :-) >>>>>>>>> I would be comfortable if our specifications were >>>>>> silent on this >>>>>>>>> point, and might be more comfortable if we pointer out >>>>>>>> somewhere that >>>>>>>>> the REGISTER exchange does not provide this information, >>>>>>> but people >>>>>>>>> who want the information can use regevents or whatever >>>>>>> other method >>>>>>>>> seems appropriate to get the information that they want. >>>>>>>>> >>>>>>>>> But (Bernard and) I don't get to decide what >> working group >>>>>>>> consensus >>>>>>>>> is - we only get to recognize what consensus >> is, and when >>>>>>> it exists. >>>>>>>>> For that, we >>>>>>>>> need to hear from other participants (including you, of >>>>>>>> course - and >>>>>>>>> "thank you" to participants who care, and have >>>>>> expressed opinions >>>>>>>>> about this, in the current thread. >>>>>>>>> >>>>>>>>> I hope this is helpful. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Spencer >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Brian Lindsay" >>>>>>>>> To: "Spencer Dawkins" ; >>>>> "Adam Roach" >>>>>>>>> ; "Paul Kyzivat" >>>>>>>>> Cc: "Bernard Aboba" >> ; "MARTINI" >>>>>>>>> >>>>>>>>> Sent: Tuesday, February 16, 2010 3:51 PM >>>>>>>>> Subject: RE: [martini] DID Number Mobility and MARTINI >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Spencer, >>>>>>>>> >>>>>>>>> So basically since the provisioning/sync of >> the E.164 >>>>>>>>> numbers/ranges is out of scope I don't see a strong >>>>>> argument for >>>>>>>>> including them in the registration transaction. >>> The Service >>>>>>>> Provider >>>>>>>>> has a set of E.164 numbers that, based on prior >>>>>>>>> assignment/arrangement, it is responsible to >> route to the >>>>>>>> SIP PBX. The >>>>>>>>> SIP PBX is aware of these numbers already. >>>>>>>>> The registration process (using an AoR identifying the >>>>>>> SIP PBX) is >>>>>>>>> intended to provide reachability information for the SIP >>>>>>>> PBX, in the >>>>>>>>> absence of static IP address configuration / DNS >>> (hence the >>>>>>>> ranges are >>>>>>>>> not actually required in this transaction). >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Spencer Dawkins [mailto:spencer@wonderhamster.org] >>>>>>>>> Sent: Tuesday, February 16, 2010 4:37 PM >>>>>>>>> To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat >>>>>>>>> Cc: Bernard Aboba; MARTINI >>>>>>>>> Subject: Re: [martini] DID Number Mobility and MARTINI >>>>>>>>> >>>>>>>>> Hi, Brian, >>>>>>>>> >>>>>>>>> Just trying to stay synchronized here. >>>>>>>>> >>>>>>>>> Speaking as an individual, I think you're right about >>>>>>> provisioning >>>>>>>>> being out of scope, based on what I've been >>> hearing on this >>>>>>>> list and >>>>>>>>> in telechats, etc. >>>>>>>>> >>>>>>>>> What I thought Adam was talking about isn't quite >>>>> provisioning >>>>>>>>> (ignoring the question direction - I've heard >> some people >>>>>>>> suggest each >>>>>>>>> direction). >>>>>>>>> It was more like "I expect these numbers to be >> registered" >>>>>>>> and/or "I >>>>>>>>> registered these numbers on your behalf", with the >>>>>>> question of how >>>>>>>>> each end knows what numbers "should" be registered being >>>>>>>> out of scope >>>>>>>>> - because "knowing" was provisioned. >>>>>>>>> >>>>>>>>> At least, that's the context in which I was >> reading Adam's >>>>>>>> note below. >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Spencer >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I think it's been stated many times in the >>> threads that >>>>>>>>> E.164 number >>>>>>>>> >>>>>>>>>> provisioning between the enterprise and >> service provider >>>>>>>> is out of >>>>>>>>>> scope of MARTINI. So we're not using the register >>>>>>> transaction to >>>>>>>>>> perform any syncronization on these numbers >> betweeen the >>>>>>>> enterprise >>>>>>>>>> and service provider. The registration is just >>> being used >>>>>>>> to provide >>>>>>>>>> reachability info, to allow requests to a set of E.164 >>>>>>>> numbers to be >>>>>>>>>> routed to the SIP PBX. As such, I don't think >> the number >>>>>>>> ranges need >>>>>>>>>> to be part of the registration transaction. It'll just >>>>>>> add extra >>>>>>>>>> complexity to the implementations. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: martini-bounces@ietf.org >>>>>>>> [mailto:martini-bounces@ietf.org] On >>>>>>>>>> Behalf Of Adam Roach >>>>>>>>>> Sent: Tuesday, February 16, 2010 1:39 PM >>>>>>>>>> To: Paul Kyzivat >>>>>>>>>> Cc: Bernard Aboba; 'MARTINI' >>>>>>>>>> Subject: Re: [martini] DID Number Mobility and MARTINI >>>>>>>>>> >>>>>>>>>> So, here's what I don't understand: 3GPP at least >>>> defined a >>>>>>>>> procedure >>>>>>>>>> -- through a questionable use of >> P-Associated-URI -- to >>>>>>>>> indicate which >>>>>>>>> >>>>>>>>>> URIs the registrar would be registering on >> behalf of the >>>>>>>>> user. So even >>>>>>>>> >>>>>>>>>> the original 3GPP implicit approach had an >>> enumeration of >>>>>>>> the AORs >>>>>>>>>> associated with the registration process. >>>>>>>>>> >>>>>>>>>> We're proposing to be even more sparse than >> that. Rather >>>>>>>> than just >>>>>>>>>> "implicit with a list of AORs," we're proposing >>> "implicit >>>>>>>> with *no* >>>>>>>>>> list of AORs." >>>>>>>>>> >>>>>>>>>> So, even if your assertion that our allowing >>> the implicit >>>>>>>>> mechanism to >>>>>>>>> >>>>>>>>>> stand is somehow tacit approval, what's being proposed >>>>>>>> here is even >>>>>>>>>> one step more nebulous. >>>>>>>>>> >>>>>>>>>> /a >>>>>>>>>> >>>>>>>>>> On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: >>>>>>>>>>> Dean, >>>>>>>>>>> >>>>>>>>>>> In principle I agree with you. >>>>>>>>>>> But this horse is already out of the barn with >>>> IMS implicit >>>>>>>>>> registration. >>>>>>>>>>> It was never explicitly brought to the ietf, >>>> though things >>>>>>>>> linked to >>>>>>>>>>> it like P-Asserted-ID and P-Associated-URI >> were. While >>>>>>>> we could say >>>>>>>>>>> that is not our problem, I think we already >> implicitly >>>>>>>> approved it >>>>>>>>>>> via >>>>>>>>>>> benign neglect. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> Dean Willis wrote: >>>>>>>>>>>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Speaking as co-chair, the non-registration >> aspects of >>>>>>>> DID number >>>>>>>>>>>>> mobility are outside the scope of the >> current MARTINI >>>>>>>> WG charter. >>>>>>>>>>>>> The question on the table (see >>>>>>>>>>>>> >>> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html >>>>>>>>>>>>> ) >>>>>>>>>>>>> is whether the registration aspects represent a >>>>>>>>> requirement or not. >>>>>>>>>>>>> Feel free >>>>>>>>>>>>> to respond and provide your opinion on that thread. >>>>>>>>>>>> Explicit is its own reward. >>>>>>>>>>>> >>>>>>>>>>>> Remember, the one thing that RFC 3261 >> REGISTER really >>>>>>>> does is bind >>>>>>>>>>>> an >>>>>>>>>>>> AOR to a Contact. Both the AOR and the Contact >>>>>> involved are >>>>>>>>>>>> explicitly encoded in the request. >>>>>>>>>>>> >>>>>>>>>>>> I'm OKAY with extending REGISTER to bind >> multiple AORs >>>>>>>> to multiple >>>>>>>>>>>> Contacts. This seems like a reasonable extension to >>>>>>>> simplify life >>>>>>>>>>>> for >>>>>>>>>>>> a "multi user" SIP user agent. But I really think we >>>>>>>>> should respect >>>>>>>>>>>> the history of REGISTERs explicit encoding >> of the AORs >>>>>>>>> and Contacts >>>>>>>>>>>> involved. >>>>>>>>>>>> >>>>>>>>>>>> From a requirements perspective, I'd be >> happy with a >>>>>>>> requirement >>>>>>>>>>>> along the lines of "must not preclude AOR mobility >>>>>>>>> indicated by the >>>>>>>>> >>>>>>>>>>>> registration." I agree that we can't justify a >>>>>> requirement to >>>>>>>>>>>> produce >>>>>>>>>>>> a mechanism at the time for the whole enchilada. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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. >>>>> ******************************** >>>>> >>>>> >>> ********************************* >>> 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. >> ******************************** >> >> > > ********************************* > 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 adam@nostrum.com Thu Feb 18 14:00: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 5D3443A8043 for ; Thu, 18 Feb 2010 14:00:04 -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.023, 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 RGnrYVk6ztcx for ; Thu, 18 Feb 2010 14:00: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 439663A6F85 for ; Thu, 18 Feb 2010 14:00:02 -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 o1IM1a0A053805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 16:01:36 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7DB8C0.2010502@nostrum.com> Date: Thu, 18 Feb 2010 16:01: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: Spencer Dawkins References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.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 , Bernard Aboba Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 22:00:04 -0000 On 2/18/10 10:44, Feb 18, Spencer Dawkins wrote: > I sent that note as an individual, but I think it's now appropriate > for me to ask, as co-chair, that someone explain why > > - the SIP-PBX can't use MARTINI to provision the SP, AND > > - the SP can't use MARTINI to provision the SIP-PBX, AND I can't even begin to get a grip on your questions. MARTINI isn't about provisioning. /a From adam@nostrum.com Thu Feb 18 15:33: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 9C33A3A7DF9 for ; Thu, 18 Feb 2010 15:33:41 -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, 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 xL-EdG+fy0HL for ; Thu, 18 Feb 2010 15:33:40 -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 6F7F73A7BED for ; Thu, 18 Feb 2010 15:33: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 o1INZJ34060604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 17:35:20 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B7DCEB7.9010501@nostrum.com> Date: Thu, 18 Feb 2010 17:35: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: Spencer Dawkins References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070800000609040806000701" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 23:33:41 -0000 This is a multi-part message in MIME format. --------------070800000609040806000701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/18/10 00:28, Feb 18, Spencer Dawkins wrote: > - (2) if we're saying that provisioning AoRs at the SP AND at the > SIP-PBX is required (and is out of scope for MARTINI - right?), I'm > not sure why the additional effort to provision middleboxes with these > AoRs justifies explicit signaling. > Registration state and provisioning are very different things. Many middleboxes do track registration state. And middleboxes that track registration state need to track registration state to function properly. I'm sure they wouldn't be doing it otherwise, since it's not a particularly cheap operation. And part of normal registration state includes the AOR involved in the registration. Once you're registering multiple AORs in a single registration, it's pretty clear that the registration state includes all of those AORs. So the middleboxes will want to know about them. We can certainly engage in a discussion around whether it makes more sense to provision all the extensions into the middleboxes, but that seems exceedingly operationally expensive. And if we were willing to absorb the cost of additional operational expenses due to provisioning, the answer would be "provision the PBX IP address into the SSP and be done with it" instead of doing all this MARTINI work. /a --------------070800000609040806000701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/18/10 00:28, Feb 18, Spencer Dawkins wrote:
- (2) if we're saying that provisioning AoRs at the SP AND at the SIP-PBX is required (and is out of scope for MARTINI - right?), I'm not sure why the additional effort to provision middleboxes with these AoRs justifies explicit signaling.


Registration state and provisioning are very different things. Many middleboxes do track registration state.

And middleboxes that track registration state need to track registration state to function properly. I'm sure they wouldn't be doing it otherwise, since it's not a particularly cheap operation.

And part of normal registration state includes the AOR involved in the registration.

Once you're registering multiple AORs in a single registration, it's pretty clear that the registration state includes all of those AORs.

So the middleboxes will want to know about them.

We can certainly engage in a discussion around whether it makes more sense to provision all the extensions into the middleboxes, but that seems exceedingly operationally expensive. And if we were willing to absorb the cost of additional operational expenses due to provisioning, the answer would be "provision the PBX IP address into the SSP and be done with it" instead of doing all this MARTINI work.

/a
--------------070800000609040806000701-- From bernard_aboba@hotmail.com Thu Feb 18 15:45: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 BC40B3A7A65 for ; Thu, 18 Feb 2010 15:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.571, 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 3bbAR23C69uu for ; Thu, 18 Feb 2010 15:45:25 -0800 (PST) Received: from blu0-omc1-s23.blu0.hotmail.com (blu0-omc1-s23.blu0.hotmail.com [65.55.116.34]) by core3.amsl.com (Postfix) with ESMTP id 186BF3A73B6 for ; Thu, 18 Feb 2010 15:45:25 -0800 (PST) Received: from BLU137-DS5 ([65.55.116.7]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 15:47:09 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Adam Roach'" , "'Spencer Dawkins'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> <4B7DCEB7.9010501@nostrum.com> In-Reply-To: <4B7DCEB7.9010501@nostrum.com> Date: Thu, 18 Feb 2010 15:47:03 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E6_01CAB0B1.9DF612D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqw8wm22mLK8PGFSe+LIEePNhTLQwAAR8JA Content-Language: en-us X-OriginalArrivalTime: 18 Feb 2010 23:47:09.0396 (UTC) FILETIME=[AF5AE940:01CAB0F4] Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Thu, 18 Feb 2010 23:45:27 -0000 ------=_NextPart_000_00E6_01CAB0B1.9DF612D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Adam Roach said: "Once you're registering multiple AORs in a single registration, it's pretty clear that the registration state includes all of those AORs. So the middleboxes will want to know about them." [BA] I'm curious to understand exactly what the middleboxes need to know and in what situations. After all, there are SSPs out there doing RFC 3263 domain routing without MARTINI, and presumably the middleboxes aren't a problem in that scenario. ------=_NextPart_000_00E6_01CAB0B1.9DF612D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Adam Roach said:


“Once you're registering = multiple AORs in a single registration, it's pretty clear that the registration state = includes all of those AORs.

So the middleboxes will want to know about them.”

 

[BA] I’m curious to understand exactly what the = middleboxes need to know and in what situations.  After all, there are SSPs out = there doing RFC 3263 domain routing without MARTINI, and presumably the middleboxes = aren’t a problem in that scenario. 

------=_NextPart_000_00E6_01CAB0B1.9DF612D0-- From spencer@wonderhamster.org Thu Feb 18 16:21: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 845D93A7904 for ; Thu, 18 Feb 2010 16:21:47 -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 FSYX3BVNCp6u for ; Thu, 18 Feb 2010 16:21:46 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 98E413A6BF8 for ; Thu, 18 Feb 2010 16:21:46 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0McDMd-1NPmRg2VOB-00JnHO; Thu, 18 Feb 2010 19:22:29 -0500 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> <4B7DB8C0.2010502@nostrum.com> Date: Thu, 18 Feb 2010 18:22:10 -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: V01U2FsdGVkX19lEKDCuaQ1rEqFdVxShjwM6Nx4dpjt3DBUtf1 CPKwAt7DnFRzUM9dp/pGG/Z/9rNkmsXvsV5xNAD+dL4ev5auAJ 7+bCEgVrUrM/QdV+YHKhZRUaScPyd9Z/w/oh11piDk= Cc: MARTINI , Bernard Aboba Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 00:21:47 -0000 Hi, Adam, >> I sent that note as an individual, but I think it's now appropriate for >> me to ask, as co-chair, that someone explain why >> >> - the SIP-PBX can't use MARTINI to provision the SP, AND >> >> - the SP can't use MARTINI to provision the SIP-PBX, AND > > I can't even begin to get a grip on your questions. MARTINI isn't about > provisioning. I may not have been clear enough - my point was that MARTINI isn't about provisioning either end, so that's happening some other way on both ends, so why would we suddenly we need explicit lists so that the middlebox can figure out what's going on - that's what I wasn't understanding. Thanks, Spencer From dean.willis@softarmor.com Thu Feb 18 22:03: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 1CA3828C143 for ; Thu, 18 Feb 2010 22:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Ti7kqaQR8YoP for ; Thu, 18 Feb 2010 22:03:04 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2C7183A80BB for ; Thu, 18 Feb 2010 22:03:04 -0800 (PST) Received: from [10.58.96.138] (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 o1J63Oul031879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 00:03:26 -0600 Message-ID: <4B7E29A6.7070400@softarmor.com> Date: Fri, 19 Feb 2010 00:03:18 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Spencer Dawkins References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MARTINI , Bernard Aboba Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 06:03:05 -0000 Spencer Dawkins wrote: > ... > "- (2) if we're saying that provisioning AoRs at the SP AND at the > SIP-PBX is required (and is out of scope for MARTINI - right?), I'm > not sure why the additional effort to provision middleboxes with these > AoRs justifies explicit signaling." > > I sent that note as an individual, but I think it's now appropriate > for me to ask, as co-chair, that someone explain why > > - the SIP-PBX can't use MARTINI to provision the SP, AND > > - the SP can't use MARTINI to provision the SIP-PBX, AND > > - we have to explicitly include the list of AoRs in signaling because > there are middleboxes that neither end can provision > Because "provision", in bellheadspeak, is either an arcane swearword or a description of the most complex, highly-regulated, and frequently audited process of the entire operations world, and is supported by the most expensive single software system in a service provider environment. It is generally easier to obtain revisions to the great holy books of any major religion than it is to change a provisioning system. If Social Security is the third rail of American politics (referring to that part of an electric train track that will electrocute you if touched), the provisioning is the third rail of service provider politics. Congratulations, you've just been electrocuted. Dynamic binding and "gate unlocking" are therefore NOT provisioning. -- Dean From dean.willis@softarmor.com Thu Feb 18 22:11: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 DD29E28C1D9 for ; Thu, 18 Feb 2010 22:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 s1liRe52NyDh for ; Thu, 18 Feb 2010 22:11:25 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B693B28C1D6 for ; Thu, 18 Feb 2010 22:11:10 -0800 (PST) Received: from [10.58.96.138] (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 o1J6CoSs031940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 00:12:52 -0600 Message-ID: <4B7E2BDC.3070009@softarmor.com> Date: Fri, 19 Feb 2010 00:12:44 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Kyzivat References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> <31048_1266520648_4B7D9248_31048_10997_1_9ECCF01B52E7AB408A7EB85352642141011D8D05@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C94A12B@zcarhxm1.corp.nortel.com> <4563_1266524838_4B7DA2A6_4563_27332_1_9ECCF01B52E7AB408A7EB85352642141011D8D0C@ftrdmel0.rd.francetelecom.fr> <4B7DACEA.1030101@cisco.com> In-Reply-To: <4B7DACEA.1030101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 06:11:31 -0000 Paul Kyzivat wrote: > Why would using DNS rather than registration have anything to do with > trust, or lack of trust, in the PBX? Registration is not the only form > of authentication. > Registration is the only authenticated exchange in classic IMS. This "mistake" (as I railed against it muchly at the time) has consequences like only being able to trust-anchor in a REGISTER transaction, or have to rely on entirely contractual trust anchoring. Oddly enough, the problem was derived from the method name REGISTER, which sounded too much like "registration" in a GSM system and was consequently forced to function the same way. If we had called the method SETCONTACT to start with, everything would be different today. This also gets back to Christer's question about the negativity of our experience with implicit invocations. Other things that might be pointed out are implicit subscriptions on REFER (giving us norefersub as a needed extension), implicit terminations (requiring regevent in IMS), the nightmare of implicit bandwidth gating in the early PacketCable work, and many more that I'm just too tired of to keep in my head. -- Dean From dean.willis@softarmor.com Thu Feb 18 22:17: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 8EE5928C1D0 for ; Thu, 18 Feb 2010 22:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 QjgbjWnLDlze for ; Thu, 18 Feb 2010 22:17:10 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 54BB93A7E57 for ; Thu, 18 Feb 2010 22:17:10 -0800 (PST) Received: from [10.58.96.138] (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 o1J6IrvH031992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 00:18:54 -0600 Message-ID: <4B7E2D47.9060501@softarmor.com> Date: Fri, 19 Feb 2010 00:18:47 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bernard Aboba References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> <4B7DCEB7.9010501@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 06:17:14 -0000 Bernard Aboba wrote: > > *Adam Roach said: * > > > “Once you're registering multiple AORs in a single registration, it's > pretty clear that the registration state includes all of those AORs. > > So the middleboxes will want to know about them.” > > *[BA] I’m curious to understand exactly what the middleboxes need to > know and in what situations. After all, there are SSPs out there doing > RFC 3263 domain routing without MARTINI, and presumably the > middleboxes aren’t a problem in that scenario. *** > The middleboxes will block any request message sent towards the PBX that contains a Request-URI which does not match a Contact seen in a current registration by that middlebox. In other words, if the middlebox hasn't seen a REGISTER for that URI, it blocks all requests being sent to that URI. Envision, if you will, a spam control mechanism that only allows your email server to receive SMTP messages for a given email address if, in the preceding few seconds, your email server had POPed messages that were to that same email address. It's an absolutely barbaric thing for a middlebox to do, but some people would rather do stuff like this than use real identity mechanisms. Go figure. -- Dean From spencer@wonderhamster.org Thu Feb 18 22:48: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 5E14A3A80C8 for ; Thu, 18 Feb 2010 22:48:31 -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, 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 6HsRjrHEAhw6 for ; Thu, 18 Feb 2010 22:48:29 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id BA0C63A7B16 for ; Thu, 18 Feb 2010 22:48:29 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LtZQC-1NqERO1iY0-011J2h; Fri, 19 Feb 2010 01:49:28 -0500 Message-ID: <9E28E51137ED46A2B8534BAD96036F8A@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> <4B7E29A6.7070400@softarmor.com> Date: Fri, 19 Feb 2010 00:49:08 -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: V01U2FsdGVkX19JkxOweXV02C7Cic5/DqBham3Q0sVSRBUCUBF JmLUW/pyvsE0hRstE/dHRAxU1amQMeIr0CeN53k2vKzNXKyQQX IG5BudC0EhaqPidikF6YzX4Wc421LafOD+gkB09wB4= Cc: MARTINI , Bernard Aboba Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 06:48:31 -0000 I should probably stop posting (as an individual) in this thread, but ... > Spencer Dawkins wrote: >> ... > >> "- (2) if we're saying that provisioning AoRs at the SP AND at the >> SIP-PBX is required (and is out of scope for MARTINI - right?), I'm >> not sure why the additional effort to provision middleboxes with these >> AoRs justifies explicit signaling." >> >> I sent that note as an individual, but I think it's now appropriate >> for me to ask, as co-chair, that someone explain why >> >> - the SIP-PBX can't use MARTINI to provision the SP, AND >> >> - the SP can't use MARTINI to provision the SIP-PBX, AND >> >> - we have to explicitly include the list of AoRs in signaling because >> there are middleboxes that neither end can provision >> > > Because "provision", in bellheadspeak, is either an arcane swearword or > a description of the most complex, highly-regulated, and frequently > audited process of the entire operations world, and is supported by the > most expensive single software system in a service provider environment. > It is generally easier to obtain revisions to the great holy books of > any major religion than it is to change a provisioning system. > > If Social Security is the third rail of American politics (referring to > that part of an electric train track that will electrocute you if > touched), the provisioning is the third rail of service provider > politics. Congratulations, you've just been electrocuted. > > > Dynamic binding and "gate unlocking" are therefore NOT provisioning. I'm trying to tug at the reaons that people have suggested sending lists of AoRs explicitly in signaling, and "indication of what AoRs were being registered to intermediate devices" was on the list of reasons that Adam thoughtfully provided in http://www.ietf.org/mail-archive/web/martini/current/msg00757.html. What I'm trying to ask, perhaps not using helpful terminology, is why middleboxes that I believe are under the same administrative control as either the SP or the SIP-PBX, need to be treated differently than we're treating the SP and the SIP-PBX in MARTINI. I tried to be clear that MARTINI wasn't provisioning in my post at http://www.ietf.org/mail-archive/web/martini/current/msg00783.html, but you may be correct that the word "provisioning" is so poisonous that I can't use it in a sentence that people can parse. If that's true, I apologise for using the word. But ... my understanding is that, by some process that is out of scope for MARTINI, the SP and the SIP-PBX both automagically know, without either telling the other, what AoRs would be registered, and I'm asking, if the middlebox is either in the same administrative domain as the SP, or in the same administrative domain name as the SIP-PBX, why we can't/shouldn't make the same assumption for middleboxes that we're already making for the SP and for the SIP-PBX - that they will automagically know what AoRs are being MARTINI-REGISTERed as well. Does that sound like a different question, that might be useful for people to respond to? Thanks, Spencer From john.elwell@siemens-enterprise.com Thu Feb 18 23:46: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 666BB28C162 for ; Thu, 18 Feb 2010 23:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 We26ZB+7KaBU for ; Thu, 18 Feb 2010 23:46: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 D3EF028C130 for ; Thu, 18 Feb 2010 23:46:31 -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-941539; Fri, 19 Feb 2010 08:48:16 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 01E6D23F0278; Fri, 19 Feb 2010 08:48:16 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 19 Feb 2010 08:48:16 +0100 From: "Elwell, John" To: Spencer Dawkins , Dean Willis Date: Fri, 19 Feb 2010 08:48:13 +0100 Thread-Topic: Middlebox needs (was RE: [martini] DID Number Mobility and MARTINI) Thread-Index: AcqxL8pqY5w61Z9pQbGMPPaX+FJNUwAA1m8g Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> <4B7E29A6.7070400@softarmor.com> <9E28E51137ED46A2B8534BAD96036F8A@china.huawei.com> In-Reply-To: <9E28E51137ED46A2B8534BAD96036F8A@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: Bernard Aboba , MARTINI Subject: [martini] Middlebox needs (was RE: DID Number Mobility and 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: Fri, 19 Feb 2010 07:46:33 -0000 During the flurry of messages late yesterday I detected a lack of synch bet= ween some participants. I think Adam made it clear that what we should be d= iscussing is whether middleboxes need to know the registration state (not p= rovisioning) of AORs, so we should focus on this need.=20 I would like to try to understand why these middleboxes need knowledge of t= he registration state of individual AORs, if at all. I think there have bee= n arguments that they need some state in order to route inbound requests to= the PBX. There have also been arguments that they need state in order to a= ssert identities for outbound requests. Are there any other reasons for mid= dleboxes needing knowledge of the registration state of individual AORs? (F= orgive me if I have forgotten something already posted.) The GIN draft does indeed provide a mechanism whereby the middlebox gains t= his state knowledge. If there is consensus this is needed, or might be need= ed in some reasonable circumstances, we should probably go along with somet= hing similar to what is in the GIN draft. On the other hand, I am hearing s= ome people opposed to putting in functionality that they believe to be unne= cessary, so those arguing for having this functionality need to argue more = convincingly. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 19 February 2010 06:49 > To: Dean Willis > Cc: Elwell, John; Brian Lindsay; Adam Roach; Paul Kyzivat;=20 > Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > I should probably stop posting (as an individual) in this=20 > thread, but ... >=20 >=20 > > Spencer Dawkins wrote: > >> ... > > > >> "- (2) if we're saying that provisioning AoRs at the SP AND at the > >> SIP-PBX is required (and is out of scope for MARTINI - right?), I'm > >> not sure why the additional effort to provision=20 > middleboxes with these > >> AoRs justifies explicit signaling." > >> > >> I sent that note as an individual, but I think it's now appropriate > >> for me to ask, as co-chair, that someone explain why > >> > >> - the SIP-PBX can't use MARTINI to provision the SP, AND > >> > >> - the SP can't use MARTINI to provision the SIP-PBX, AND > >> > >> - we have to explicitly include the list of AoRs in=20 > signaling because > >> there are middleboxes that neither end can provision > >> > > > > Because "provision", in bellheadspeak, is either an arcane=20 > swearword or > > a description of the most complex, highly-regulated, and frequently > > audited process of the entire operations world, and is=20 > supported by the > > most expensive single software system in a service provider=20 > environment. > > It is generally easier to obtain revisions to the great=20 > holy books of > > any major religion than it is to change a provisioning system. > > > > If Social Security is the third rail of American politics=20 > (referring to > > that part of an electric train track that will electrocute you if > > touched), the provisioning is the third rail of service provider > > politics. Congratulations, you've just been electrocuted. > > > > > > Dynamic binding and "gate unlocking" are therefore NOT provisioning. >=20 > I'm trying to tug at the reaons that people have suggested=20 > sending lists of=20 > AoRs explicitly in signaling, and "indication of what AoRs were being=20 > registered to intermediate devices" was on the list of=20 > reasons that Adam=20 > thoughtfully provided in=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00757.html. >=20 > What I'm trying to ask, perhaps not using helpful terminology, is why=20 > middleboxes that I believe are under the same administrative=20 > control as=20 > either the SP or the SIP-PBX, need to be treated differently=20 > than we're=20 > treating the SP and the SIP-PBX in MARTINI. >=20 > I tried to be clear that MARTINI wasn't provisioning in my post at=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00783. html, but you=20 > may be correct that the word "provisioning" is so poisonous=20 > that I can't use=20 > it in a sentence that people can parse. If that's true, I=20 > apologise for=20 > using the word. >=20 > But ... my understanding is that, by some process that is out=20 > of scope for=20 > MARTINI, the SP and the SIP-PBX both automagically know,=20 > without either=20 > telling the other, what AoRs would be registered, and I'm=20 > asking, if the=20 > middlebox is either in the same administrative domain as the=20 > SP, or in the=20 > same administrative domain name as the SIP-PBX, why we=20 > can't/shouldn't make=20 > the same assumption for middleboxes that we're already making=20 > for the SP and=20 > for the SIP-PBX - that they will automagically know what AoRs=20 > are being=20 > MARTINI-REGISTERed as well. >=20 > Does that sound like a different question, that might be=20 > useful for people=20 > to respond to? >=20 > Thanks, >=20 > Spencer=20 >=20 > = From john.elwell@siemens-enterprise.com Fri Feb 19 00:03: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 408EB28C1B5 for ; Fri, 19 Feb 2010 00:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 E94hUjK3bm9y for ; Fri, 19 Feb 2010 00:03:34 -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 2054428C152 for ; Fri, 19 Feb 2010 00:03:33 -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-942232 for martini@ietf.org; Fri, 19 Feb 2010 09:05:19 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EF1591EB82AB for ; Fri, 19 Feb 2010 09:05:18 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 19 Feb 2010 09:05:18 +0100 From: "Elwell, John" To: MARTINI Date: Fri, 19 Feb 2010 09:05:17 +0100 Thread-Topic: [martini] Middlebox needs - routing inbound requests Thread-Index: AcqxL8pqY5w61Z9pQbGMPPaX+FJNUwAA1m8gAAFQFiA= Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> <4B7E29A6.7070400@softarmor.com> <9E28E51137ED46A2B8534BAD96036F8A@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 Subject: Re: [martini] Middlebox needs - routing inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 08:03:35 -0000 I think one of the arguments I have heard (although I may have misunderstoo= d) for middleboxes needing to know registration state of individual AORs re= gistered by a PBX is to enable the routing of inbound requests to the PBX. It can be argued that, certainly when sip-outbound is used, the middlebox n= eeds to maintain state in order to route inbound requests to the PBX, altho= ugh it can achieve this by means of a cookie sent to the domain proxy/regis= trar. This needs to identify the 'flow', so that the inbound request can be= delivered over that same TCP connection or UDP path. However, even though = multiple AORs are registered by the same REGISTER request, the same 'flow'= will apply to all registrations, so I don't believe the middlebox needs kn= owledge of individual registrations. The rest of the information needed is = in the inbound request. When outbound is not used, the middlebox should just be able to route on wh= at is in the Request-URI or Route header field (depending on the particular= solution we adopt). I don't see why it needs knowledge of individual regis= trations. So what are the particular reasons, if any, that knowledge of individual re= gistrations is needed in order for a middlebox to route inbound requests to= a PBX? John From john.elwell@siemens-enterprise.com Fri Feb 19 00:10: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 AE81A3A692C for ; Fri, 19 Feb 2010 00:10:32 -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 3EVETvcOtBPw for ; Fri, 19 Feb 2010 00:10:30 -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 3BACA3A7851 for ; Fri, 19 Feb 2010 00:10:24 -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-941523; Fri, 19 Feb 2010 09:12:09 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id F241A23F0278; Fri, 19 Feb 2010 09:12:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 19 Feb 2010 09:12:08 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "blindsay@nortel.com" , "spencer@wonderhamster.org" , "adam@nostrum.com" , "pkyzivat@cisco.com" Date: Fri, 19 Feb 2010 09:12:07 +0100 Thread-Topic: Middlebox needs - asserting identity for outbound requests Thread-Index: AcqvVshV7lvTwS+iQK6C3Vqod55i6gASfaggAAciF5AABgBn0AACBH1gAAVVrTAAMB1ZMAAGg3dQAAApNoAAAePfUAAAvNLQABiO3rA= Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com><4B7858E0.90602@cisco.com><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> <31048_1266520648_4B7D9248_31048_10997_1_9ECCF01B52E7AB408A7EB85352642141011D8D05@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C94A12B@zcarhxm1.corp.nortel.com> <4563_1266524838_4B7DA2A6_4563_27332_1_9ECCF01B52E7AB408A7EB85352642141011D8D0C@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4563_1266524838_4B7DA2A6_4563_27332_1_9ECCF01B52E7AB408A7EB85352642141011D8D0C@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: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: [martini] Middlebox needs - asserting identity for outbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 08:10:32 -0000 (Subject changed) The answer is to use P-Asserted-Identity also for the MARTINI case. I don't= think we should bring the subject of Trust Domains and PAI versus PPI into= the MARTINI discussions - these are orthogonal issues. John > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: 18 February 2010 20:27 > To: blindsay@nortel.com; Elwell, John; > spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: RE: [martini] DID Number Mobility and MARTINI > > This sounds like you are referring to what ETSI calls the > "peering-based" approach. In this case the edge proxy does > not assert identities. It receives a P-Asserted-Identity > header field from the PBX rather than a P-Preferred-Identity. > The SSP has to trust the enterprise network. > > > -----Message d'origine----- > > De : Brian Lindsay [mailto:blindsay@nortel.com] > > Envoy=E9 : jeudi 18 f=E9vrier 2010 21:17 > > =C0 : CHATRAS Bruno RD-CORE-ISS; > > john.elwell@siemens-enterprise.com; > > spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com > > Cc : bernard_aboba@hotmail.com; martini@ietf.org > > Objet : RE: [martini] DID Number Mobility and MARTINI > > > > > > Hi Bruno, > > > > Thanks. So there are cases where edge proxies perform a > > surrogate registration. > > > > I was wondering about cases where the "core" network > > itself isn't using a registration-based approach for a SIP > > PBX, but just uses a static IP or dns for routing towards the > > SIP PBX. > > > > How do edge proxies operate in that context? Would they > > still manage identify assertion and would they they typically > > be provisioned with address info to do so? Just wondering > > what the existing baseline solutions are for this. > > > > Thanks > > Brian > > > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: Thursday, February 18, 2010 2:17 PM > > To: Lindsay, Brian (CAR:AR00); > > john.elwell@siemens-enterprise.com; > > spencer@wonderhamster.org; adam@nostrum.com; pkyzivat@cisco.com > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > In this case you need a work-around of course... One option > > consists in inserting an adaptor between the PBX and the > > edge proxy. The adaptor sneds the REGISTER request on behalf > > of the PBX. Another option consists in sending an O&M command > > to the edge proxy that triggers the sending a REGISTER > > request with appropriate parameters to the registrar... > > > > > -----Message d'origine----- > > > De : Brian Lindsay [mailto:blindsay@nortel.com] Envoy=E9 : jeudi 18 > > > f=E9vrier 2010 20:08 =C0 : CHATRAS Bruno RD-CORE-ISS; > > > john.elwell@siemens-enterprise.com; > > > spencer@wonderhamster.org; adam@nostrum.com; > > pkyzivat@cisco.com Cc : > > > bernard_aboba@hotmail.com; martini@ietf.org Objet : RE: > > [martini] DID > > > Number Mobility and MARTINI > > > > > > Hi Bruno, > > > > > > I'm just curious about this works for cases where SIP > PBXs don't > > > actually register (e.g. have a static IP address, DNS is > used, etc). > > > > > > Thanks > > > Brian > > > > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: Thursday, February 18, 2010 11:00 AM > > > To: john.elwell@siemens-enterprise.com; > > > spencer@wonderhamster.org; Lindsay, Brian (CAR:AR00); > > > adam@nostrum.com; pkyzivat@cisco.com > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > Hi John, > > > > > > You almost wrote the text for such a requirement. > > > > > > "An edge proxy shall be able to base identity assertions > > for outbound > > > (non-REGISTER) requests received from a PBX on whether > the identity > > > concerned has been registered." > > > > > > Are you looking for a more formal comment on the requirements > > > document? > > > > > > Bruno > > > > > > > -----Message d'origine----- > > > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 18:05 =C0 : CHATRAS Bruno > > > RD-CORE-ISS; > > > > spencer@wonderhamster.org; blindsay@nortel.com; > adam@nostrum.com; > > > > pkyzivat@cisco.com Cc : bernard_aboba@hotmail.com; > > martini@ietf.org > > > > Objet : RE: [martini] DID Number Mobility and MARTINI > > > > > > > > Bruno, > > > > > > > > This depends whether we have a requirement for an edge > > proxy to be > > > > able to base identity assertions for outbound > > > > (non-REGISTER) requests on whether the identity concerned > > has been > > > > registered. We don't have such a requirement at present, > > so if you > > > > think we need such a requirement, please propose text for the > > > > requirements document. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: bruno.chatras@orange-ftgroup.com > > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > > Sent: 17 February 2010 14:29 > > > > > To: Elwell, John; spencer@wonderhamster.org; > > blindsay@nortel.com; > > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > A good solution should work irrespective of which proxy is > > > > > responsibile for asserting identities, including the case > > > > where this > > > > > is the edge proxy. > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Envoy=E9 : mercredi 17 f=E9vrier 2010 14:37 =C0 : CHATRAS Bruno > > > > > > RD-CORE-ISS; spencer@wonderhamster.org; > blindsay@nortel.com; > > > > > > adam@nostrum.com; pkyzivat@cisco.com Cc : > > > > bernard_aboba@hotmail.com; > > > > > > martini@ietf.org Objet : RE: [martini] DID Number > > Mobility and > > > > > > MARTINI > > > > > > > > > > > > Bruno, > > > > > > > > > > > > Thanks. However, this particular reason for a proxy > > > needing this > > > > > > information is because of an architecture where the > proxy is > > > > > > assigned responsibility for asserting an identity for the > > > > source of > > > > > > a request. If the domain proxy takes on this > > > > responsibility instead, > > > > > > problem solved. So it is a question of whether this > > particular > > > > > > architecture is common enough that we need a solution > > > > that conveys > > > > > > registered identities to the edge proxy. IMS solves this > > > > using PAU > > > > > > (ignoring issues of response size), so the question for > > > others is > > > > > > whether there are other architectures in practice > > where this is > > > > > > important. I guess for this particular usage it > > doesn't matter > > > > > > whether the information is in the REGISTER request or the > > > > REGISTER > > > > > > response. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: bruno.chatras@orange-ftgroup.com > > > > > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > > > > > Sent: 17 February 2010 12:45 > > > > > > > To: Elwell, John; spencer@wonderhamster.org; > > > > blindsay@nortel.com; > > > > > > > adam@nostrum.com; pkyzivat@cisco.com > > > > > > > Cc: bernard_aboba@hotmail.com; martini@ietf.org > > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > My view is that there is no strong need need for > > > carrying this > > > > > > > information accross the SIP-PBX - SSP interface. > > However this > > > > > > > information needs to be provided by the SSP's Registrar to > > > > > > the SSP's > > > > > > > edge proxy so as to enable the edge proxy to assert > > > identities > > > > > > > received from the PBX in a P-Preferred-Identity > > header field. > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > > De : martini-bounces@ietf.org > > > > > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > > > > > John Envoy=E9 > > > > > > > > : mercredi 17 f=E9vrier 2010 08:36 =C0 : Spencer Dawkins; > > > > > > Brian Lindsay; > > > > > > > > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI > > > > > Objet : Re: > > > > > > > > [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > So in trying to tease out whether there needs to be, as > > > > > > part of the > > > > > > > > MARTINI mechanism (as opposed to provisioning) an > > > > > > explicit list of > > > > > > > > numbers and/or contacts (I won't try to tie > down which at > > > > > > present), > > > > > > > > I think it is important to understand which direction > > > > > > this is needed > > > > > > > > in, because that will go some way towards > determining the > > > > > > mechanism. > > > > > > > > Do people think: > > > > > > > > > > > > > > > > a) there is good reason for providing this > > > information in the > > > > > > > > direction SIP-PBX to SSP (in which case inclusion in > > > > a REGISTER > > > > > > > > request might be one solution); or > > > > > > > > > > > > > > > > b) there is a good reason for providing this > > > > information in the > > > > > > > > direction SSP to SIP-PBX (in which case reg-events > > > > might be one > > > > > > > > solution); or > > > > > > > > > > > > > > > > c) it doesn't matter which direction - either direction > > > > > would be > > > > > > > > good enough so that at least one side is able > to detect a > > > > > > > > discrepancy; or > > > > > > > > > > > > > > > > d) there is a good reason for doing both; or > > > > > > > > > > > > > > > > e) there is no good reason to do either. > > > > > > > > > > > > > > > > My personal opinion is e), but I would like to > hear other > > > > > > opinions, > > > > > > > > with reasons. > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: martini-bounces@ietf.org > > > > > > > > > [mailto:martini-bounces@ietf.org] On Behalf Of > > > > Spencer Dawkins > > > > > > > > > Sent: 16 February 2010 22:23 > > > > > > > > > To: Brian Lindsay; Adam Roach; Paul Kyzivat > > > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > > > > > Speaking carefully as chair, and Bernard can > > correct me if > > > > > > > > I am saying > > > > > > > > > things I should not be saying as chair, at > this point... > > > > > > > > > > > > > > > > > > I happen to agree with your reasoning, re: > > REGISTER. What > > > > > > > > I'm trying > > > > > > > > > to tease out is whether we can just say "we're not > > > > > > providing that > > > > > > > > > information in the REGISTER exchange, BUT you > > can get that > > > > > > > > information > > > > > > > > > using regevents", so that we can move on - I haven't > > > > > > heard anyone > > > > > > > > > propose that MARTINI would say "MUST NOT use > > > regevents" :-) > > > > > > > > > > > > > > > > > > I would be comfortable if our specifications were > > > > > > silent on this > > > > > > > > > point, and might be more comfortable if we pointer out > > > > > > > > somewhere that > > > > > > > > > the REGISTER exchange does not provide this > information, > > > > > > > but people > > > > > > > > > who want the information can use regevents or whatever > > > > > > > other method > > > > > > > > > seems appropriate to get the information that > they want. > > > > > > > > > > > > > > > > > > But (Bernard and) I don't get to decide what > > working group > > > > > > > > consensus > > > > > > > > > is - we only get to recognize what consensus > > is, and when > > > > > > > it exists. > > > > > > > > > For that, we > > > > > > > > > need to hear from other participants > (including you, of > > > > > > > > course - and > > > > > > > > > "thank you" to participants who care, and have > > > > > > expressed opinions > > > > > > > > > about this, in the current thread. > > > > > > > > > > > > > > > > > > I hope this is helpful. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Brian Lindsay" > > > > > > > > > To: "Spencer Dawkins" ; > > > > > "Adam Roach" > > > > > > > > > ; "Paul Kyzivat" > > > > > > > > > > Cc: "Bernard Aboba" > > ; "MARTINI" > > > > > > > > > > > > > > > > > > Sent: Tuesday, February 16, 2010 3:51 PM > > > > > > > > > Subject: RE: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Spencer, > > > > > > > > > > > > > > > > > > So basically since the provisioning/sync of > > the E.164 > > > > > > > > > numbers/ranges is out of scope I don't see a strong > > > > > > argument for > > > > > > > > > including them in the registration transaction. > > > The Service > > > > > > > > Provider > > > > > > > > > has a set of E.164 numbers that, based on prior > > > > > > > > > assignment/arrangement, it is responsible to > > route to the > > > > > > > > SIP PBX. The > > > > > > > > > SIP PBX is aware of these numbers already. > > > > > > > > > The registration process (using an AoR identifying the > > > > > > > SIP PBX) is > > > > > > > > > intended to provide reachability information > for the SIP > > > > > > > > PBX, in the > > > > > > > > > absence of static IP address configuration / DNS > > > (hence the > > > > > > > > ranges are > > > > > > > > > not actually required in this transaction). > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Spencer Dawkins > [mailto:spencer@wonderhamster.org] > > > > > > > > > Sent: Tuesday, February 16, 2010 4:37 PM > > > > > > > > > To: Lindsay, Brian (CAR:AR00); Adam Roach; > Paul Kyzivat > > > > > > > > > Cc: Bernard Aboba; MARTINI > > > > > > > > > Subject: Re: [martini] DID Number Mobility and MARTINI > > > > > > > > > > > > > > > > > > Hi, Brian, > > > > > > > > > > > > > > > > > > Just trying to stay synchronized here. > > > > > > > > > > > > > > > > > > Speaking as an individual, I think you're right about > > > > > > > provisioning > > > > > > > > > being out of scope, based on what I've been > > > hearing on this > > > > > > > > list and > > > > > > > > > in telechats, etc. > > > > > > > > > > > > > > > > > > What I thought Adam was talking about isn't quite > > > > > provisioning > > > > > > > > > (ignoring the question direction - I've heard > > some people > > > > > > > > suggest each > > > > > > > > > direction). > > > > > > > > > It was more like "I expect these numbers to be > > registered" > > > > > > > > and/or "I > > > > > > > > > registered these numbers on your behalf", with the > > > > > > > question of how > > > > > > > > > each end knows what numbers "should" be > registered being > > > > > > > > out of scope > > > > > > > > > - because "knowing" was provisioned. > > > > > > > > > > > > > > > > > > At least, that's the context in which I was > > reading Adam's > > > > > > > > note below. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Spencer > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I think it's been stated many times in the > > > threads that > > > > > > > > > E.164 number > > > > > > > > > > > > > > > > > > > provisioning between the enterprise and > > service provider > > > > > > > > is out of > > > > > > > > > > scope of MARTINI. So we're not using the register > > > > > > > transaction to > > > > > > > > > > perform any syncronization on these numbers > > betweeen the > > > > > > > > enterprise > > > > > > > > > > and service provider. The registration is just > > > being used > > > > > > > > to provide > > > > > > > > > > reachability info, to allow requests to a > set of E.164 > > > > > > > > numbers to be > > > > > > > > > > routed to the SIP PBX. As such, I don't think > > the number > > > > > > > > ranges need > > > > > > > > > > to be part of the registration transaction. > It'll just > > > > > > > add extra > > > > > > > > > > complexity to the implementations. > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: martini-bounces@ietf.org > > > > > > > > [mailto:martini-bounces@ietf.org] On > > > > > > > > > > Behalf Of Adam Roach > > > > > > > > > > Sent: Tuesday, February 16, 2010 1:39 PM > > > > > > > > > > To: Paul Kyzivat > > > > > > > > > > Cc: Bernard Aboba; 'MARTINI' > > > > > > > > > > Subject: Re: [martini] DID Number Mobility > and MARTINI > > > > > > > > > > > > > > > > > > > > So, here's what I don't understand: 3GPP at least > > > > defined a > > > > > > > > > procedure > > > > > > > > > > -- through a questionable use of > > P-Associated-URI -- to > > > > > > > > > indicate which > > > > > > > > > > > > > > > > > > > URIs the registrar would be registering on > > behalf of the > > > > > > > > > user. So even > > > > > > > > > > > > > > > > > > > the original 3GPP implicit approach had an > > > enumeration of > > > > > > > > the AORs > > > > > > > > > > associated with the registration process. > > > > > > > > > > > > > > > > > > > > We're proposing to be even more sparse than > > that. Rather > > > > > > > > than just > > > > > > > > > > "implicit with a list of AORs," we're proposing > > > "implicit > > > > > > > > with *no* > > > > > > > > > > list of AORs." > > > > > > > > > > > > > > > > > > > > So, even if your assertion that our allowing > > > the implicit > > > > > > > > > mechanism to > > > > > > > > > > > > > > > > > > > stand is somehow tacit approval, what's > being proposed > > > > > > > > here is even > > > > > > > > > > one step more nebulous. > > > > > > > > > > > > > > > > > > > > /a > > > > > > > > > > > > > > > > > > > > On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote: > > > > > > > > > >> Dean, > > > > > > > > > >> > > > > > > > > > >> In principle I agree with you. > > > > > > > > > >> But this horse is already out of the barn with > > > > IMS implicit > > > > > > > > > > registration. > > > > > > > > > >> > > > > > > > > > >> It was never explicitly brought to the ietf, > > > > though things > > > > > > > > > linked to > > > > > > > > > >> it like P-Asserted-ID and P-Associated-URI > > were. While > > > > > > > > we could say > > > > > > > > > >> that is not our problem, I think we already > > implicitly > > > > > > > > approved it > > > > > > > > > >> via > > > > > > > > > > > > > > > > > > > >> benign neglect. > > > > > > > > > >> > > > > > > > > > >> Thanks, > > > > > > > > > >> Paul > > > > > > > > > >> > > > > > > > > > >> Dean Willis wrote: > > > > > > > > > >>> > > > > > > > > > >>> On Feb 15, 2010, at 4:44 PM, Bernard Aboba wrote: > > > > > > > > > >>> > > > > > > > > > >>>> Speaking as co-chair, the non-registration > > aspects of > > > > > > > > DID number > > > > > > > > > >>>> mobility are outside the scope of the > > current MARTINI > > > > > > > > WG charter. > > > > > > > > > >>>> > > > > > > > > > >>>> The question on the table (see > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/martini/current/msg00687.html > > > > > > > > > >>>> ) > > > > > > > > > > > > > > > > > > > >>>> is whether the registration aspects represent a > > > > > > > > > requirement or not. > > > > > > > > > >>>> Feel free > > > > > > > > > >>>> to respond and provide your opinion on > that thread. > > > > > > > > > >>> > > > > > > > > > >>> Explicit is its own reward. > > > > > > > > > >>> > > > > > > > > > >>> Remember, the one thing that RFC 3261 > > REGISTER really > > > > > > > > does is bind > > > > > > > > > >>> an > > > > > > > > > > > > > > > > > > > >>> AOR to a Contact. Both the AOR and the Contact > > > > > > involved are > > > > > > > > > >>> explicitly encoded in the request. > > > > > > > > > >>> > > > > > > > > > >>> I'm OKAY with extending REGISTER to bind > > multiple AORs > > > > > > > > to multiple > > > > > > > > > >>> Contacts. This seems like a reasonable > extension to > > > > > > > > simplify life > > > > > > > > > >>> for > > > > > > > > > > > > > > > > > > > >>> a "multi user" SIP user agent. But I > really think we > > > > > > > > > should respect > > > > > > > > > >>> the history of REGISTERs explicit encoding > > of the AORs > > > > > > > > > and Contacts > > > > > > > > > >>> involved. > > > > > > > > > >>> > > > > > > > > > >>> From a requirements perspective, I'd be > > happy with a > > > > > > > > requirement > > > > > > > > > >>> along the lines of "must not preclude > AOR mobility > > > > > > > > > indicated by the > > > > > > > > > > > > > > > > > > >>> registration." I agree that we can't justify a > > > > > > requirement to > > > > > > > > > >>> produce > > > > > > > > > > > > > > > > > > > >>> a mechanism at the time for the whole enchilada. > > > > > > > > > >>> > > > > > > > > > >>> -- > > > > > > > > > >>> 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 > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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. > > > > > ******************************** > > > > > > > > > > > > > > > > > > > > ********************************* > > > 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. > > ******************************** > > > > > > ********************************* > 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 john.elwell@siemens-enterprise.com Fri Feb 19 00:22: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 3A59C3A80F2 for ; Fri, 19 Feb 2010 00:22:31 -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 Pa2OFDKBNqjp for ; Fri, 19 Feb 2010 00:22:30 -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 175153A80F0 for ; Fri, 19 Feb 2010 00:22:29 -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-942445; Fri, 19 Feb 2010 09:24:14 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EACA01EB82AB; Fri, 19 Feb 2010 09:24:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 19 Feb 2010 09:24:14 +0100 From: "Elwell, John" To: Dean Willis , Bernard Aboba Date: Fri, 19 Feb 2010 09:24:13 +0100 Thread-Topic: Middlebox needs - admitting inbound requests Thread-Index: AcqxK3D4+r2OU3hsRFCvt9txBdPQkQAEHWSA Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> <4B7DCEB7.9010501@nostrum.com> <4B7E2D47.9060501@softarmor.com> In-Reply-To: <4B7E2D47.9060501@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' Subject: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 08:22:31 -0000 (Subject changed) Dean, you are arguing that some middleboxes need to know registration state= so that they can match a Request-URI in an inbound request with a known re= gistered contact URI and block requests where there is no match. I would argue that an SSP would not use such a middlebox if it wanted to of= fer a MARTINI interface to PBXs. As you say, it is broken. I would argue th= at we should not try to accommodate such broken middleboxes. However, if the WG feels there is a need, we would need to introduce a new = requirement along the lines of "An edge proxy MUST be able to filter inboun= d requests to a PBX on the basis of whether or not they are addressed to cu= rrently registered contact URIs". John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 19 February 2010 06:19 > To: Bernard Aboba > Cc: 'MARTINI' > Subject: Re: [martini] DID Number Mobility and MARTINI >=20 > Bernard Aboba wrote: > > > > *Adam Roach said: * > > > > > > "Once you're registering multiple AORs in a single=20 > registration, it's > > pretty clear that the registration state includes all of those AORs. > > > > So the middleboxes will want to know about them." > > > > *[BA] I'm curious to understand exactly what the middleboxes need to > > know and in what situations. After all, there are SSPs out=20 > there doing > > RFC 3263 domain routing without MARTINI, and presumably the > > middleboxes aren't a problem in that scenario. *** > > > The middleboxes will block any request message sent towards=20 > the PBX that > contains a Request-URI which does not match a Contact seen in=20 > a current > registration by that middlebox. In other words, if the=20 > middlebox hasn't > seen a REGISTER for that URI, it blocks all requests being=20 > sent to that URI. >=20 > Envision, if you will, a spam control mechanism that only allows your > email server to receive SMTP messages for a given email address if, in > the preceding few seconds, your email server had POPed messages that > were to that same email address. >=20 > It's an absolutely barbaric thing for a middlebox to do, but=20 > some people > would rather do stuff like this than use real identity mechanisms. Go > figure. >=20 > -- > Dean >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From christer.holmberg@ericsson.com Fri Feb 19 02: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 1A4F328C185 for ; Fri, 19 Feb 2010 02:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 cmwpLmSdz5E2 for ; Fri, 19 Feb 2010 02:01:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 11EFA28C148 for ; Fri, 19 Feb 2010 02:01:48 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-85-4b7e61f5be95 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 82.F5.02429.5F16E7B4; Fri, 19 Feb 2010 11:03:33 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 19 Feb 2010 11:03:32 +0100 From: Christer Holmberg To: Dean Willis , Spencer Dawkins Date: Fri, 19 Feb 2010 11:03:31 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqxKXUbq7GHPcH4Tr2Zn+WwfJSFYAAITTfw Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> <4B7E29A6.7070400@softarmor.com> In-Reply-To: <4B7E29A6.7070400@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 X-Brightmail-Tracker: AAAAAA== Cc: Bernard Aboba , MARTINI Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 10:01:50 -0000 =20 >It is generally easier to obtain revisions to the great holy=20 >books of any major religion than it is to change a=20 >provisioning system. Do you include RFC 3261 in that list of holy books? ;) From christer.holmberg@ericsson.com Fri Feb 19 02:08: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 B88433A8118 for ; Fri, 19 Feb 2010 02:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=-0.215, 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 7WdyyDLKgL5f for ; Fri, 19 Feb 2010 02:08:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A3FC43A8116 for ; Fri, 19 Feb 2010 02:07:59 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-fc-4b7e6368292f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5A.45.31641.8636E7B4; Fri, 19 Feb 2010 11:09:44 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.27]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 19 Feb 2010 11:09:44 +0100 From: Christer Holmberg To: Dean Willis , Paul Kyzivat Date: Fri, 19 Feb 2010 11:09:43 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqxKqVHILRxXsFHS0CxuuEh/+w3uwAIFZBA Message-ID: References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <8078_1266410694_4B7BE4C6_8078_17762_1_9ECCF01B52E7AB408A7EB85352642141011D8370@ftrdmel0.rd.francetelecom.fr> <9770_1266416954_4B7BFD3A_9770_60367_1_9ECCF01B52E7AB408A7EB85352642141011D8452@ftrdmel0.rd.francetelecom.fr> <4946_1266508815_4B7D640F_4946_58014_1_9ECCF01B52E7AB408A7EB85352642141011D8BD4@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C949F9A@zcarhxm1.corp.nortel.com> <31048_1266520648_4B7D9248_31048_10997_1_9ECCF01B52E7AB408A7EB85352642141011D8D05@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C94A12B@zcarhxm1.corp.nortel.com> <4563_1266524838_4B7DA2A6_4563_27332_1_9ECCF01B52E7AB408A7EB85352642141011D8D0C@ftrdmel0.rd.francetelecom.fr> <4B7DACEA.1030101@cisco.com> <4B7E2BDC.3070009@softarmor.com> In-Reply-To: <4B7E2BDC.3070009@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 X-Brightmail-Tracker: AAAAAA== Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 10:08:00 -0000 Hi,=20 >>Why would using DNS rather than registration have anything to do with=20 >>trust, or lack of trust, in the PBX? Registration is not=20 >>the only form of authentication. >> >Registration is the only authenticated exchange in classic=20 >IMS. This "mistake" (as I railed against it muchly at the=20 >time) has consequences like only being able to trust-anchor=20 >in a REGISTER transaction, or have to rely on entirely=20 >contractual trust anchoring. Oddly enough, the problem was=20 >derived from the method name REGISTER, which sounded too=20 >much like "registration" in a GSM system and was consequently=20 >forced to function the same way. If we had called the method=20 >SETCONTACT to start with, everything would be different today. >=20 >This also gets back to Christer's question about the=20 >negativity of our experience with implicit invocations. =20 >Other things that might be pointed out are implicit=20 >subscriptions on REFER (giving us norefersub as a needed=20 >extension), implicit terminations (requiring regevent in=20 >IMS), the nightmare of implicit bandwidth gating in the early=20 >PacketCable work, and many more that I'm just too tired of to=20 >keep in my head. I am not familiar with all the things listed above, but to me they sound a = little different than implicit registrations. When implicit registrations occur, you get a list of what has been register= ed implicitly. You don't need to "assume" something has happended in the ne= twork, and there are no additional "embedded" SIP actions (subscriptions et= c) taking place. Regarding REFER, I don't think implicit subscriptions as such is the proble= m. The problem is that we didn't include norefersub from the beginning. Regards, Christer From spencer@wonderhamster.org Fri Feb 19 06:10: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 BFDDD28C1F9 for ; Fri, 19 Feb 2010 06:10:16 -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, 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 ySvhuMmPY+9F for ; Fri, 19 Feb 2010 06:10:15 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id C613528C1EE for ; Fri, 19 Feb 2010 06:10:14 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LkPJr-1OF3ZS2G9j-00bo9s; Fri, 19 Feb 2010 09:11:22 -0500 Message-ID: <7E50DEE601894D5DA35B1EA2356B1E33@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "Dean Willis" References: <4B7D4BA4.8010307@softarmor.com> <4B7E29A6.7070400@softarmor.com> <9E28E51137ED46A2B8534BAD96036F8A@china.huawei.com> Date: Fri, 19 Feb 2010 08:11:03 -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: V01U2FsdGVkX19298160bop8CophJTYtYGF9fQhDY0lmlfMDD0 qPg+mn5PSPYAKjpIzK4tR+2eXB8o43E7sskhmXHpTC/JtJsAdW mL2JWeAh3YHGhuMtj64oT6sci2PYXzzRNjZlnQiaZE= Cc: Bernard Aboba , MARTINI Subject: Re: [martini] Middlebox needs (was RE: DID Number Mobility and 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: Fri, 19 Feb 2010 14:10:16 -0000 Hi, John, Speaking as co-chair, thanks for framing the question in this manner. This was helpful. Spencer ----- Original Message ----- From: "Elwell, John" To: "Spencer Dawkins" ; "Dean Willis" Cc: "Brian Lindsay" ; "Adam Roach" ; "Paul Kyzivat" ; "Bernard Aboba" ; "MARTINI" Sent: Friday, February 19, 2010 1:48 AM Subject: Middlebox needs (was RE: [martini] DID Number Mobility and MARTINI) During the flurry of messages late yesterday I detected a lack of synch between some participants. I think Adam made it clear that what we should be discussing is whether middleboxes need to know the registration state (not provisioning) of AORs, so we should focus on this need. I would like to try to understand why these middleboxes need knowledge of the registration state of individual AORs, if at all. I think there have been arguments that they need some state in order to route inbound requests to the PBX. There have also been arguments that they need state in order to assert identities for outbound requests. Are there any other reasons for middleboxes needing knowledge of the registration state of individual AORs? (Forgive me if I have forgotten something already posted.) The GIN draft does indeed provide a mechanism whereby the middlebox gains this state knowledge. If there is consensus this is needed, or might be needed in some reasonable circumstances, we should probably go along with something similar to what is in the GIN draft. On the other hand, I am hearing some people opposed to putting in functionality that they believe to be unnecessary, so those arguing for having this functionality need to argue more convincingly. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 19 February 2010 06:49 > To: Dean Willis > Cc: Elwell, John; Brian Lindsay; Adam Roach; Paul Kyzivat; > Bernard Aboba; MARTINI > Subject: Re: [martini] DID Number Mobility and MARTINI > > I should probably stop posting (as an individual) in this > thread, but ... > > > > Spencer Dawkins wrote: > >> ... > > > >> "- (2) if we're saying that provisioning AoRs at the SP AND at the > >> SIP-PBX is required (and is out of scope for MARTINI - right?), I'm > >> not sure why the additional effort to provision > middleboxes with these > >> AoRs justifies explicit signaling." > >> > >> I sent that note as an individual, but I think it's now appropriate > >> for me to ask, as co-chair, that someone explain why > >> > >> - the SIP-PBX can't use MARTINI to provision the SP, AND > >> > >> - the SP can't use MARTINI to provision the SIP-PBX, AND > >> > >> - we have to explicitly include the list of AoRs in > signaling because > >> there are middleboxes that neither end can provision > >> > > > > Because "provision", in bellheadspeak, is either an arcane > swearword or > > a description of the most complex, highly-regulated, and frequently > > audited process of the entire operations world, and is > supported by the > > most expensive single software system in a service provider > environment. > > It is generally easier to obtain revisions to the great > holy books of > > any major religion than it is to change a provisioning system. > > > > If Social Security is the third rail of American politics > (referring to > > that part of an electric train track that will electrocute you if > > touched), the provisioning is the third rail of service provider > > politics. Congratulations, you've just been electrocuted. > > > > > > Dynamic binding and "gate unlocking" are therefore NOT provisioning. > > I'm trying to tug at the reaons that people have suggested > sending lists of > AoRs explicitly in signaling, and "indication of what AoRs were being > registered to intermediate devices" was on the list of > reasons that Adam > thoughtfully provided in > http://www.ietf.org/mail-archive/web/martini/current/msg00757.html. > > What I'm trying to ask, perhaps not using helpful terminology, is why > middleboxes that I believe are under the same administrative > control as > either the SP or the SIP-PBX, need to be treated differently > than we're > treating the SP and the SIP-PBX in MARTINI. > > I tried to be clear that MARTINI wasn't provisioning in my post at > http://www.ietf.org/mail-archive/web/martini/current/msg00783. html, but you > may be correct that the word "provisioning" is so poisonous > that I can't use > it in a sentence that people can parse. If that's true, I > apologise for > using the word. > > But ... my understanding is that, by some process that is out > of scope for > MARTINI, the SP and the SIP-PBX both automagically know, > without either > telling the other, what AoRs would be registered, and I'm > asking, if the > middlebox is either in the same administrative domain as the > SP, or in the > same administrative domain name as the SIP-PBX, why we > can't/shouldn't make > the same assumption for middleboxes that we're already making > for the SP and > for the SIP-PBX - that they will automagically know what AoRs > are being > MARTINI-REGISTERed as well. > > Does that sound like a different question, that might be > useful for people > to respond to? > > Thanks, > > Spencer > > = From spencer@wonderhamster.org Fri Feb 19 06:18: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 B056228C266 for ; Fri, 19 Feb 2010 06:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, 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 C4snMPK1Us7x for ; Fri, 19 Feb 2010 06:18:15 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 75A6128C228 for ; Fri, 19 Feb 2010 06:18:15 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M6S2d-1Nt6k22B35-00yJWk; Fri, 19 Feb 2010 09:20:00 -0500 Message-ID: <4FAD8A662E174C98A694FD60A19F1B9C@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "MARTINI" References: Date: Fri, 19 Feb 2010 08:19: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: V01U2FsdGVkX19KDXgzGtcJU0Puo2lRga6E/G3c0pMZPvHEZMY B8riYwbLoeL/Oa3laZ2OnQ4MIbpis9QNf+Us2gnNP6aCvslffS mtk9dSJIYsMlyZ2ofP3g7+G8ZoBRGU9B4yzPD/FZD0= Subject: Re: [martini] Middlebox needs - routing inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 14:18:20 -0000 Hi, John, Again, I think your posting below was helpful. If I am understanding correctly, I saw some discussion asking "how would a middlebox do this for a SIP-PBX that was using RFC 3263 routing to/from the SP, so that the middlebox would not be aware of registration state for the AORs that UAs inside the enterprise REGISTER with the SIP-PBX?" If I am understanding correctly, I'd like to include this as part of John's request for feedback that started this thread. Thank you, Spencer >I think one of the arguments I have heard (although I may have >misunderstood) for middleboxes needing to know registration state of >individual AORs registered by a PBX is to enable the routing of inbound >requests to the PBX. > > It can be argued that, certainly when sip-outbound is used, the middlebox > needs to maintain state in order to route inbound requests to the PBX, > although it can achieve this by means of a cookie sent to the domain > proxy/registrar. This needs to identify the 'flow', so that the inbound > request can be delivered over that same TCP connection or UDP path. > However, even though multiple AORs are registered by the same REGISTER > request, the same 'flow' will apply to all registrations, so I don't > believe the middlebox needs knowledge of individual registrations. The > rest of the information needed is in the inbound request. > > When outbound is not used, the middlebox should just be able to route on > what is in the Request-URI or Route header field (depending on the > particular solution we adopt). I don't see why it needs knowledge of > individual registrations. > > So what are the particular reasons, if any, that knowledge of individual > registrations is needed in order for a middlebox to route inbound requests > to a PBX? > > John > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Fri Feb 19 06:19: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 DBAAC28C1E3 for ; Fri, 19 Feb 2010 06:19:46 -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.038, 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 KWOT25MoqUlw for ; Fri, 19 Feb 2010 06:19:46 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D872B3A7CFB for ; Fri, 19 Feb 2010 06:19:45 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MVNo6-1N9txF0bao-00YopP; Fri, 19 Feb 2010 09:20:58 -0500 Message-ID: <85CB68B75FEA4B10B220F679A13DFEC7@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> <4B7DCEB7.9010501@nos trum.com> Date: Fri, 19 Feb 2010 08:20:41 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C17_01CAB13C.6CC7FBC0" 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: V01U2FsdGVkX19osordIDkHrQ3WhNl79tF7CK2SKYQ1JhD6dT/ aFvXe+vEIiTu8+tW7Ry40nfSqsguZ6y5g2wryj4qCrK1AsPG13 Jkq25W9gkID1v3gfbk8RKg/ivKt2406phcgyH11hgM= Cc: Bernard Aboba , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 14:19:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0C17_01CAB13C.6CC7FBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Adam, Speaking as co-chair, this was a helpful clarification. Thank you for = the post. Spencer ----- Original Message -----=20 From: Adam Roach=20 To: Spencer Dawkins=20 Cc: Bernard Aboba ; 'Brian Lindsay' ; 'Elwell, John' ; 'Paul Kyzivat' = ; 'MARTINI'=20 Sent: Thursday, February 18, 2010 5:35 PM Subject: Re: [martini] DID Number Mobility and MARTINI On 2/18/10 00:28, Feb 18, Spencer Dawkins wrote:=20 - (2) if we're saying that provisioning AoRs at the SP AND at the = SIP-PBX is required (and is out of scope for MARTINI - right?), I'm not = sure why the additional effort to provision middleboxes with these AoRs = justifies explicit signaling. Registration state and provisioning are very different things. Many = middleboxes do track registration state. And middleboxes that track registration state need to track = registration state to function properly. I'm sure they wouldn't be doing = it otherwise, since it's not a particularly cheap operation. And part of normal registration state includes the AOR involved in the = registration. Once you're registering multiple AORs in a single registration, it's = pretty clear that the registration state includes all of those AORs. So the middleboxes will want to know about them. We can certainly engage in a discussion around whether it makes more = sense to provision all the extensions into the middleboxes, but that = seems exceedingly operationally expensive. And if we were willing to = absorb the cost of additional operational expenses due to provisioning, = the answer would be "provision the PBX IP address into the SSP and be = done with it" instead of doing all this MARTINI work. /a ------=_NextPart_000_0C17_01CAB13C.6CC7FBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Adam,
 
Speaking as co-chair, this was a helpful = clarification. Thank=20 you for the post.
 
Spencer
----- Original Message -----
From:=20 Adam = Roach
Cc: Bernard Aboba ; 'Brian = Lindsay' ; 'Elwell, John' = ; 'Paul = Kyzivat' ;=20 'MARTINI'
Sent: Thursday, February 18, = 2010 5:35=20 PM
Subject: Re: [martini] DID = Number=20 Mobility and MARTINI

On 2/18/10 00:28, Feb 18, Spencer Dawkins wrote:=20
- (2) if we're saying that provisioning AoRs at = the SP AND=20 at the SIP-PBX is required (and is out of scope for MARTINI - = right?), I'm=20 not sure why the additional effort to provision middleboxes with = these AoRs=20 justifies explicit signaling.


Registration state and provisioning are = very=20 different things. Many middleboxes do track registration = state.

And=20 middleboxes that track registration state need to track registration = state to=20 function properly. I'm sure they wouldn't be doing it otherwise, since = it's=20 not a particularly cheap operation.

And part of normal = registration=20 state includes the AOR involved in the registration.

Once = you're=20 registering multiple AORs in a single registration, it's pretty clear = that the=20 registration state includes all of those AORs.

So the = middleboxes will=20 want to know about them.

We can certainly engage in a = discussion around=20 whether it makes more sense to provision all the extensions into the=20 middleboxes, but that seems exceedingly operationally expensive. And = if we=20 were willing to absorb the cost of additional operational expenses due = to=20 provisioning, the answer would be "provision the PBX IP address into = the SSP=20 and be done with it" instead of doing all this MARTINI=20 work.

/a
------=_NextPart_000_0C17_01CAB13C.6CC7FBC0-- From john.elwell@siemens-enterprise.com Fri Feb 19 06:59: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 D42C03A7968 for ; Fri, 19 Feb 2010 06:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ZWHv-XpxiJcc for ; Fri, 19 Feb 2010 06:59:47 -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 AA82A3A72EC for ; Fri, 19 Feb 2010 06:59:46 -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-948371; Fri, 19 Feb 2010 16:01:32 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 7A3E41EB82BC; Fri, 19 Feb 2010 16:01:32 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 19 Feb 2010 16:01:32 +0100 From: "Elwell, John" To: Spencer Dawkins , MARTINI Date: Fri, 19 Feb 2010 16:01:31 +0100 Thread-Topic: [martini] Middlebox needs - routing inbound requests Thread-Index: Acqxbp/iR1dQXU++SrikfsE5VAKAigAAYeIA Message-ID: References: <4FAD8A662E174C98A694FD60A19F1B9C@china.huawei.com> In-Reply-To: <4FAD8A662E174C98A694FD60A19F1B9C@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 Subject: Re: [martini] Middlebox needs - routing inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 14:59:47 -0000 Spencer, I thought that question arose in the context of a middlebox asserting ident= ity for outbound requests, not in the context of inbound requests, but I ma= y have missed something. John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 19 February 2010 14:20 > To: Elwell, John; MARTINI > Subject: Re: [martini] Middlebox needs - routing inbound requests >=20 > Hi, John, >=20 > Again, I think your posting below was helpful. >=20 > If I am understanding correctly, I saw some discussion asking=20 > "how would a=20 > middlebox do this for a SIP-PBX that was using RFC 3263=20 > routing to/from the=20 > SP, so that the middlebox would not be aware of registration=20 > state for the=20 > AORs that UAs inside the enterprise REGISTER with the SIP-PBX?" >=20 > If I am understanding correctly, I'd like to include this as=20 > part of John's=20 > request for feedback that started this thread. >=20 > Thank you, >=20 > Spencer >=20 >=20 > >I think one of the arguments I have heard (although I may have=20 > >misunderstood) for middleboxes needing to know registration state of=20 > >individual AORs registered by a PBX is to enable the routing=20 > of inbound=20 > >requests to the PBX. > > > > It can be argued that, certainly when sip-outbound is used,=20 > the middlebox=20 > > needs to maintain state in order to route inbound requests=20 > to the PBX,=20 > > although it can achieve this by means of a cookie sent to=20 > the domain=20 > > proxy/registrar. This needs to identify the 'flow', so that=20 > the inbound=20 > > request can be delivered over that same TCP connection or UDP path.=20 > > However, even though multiple AORs are registered by the=20 > same REGISTER=20 > > request, the same 'flow' will apply to all registrations,=20 > so I don't=20 > > believe the middlebox needs knowledge of individual=20 > registrations. The=20 > > rest of the information needed is in the inbound request. > > > > When outbound is not used, the middlebox should just be=20 > able to route on=20 > > what is in the Request-URI or Route header field (depending on the=20 > > particular solution we adopt). I don't see why it needs=20 > knowledge of=20 > > individual registrations. > > > > So what are the particular reasons, if any, that knowledge=20 > of individual=20 > > registrations is needed in order for a middlebox to route=20 > inbound requests=20 > > to a PBX? > > > > John > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini=20 >=20 > = From richard@shockey.us Fri Feb 19 07:09: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 96CF13A73B8 for ; Fri, 19 Feb 2010 07:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 Lo8CW-CoB0-D for ; Fri, 19 Feb 2010 07:09:09 -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 917BA3A6A3D for ; Fri, 19 Feb 2010 07:09:09 -0800 (PST) Received: (qmail 9016 invoked by uid 0); 19 Feb 2010 15:10:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 19 Feb 2010 15:10:55 -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=dKU7ZNSEEtyRC17q6Biun2gk0u+iAk77gDL42NAsLS0uOc3I4Re4lIL8QaW10rkrU4e7k84LUvwdTrK5LCqeVe/IATzMCDEcOWv0MC/CcU7BpHxf0Ufirjp8EvjOKrjD; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NiUVL-0006CI-2g; Fri, 19 Feb 2010 08:10:55 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Spencer Dawkins'" References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <4B7858E0.90602@cisco.com> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <4B7D4BA4.8010307@softarmor.com> <4B7E29A6.7070400@softarmor.com> In-Reply-To: <4B7E29A6.7070400@softarmor.com> Date: Fri, 19 Feb 2010 10:10:50 -0500 Message-ID: <003b01cab175$b9e764c0$2db62e40$@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: AcqxKXPqT1KnR/v+Tc+z4xe7oiY1KwATCNMw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: 'Bernard Aboba' , 'MARTINI' Subject: Re: [martini] DID Number Mobility and 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: Fri, 19 Feb 2010 15:09:10 -0000 Dean is absolutely correct here. Which is why we can't go there. > > - the SIP-PBX can't use MARTINI to provision the SP, AND > > - the SP can't use MARTINI to provision the SIP-PBX, AND > > - we have to explicitly include the list of AoRs in signaling because > there are middleboxes that neither end can provision > Because "provision", in bellheadspeak, is either an arcane swearword or a description of the most complex, highly-regulated, and frequently audited process of the entire operations world, and is supported by the most expensive single software system in a service provider environment. It is generally easier to obtain revisions to the great holy books of any major religion than it is to change a provisioning system. If Social Security is the third rail of American politics (referring to that part of an electric train track that will electrocute you if touched), the provisioning is the third rail of service provider politics. Congratulations, you've just been electrocuted. Dynamic binding and "gate unlocking" are therefore NOT provisioning. -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Fri Feb 19 07: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 225223A7315 for ; Fri, 19 Feb 2010 07:17:16 -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.036, 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 lU5TIHwGaq+t for ; Fri, 19 Feb 2010 07:17:15 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id DA4563A7CD6 for ; Fri, 19 Feb 2010 07:17:14 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LgaNB-1O3Vy83mbN-00nmgs; Fri, 19 Feb 2010 10:19:00 -0500 Message-ID: <658BC20C52ED4FC8BFDE2213907E5B29@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "MARTINI" References: <4FAD8A662E174C98A694FD60A19F1B9C@china.huawei.com> Date: Fri, 19 Feb 2010 09:18: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: V01U2FsdGVkX19Zs7LnOSYmwkjPMHT84beCiQav90mUdkzeNEt huHbJFXDj23VNW3DbeJHHJa1ny9jn3RCsAOwNVxA2HgYZ5VHoc xYe67Hg0owQC6v7RRgmonzNT5WtrTgjhtrVFgJsfVA= Subject: Re: [martini] Middlebox needs - routing inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 15:17:16 -0000 Speaking as individual, As always, I apologize for mischaracterizing the discussion. I am still curious about the question on middlebox filtering based on awareness of registration state that I raised - perhaps the previous discussion just got me thinking about another topic ... Are we saying that middleboxes do this filtering for you if you REGISTER, but stop doing it if you get your own domain and start using RFC 3263? Thanks, Spencer ----- Original Message ----- From: "Elwell, John" To: "Spencer Dawkins" ; "MARTINI" Sent: Friday, February 19, 2010 9:01 AM Subject: RE: [martini] Middlebox needs - routing inbound requests Spencer, I thought that question arose in the context of a middlebox asserting identity for outbound requests, not in the context of inbound requests, but I may have missed something. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 19 February 2010 14:20 > To: Elwell, John; MARTINI > Subject: Re: [martini] Middlebox needs - routing inbound requests > > Hi, John, > > Again, I think your posting below was helpful. > > If I am understanding correctly, I saw some discussion asking > "how would a > middlebox do this for a SIP-PBX that was using RFC 3263 > routing to/from the > SP, so that the middlebox would not be aware of registration > state for the > AORs that UAs inside the enterprise REGISTER with the SIP-PBX?" > > If I am understanding correctly, I'd like to include this as > part of John's > request for feedback that started this thread. > > Thank you, > > Spencer > > > >I think one of the arguments I have heard (although I may have > >misunderstood) for middleboxes needing to know registration state of > >individual AORs registered by a PBX is to enable the routing > of inbound > >requests to the PBX. > > > > It can be argued that, certainly when sip-outbound is used, > the middlebox > > needs to maintain state in order to route inbound requests > to the PBX, > > although it can achieve this by means of a cookie sent to > the domain > > proxy/registrar. This needs to identify the 'flow', so that > the inbound > > request can be delivered over that same TCP connection or UDP path. > > However, even though multiple AORs are registered by the > same REGISTER > > request, the same 'flow' will apply to all registrations, > so I don't > > believe the middlebox needs knowledge of individual > registrations. The > > rest of the information needed is in the inbound request. > > > > When outbound is not used, the middlebox should just be > able to route on > > what is in the Request-URI or Route header field (depending on the > > particular solution we adopt). I don't see why it needs > knowledge of > > individual registrations. > > > > So what are the particular reasons, if any, that knowledge > of individual > > registrations is needed in order for a middlebox to route > inbound requests > > to a PBX? > > > > John > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > = From JSBURTON@cablevision.com Fri Feb 19 08:23: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 897E828C247 for ; Fri, 19 Feb 2010 08:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.145, 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 xZfAPAPCx9uo for ; Fri, 19 Feb 2010 08:23:48 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id C8EF228C1F0 for ; Fri, 19 Feb 2010 08:23:46 -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 o1JGNhHr005947 for ; Fri, 19 Feb 2010 11:25:26 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o1JGNhHr005947 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1266596727; bh=CqTNzVvbcIQeguVV90juJlrOc6Vqo3bmsmQd40u aM3Q=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=x6tXN73hqTJPATkto/LlAsWqf6JlGc6EVDCh9 L9P53vSPo9cCLOK4Wgrr+1KkjcTdHfcKilNFMOI3fPUWK23FlmaeW+rp8JbLf97tCS8 NLtXDokzM+7pRLtsoCG5szlezbsyY36Wdnhyg6EG2KX2SfZMrHePjwrB2qI1nyA3NZ0 = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Fri, 19 Feb 2010 11:22:25 -0500 Message-Id: <4B7E746E.38CD.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Fri, 19 Feb 2010 11:22:21 -0500 From: "Jack Burton" To: "MARTINI" References: <4FAD8A662E174C98A694FD60A19F1B9C@china.huawei.com> <658BC20C52ED4FC8BFDE2213907E5B29@china.huawei.com> In-Reply-To: <658BC20C52ED4FC8BFDE2213907E5B29@china.huawei.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part4A6072AD.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] Middlebox needs - routing inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 16:23:49 -0000 --=__Part4A6072AD.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit No, the way our middle-boxes work does not require knowledge of implicitly registered entities behind the PBX. While the PBX is registered, any methods originating from it's IP address are considered registered. It is up to the SP's elements to decide whether a DID number presented on an outbound call is within the customer's authorized ranges, and could: 1) complete the call, passing information as-is 2) complete the call, changing information to the customer's main number 3) reject the call All of this would seem to be out-of-scope to me. Implicit registration should (and does) work fine through our SBCs. -Jack >>> "Spencer Dawkins" 2/19/2010 10:18 >>> Speaking as individual, As always, I apologize for mischaracterizing the discussion. I am still curious about the question on middlebox filtering based on awareness of registration state that I raised - perhaps the previous discussion just got me thinking about another topic ... Are we saying that middleboxes do this filtering for you if you REGISTER, but stop doing it if you get your own domain and start using RFC 3263? Thanks, Spencer ----- Original Message ----- From: "Elwell, John" To: "Spencer Dawkins" ; "MARTINI" Sent: Friday, February 19, 2010 9:01 AM Subject: RE: [martini] Middlebox needs - routing inbound requests Spencer, I thought that question arose in the context of a middlebox asserting identity for outbound requests, not in the context of inbound requests, but I may have missed something. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 19 February 2010 14:20 > To: Elwell, John; MARTINI > Subject: Re: [martini] Middlebox needs - routing inbound requests > > Hi, John, > > Again, I think your posting below was helpful. > > If I am understanding correctly, I saw some discussion asking > "how would a > middlebox do this for a SIP-PBX that was using RFC 3263 > routing to/from the > SP, so that the middlebox would not be aware of registration > state for the > AORs that UAs inside the enterprise REGISTER with the SIP-PBX?" > > If I am understanding correctly, I'd like to include this as > part of John's > request for feedback that started this thread. > > Thank you, > > Spencer > > > >I think one of the arguments I have heard (although I may have > >misunderstood) for middleboxes needing to know registration state of > >individual AORs registered by a PBX is to enable the routing > of inbound > >requests to the PBX. > > > > It can be argued that, certainly when sip-outbound is used, > the middlebox > > needs to maintain state in order to route inbound requests > to the PBX, > > although it can achieve this by means of a cookie sent to > the domain > > proxy/registrar. This needs to identify the 'flow', so that > the inbound > > request can be delivered over that same TCP connection or UDP path. > > However, even though multiple AORs are registered by the > same REGISTER > > request, the same 'flow' will apply to all registrations, > so I don't > > believe the middlebox needs knowledge of individual > registrations. The > > rest of the information needed is in the inbound request. > > > > When outbound is not used, the middlebox should just be > able to route on > > what is in the Request-URI or Route header field (depending on the > > particular solution we adopt). I don't see why it needs > knowledge of > > individual registrations. > > > > So what are the particular reasons, if any, that knowledge > of individual > > registrations is needed in order for a middlebox to route > inbound requests > > to a PBX? > > > > 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 -------------------------------------------------------- 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 information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright. 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(s) 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. -------------------------------------------------------- --=__Part4A6072AD.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
No, the way our middle-boxes work does not require knowledge of implic= itly registered entities behind the PBX.
 
While the PBX is registered, any methods originating from it's IP addr= ess are considered registered.
 
It is up to the SP's elements to decide whether a DID number presented= on an outbound call is within the customer's authorized ranges, and could:=
1) complete the call, passing information as-is
2) complete the call, changing information to the customer's main numb= er
3) reject the call
 
All of this would seem to be out-of-scope to me.  Implicit regist= ration should (and does) work fine through our SBCs.
 
-Jack


>>> "Spencer Dawkins" <spencer@wonderhamster.org&g= t; 2/19/2010 10:18 >>>
Speaking as individual,

As always= , I apologize for mischaracterizing the discussion.

I am still curio= us about the question on middlebox filtering based on
awareness of regi= stration state that I raised - perhaps the previous
discussion just got= me thinking about another topic ...

Are we saying that middleboxes = do this filtering for you if you REGISTER,
but stop doing it if you get= your own domain and start using RFC 3263?

Thanks,

Spencer
----- Original Message -----
From: "Elwell, John" <john.elwell@= siemens-enterprise.com>
To: "Spencer Dawkins" <spencer@wonderhamst= er.org>; "MARTINI"
<martini@ietf.org>
Sent: Friday, Februar= y 19, 2010 9:01 AM
Subject: RE: [martini] Middlebox needs - routing inbo= und requests


Spencer,

I thought that question arose in th= e context of a middlebox asserting
identity for outbound requests, not = in the context of inbound requests, but
I may have missed something.
John

> -----Original Message-----
> From: Spencer Dawk= ins [mailto:spencer@wonderhamster.org]
> Sent: 19 February 2010 14:20=
> To: Elwell, John; MARTINI
> Subject: Re: [martini] Middlebox= needs - routing inbound requests
>
> Hi, John,
>
>= Again, I think your posting below was helpful.
>
> If I am und= erstanding correctly, I saw some discussion asking
> "how would a
= > middlebox do this for a SIP-PBX that was using RFC 3263
> routin= g to/from the
> SP, so that the middlebox would not be aware of regis= tration
> state for the
> AORs that UAs inside the enterprise R= EGISTER with the SIP-PBX?"
>
> If I am understanding correctly,= I'd like to include this as
> part of John's
> request for fee= dback that started this thread.
>
> Thank you,
>
> = Spencer
>
>
> >I think one of the arguments I have hea= rd (although I may have
> >misunderstood) for middleboxes needing = to know registration state of
> >individual AORs registered by a P= BX is to enable the routing
> of inbound
> >requests to the = PBX.
> >
> > It can be argued that, certainly when sip-ou= tbound is used,
> the middlebox
> > needs to maintain state = in order to route inbound requests
> to the PBX,
> > althoug= h it can achieve this by means of a cookie sent to
> the domain
&g= t; > proxy/registrar. This needs to identify the 'flow', so that
>= the inbound
> > request can be delivered over that same TCP conne= ction or UDP path.
> > However, even though multiple AORs are = ; registered by the
> same REGISTER
> > request, the same 'f= low' will apply to all registrations,
> so I don't
> > belie= ve the middlebox needs knowledge of individual
> registrations. The> > rest of the information needed is in the inbound request.
&g= t; >
> > When outbound is not used, the middlebox should just b= e
> able to route on
> > what is in the Request-URI or Route= header field (depending on the
> > particular solution we adopt).= I don't see why it needs
> knowledge of
> > individual regi= strations.
> >
> > So what are the particular reasons, if= any, that knowledge
> of individual
> > registrations is ne= eded in order for a middlebox to route
> inbound requests
> >= ; to a PBX?
> >
> > John
> > ___________________= ____________________________
> > martini mailing list
> >= martini@ietf.org
> > https://www.ietf.org/mailman/listinfo/martini
>
= > =3D

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

--------------------------------------------------------
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 information concerning Cablevision and/or its affiliates and subsidiaries= that is proprietary, privileged, confidential and/or subject to copyright.= 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(s) is prohibited and may be unlawful. If you r= eceived 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.
-------------------------------------------------------- --=__Part4A6072AD.0__=-- From root@core3.amsl.com Fri Feb 19 09:45:01 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 6353B3A7FCD; Fri, 19 Feb 2010 09:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100219174501.6353B3A7FCD@core3.amsl.com> Date: Fri, 19 Feb 2010 09:45:01 -0800 (PST) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-reqs-01.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 17:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF. Title : Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) Author(s) : J. Elwell, H. Kaplan Filename : draft-ietf-martini-reqs-01.txt Pages : 12 Date : 2010-02-19 This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized PBXs. The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This work is being discussed on the martini@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-martini-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-19094407.I-D@ietf.org> --NextPart-- From john.elwell@siemens-enterprise.com Fri Feb 19 09:51: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 0E61028C2B2 for ; Fri, 19 Feb 2010 09:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 954K9nGIs2KJ for ; Fri, 19 Feb 2010 09:51:50 -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 DBFD528C1E0 for ; Fri, 19 Feb 2010 09:51:49 -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-951035 for martini@ietf.org; Fri, 19 Feb 2010 18:53:36 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 868021EB82BC for ; Fri, 19 Feb 2010 18:53:36 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 19 Feb 2010 18:53:36 +0100 From: "Elwell, John" To: MARTINI Date: Fri, 19 Feb 2010 18:53:34 +0100 Thread-Topic: [martini] I-D Action:draft-ietf-martini-reqs-01.txt Thread-Index: Acqxi4Us7sT/7tFSSmSS8d+t9uIkcwAALijQ Message-ID: References: <20100219174501.6353B3A7FCD@core3.amsl.com> In-Reply-To: <20100219174501.6353B3A7FCD@core3.amsl.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] I-D Action:draft-ietf-martini-reqs-01.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 17:51:51 -0000 Based on the principles I outlined in an earlier message, I have merged par= ts of Hadriel's mixing-problems draft into this 01 version of the requireme= nts draft. Basically the changes are: - addition of Hadriel as co-author; - minor wording changes in section 1 to refer to section 3 instead of to th= e mixing-problems draft; - new section 3; - addition of reference to GRUU RFC; - addition of REQ18 concerning transport (which I think we have consensus o= n); - split of references into normative and informative. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 19 February 2010 17:45 > To: i-d-announce@ietf.org > Cc: martini@ietf.org > Subject: [martini] I-D Action:draft-ietf-martini-reqs-01.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Multiple AoR reachabiliTy=20 > InformatioN Indication Working Group of the IETF. >=20 >=20 > Title : Requirements for multiple address of=20 > record (AOR) reachability information in the Session=20 > Initiation Protocol (SIP) > Author(s) : J. Elwell, H. Kaplan > Filename : draft-ietf-martini-reqs-01.txt > Pages : 12 > Date : 2010-02-19 >=20 > This document states requirements for a standardized SIP registration > mechanism for multiple addresses of record, the mechanism being > suitable for deployment by SIP service providers on a large scale in > support of small to medium sized PBXs. The requirements are for a > solution that can, as a minimum, support AORs based on E.164 numbers. >=20 > This work is being discussed on the martini@ietf.org mailing list. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = From spencer@wonderhamster.org Fri Feb 19 11:43: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 B3D953A7BBA for ; Fri, 19 Feb 2010 11:43:32 -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.079, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 l4k1WWwc9mCK for ; Fri, 19 Feb 2010 11:43:32 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id DBE593A7D2F for ; Fri, 19 Feb 2010 11:43:31 -0800 (PST) Received: from S73602b (67-207-123-4.static.wiline.com [67.207.123.4]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LnPio-1O9Nkw05y2-00hSxC; Fri, 19 Feb 2010 14:45:18 -0500 Message-ID: From: "Spencer Dawkins" To: "Elwell, John" , "MARTINI" References: <20100219174501.6353B3A7FCD@core3.amsl.com> Date: Fri, 19 Feb 2010 13:45:05 -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: V01U2FsdGVkX19OkSm/ZKpEaxPMuL32ImbbkmqiU2pgJ45Vepr CfHMJCo45oRDDYR6Eq3KQVHsn2yRilzFdK2gqvg7/DZsICae+l ug3d1RZbLFrWg9n65NR99X3nws5OOdEwSYumSh7CG8= Subject: Re: [martini] I-D Action:draft-ietf-martini-reqs-01.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 19 Feb 2010 19:43:32 -0000 Hi, John, Thank you (and Hadriel) for getting this submitted quickly! Spencer (as co-chair) > Based on the principles I outlined in an earlier message, I have merged > parts of Hadriel's mixing-problems draft into this 01 version of the > requirements draft. Basically the changes are: > - addition of Hadriel as co-author; > - minor wording changes in section 1 to refer to section 3 instead of to > the mixing-problems draft; > - new section 3; > - addition of reference to GRUU RFC; > - addition of REQ18 concerning transport (which I think we have consensus > on); > - split of references into normative and informative. > > John > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: 19 February 2010 17:45 >> To: i-d-announce@ietf.org >> Cc: martini@ietf.org >> Subject: [martini] I-D Action:draft-ietf-martini-reqs-01.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Multiple AoR reachabiliTy >> InformatioN Indication Working Group of the IETF. >> >> >> Title : Requirements for multiple address of >> record (AOR) reachability information in the Session >> Initiation Protocol (SIP) >> Author(s) : J. Elwell, H. Kaplan >> Filename : draft-ietf-martini-reqs-01.txt >> Pages : 12 >> Date : 2010-02-19 >> >> This document states requirements for a standardized SIP registration >> mechanism for multiple addresses of record, the mechanism being >> suitable for deployment by SIP service providers on a large scale in >> support of small to medium sized PBXs. The requirements are for a >> solution that can, as a minimum, support AORs based on E.164 numbers. >> >> This work is being discussed on the martini@ietf.org mailing list. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Fri Feb 19 20:54: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 7524228B23E for ; Fri, 19 Feb 2010 20:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.566, 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 Bzh8B-awsuMD for ; Fri, 19 Feb 2010 20:54:57 -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 5E8883A72CE for ; Fri, 19 Feb 2010 20:54:57 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.73]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 20:56:46 -0800 X-Originating-IP: [64.134.238.98] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 19 Feb 2010 20:56:42 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CAB1A6.0A56F940" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqx6RgYDE9q/DzeSNGgmfcwPs10EA== Content-Language: en-us X-OriginalArrivalTime: 20 Feb 2010 04:56:46.0549 (UTC) FILETIME=[1A9D4050:01CAB1E9] Subject: [martini] MARTINI WG Last Call on the Requirements document X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 20 Feb 2010 04:54:58 -0000 ------=_NextPart_000_0001_01CAB1A6.0A56F940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is an announcement of MARTINI WG Last Call on the "Requirements" document, prior to sending it on to the IESG for publication as an Informational RFC. The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-martini-reqs The MARTINI WG last call will last until Friday, March 5, 2010. Please respond to this WG last call, whether you have comments or not. If you have no comments, please reply to this message and indicate in the body of your message whether you think the document is ready for consideration by the IESG or not. If you have comments, please provide them to the WG in one of the following ways: 1. If you have an account on the IETF Tools server, or can open one, please login and enter your issue(s) in the MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. 2. If you don't have an account on the IETF Tools server, please post your Issue to the MARTINI WG mailing list (martini@ietf.org) in the following format: To: martini@ietf.org Subject: Requirements-Issue: Priority: blocker, critical, major, minor or trivial <Explanation of your issue, including a proposal for specific text changes to resolve the issue> ------=_NextPart_000_0001_01CAB1A6.0A56F940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal>This is an announcement of MARTINI WG Last Call on = the "Requirements" document, prior to sending it <o:p></o:p></p> <p class=3DMsoNormal>on to the IESG for publication as an Informational = RFC.  The document is available for inspection here:<o:p></o:p></p> <p = class=3DMsoNormal>http://tools.ietf.org/html/draft-ietf-martini-reqs<o:p>= </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The MARTINI WG last call will last until Friday, = March 5, 2010.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Please respond to this WG last call, whether you = have comments or not. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>If you have no comments, please reply to this = message and indicate in the body of your message whether you<o:p></o:p></p> <p class=3DMsoNormal>think the document is ready for consideration by = the IESG or not. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>If you have comments, please provide them to the WG = in one of the following ways: <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>1. If you have an account on the IETF Tools server, = or can open one, please login and enter your issue(s) in the <o:p></o:p></p> <p class=3DMsoNormal>MARTINI Issue tracking database (TRAC), which is = available here:<o:p></o:p></p> <p = class=3DMsoNormal>http://trac.tools.ietf.org/wg/martini/trac/newticket<o:= p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. = <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>2. If you don't have an account on the IETF Tools = server, please post your<o:p></o:p></p> <p class=3DMsoNormal>Issue to the MARTINI WG mailing list = (martini@ietf.org) in the following format: <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>To:  martini@ietf.org<o:p></o:p></p> <p class=3DMsoNormal>Subject: Requirements-Issue: <title of your = issue><o:p></o:p></p> <p class=3DMsoNormal>Priority: blocker, critical, major, minor or = trivial<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><Explanation of your issue, including a proposal = for specific text changes to resolve the issue><o:p></o:p></p> </div> </body> </html> ------=_NextPart_000_0001_01CAB1A6.0A56F940-- From trac@tools.ietf.org Fri Feb 19 21:13:56 2010 Return-Path: <trac@tools.ietf.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21F63A8074 for <martini@core3.amsl.com>; Fri, 19 Feb 2010 21:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MidE+xjKqQRd for <martini@core3.amsl.com>; Fri, 19 Feb 2010 21:13:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D39C83A8070 for <martini@ietf.org>; Fri, 19 Feb 2010 21:13:54 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1Nihgr-0005nR-JI; Fri, 19 Feb 2010 21:15:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Sat, 20 Feb 2010 05:15:41 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/1 Message-ID: <067.7d8271ea1de6fc8ed5e023806a546bff@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 19 Feb 2010 21:19:56 -0800 Cc: martini@ietf.org Subject: [martini] #1: Editorial Issues X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 05:13:56 -0000 #1: Editorial Issues ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: john.elwell@… Type: defect | Status: new Priority: trivial | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Some editorial NITs: Section 1 Change: "to cater for UAs behind NATs and" To: "to cater to UAs behind Network Address Translators (NATs) and" Section 3 s/AORS/AORs/ Section 3.1.4 The current syntax for "wildcarded" PAUs is illegal for TEL URIs, based on the ABNF rules for TEL URIs. Please provide a reference. -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/1> martini <http://tools.ietf.org/martini/> From bernard_aboba@hotmail.com Fri Feb 19 21:51:01 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F46B28C115 for <martini@core3.amsl.com>; Fri, 19 Feb 2010 21:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.561, 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 vTvvE12iv4mf for <martini@core3.amsl.com>; Fri, 19 Feb 2010 21:50:55 -0800 (PST) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by core3.amsl.com (Postfix) with ESMTP id 92EA33A7CE9 for <martini@ietf.org>; Fri, 19 Feb 2010 21:50:55 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.71]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 21:52:44 -0800 X-Originating-IP: [64.134.238.98] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: <BLU137-DS17F633291497970FAFA5793450@phx.gbl> From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: <martini@ietf.org> Date: Fri, 19 Feb 2010 21:52:43 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CAB1AD.DDE32570" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqx8OuUhV84+L0ARaauciJ6BsBcpg== Content-Language: en-us X-OriginalArrivalTime: 20 Feb 2010 05:52:44.0885 (UTC) FILETIME=[EC56A850:01CAB1F0] Subject: [martini] The MARTINI User's Guide to TRAC X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 05:51:01 -0000 ------=_NextPart_000_0024_01CAB1AD.DDE32570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Documentation relating to the TRAC Issue Tracking database is available here: http://trac.tools.ietf.org/wg/martini/trac/wiki Since this documentation is somewhat lengthy (and mostly relevant to Admins), here is a pithy synopsis of everything you will need to know to use TRAC as a MARTINI WG participant. 1. To submit an issue in the MARTINI Issues database (known as TRAC), you first need to login to the MARTINI WG site on the tools server (http://tools.ietf.org/wg/martini/trac/login ) 2. If you don't already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http://trac.tools.ietf.org/wg/martini/trac/newticket 4. When opening an issue: a. The Type: field should be set to "defect" for an issue with the current document text, or "enhancement" for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically "minor" or "trivial". c. The Milestone: field should be set to milestone1 (useless, I know). d. The Component: field should be set to the document you are filing the issue on. Currently "Reqs" is the only available choice, since this is the only WG work item. e. The Version: field should be set to "1.0". f. The Severity: field should be set to based on the status of the document (e.g. "In WG Last Call" for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you. h. The Assign To: field is generally filled in with the email address of the editor. 5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select "I have files to attach to this ticket". 6. If you want to preview your Issue, click on the "Preview" button. When you're ready to submit the issue, click on the "Create Ticket" button. That's it! If you have an problems in dealing with TRAC, send email to me and I'll try to figure out what's going on. Happy TRACing, Bernard ------=_NextPart_000_0024_01CAB1AD.DDE32570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:478423222; mso-list-type:hybrid; mso-list-template-ids:-2125976136 67698713 67698713 67698715 67698703 = 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} @list l1 {mso-list-id:1806116149; mso-list-type:hybrid; mso-list-template-ids:-1027539962 67698703 67698713 67698715 67698703 = 67698713 67698715 67698703 67698713 67698715;} @list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal>Documentation relating to the TRAC Issue Tracking = database is available here:<o:p></o:p></p> <p class=3DMsoNormal><a = href=3D"http://trac.tools.ietf.org/wg/martini/trac/wiki">http://trac.tool= s.ietf.org/wg/martini/trac/wiki</a><o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Since this documentation is somewhat lengthy (and = mostly relevant to Admins), here is a pithy synopsis of everything you will = need to know to use TRAC as a MARTINI WG participant. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>To submit an issue in the MARTINI Issues = database (known as TRAC), you first need to login to the MARTINI WG site on the = tools server (<a = href=3D"http://tools.ietf.org/wg/martini/trac/login">http://tools.ietf.or= g/wg/martini/trac/login</a> ) <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>2.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>If you don’t already have a login ID, you = can obtain one by navigating to this site:   <a href=3D"http://trac.tools.ietf.org/newlogin">http://trac.tools.ietf.org/n= ewlogin</a><o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>3.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>Once you have obtained an account, and have = logged in, you can file an issue by navigating to the  ticket entry form: <a href=3D"http://trac.tools.ietf.org/wg/martini/trac/newticket">http://trac= .tools.ietf.org/wg/martini/trac/newticket</a><o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>4.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>When opening an issue:<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>a.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>The Type: field should be set to = “defect” for an issue with the current document text, or = “enhancement” for a proposed addition of functionality (such as an additional requirement). = <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>b.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span><![endif]>The Priority: field is set based on the severity = of the Issue.   For example, editorial issues are typically = “minor” or “trivial”. <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>c.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>The Milestone: field should be set to milestone1 (useless, I know). <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>d.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span><![endif]>The Component: field should be set to the = document you are filing the issue on.  Currently “Reqs” is the only = available choice, since this is the only WG work item. <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>e.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span><![endif]>The Version: field should be set to = “1.0”. <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>f.<span style=3D'font:7.0pt "Times New = Roman"'>        </span></span><![endif]>The Severity: field should be set to based on = the status of the document (e.g. “In WG Last Call” for a = document in WG last call)<o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>g.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]> The Keywords: and CC: fields can be left = blank unless inspiration seizes you. <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>h.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span><![endif]>The Assign To: field is generally filled in with = the email address of the editor. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>5.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>Typically it won’t be necessary to enclose = a file with the ticket, but if you need to, select “I have files to = attach to this ticket”. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>6.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>If you want to preview your Issue, click on the = “Preview” button.  When you’re ready to submit the issue, click on the = “Create Ticket” button. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>That’s it!  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>If you have an problems in dealing with TRAC, send = email to me and I’ll try to figure out what’s going on. = <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Happy TRACing,<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Bernard<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> </div> </body> </html> ------=_NextPart_000_0024_01CAB1AD.DDE32570-- From trac@tools.ietf.org Fri Feb 19 21:21:46 2010 Return-Path: <trac@tools.ietf.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1905C3A80AB for <martini@core3.amsl.com>; Fri, 19 Feb 2010 21:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3CBCtT8Sq58 for <martini@core3.amsl.com>; Fri, 19 Feb 2010 21:21:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4E78A3A80A6 for <martini@ietf.org>; Fri, 19 Feb 2010 21:21:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1NihoU-0000q7-Oz; Fri, 19 Feb 2010 21:23:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Sat, 20 Feb 2010 05:23:34 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/2 Message-ID: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 19 Feb 2010 21:52:48 -0800 Cc: martini@ietf.org Subject: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 05:21:46 -0000 #2: Scaling to Several Thousand Assigned Telephone Numbers ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: john.elwell@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Section 5 DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand assigned telephone numbers. [BA] Do we really think that the MARTINI mechanism will be used to register several thousand AORs?? I had thought that is mechanism is most likely to appeal to small businesses or branch offices with a modest number of extensions (e.g. typically a few hundred at most). Recommending that the mechanism work with several thousand AORs has implications for issues such as request or response fragmentation, SIP message size, etc. So before putting in a requirement like this (even if it is only desirable), I'd like to see concrete evidence that there are real customers out there who both might use it that way, and have good reasons to do so (e.g. there is a good reason why they can't use RFC 3263 domain routing instead with a static or even a dynamically assigned address and dynamic DNS). -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2> martini <http://tools.ietf.org/martini/> From dean.willis@softarmor.com Fri Feb 19 23:09:47 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C46628C0D9 for <martini@core3.amsl.com>; Fri, 19 Feb 2010 23:09:47 -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 VWcxDSerj7dZ for <martini@core3.amsl.com>; Fri, 19 Feb 2010 23:09:46 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8C73928C0F3 for <martini@ietf.org>; Fri, 19 Feb 2010 23:09:46 -0800 (PST) Received: from [10.58.96.138] (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 o1K7BUw1011264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Feb 2010 01:11:32 -0600 Message-ID: <4B7F8B1D.4080507@softarmor.com> Date: Sat, 20 Feb 2010 01:11:25 -0600 From: Dean Willis <dean.willis@softarmor.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Spencer Dawkins <spencer@wonderhamster.org> References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><E903D5C9-DF03-47E6-82CF-11E7DD412836@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <B7B60109988A47408E591FC6F17E60C9@china.huawei.com> <FF84A09F50A6DC48ACB6714F4666CC743F2509AD4D@ESESSCMS0354.eemea.ericsson.se> <4B7858E0.90602@cisco.com> <BLU137-DS63E176E102BA391145310934A0@phx.gbl> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <E978C357371446AD9B8F123582D1C28C@china.huawei.com> <A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net> <4B7D4BA4.8010307@softarmor.com> <EADD8CE589974C4A9F5DD421FE89A152@china.huawei.com> <4B7E29A6.7070400@softarmor.com> <9E28E51137ED46A2B8534BAD96036F8A@china.huawei.com> In-Reply-To: <9E28E51137ED46A2B8534BAD96036F8A@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MARTINI <martini@ietf.org>, Bernard Aboba <bernard_aboba@hotmail.com> Subject: Re: [martini] DID Number Mobility and MARTINI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 07:09:47 -0000 Spencer Dawkins wrote: > > What I'm trying to ask, perhaps not using helpful terminology, is why > middleboxes that I believe are under the same administrative control > as either the SP or the SIP-PBX, need to be treated differently than > we're treating the SP and the SIP-PBX in MARTINI. Here's the argument everybody is thinking but unwilling to say out loud. I'm not sure I believe it, but there may be more truth to it than Senior Management believes. The middleboxes are only nominally under the same administrative control as either SSP or OBX. In practice, they're run by either the service provider or the corporate security department according to "industry best practices". This means that the telecom people have almost no influence on how they get operated. Neither the corporate nor service provider provisioning systems are tied into them, change control requires bribing, suborning, or outmanuevering somebody who thinks that their alleged security expertise puts them above practical considerations like "making the system work right", and in actuality nobody understands how the damned middlebox works or what its supposed to do. It just squats there doing its thing blindly, like a cross between the zodiacal Libra and a turnpike tollbooth. Think how much control the average homeowner has over their NAT-router, and that's about how much control is exercised over the middleboxes. Once the basic setup is done, usually by a vendor sales engineer, the middlebox basically has to learn everything it needs to work by watching the signaling go by because nobody knows how to tell it how to do anything more useful. > > I tried to be clear that MARTINI wasn't provisioning in my post at > http://www.ietf.org/mail-archive/web/martini/current/msg00783.html, > but you may be correct that the word "provisioning" is so poisonous > that I can't use it in a sentence that people can parse. If that's > true, I apologise for using the word. accepted! > > But ... my understanding is that, by some process that is out of scope > for MARTINI, the SP and the SIP-PBX both automagically know, without > either telling the other, what AoRs would be registered, and I'm > asking, if the middlebox is either in the same administrative domain > as the SP, or in the same administrative domain name as the SIP-PBX, > why we can't/shouldn't make the same assumption for middleboxes that > we're already making for the SP and for the SIP-PBX - that they will > automagically know what AoRs are being MARTINI-REGISTERed as well. > The argument basically says that the SSP and the PBX automagically know because either a telecom guy at PBX or one at SSP (depending on which order fulfillment model you believe in) is feeding stuff into the System That Controls Everything Except The Middleboxes. However, the middleboxes, like mushrooms, are kept totally in the dark, and subsist only on the effluent passing by them in the currents of signaling. Imagine the coral reefs that divide the lagoon from the open ocean, and the only way through the reef is to be consumed and digested by the coral, then excreted on the other side. -- Dean From dean.willis@softarmor.com Fri Feb 19 23:15:00 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A37D3A7B42 for <martini@core3.amsl.com>; Fri, 19 Feb 2010 23:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 wXuy4KWxQT7N for <martini@core3.amsl.com>; Fri, 19 Feb 2010 23:14:59 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 31FFF3A6825 for <martini@ietf.org>; Fri, 19 Feb 2010 23:14:59 -0800 (PST) Received: from [10.58.96.138] (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 o1K7GjcZ011313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Feb 2010 01:16:47 -0600 Message-ID: <4B7F8C58.406@softarmor.com> Date: Sat, 20 Feb 2010 01:16:40 -0600 From: Dean Willis <dean.willis@softarmor.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Elwell, John" <john.elwell@siemens-enterprise.com> References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B7858E0.90602@cisco.com> <BLU137-DS63E176E102BA391145310934A0@phx.gbl> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <E978C357371446AD9B8F123582D1C28C@china.huawei.com> <A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> <BLU137-DS78E5C8A1CC7F9A0EAA04F93470@phx.gbl> <D743D3DA3D88485E834338B60E4CB2F7@china.huawei.com> <4B7DCEB7.9010501@nostrum.com> <BLU137-DS5C0DF93FD0B84C7E0FA3A93470@phx.g! bl> <4B7E2D47.9060501@softarmor.com> <A444A0F8084434499206E78C106220CAB93E0833@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAB93E0833@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 07:15:00 -0000 Elwell, John wrote: > (Subject changed) > Dean, you are arguing that some middleboxes need to know registration state so that they can match a Request-URI in an inbound request with a known registered contact URI and block requests where there is no match. > Yep. They may also perform the same blocking on outbound requests; it depends on whether the middlebox is protecting the service provider or the enterprise (or very rarely, both). > I would argue that an SSP would not use such a middlebox if it wanted to offer a MARTINI interface to PBXs. As you say, it is broken. I would argue that we should not try to accommodate such broken middleboxes. > I'd think so too, but apparently people keep deploying the things. > However, if the WG feels there is a need, we would need to introduce a new requirement along the lines of "An edge proxy MUST be able to filter inbound requests to a PBX on the basis of whether or not they are addressed to currently registered contact URIs". > That is exactly the correct question, if you strike the words "inbound" and "to a PBX", and add "or from currently registered contact URIs, or AORs to which a sending Contact is currently registered". -- Dean From dean.willis@softarmor.com Fri Feb 19 23:16:10 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E8E3A81C5 for <martini@core3.amsl.com>; Fri, 19 Feb 2010 23:16:10 -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 ZHqgqb-C31h3 for <martini@core3.amsl.com>; Fri, 19 Feb 2010 23:16:09 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C42EA3A81C3 for <martini@ietf.org>; Fri, 19 Feb 2010 23:16:09 -0800 (PST) Received: from [10.58.96.138] (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 o1K7Hsll011338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Feb 2010 01:17:56 -0600 Message-ID: <4B7F8C9D.5060200@softarmor.com> Date: Sat, 20 Feb 2010 01:17:49 -0600 From: Dean Willis <dean.willis@softarmor.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christer Holmberg <christer.holmberg@ericsson.com> References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><E903D5C9-DF03-47E6-82CF-11E7DD412836@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <B7B60109988A47408E591FC6F17E60C9@china.huawei.com> <FF84A09F50A6DC48ACB6714F4666CC743F2509AD4D@ESESSCMS0354.eemea.ericsson.se> <4B7858E0.90602@cisco.com> <BLU137-DS63E176E102BA391145310934A0@phx.gbl> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <E978C357371446AD9B8F123582D1C28C@china.huawei.com> <A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net> <4B7D4BA4.8010307@softarmor.com> <EADD8CE589974C4A9F5DD421FE89A152@china.huawei.com> <4B7E29A6.7070400@softarmor.com> <FF84A09F50A6DC48ACB6714F4666CC7447519E39FF@ESESSCMS0354.eemea.ericsson.se> In-Reply-To: <FF84A09F50A6DC48ACB6714F4666CC7447519E39FF@ESESSCMS0354.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MARTINI <martini@ietf.org> Subject: Re: [martini] DID Number Mobility and MARTINI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 07:16:10 -0000 Christer Holmberg wrote: > > >> It is generally easier to obtain revisions to the great holy >> books of any major religion than it is to change a >> provisioning system. >> > > Do you include RFC 3261 in that list of holy books? ;) > > Of course! I've been trying to change it for years, but the priesthood keeps blocking! -- Dean From dean.willis@softarmor.com Fri Feb 19 23:25:49 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7011D3A7C6C for <martini@core3.amsl.com>; Fri, 19 Feb 2010 23:25:49 -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.054, 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 gH4FemJGmfMv for <martini@core3.amsl.com>; Fri, 19 Feb 2010 23:25:48 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9C3F93A7C41 for <martini@ietf.org>; Fri, 19 Feb 2010 23:25:48 -0800 (PST) Received: from [10.58.96.138] (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 o1K7RaUv011398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Feb 2010 01:27:37 -0600 Message-ID: <4B7F8EE2.7060905@softarmor.com> Date: Sat, 20 Feb 2010 01:27:30 -0600 From: Dean Willis <dean.willis@softarmor.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Spencer Dawkins <spencer@wonderhamster.org> References: <A444A0F8084434499206E78C106220CAB93E0819@MCHP058A.global-ad.net> <4FAD8A662E174C98A694FD60A19F1B9C@china.huawei.com> <A444A0F8084434499206E78C106220CAB93E0BAD@MCHP058A.global-ad.net> <658BC20C52ED4FC8BFDE2213907E5B29@china.huawei.com> In-Reply-To: <658BC20C52ED4FC8BFDE2213907E5B29@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - routing inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 07:25:49 -0000 Spencer Dawkins wrote: > > Are we saying that middleboxes do this filtering for you if you > REGISTER, but stop doing it if you get your own domain and start using > RFC 3263? Getting your own domain and using RFC 3263 is hard because it requires you to stop using those expensive middleboxes that somebody sold your security department, and the middlebox vendor's sales team is in tight with your CFO. AFAIK, the sipconnect work therefore assumes that most PBXes will have to REGISTER with their SSP. Seriously, people use the middleboxes in large part because they take away the responsibility of running your VoIP system the "right way". Running a system is fairly hard, people are lazy, and it's easier to punt and assume the middlebox knows what it's doing. Since the middlebox isn't tied into anybody's provisioning system (because that would be even harder!), the middlebox has to learn everything by watching signaling go past. I believe this in large part explains the lack of real sips: deployments -- the people running the middleboxes can't handle the key management needed to allow the middlebox to do its job by back-dooring the security infrastructure. -- Dean -- Dean From spencer@wonderhamster.org Sat Feb 20 06:30:53 2010 Return-Path: <spencer@wonderhamster.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C53628C144 for <martini@core3.amsl.com>; Sat, 20 Feb 2010 06:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, 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 eMm1G8TR9v9g for <martini@core3.amsl.com>; Sat, 20 Feb 2010 06:30:52 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 2FFB928C142 for <martini@ietf.org>; Sat, 20 Feb 2010 06:30:52 -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 0MO7O0-1NdKbA0lkq-005f6X; Sat, 20 Feb 2010 09:32:32 -0500 Message-ID: <B93EB88057954076B2989FC9822C0EA0@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "Dean Willis" <dean.willis@softarmor.com> References: <A444A0F8084434499206E78C106220CAB93E0819@MCHP058A.global-ad.net> <4FAD8A662E174C98A694FD60A19F1B9C@china.huawei.com> <A444A0F8084434499206E78C106220CAB93E0BAD@MCHP058A.global-ad.net> <658BC20C52ED4FC8BFDE2213907E5B29@china.huawei.com> <4B7F8EE2.7060905@softarmor.com> Date: Sat, 20 Feb 2010 08:32: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+92f7rNC/TSd3OiJ4oKdtLFlDswx9jBF9RGDg yn9YVUohzaO0Ogm7Nutd57tOAwp95FbmVK33X7yxJObukavALj TFxBNHr/dElKBNYwzKGQIZqZQNaUi9hLK08hprRXCE= Cc: MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - routing inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 14:30:53 -0000 Just a small clarification here... > Getting your own domain and using RFC 3263 is hard because it requires > you to stop using those expensive middleboxes that somebody sold your > security department, and the middlebox vendor's sales team is in tight > with your CFO. AFAIK, the sipconnect work therefore assumes that most > PBXes will have to REGISTER with their SSP. (speaking as SIPconnect 1.1 editor) The current draft of SIPconnect 1.1 has two modes of operation - one using RFC 3263 for call routing, and one currently stalled waiting on MARTINI registration for call routing. Only the latter mode of operation makes that assumption - but it does make that assumption. Thanks, Spencer From richard@shockey.us Sat Feb 20 06:48:38 2010 Return-Path: <richard@shockey.us> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3516B28C154 for <martini@core3.amsl.com>; Sat, 20 Feb 2010 06:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 g5LP8wUS-lhO for <martini@core3.amsl.com>; Sat, 20 Feb 2010 06:48:37 -0800 (PST) Received: from outbound-mail-356.bluehost.com (outbound-mail-356.bluehost.com [66.147.249.250]) by core3.amsl.com (Postfix) with SMTP id 406BC28C152 for <martini@ietf.org>; Sat, 20 Feb 2010 06:48:37 -0800 (PST) Received: (qmail 18655 invoked by uid 0); 20 Feb 2010 14:50:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 20 Feb 2010 14:50:28 -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=FBlyVWJVEgxAsU6c28o5FwHDgTj90F7Xc9txU471OqSgucUk0QSyk5slNDySiHGK4sew4+Sz6k7Jcwq9O+1lmW8sX0G1JiCRCLQWKKDmQj+lrc6d5VeAifePggn1qEZq; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1Niqf5-00074P-Lx for martini@ietf.org; Sat, 20 Feb 2010 07:50:28 -0700 From: "Richard Shockey" <richard@shockey.us> To: "'MARTINI'" <martini@ietf.org> References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> In-Reply-To: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> Date: Sat, 20 Feb 2010 09:50:24 -0500 Message-ID: <000001cab23c$092d3520$1b879f60$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqx8TBbRtdPrnhpQcavA/7YjDk24gASkqFQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 14:48:38 -0000 I think this requirement can safely be removed. The vast majority of = installations I'm aware of that use Implicit Registration are typically = sub 24 CUA's in the single site SMB market. Section 5 DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand assigned telephone numbers. [BA] Do we really think that the MARTINI mechanism will be used to register several thousand AORs?? I had thought that is mechanism is = most likely to appeal to small businesses or branch offices with a modest number of extensions (e.g. typically a few hundred at most). Recommending that the mechanism work with several thousand AORs has implications for issues such as request or response fragmentation, SIP message size, etc. So before putting in a requirement like this (even = if it is only desirable), I'd like to see concrete evidence that there are real customers out there who both might use it that way, and have good reasons to do so (e.g. there is a good reason why they can't use RFC 3263 domain routing instead with a static = or even a dynamically assigned address and dynamic DNS). --=20 Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2> martini <http://tools.ietf.org/martini/> _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From md3135@att.com Sat Feb 20 07:00:54 2010 Return-Path: <md3135@att.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5798D3A8159 for <martini@core3.amsl.com>; Sat, 20 Feb 2010 07:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd1bpSSBlSVk for <martini@core3.amsl.com>; Sat, 20 Feb 2010 07:00:53 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 5EF723A6FF9 for <martini@ietf.org>; Sat, 20 Feb 2010 07:00:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1266678162!33263156!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 23346 invoked from network); 20 Feb 2010 15:02:43 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Feb 2010 15:02:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1KF2Y3k002324; Sat, 20 Feb 2010 10:02:34 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1KF2UxY002310; Sat, 20 Feb 2010 10:02:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 20 Feb 2010 10:02:38 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D63@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers Thread-Index: Acqx8TBbRtdPrnhpQcavA/7YjDk24gASkqFQAACQ3gk= From: "DOLLY, MARTIN C (ATTLABS)" <md3135@att.com> To: <richard@shockey.us>, <martini@ietf.org> Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 15:00:54 -0000 U28gdGhlIHNjb3BlIGlzIGxpbWl0ZWQgdG8gU01CDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCkZyb206IG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZyA8bWFydGluaS1ib3VuY2VzQGll dGYub3JnPg0KVG86ICdNQVJUSU5JJyA8bWFydGluaUBpZXRmLm9yZz4NClNlbnQ6IFNhdCBGZWIg MjAgMDk6NTA6MjQgMjAxMA0KU3ViamVjdDogUmU6IFttYXJ0aW5pXSAjMjogU2NhbGluZyB0byBT ZXZlcmFsIFRob3VzYW5kIEFzc2lnbmVkIFRlbGVwaG9uZU51bWJlcnMNCg0KSSB0aGluayB0aGlz IHJlcXVpcmVtZW50IGNhbiBzYWZlbHkgYmUgcmVtb3ZlZC4gVGhlIHZhc3QgbWFqb3JpdHkgb2Yg aW5zdGFsbGF0aW9ucyBJJ20gYXdhcmUgb2YgdGhhdCB1c2UgSW1wbGljaXQgUmVnaXN0cmF0aW9u IGFyZSB0eXBpY2FsbHkgc3ViIDI0IENVQSdzIGluIHRoZSBzaW5nbGUgc2l0ZSBTTUIgbWFya2V0 Lg0KDQoNCg0KIFNlY3Rpb24gNQ0KDQogICAgREVTMiAtIFRoZSBtZWNoYW5pc20gU0hPVUxEIHNj YWxlIHRvIFNJUC1QQlhzIG9mIHNldmVyYWwgdGhvdXNhbmQNCiAgICBhc3NpZ25lZCB0ZWxlcGhv bmUgbnVtYmVycy4NCg0KIFtCQV0gRG8gd2UgcmVhbGx5IHRoaW5rIHRoYXQgdGhlIE1BUlRJTkkg bWVjaGFuaXNtIHdpbGwgYmUgdXNlZCB0bw0KIHJlZ2lzdGVyIHNldmVyYWwgdGhvdXNhbmQgQU9S cz8/ICBJIGhhZCB0aG91Z2h0IHRoYXQgaXMgbWVjaGFuaXNtIGlzIG1vc3QNCiBsaWtlbHkgdG8g YXBwZWFsIHRvIHNtYWxsIGJ1c2luZXNzZXMgb3IgYnJhbmNoIG9mZmljZXMgd2l0aCBhIG1vZGVz dA0KIG51bWJlciBvZiBleHRlbnNpb25zIChlLmcuIHR5cGljYWxseSBhIGZldyBodW5kcmVkIGF0 IG1vc3QpLg0KDQogUmVjb21tZW5kaW5nIHRoYXQgdGhlIG1lY2hhbmlzbSB3b3JrIHdpdGggc2V2 ZXJhbCB0aG91c2FuZCBBT1JzIGhhcw0KIGltcGxpY2F0aW9ucyBmb3IgaXNzdWVzIHN1Y2ggYXMg cmVxdWVzdCBvciByZXNwb25zZSBmcmFnbWVudGF0aW9uLCBTSVANCiBtZXNzYWdlIHNpemUsIGV0 Yy4gIFNvIGJlZm9yZSBwdXR0aW5nIGluIGEgcmVxdWlyZW1lbnQgbGlrZSB0aGlzIChldmVuIGlm DQogaXQgaXMgb25seSBkZXNpcmFibGUpLCBJJ2QgbGlrZSB0byBzZWUgY29uY3JldGUgZXZpZGVu Y2UgdGhhdCB0aGVyZSBhcmUNCiByZWFsIGN1c3RvbWVycyBvdXQgdGhlcmUgd2hvIGJvdGggbWln aHQNCiB1c2UgaXQgdGhhdCB3YXksIGFuZCBoYXZlIGdvb2QgcmVhc29ucyB0byBkbyBzbyAoZS5n LiB0aGVyZSBpcyBhIGdvb2QNCiByZWFzb24gd2h5IHRoZXkgY2FuJ3QgdXNlIFJGQyAzMjYzIGRv bWFpbiByb3V0aW5nIGluc3RlYWQgd2l0aCBhIHN0YXRpYyBvcg0KIGV2ZW4gYSBkeW5hbWljYWxs eSBhc3NpZ25lZCBhZGRyZXNzIGFuZCBkeW5hbWljIEROUykuDQoNCi0tIA0KVGlja2V0IFVSTDog PGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL21hcnRpbmkvdHJhYy90aWNrZXQvMj4NCm1h cnRpbmkgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9tYXJ0aW5pLz4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hcnRpbmkgbWFpbGluZyBsaXN0DQpt YXJ0aW5pQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h cnRpbmkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1hcnRpbmkgbWFpbGluZyBsaXN0DQptYXJ0aW5pQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmkNCg== From richard@shockey.us Sat Feb 20 07:12:57 2010 Return-Path: <richard@shockey.us> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7EE228C14A for <martini@core3.amsl.com>; Sat, 20 Feb 2010 07:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 9af52QLZOF9e for <martini@core3.amsl.com>; Sat, 20 Feb 2010 07:12:56 -0800 (PST) Received: from outbound-mail-356.bluehost.com (outbound-mail-356.bluehost.com [66.147.249.250]) by core3.amsl.com (Postfix) with SMTP id 356EF28C149 for <martini@ietf.org>; Sat, 20 Feb 2010 07:12:56 -0800 (PST) Received: (qmail 23665 invoked by uid 0); 20 Feb 2010 15:14:47 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 20 Feb 2010 15:14:47 -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=ZvF6GYYDEz3o16SesB3aE4RgNVrhK8jBpoSx9wt6vzk903ttvzKwWBNYwDNV0l53oc5gRRxFW//mL1HNje0MCHnkd+OPuc2FOx0Z5lp8FN4SEg2l1DLWdjMnXAazni8r; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1Nir2d-0000x9-00; Sat, 20 Feb 2010 08:14:47 -0700 From: "Richard Shockey" <richard@shockey.us> To: "'Dean Willis'" <dean.willis@softarmor.com>, "'Spencer Dawkins'" <spencer@wonderhamster.org> References: <A444A0F8084434499206E78C106220CAB93E0819@MCHP058A.global-ad.net> <4FAD8A662E174C98A694FD60A19F1B9C@china.huawei.com> <A444A0F8084434499206E78C106220CAB93E0BAD@MCHP058A.global-ad.net> <658BC20C52ED4FC8BFDE2213907E5B29@china.huawei.com> <4B7F8EE2.7060905@softarmor.com> In-Reply-To: <4B7F8EE2.7060905@softarmor.com> Date: Sat, 20 Feb 2010 10:14:43 -0500 Message-ID: <000b01cab23f$6effc4a0$4cff4de0$@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: Acqx/i7kGlBLPEdFQzO7boPAa/dk/wAPh/bw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - routing inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 15:12:57 -0000 Dean ...like DUH here! Does this actually surprise you? As I think we have understood 99.967 percent of SIP PBX installations use phone numbers. Your vets office, hair salon and auto body shop really doesn't care about key management, middle boxes and probably will never use a SIP URI on the side of their trucks. The ultimate customer here wants nice simple dial tone with no hassles. Some nice CLEC or MSO came to the business owner with a offer.. new phones, HD TV for the waiting room, Internet WIFI etal and probably real customer support for a price that was probably lower than his PRI voice only service. "Press hard you are making three copies..the installation team will be there Thursday." Sure there are some business case assumptions in why MARTINI is scoped the way it is but it is a feature not a bug. As for the reasons for the lack of SIPS deployments, there is a simpler answer. No one cares other than the govt. In the vast majority of SIP trunking installations SSP also is controlling the Layer 1 circuit which is why I hear the "Why do I need TLS?" question all the time. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis Sent: Saturday, February 20, 2010 2:28 AM To: Spencer Dawkins Cc: MARTINI Subject: Re: [martini] Middlebox needs - routing inbound requests Spencer Dawkins wrote: > > Are we saying that middleboxes do this filtering for you if you > REGISTER, but stop doing it if you get your own domain and start using > RFC 3263? Getting your own domain and using RFC 3263 is hard because it requires you to stop using those expensive middleboxes that somebody sold your security department, and the middlebox vendor's sales team is in tight with your CFO. AFAIK, the sipconnect work therefore assumes that most PBXes will have to REGISTER with their SSP. Seriously, people use the middleboxes in large part because they take away the responsibility of running your VoIP system the "right way". Running a system is fairly hard, people are lazy, and it's easier to punt and assume the middlebox knows what it's doing. Since the middlebox isn't tied into anybody's provisioning system (because that would be even harder!), the middlebox has to learn everything by watching signaling go past. I believe this in large part explains the lack of real sips: deployments -- the people running the middleboxes can't handle the key management needed to allow the middlebox to do its job by back-dooring the security infrastructure. -- Dean -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Sat Feb 20 07:14:35 2010 Return-Path: <pkyzivat@cisco.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9C228C14B for <martini@core3.amsl.com>; Sat, 20 Feb 2010 07:14:35 -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 NduoDGrXuj8t for <martini@core3.amsl.com>; Sat, 20 Feb 2010 07:14: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 60C9F3A8159 for <martini@ietf.org>; Sat, 20 Feb 2010 07:14: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: AvsEAAGMf0tAZnwN/2dsb2JhbACbE3OiYpdbhGsEgxU X-IronPort-AV: E=Sophos;i="4.49,508,1262563200"; d="scan'208";a="87674055" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2010 15:16:23 +0000 Received: from [10.86.242.72] (che-vpn-cluster-2-72.cisco.com [10.86.242.72]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1KFGNCk011014; Sat, 20 Feb 2010 15:16:23 GMT Message-ID: <4B7FFCC6.2080705@cisco.com> Date: Sat, 20 Feb 2010 10:16:22 -0500 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis <dean.willis@softarmor.com> References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><E903D5C9-DF03-47E6-82CF-11E7DD412836@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <B7B60109988A47408E591FC6F17E60C9@china.huawei.com> <FF84A09F50A6DC48ACB6714F4666CC743F2509AD4D@ESESSCMS0354.eemea.ericsson.se> <4B7858E0.90602@cisco.com> <BLU137-DS63E176E102BA391145310934A0@phx.gbl> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <E978C357371446AD9B8F123582D1C28C@china.huawei.com> <A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net> <4B7D4BA4.8010307@softarmor.com> <EADD8CE589974C4A9F5DD421FE89A152@china.huawei.com> <4B7E29A6.7070400@softarmor.com> <9E28E51137ED46A2B8534BAD96036F8A@china.huawei.com> <4B7F8B1D.4080507@softarmor.com> In-Reply-To: <4B7F8B1D.4080507@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MARTINI <martini@ietf.org>, Bernard Aboba <bernard_aboba@hotmail.com> Subject: Re: [martini] DID Number Mobility and MARTINI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 15:14:35 -0000 Dean Willis wrote: > However, the > middleboxes, like mushrooms, are kept totally in the dark, and subsist > only on the effluent passing by them in the currents of signaling. > Imagine the coral reefs that divide the lagoon from the open ocean, and > the only way through the reef is to be consumed and digested by the > coral, then excreted on the other side. Dean, I don't know how you keep coming up with such apt imagery, but you do. This is some of the best in awhile! I think somebody should publish a supplement to Bartlett's Familiar Quotations dedicated to you. Paul From richard@shockey.us Sat Feb 20 07:33:04 2010 Return-Path: <richard@shockey.us> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500D728C15D for <martini@core3.amsl.com>; Sat, 20 Feb 2010 07:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 5UVIyoM9IOFg for <martini@core3.amsl.com>; Sat, 20 Feb 2010 07:33:03 -0800 (PST) Received: from outbound-mail-357.bluehost.com (outbound-mail-357.bluehost.com [66.147.249.251]) by core3.amsl.com (Postfix) with SMTP id 3E99728C152 for <martini@ietf.org>; Sat, 20 Feb 2010 07:33:03 -0800 (PST) Received: (qmail 19850 invoked by uid 0); 20 Feb 2010 15:34:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 20 Feb 2010 15:34: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=h0jAwb4l62dV16ZeqHVpV7xRQPd+cTnXxkQZbe2C2ewxxV6UATw3vpHCItDQw6u9qdWCyv1IBilXK79dQbyzZKESGxmpnIJR33bOgb/32Xw9/2G7lRlWMMQdDs9fkm8n; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1NirM5-0001uN-Qs; Sat, 20 Feb 2010 08:34:54 -0700 From: "Richard Shockey" <richard@shockey.us> To: "'DOLLY, MARTIN C \(ATTLABS\)'" <md3135@att.com>, <martini@ietf.org> References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D63@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D63@gaalpa1msgusr7e.ugd.att.com> Date: Sat, 20 Feb 2010 10:34:50 -0500 Message-ID: <000f01cab242$3e5194c0$baf4be40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqx8TBbRtdPrnhpQcavA/7YjDk24gASkqFQAACQ3gkAARI1wA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 15:33:04 -0000 Well Marty I never want to say never but it seems to be the reality. = Then you have to define SMB and I don=E2=80=99t think we want to go = there either ..its like the FCC trying to define Broadband. -----Original Message----- From: DOLLY, MARTIN C (ATTLABS) [mailto:md3135@att.com]=20 Sent: Saturday, February 20, 2010 10:03 AM To: richard@shockey.us; martini@ietf.org Subject: Re: [martini] #2: Scaling to Several Thousand Assigned = TelephoneNumbers So the scope is limited to SMB ----- Original Message ----- From: martini-bounces@ietf.org <martini-bounces@ietf.org> To: 'MARTINI' <martini@ietf.org> Sent: Sat Feb 20 09:50:24 2010 Subject: Re: [martini] #2: Scaling to Several Thousand Assigned = TelephoneNumbers I think this requirement can safely be removed. The vast majority of = installations I'm aware of that use Implicit Registration are typically = sub 24 CUA's in the single site SMB market. Section 5 DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand assigned telephone numbers. [BA] Do we really think that the MARTINI mechanism will be used to register several thousand AORs?? I had thought that is mechanism is = most likely to appeal to small businesses or branch offices with a modest number of extensions (e.g. typically a few hundred at most). Recommending that the mechanism work with several thousand AORs has implications for issues such as request or response fragmentation, SIP message size, etc. So before putting in a requirement like this (even = if it is only desirable), I'd like to see concrete evidence that there are real customers out there who both might use it that way, and have good reasons to do so (e.g. there is a good reason why they can't use RFC 3263 domain routing instead with a static = or even a dynamically assigned address and dynamic DNS). --=20 Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2> martini <http://tools.ietf.org/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 Sat Feb 20 08:55:13 2010 Return-Path: <spencer@wonderhamster.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF883A7FB0 for <martini@core3.amsl.com>; Sat, 20 Feb 2010 08:55:13 -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 psF71TOpkGzC for <martini@core3.amsl.com>; Sat, 20 Feb 2010 08:55:12 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 9A1E63A7CD0 for <martini@ietf.org>; Sat, 20 Feb 2010 08:55:12 -0800 (PST) Received: from S73602b (67-200-163-178.static.logixcom.net [67.200.163.178]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MhR1O-1O5TxI2SOY-00M9HL; Sat, 20 Feb 2010 11:57:03 -0500 Message-ID: <AEB54955E56D451C8BB23B6899D91970@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "DOLLY, MARTIN C \(ATTLABS\)" <md3135@att.com>, <richard@shockey.us>, <martini@ietf.org> References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D63@gaalpa1msgusr7e.ugd.att.com> Date: Sat, 20 Feb 2010 10:56:44 -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+mIA+9EXvmwxunK6DgvJcrunmrc8RkJIbZ5it w0nlV7J6L/yEHyDcOT09kBG7IMLQPFzS5FK9hymSdIus7MWSD6 kHRchCl6fVTBSbjfc4PKWsyUPkGmoMtuAOFgyxZaMM= Subject: Re: [martini] #2: Scaling to Several Thousand AssignedTelephoneNumbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2010 16:55:13 -0000 (where "SMB" is defined as "the number of AoRs that we don't have to worry about fragmentation to include") :-) ? > So the scope is limited to SMB > > ----- Original Message ----- > From: martini-bounces@ietf.org <martini-bounces@ietf.org> > To: 'MARTINI' <martini@ietf.org> > Sent: Sat Feb 20 09:50:24 2010 > Subject: Re: [martini] #2: Scaling to Several Thousand Assigned > TelephoneNumbers > > I think this requirement can safely be removed. The vast majority of > installations I'm aware of that use Implicit Registration are typically > sub 24 CUA's in the single site SMB market. > > > > Section 5 > > DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand > assigned telephone numbers. > > [BA] Do we really think that the MARTINI mechanism will be used to > register several thousand AORs?? I had thought that is mechanism is most > likely to appeal to small businesses or branch offices with a modest > number of extensions (e.g. typically a few hundred at most). > > Recommending that the mechanism work with several thousand AORs has > implications for issues such as request or response fragmentation, SIP > message size, etc. So before putting in a requirement like this (even if > it is only desirable), I'd like to see concrete evidence that there are > real customers out there who both might > use it that way, and have good reasons to do so (e.g. there is a good > reason why they can't use RFC 3263 domain routing instead with a static or > even a dynamically assigned address and dynamic DNS). > > -- > Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2> > martini <http://tools.ietf.org/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 dean.willis@softarmor.com Sun Feb 21 08:15:44 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1CE3A7978 for <martini@core3.amsl.com>; Sun, 21 Feb 2010 08:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBu9cm7gAz3u for <martini@core3.amsl.com>; Sun, 21 Feb 2010 08:15:42 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2BA4A3A711D for <martini@ietf.org>; Sun, 21 Feb 2010 08:15:42 -0800 (PST) Received: from [10.58.96.138] (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 o1LGHWpp023631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Feb 2010 10:17:35 -0600 Message-ID: <4B815C97.90904@softarmor.com> Date: Sun, 21 Feb 2010 10:17:27 -0600 From: Dean Willis <dean.willis@softarmor.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4D63@gaalpa1msgusr7e.ugd.att.com> <AEB54955E56D451C8BB23B6899D91970@china.huawei.com> In-Reply-To: <AEB54955E56D451C8BB23B6899D91970@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] #2: Scaling to Several Thousand AssignedTelephoneNumbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 21 Feb 2010 16:15:44 -0000 Spencer Dawkins wrote: > (where "SMB" is defined as "the number of AoRs that we don't have to > worry about fragmentation to include") :-) ? > Ok, that's a good question. Exactly what is the limit on the number of AORs that we can encode without worrying about fragmentation? Reverse-engineering, I suppose we should have a number for the size of a current registration message. I just wiresharked my ekiga and gizmo registrations, and they're 584 and 633 bytes each, respectively. If that's representative, this gives something in the neighborhood of 700 bytes of wiggle room. At 10 bytes per phone number range, that's about 70 numbers. So, worst-case, we COULD explicitly list a few dozen URIs without having to worry about clever encoding of ranges, and with clever encoding we might reasonably expect more than 50 phone number ranges. By the way, I had not done a packet capture on my Ekiga client lately. My goodness it is chatty! Lots of 489 and 405 messages, too, indicating somebody didn't capabilities-match very well. -- Dean -- Dean From christer.holmberg@ericsson.com Sun Feb 21 21:20:00 2010 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A413A7B36 for <martini@core3.amsl.com>; Sun, 21 Feb 2010 21:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=-0.151, 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 FCvL2+fDX+9X for <martini@core3.amsl.com>; Sun, 21 Feb 2010 21:20:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A6D4E3A7B1F for <martini@ietf.org>; Sun, 21 Feb 2010 21:19:59 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-19-4b821473c213 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D6.6D.31641.374128B4; Mon, 22 Feb 2010 06:21:55 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 22 Feb 2010 06:21:55 +0100 From: Christer Holmberg <christer.holmberg@ericsson.com> To: 'Paul Kyzivat' <pkyzivat@cisco.com>, Dean Willis <dean.willis@softarmor.com> Date: Mon, 22 Feb 2010 06:21:54 +0100 Thread-Topic: [martini] DID Number Mobility and MARTINI Thread-Index: AcqyP65SaMeRKk3uT+mD0R6tHiZ8QwBPsykA Message-ID: <FF84A09F50A6DC48ACB6714F4666CC744E1A845FEF@ESESSCMS0354.eemea.ericsson.se> References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><E903D5C9-DF03-47E6-82CF-11E7DD412836@softarmor.com> <4B72A724.6D98.00CB.0@cablevision.com> <B7B60109988A47408E591FC6F17E60C9@china.huawei.com> <FF84A09F50A6DC48ACB6714F4666CC743F2509AD4D@ESESSCMS0354.eemea.ericsson.se> <4B7858E0.90602@cisco.com> <BLU137-DS63E176E102BA391145310934A0@phx.gbl> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <E978C357371446AD9B8F123582D1C28C@china.huawei.com> <A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net> <4B7D4BA4.8010307@softarmor.com> <EADD8CE589974C4A9F5DD421FE89A152@china.huawei.com> <4B7E29A6.7070400@softarmor.com> <9E28E51137ED46A2B8534BAD96036F8A@china.huawei.com> <4B7F8B1D.4080507@softarmor.com> <4B7FFCC6.2080705@cisco.com> In-Reply-To: <4B7FFCC6.2080705@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: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] DID Number Mobility and MARTINI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 05:20:01 -0000 The coral reefs are disapearing because of all the crap in the oceans. The middleboxes are deployed because of all the crap on the internet. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 20. helmikuuta 2010 17:16 To: Dean Willis Cc: MARTINI; Bernard Aboba Subject: Re: [martini] DID Number Mobility and MARTINI Dean Willis wrote: > However, the > middleboxes, like mushrooms, are kept totally in the dark, and subsist=20 > only on the effluent passing by them in the currents of signaling. > Imagine the coral reefs that divide the lagoon from the open ocean,=20 > and the only way through the reef is to be consumed and digested by=20 > the coral, then excreted on the other side. Dean, I don't know how you keep coming up with such apt imagery, but you do. This is some of the best in awhile! I think somebody should publish a supplement to Bartlett's Familiar Quotati= ons dedicated to you. Paul _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From trac@tools.ietf.org Mon Feb 22 00:13:23 2010 Return-Path: <trac@tools.ietf.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21D928C0CF for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlM+94fwC0HZ for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:13:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4731A3A7AF7 for <martini@ietf.org>; Mon, 22 Feb 2010 00:13:16 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1NjTRb-0005Wk-S1; Mon, 22 Feb 2010 00:15:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens.com, john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 22 Feb 2010 08:15:07 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/3 Message-ID: <076.528e2a835ae2d9054533d1ea46b03e16@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens.com, john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #3: Requirement for identity assertions X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 08:13:23 -0000 #3: Requirement for identity assertions ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: john.elwell@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- Do we need a requirements along the lines of "An edge proxy shall be able to base identity assertions for outbound (non-REGISTER) requests received from a PBX on whether the identity concerned has been registered."? -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/3> martini <http://tools.ietf.org/martini/> From john.elwell@siemens-enterprise.com Mon Feb 22 00:14:06 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1542D28C12C for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ZZsS42dDukcO for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:13: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 AAD383A839C for <martini@ietf.org>; Mon, 22 Feb 2010 00:13:48 -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-960029 for martini@ietf.org; Mon, 22 Feb 2010 09:15:45 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 92FD41EB82AB for <martini@ietf.org>; Mon, 22 Feb 2010 09:15:45 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Feb 2010 09:15:45 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: MARTINI <martini@ietf.org> Date: Mon, 22 Feb 2010 09:15:43 +0100 Thread-Topic: Possible additional requirement - identity assertions - consensus call Thread-Index: Acqzlzp4ChUXdBxuQja3DXvZf+DHAQ== Message-ID: <A444A0F8084434499206E78C106220CAB93E0F40@MCHP058A.global-ad.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 Subject: [martini] Possible additional requirement - identity assertions - consensus call X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 08:14:07 -0000 A short while ago, Bruno proposed the following requirement, which is not i= n reqs-01 (because I didn't feel there was any consensus). "An edge proxy shall be able to base identity assertions for outbound (non-= REGISTER) requests received from a PBX on whether the identity concerned ha= s been registered."=20 Please indicate whether you would like to see such a requirement. John (as editor)= From john.elwell@siemens-enterprise.com Mon Feb 22 00:35:01 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9120428C22D for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 um+AZXJyorbq for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:35: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 8400928C12A for <martini@ietf.org>; Mon, 22 Feb 2010 00:35:00 -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-959543; Mon, 22 Feb 2010 09:36:57 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 9297E23F0278; Mon, 22 Feb 2010 09:36:57 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Feb 2010 09:36:57 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> Date: Mon, 22 Feb 2010 09:36:56 +0100 Thread-Topic: [martini] #1: Editorial Issues Thread-Index: Acqx68D1DQFc0gocRY68r5IVASNI9ABrSFjQ Message-ID: <A444A0F8084434499206E78C106220CAB93E0F77@MCHP058A.global-ad.net> References: <067.7d8271ea1de6fc8ed5e023806a546bff@tools.ietf.org> In-Reply-To: <067.7d8271ea1de6fc8ed5e023806a546bff@tools.ietf.org> 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" <martini@ietf.org> Subject: Re: [martini] #1: Editorial Issues X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 08:35:01 -0000 Keith, The last of these "editorial issues" calls for a reference to the place whe= re 3GPP defines wildcard public user identities. I looked in 24.229 (release 9) and found in 5.2.6.3.3 item 6A a reference t= o RFC 5002. Yet RFC 5002 mentions only wildcard public service identities. = Please can you clarify what should be the correct reference for wildcard pu= blic user identities? Thanks, John=09 =20 > -----Original Message----- > From: martini issue tracker [mailto:trac@tools.ietf.org]=20 > Sent: 20 February 2010 05:16 > To: Elwell, John; bernard_aboba@hotmail.com > Cc: martini@ietf.org > Subject: [martini] #1: Editorial Issues >=20 > #1: Editorial Issues > ---------------------------------------+---------------------- > -------------- > Reporter: bernard_aboba@... | Owner: =20 > john.elwell@... =20 > Type: defect | Status: new =20 > =20 > Priority: trivial | Milestone: =20 > milestone1 =20 > Component: reqs | Version: 1.0 =20 > =20 > Severity: In WG Last Call | Keywords: =20 > =20 > ---------------------------------------+---------------------- > -------------- > Some editorial NITs: >=20 > Section 1 >=20 > Change: >=20 > "to cater for UAs behind NATs and" >=20 > To: >=20 > "to cater to UAs behind Network Address Translators (NATs) and" >=20 >=20 > Section 3 >=20 > s/AORS/AORs/ >=20 > Section 3.1.4 >=20 > The current syntax for "wildcarded" PAUs is illegal for TEL URIs, > based on the ABNF rules for TEL URIs. >=20 > Please provide a reference. >=20 > --=20 > Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/1> > martini <http://tools.ietf.org/martini/> >=20 > = From trac@tools.ietf.org Mon Feb 22 00:40:55 2010 Return-Path: <trac@tools.ietf.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088D828C12C for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYKJMZM1xVpH for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:40:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 69D9228C0FC for <martini@ietf.org>; Mon, 22 Feb 2010 00:40:54 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1NjTsR-0005zv-U4; Mon, 22 Feb 2010 00:42:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 22 Feb 2010 08:42:51 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/1#comment:1 Message-ID: <076.15e2bd275f0e4262d667436a1cbb1a5c@tools.ietf.org> References: <067.7d8271ea1de6fc8ed5e023806a546bff@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <067.7d8271ea1de6fc8ed5e023806a546bff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #1: Editorial Issues X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 08:40:55 -0000 #1: Editorial Issues ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: john.elwell@… Type: defect | Status: new Priority: trivial | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Comment(by john.elwell@…): All done, except waiting for reference to wildcarding. -- Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/1#comment:1> martini <http://tools.ietf.org/martini/> From john.elwell@siemens-enterprise.com Mon Feb 22 00:57:53 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7FC28C12A for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:57:53 -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.037, 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 6uhluM6S6Z54 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 00:57:52 -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 73F4128C0E6 for <martini@ietf.org>; Mon, 22 Feb 2010 00:57:52 -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-959889 for martini@ietf.org; Mon, 22 Feb 2010 09:59:49 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 958AD23F0278 for <martini@ietf.org>; Mon, 22 Feb 2010 09:59:49 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 22 Feb 2010 09:59:49 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "martini@ietf.org" <martini@ietf.org> Date: Mon, 22 Feb 2010 09:59:47 +0100 Thread-Topic: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers Thread-Index: Acqx7No/xlTXkV/sQXOg+S3AU/Y82QBr/Diw Message-ID: <A444A0F8084434499206E78C106220CAB93E0FAC@MCHP058A.global-ad.net> References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> In-Reply-To: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> 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] #2: Scaling to Several Thousand Assigned Telephone Numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 08:57:53 -0000 Yes, there was some discussion on this way back, and I guess there was not= clear consensus. I think Spencer suggested it should be removed and Jack w= anted to retain it, so it stayed. I don't know if anyone else spoke for or = against. I believe there should be some sort of figure given here as a desirable tar= get, but "several thousand" might be too high. Clearly a solution that scal= es only to 10 AORs, say, would not be adequate. John > -----Original Message----- > From: martini issue tracker [mailto:trac@tools.ietf.org]=20 > Sent: 20 February 2010 05:24 > To: Elwell, John; bernard_aboba@hotmail.com > Cc: martini@ietf.org > Subject: [martini] #2: Scaling to Several Thousand Assigned=20 > Telephone Numbers >=20 > #2: Scaling to Several Thousand Assigned Telephone Numbers > ---------------------------------------+---------------------- > -------------- > Reporter: bernard_aboba@... | Owner: =20 > john.elwell@... =20 > Type: defect | Status: new =20 > =20 > Priority: major | Milestone: =20 > milestone1 =20 > Component: reqs | Version: 1.0 =20 > =20 > Severity: In WG Last Call | Keywords: =20 > =20 > ---------------------------------------+---------------------- > -------------- > Section 5 >=20 > DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand > assigned telephone numbers. >=20 > [BA] Do we really think that the MARTINI mechanism will be used to > register several thousand AORs?? I had thought that is=20 > mechanism is most > likely to appeal to small businesses or branch offices with a modest > number of extensions (e.g. typically a few hundred at most). >=20 > Recommending that the mechanism work with several thousand AORs has > implications for issues such as request or response=20 > fragmentation, SIP > message size, etc. So before putting in a requirement like=20 > this (even if > it is only desirable), I'd like to see concrete evidence=20 > that there are > real customers out there who both might > use it that way, and have good reasons to do so (e.g. there is a good > reason why they can't use RFC 3263 domain routing instead=20 > with a static or > even a dynamically assigned address and dynamic DNS). >=20 > --=20 > Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2> > martini <http://tools.ietf.org/martini/> >=20 > = From john.elwell@siemens-enterprise.com Mon Feb 22 01:24:59 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E5B3A7DE5 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 01:24:59 -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.037, 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 6NQVF+b-Owbh for <martini@core3.amsl.com>; Mon, 22 Feb 2010 01:24: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 460B03A7851 for <martini@ietf.org>; Mon, 22 Feb 2010 01:24:57 -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-960357; Mon, 22 Feb 2010 10:26:53 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id AE39B1EB82AB; Mon, 22 Feb 2010 10:26:53 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 22 Feb 2010 10:26:53 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Dean Willis <dean.willis@softarmor.com> Date: Mon, 22 Feb 2010 10:26:51 +0100 Thread-Topic: Middlebox needs - admitting inbound requests Thread-Index: Acqx/K4sXnzbq8+YQDaQwEIM73SCrwBo1yJQ Message-ID: <A444A0F8084434499206E78C106220CAB93E0FFC@MCHP058A.global-ad.net> References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B7858E0.90602@cisco.com> <BLU137-DS63E176E102BA391145310934A0@phx.gbl> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <E978C357371446AD9B8F123582D1C28C@china.huawei.com> <A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> <BLU137-DS78E5C8A1CC7F9A0EAA04F93470@phx.gbl> <D743D3DA3D88485E834338B60E4CB2F7@china.huawei.com> <4B7DCEB7.9010501@nostrum.com> <BLU137-DS5C0DF93FD0B84C7E0FA3A93470@phx.g! bl> <4B7E2D47.9060501@softarmor.com> <A444A0F8084434499206E78C106220CAB93E0833@MCHP058A.global-ad.net> <4B7F8C58.406@softarmor.com> In-Reply-To: <4B7F8C58.406@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: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 09:24:59 -0000 Dean, I don't agree with a requirement for supporting the admission of outbound r= equests based on whether the caller has registered. This would prevent, for= example, a call from A to B being forwarded to C via the SSP, where A is n= ot one of the registered AORs at this particular PBX (unless you do horribl= e things that I don't think we want to condone, like pretending the caller = is B, who is registered). If you want to pursue the question of being able to support admitting both = inbound requests and outbound requests on the basis of the current registra= tion state of the AOR, I think we should consider these as separate issues.= Do you want to raise issues on the tracker for one or both of these? John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 20 February 2010 07:17 > To: Elwell, John > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: Middlebox needs - admitting inbound requests >=20 > Elwell, John wrote: > > (Subject changed) > > Dean, you are arguing that some middleboxes need to know=20 > registration state so that they can match a Request-URI in an=20 > inbound request with a known registered contact URI and block=20 > requests where there is no match. > > =20 >=20 > Yep. They may also perform the same blocking on outbound requests; it > depends on whether the middlebox is protecting the service provider or > the enterprise (or very rarely, both). >=20 > > I would argue that an SSP would not use such a middlebox if=20 > it wanted to offer a MARTINI interface to PBXs. As you say,=20 > it is broken. I would argue that we should not try to=20 > accommodate such broken middleboxes. > > =20 >=20 > I'd think so too, but apparently people keep deploying the things. > > However, if the WG feels there is a need, we would need to=20 > introduce a new requirement along the lines of "An edge proxy=20 > MUST be able to filter inbound requests to a PBX on the basis=20 > of whether or not they are addressed to currently registered=20 > contact URIs". > > =20 >=20 > That is exactly the correct question, if you strike the words=20 > "inbound" > and "to a PBX", and add "or from currently registered contact URIs, or > AORs to which a sending Contact is currently registered". >=20 >=20 > -- > Dean > = From john.elwell@siemens-enterprise.com Mon Feb 22 05:39:48 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFCE28C2D3 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 05:39:48 -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 76e0UxJ5Ua5X for <martini@core3.amsl.com>; Mon, 22 Feb 2010 05:39:47 -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 6BA3028C122 for <martini@ietf.org>; Mon, 22 Feb 2010 05:39: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-965192; Mon, 22 Feb 2010 14:41:45 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 47DBB1EB82AB; Mon, 22 Feb 2010 14:41:45 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Feb 2010 14:41:45 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> Date: Mon, 22 Feb 2010 14:41:43 +0100 Thread-Topic: [martini] #1: Editorial Issues Thread-Index: Acqx68D1DQFc0gocRY68r5IVASNI9ABrSFjQAArzsSA= Message-ID: <A444A0F8084434499206E78C106220CAB93E1284@MCHP058A.global-ad.net> References: <067.7d8271ea1de6fc8ed5e023806a546bff@tools.ietf.org> 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" <martini@ietf.org> Subject: Re: [martini] #1: Editorial Issues X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 13:39:48 -0000 I am told the reference is TS 23.003. John=20 > -----Original Message----- > From: Elwell, John=20 > Sent: 22 February 2010 08:37 > To: 'DRAGE, Keith (Keith)' > Cc: martini@ietf.org > Subject: RE: [martini] #1: Editorial Issues >=20 > Keith, >=20 > The last of these "editorial issues" calls for a reference to=20 > the place where 3GPP defines wildcard public user identities. >=20 > I looked in 24.229 (release 9) and found in 5.2.6.3.3 item 6A=20 > a reference to RFC 5002. Yet RFC 5002 mentions only wildcard=20 > public service identities. Please can you clarify what should=20 > be the correct reference for wildcard public user identities? >=20 > Thanks, >=20 > John=09 >=20 > =20 >=20 > > -----Original Message----- > > From: martini issue tracker [mailto:trac@tools.ietf.org]=20 > > Sent: 20 February 2010 05:16 > > To: Elwell, John; bernard_aboba@hotmail.com > > Cc: martini@ietf.org > > Subject: [martini] #1: Editorial Issues > >=20 > > #1: Editorial Issues > > ---------------------------------------+---------------------- > > -------------- > > Reporter: bernard_aboba@... | Owner: =20 > > john.elwell@... =20 > > Type: defect | Status: new =20 > > =20 > > Priority: trivial | Milestone: =20 > > milestone1 =20 > > Component: reqs | Version: 1.0 =20 > > =20 > > Severity: In WG Last Call | Keywords: =20 > > =20 > > ---------------------------------------+---------------------- > > -------------- > > Some editorial NITs: > >=20 > > Section 1 > >=20 > > Change: > >=20 > > "to cater for UAs behind NATs and" > >=20 > > To: > >=20 > > "to cater to UAs behind Network Address Translators (NATs) and" > >=20 > >=20 > > Section 3 > >=20 > > s/AORS/AORs/ > >=20 > > Section 3.1.4 > >=20 > > The current syntax for "wildcarded" PAUs is illegal for=20 > TEL URIs, > > based on the ABNF rules for TEL URIs. > >=20 > > Please provide a reference. > >=20 > > --=20 > > Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/1> > > martini <http://tools.ietf.org/martini/> > >=20 > > = From BLINDSAY@nortel.com Mon Feb 22 06:16:28 2010 Return-Path: <BLINDSAY@nortel.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FFF828C2F5 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 06:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 JU+Y4zI85oYk for <martini@core3.amsl.com>; Mon, 22 Feb 2010 06:16:27 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 563C928C2F4 for <martini@ietf.org>; Mon, 22 Feb 2010 06:16:26 -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 o1MEIKH24976; Mon, 22 Feb 2010 14:18:20 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, 22 Feb 2010 09:18:16 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C9D82F2@zcarhxm1.corp.nortel.com> In-Reply-To: <A444A0F8084434499206E78C106220CAB93E0F40@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Possible additional requirement - identity assertions - consensus call Thread-Index: Acqzlzp4ChUXdBxuQja3DXvZf+DHAQAME+cg References: <A444A0F8084434499206E78C106220CAB93E0F40@MCHP058A.global-ad.net> From: "Brian Lindsay" <blindsay@nortel.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "MARTINI" <martini@ietf.org> Subject: Re: [martini] Possible additional requirement - identity assertions - consensus call X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 14:16:28 -0000 Hi John, I think this should be left out as a general requirement. The discussion on this one suggested a difference in handling identity assertion between a "registration" mode of operation for SIP PBXs, and the mode of operation where SIP PBXs do not register but static IP address assignment or DNS/RFC3263 is used. In general, I would think equivalent handling should be provided in both cases, and we should not define a general requirement that would only work in one context. There was also this post suggesting this is not needed in general: http://www.ietf.org/mail-archive/web/martini/current/msg00814.html Now it is recognized that IMS does this with P-AU to support their P-CSCFs requirements, so it can be a part of specific architectures. I think this becomes a question of ongoing monitoring of this work to mame sure that the mechanism could ultimately be compatible with IMS for example (this is perhaps not the only example). Regards Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: Monday, February 22, 2010 3:16 AM To: MARTINI Subject: [martini] Possible additional requirement - identity assertions - consensus call A short while ago, Bruno proposed the following requirement, which is not in reqs-01 (because I didn't feel there was any consensus). "An edge proxy shall be able to base identity assertions for outbound (non-REGISTER) requests received from a PBX on whether the identity concerned has been registered."=20 Please indicate whether you would like to see such a requirement. John (as editor) _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From trac@tools.ietf.org Mon Feb 22 08:01:10 2010 Return-Path: <trac@tools.ietf.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3019B3A7AF3 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 08:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrFF7BH2tK8k for <martini@core3.amsl.com>; Mon, 22 Feb 2010 08:01:09 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 843C13A7F61 for <martini@ietf.org>; Mon, 22 Feb 2010 08:01:09 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1NjakW-0001gS-Cg; Mon, 22 Feb 2010 08:03:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 22 Feb 2010 16:03:08 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/1#comment:2 Message-ID: <076.87a152eef819f0f450283ef2ae680b43@tools.ietf.org> References: <067.7d8271ea1de6fc8ed5e023806a546bff@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <067.7d8271ea1de6fc8ed5e023806a546bff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #1: Editorial Issues X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 16:01:10 -0000 #1: Editorial Issues ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: john.elwell@… Type: defect | Status: closed Priority: trivial | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Changes (by john.elwell@…): * status: new => closed * resolution: => fixed Comment: Reference 3GPP TS 33.003 to be added. -- Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/1#comment:2> martini <http://tools.ietf.org/martini/> From JSBURTON@cablevision.com Mon Feb 22 08:22:16 2010 Return-Path: <JSBURTON@cablevision.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C173A82FE for <martini@core3.amsl.com>; Mon, 22 Feb 2010 08:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.132, 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 YsZypflVmKoG for <martini@core3.amsl.com>; Mon, 22 Feb 2010 08:22:14 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 4E2F73A82FB for <martini@ietf.org>; Mon, 22 Feb 2010 08:22:13 -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 o1MGOBfo026363 for <martini@ietf.org>; Mon, 22 Feb 2010 11:24:11 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o1MGOBfo026363 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1266855851; bh=8kOQG4IV+Qf9vIN1fijH5SUfruS4zb22oEoFW4x EGgQ=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=QtcEMXY5YA8bRyqPCO0NsjLWgNLNRWr+jIWJw rHvMxI7PKBHkNKwpoRU+Pre5XANEjaYCYYQHY2acTwGub7eGkT6jMsL192R1+QpFUHk AHUrSaUPtk11sYZIX+qEMAdmNVG4uuS4Ah3IWenILZKjF+tUnihUkw0LTTLERC5kEFQ = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Mon, 22 Feb 2010 11:24:11 -0500 Message-Id: <4B826952.38CD.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Mon, 22 Feb 2010 11:23:56 -0500 From: "Jack Burton" <JSBURTON@cablevision.com> To: "martini@ietf.org" <martini@ietf.org> References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> <A444A0F8084434499206E78C106220CAB93E0FAC@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAB93E0FAC@MCHP058A.global-ad.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part82A8468C.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 16:22:16 -0000 --=__Part82A8468C.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit John, I misunderstood the requirement when I made the comment desiring retention. (I was thinking several thousand endpoints among all customers, not behind a single PBX). I am OK with its deletion. -Jack >>> "Elwell, John" <john.elwell@siemens-enterprise.com> 2/22/2010 03:59 >>> Yes, there was some discussion on this way back, and I guess there was not clear consensus. I think Spencer suggested it should be removed and Jack wanted to retain it, so it stayed. I don't know if anyone else spoke for or against. I believe there should be some sort of figure given here as a desirable target, but "several thousand" might be too high. Clearly a solution that scales only to 10 AORs, say, would not be adequate. John > -----Original Message----- > From: martini issue tracker [mailto:trac@tools.ietf.org] > Sent: 20 February 2010 05:24 > To: Elwell, John; bernard_aboba@hotmail.com > Cc: martini@ietf.org > Subject: [martini] #2: Scaling to Several Thousand Assigned > Telephone Numbers > > #2: Scaling to Several Thousand Assigned Telephone Numbers > ---------------------------------------+---------------------- > -------------- > Reporter: bernard_aboba@... | Owner: > john.elwell@... > Type: defect | Status: new > > Priority: major | Milestone: > milestone1 > Component: reqs | Version: 1.0 > > Severity: In WG Last Call | Keywords: > > ---------------------------------------+---------------------- > -------------- > Section 5 > > DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand > assigned telephone numbers. > > [BA] Do we really think that the MARTINI mechanism will be used to > register several thousand AORs?? I had thought that is > mechanism is most > likely to appeal to small businesses or branch offices with a modest > number of extensions (e.g. typically a few hundred at most). > > Recommending that the mechanism work with several thousand AORs has > implications for issues such as request or response > fragmentation, SIP > message size, etc. So before putting in a requirement like > this (even if > it is only desirable), I'd like to see concrete evidence > that there are > real customers out there who both might > use it that way, and have good reasons to do so (e.g. there is a good > reason why they can't use RFC 3263 domain routing instead > with a static or > even a dynamically assigned address and dynamic DNS). > > -- > Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2> > martini <http://tools.ietf.org/martini/> > > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini -------------------------------------------------------- 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 information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright. 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(s) 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. -------------------------------------------------------- --=__Part82A8468C.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-15" http-equiv=3DContent-Typ= e> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18876"></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"> <DIV>John,</DIV> <DIV> </DIV> <DIV>I misunderstood the requirement when I made the comment desiring reten= tion.  (I was thinking several thousand endpoints among all customers,= not behind a single PBX).</DIV> <DIV> </DIV> <DIV>I am OK with its deletion.</DIV> <DIV> </DIV> <DIV>-Jack<BR><BR>>>> "Elwell, John" <john.elwell@siemens-enter= prise.com> 2/22/2010 03:59 >>><BR>Yes, there was some discussio= n on this way back, and I guess there was not clear consensus. I think Spen= cer suggested it should be removed and Jack wanted to retain it, so it stay= ed. I don't know if anyone else spoke for or against.<BR><BR>I believe ther= e should be some sort of figure given here as a desirable target, but "seve= ral thousand" might be too high. Clearly a solution that scales only to 10 = AORs, say, would not be adequate.<BR><BR>John<BR><BR><BR>> -----Original= Message-----<BR>> From: martini issue tracker [mailto:trac@tools.ietf.o= rg] <BR>> Sent: 20 February 2010 05:24<BR>> To: Elwell, John; bernard= _aboba@hotmail.com<BR>> Cc: martini@ietf.org<BR>> Subject: [martini] = #2: Scaling to Several Thousand Assigned <BR>> Telephone Numbers<BR>>= <BR>> #2: Scaling to Several Thousand Assigned Telephone Numbers<BR>>= ; ---------------------------------------+----------------------<BR>> --= ------------<BR>>  Reporter:  bernard_aboba@...  &nb= sp;         |   &nbs= p;   Owner:  <BR>> john.elwell@...    = ;            &n= bsp;    <BR>>      Type:  d= efect           &nbs= p;         |    = ;  Status:  new    <BR>>    = ;            &n= bsp;           <BR>>&n= bsp; Priority:  major        &= nbsp;           &nbs= p; |   Milestone:  <BR>> milestone1   &nbs= p;            &= nbsp;       <BR>> Component:  reqs&nb= sp;            =           |   &= nbsp; Version:  1.0    <BR>>    =             &nb= sp;           <BR>>&nb= sp; Severity:  In WG Last Call      &nbs= p;     |    Keywords:   &= nbsp;     <BR>>      &= nbsp;           &nbs= p;         <BR>> ---------------= ------------------------+----------------------<BR>> --------------<BR>&= gt;  Section 5<BR>> <BR>>     DES2 - The mec= hanism SHOULD scale to SIP-PBXs of several thousand<BR>>  &nbs= p;  assigned telephone numbers.<BR>> <BR>>  [BA] Do we real= ly think that the MARTINI mechanism will be used to<BR>>  register = several thousand AORs??  I had thought that is <BR>> mechanism is m= ost<BR>>  likely to appeal to small businesses or branch offices wi= th a modest<BR>>  number of extensions (e.g. typically a few hundre= d at most).<BR>> <BR>>  Recommending that the mechanism work wit= h several thousand AORs has<BR>>  implications for issues such as r= equest or response <BR>> fragmentation, SIP<BR>>  message size, = etc.  So before putting in a requirement like <BR>> this (even if<B= R>>  it is only desirable), I'd like to see concrete evidence <BR>&= gt; that there are<BR>>  real customers out there who both might<BR= >>  use it that way, and have good reasons to do so (e.g. there is = a good<BR>>  reason why they can't use RFC 3263 domain routing inst= ead <BR>> with a static or<BR>>  even a dynamically assigned add= ress and dynamic DNS).<BR>> <BR>> -- <BR>> Ticket URL: <<A href= =3D"http://trac.tools.ietf.org/wg/martini/trac/ticket/2">http://trac.tools.= ietf.org/wg/martini/trac/ticket/2</A>><BR>> martini <<A href=3D"ht= tp://tools.ietf.org/martini/">http://tools.ietf.org/martini/</A>><BR>>= ; <BR>> <BR>_______________________________________________<BR>martini m= ailing list<BR>martini@ietf.org<BR><A href=3D"https://www.ietf.org/mailman/= listinfo/martini">https://www.ietf.org/mailman/listinfo/martini</A><BR></DI= V></BODY></HTML> <br> -------------------------------------------------------- <br> 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 information concerning Cablevision and/or its affiliates and subsidiaries= that is proprietary, privileged, confidential and/or subject to copyright.= 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(s) is prohibited and may be unlawful. If you r= eceived 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.<br> -------------------------------------------------------- --=__Part82A8468C.0__=-- From christer.holmberg@ericsson.com Mon Feb 22 08:48:10 2010 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A78728C33B for <martini@core3.amsl.com>; Mon, 22 Feb 2010 08:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.149, 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 NIbrEyTBDbaN for <martini@core3.amsl.com>; Mon, 22 Feb 2010 08:48:09 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7B18B28C33A for <martini@ietf.org>; Mon, 22 Feb 2010 08:48:09 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-78-4b82b5bf3052 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 56.6A.31641.FB5B28B4; Mon, 22 Feb 2010 17:50:07 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.205]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 22 Feb 2010 17:50:05 +0100 From: Christer Holmberg <christer.holmberg@ericsson.com> To: "'Elwell, John'" <john.elwell@siemens-enterprise.com>, MARTINI <martini@ietf.org> Date: Mon, 22 Feb 2010 17:50:05 +0100 Thread-Topic: [martini] Possible additional requirement - identity assertions - consensus call Thread-Index: Acqzlzp4ChUXdBxuQja3DXvZf+DHAQAR44Dg Message-ID: <FF84A09F50A6DC48ACB6714F4666CC744E1A845FF3@ESESSCMS0354.eemea.ericsson.se> References: <A444A0F8084434499206E78C106220CAB93E0F40@MCHP058A.global-ad.net> In-Reply-To: <A444A0F8084434499206E78C106220CAB93E0F40@MCHP058A.global-ad.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-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] Possible additional requirement - identity assertions - consensus call X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 16:48:10 -0000 Hi, I agree that it should be possible for edge proxies to do that. However, do we really need to talk about edge proxies/middleboxes in the re= quirements? Couldn't the requirement be more generic, and just talk about sending the i= nformation that shall be sent? Then, as an example, we could mention the ed= ge proxy identity assertion use-case. Regards, Christer =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Elwell, John Sent: 22. helmikuuta 2010 10:16 To: MARTINI Subject: [martini] Possible additional requirement - identity assertions - = consensus call A short while ago, Bruno proposed the following requirement, which is not i= n reqs-01 (because I didn't feel there was any consensus). "An edge proxy shall be able to base identity assertions for outbound (non-= REGISTER) requests received from a PBX on whether the identity concerned ha= s been registered."=20 Please indicate whether you would like to see such a requirement. John (as editor) _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Mon Feb 22 08:57:51 2010 Return-Path: <spencer@wonderhamster.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776C428C325 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 08:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.010, 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 kn6V67A7-LGn for <martini@core3.amsl.com>; Mon, 22 Feb 2010 08:57:50 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 5D36828C1C9 for <martini@ietf.org>; Mon, 22 Feb 2010 08:57:50 -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 0LsTxI-1NcuXS1HFA-011toP; Mon, 22 Feb 2010 11:59:32 -0500 Message-ID: <877ACFA2914F4A5B9336B80718E233D0@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, <martini@ietf.org> References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> <A444A0F8084434499206E78C106220CAB93E0FAC@MCHP058A.global-ad.net> Date: Mon, 22 Feb 2010 10:59:17 -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: V01U2FsdGVkX18CE9lc9u3q63rxbIm0vmvyYZu92Nkq5hyCVTg AU1XEB8j3bbv0t/4qm/DeVAdX+gTVV/h2tWH9GLBoW+c0k+lMN Idurd2/+RbD7A7AjakcUqXZghDpQWfTVezffkfl5Y0= Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 16:57:51 -0000 (speaking as co-chair) > Yes, there was some discussion on this way back, and I guess there was not > clear consensus. I think Spencer suggested it should be removed and Jack > wanted to retain it, so it stayed. I don't know if anyone else spoke for > or against. > > I believe there should be some sort of figure given here as a desirable > target, but "several thousand" might be too high. Clearly a solution that > scales only to 10 AORs, say, would not be adequate. Just to explicitly state where I'm coming from... I don't care (as participant) whether we have a requirement like this. Since we have one now, and are discussing technical issues based on that requirement, I'm fairly sure that just deleting the requirement is not the right thing to do - the first time someone uses MARTINI to mass-register several thousand AoRs and it doesn't work, this will still be a technical issue. What I would like to do is to avoid the situation where we get to IETF Last Call and get review comments that ask nosy questions like, "so, I see that this request (or response, doesn't matter) can carry several thousand AoRs. Let's pretend that each AoR is 10 bytes long. What's your story for IP fragmentation? What's your story for intermediate devices that might not expect REGISTER request/responses that are that big?", and go down the rabbit hole about whether TCP fallback is realistic, etc. We've played out discussions like that on this list already, and that's before the INT and TSV guys got hold of the specifications, which would happen at IETF Last Call/IESG Evaluation time. I'm not saying that we couldn't force that through, I'm saying that we're trying to converge quickly, and ignoring known open technical issues isn't the fast path to IETF consensus. If we keep this requirement, I see a few paths forward. (a) We can ignore the likelihood that this will be noticed and discussed (and perhaps even DISCUSSed, in the IESG balloting sense). (b) We can try to figure out how we would carry several thousand 10-byte AoRs, and include that in the solutions spec (whether range encoding, byte compression, or some other clever plan). (c) We can submit a solutions draft that supports a specific number of AoRs without the enhanced encoding/compression mechanisms, and say "this will work in all reasonable deployments, even with UDP as transport". (d) We can submit a draft that says "note that MARTINI REGISTER request/responses will be bigger than ordinary REGISTER request/responses, based on the number of AoRs that you're mass-registering. If you start having problems because of the increased size, here are some things that you should do". Are there other alterntives I'm missing? I'd prefer not to do (a), because we're trying to converge quickly, and ignoring technical concerns that have already been raised is just shooting ourselves in the foot from an IETF process perspective. If Bernard and I make the decision to request publication with known technical issues, someone should appeal that decision. Even if you don't, we'll still have long discussions outside the working group that we're trying to avoid. (b) would be lovely if we can come up with a story quickly. If you agree with this alternative, please send text that takes account the Gospel according to Shockey ("number ranges fragment"). (c) isn't likely to give us "several thousand AoRs". Dean did helpful math which was more scientific than my back-of-the-envelope (see http://www.ietf.org/mail-archive/web/martini/current/msg00833.html), and came up with 70. That's more than an order of magnitude less than the requirement requires, and (unfortunately) it may be optimistic outside North America, where AoRs can be longer than 10 digits. (d) would be OK with me if we can (1) agree on some reasonable mitigations ("if TCP doesn't work on the path to your SP, you need to make it work"), and (2) include a bailout, which is probably something like "if you have tried all the successful mitigations and still can't use MARTINI, either get another SP or get a domain and start using RFC 3263". Again, if you agree with this alternative, please send text. Thanks, Spencer, as co-chair From keith.drage@alcatel-lucent.com Mon Feb 22 09:06:12 2010 Return-Path: <keith.drage@alcatel-lucent.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FE028B56A for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.612 X-Spam-Level: X-Spam-Status: No, score=-5.612 tagged_above=-999 required=5 tests=[AWL=0.637, 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 aa2gGlPIDcUs for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:06:11 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 6CF103A830B for <martini@ietf.org>; Mon, 22 Feb 2010 09:06:11 -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 o1MH7mf8026622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Feb 2010 18:08:07 +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; Mon, 22 Feb 2010 18:07:58 +0100 From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> To: "trac@localhost.amsl.com" <trac@localhost.amsl.com>, "john.elwell@siemens-enterprise.com" <john.elwell@siemens-enterprise.com>, "bernard_aboba@hotmail.com" <bernard_aboba@hotmail.com> Date: Mon, 22 Feb 2010 18:07:57 +0100 Thread-Topic: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers Thread-Index: Acqx8TL/WwuR5490TCe20uMX8NcQtwBHqIKQ Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20B05B601@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> In-Reply-To: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "martini@ietf.org" <martini@ietf.org> Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 17:06:12 -0000 V2hldGhlciB0aGUgSVAtUEJYIGlzIGF0dGFjaGVkIHRvIGEgc3Vic2NyaXB0aW9uIHR5cGUgYXBw cm9hY2ggYXMgaW4gTUFSVElOSSwgb3Igd2hldGhlciBpdCBpcyBhbGxvd2VkIHRvIHBlZXIgd2l0 aCB0aGUgb3RoZXIgbmV0d29yayBpbiBhIG1vcmUgbm9ybWFsIGZhc2hpb24gc2VlbXMgdG8gYmUg YXQgdGhlIHdoaW0gb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXIsIHJhdGhlciB0aGFuIGRlcGVuZGVu dCBvbiB0aGUgc2l6ZSBvZiB0aGUgSVBQQlguIFNvbWUgc2VydmljZSBwcm92aWRlcnMgd2lsbCBw cm92aWRlIGJvdGggbWVjaGFuaXNtcy4gU29tZSBvdGhlcnMgbWF5IGFkb3B0IG9ubHkgdGhlIE1B UlRJTkkgYXBwcm9hY2ggYmVjYXVzZSBpdCBzdWl0cyB0aGVpciBhcHByb2FjaCB0byBtYWludGFp bmluZyBjdXN0b21lciBzdWJzY3JpcHRpb25zLg0KDQpBcyBzdWNoIHRoZSBNQVJUSU5JIGFwcHJv YWNoIGhhcyB0byBjYXRlciBmb3IgYWxsIHNpemVzIG9mIFBCWCB0aGF0IGNvdWxkIHdhbnQgdG8g dXNlIGFuIFNTUC4gR2VuZXJhbGx5IHRoZSBsYXJnZXN0IFBCWHMgdGVuZCB0byBiZSBhcm91bmQg MjUwMCB0byA1MDAwIGxpbmVzICh0aGVyZSBhcmUgYmlnZ2VyIGRlcGxveW1lbnRzIG91dCB0aGVy ZSAtIGJ1dCBpbiB0aG9zZSBjYXNlcyB0aGV5IHNlZW0gdG8gYmUgZnVsZmlsbGluZyB0aGUgcm9s ZSBvZiBhbiBTU1AgaW4gdGhlaXIgb3duIHJpZ2h0Lg0KDQpyZWdhcmRzDQoNCktlaXRoIA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hcnRpbmktYm91bmNlc0BpZXRm Lm9yZyANCj4gW21haWx0bzptYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBt YXJ0aW5pIGlzc3VlIHRyYWNrZXINCj4gU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDIwLCAyMDEw IDU6MjQgQU0NCj4gVG86IGpvaG4uZWx3ZWxsQHNpZW1lbnMtZW50ZXJwcmlzZS5jb207IGJlcm5h cmRfYWJvYmFAaG90bWFpbC5jb20NCj4gQ2M6IG1hcnRpbmlAaWV0Zi5vcmcNCj4gU3ViamVjdDog W21hcnRpbmldICMyOiBTY2FsaW5nIHRvIFNldmVyYWwgVGhvdXNhbmQgQXNzaWduZWQgDQo+IFRl bGVwaG9uZSBOdW1iZXJzDQo+IA0KPiAjMjogU2NhbGluZyB0byBTZXZlcmFsIFRob3VzYW5kIEFz c2lnbmVkIFRlbGVwaG9uZSBOdW1iZXJzDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0NCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0NCj4gIFJlcG9ydGVyOiAgYmVy bmFyZF9hYm9iYUDigKYgICAgICAgICAgICB8ICAgICAgIE93bmVyOiAgDQo+IGpvaG4uZWx3ZWxs QOKApiAgICAgICAgICAgICAgICAgICAgIA0KPiAgICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3ICAgIA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCj4gIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAgICAgfCAgIE1p bGVzdG9uZTogIA0KPiBtaWxlc3RvbmUxICAgICAgICAgICAgICAgICAgICAgICAgDQo+IENvbXBv bmVudDogIHJlcXMgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFZlcnNpb246ICAxLjAgICAg DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiAgU2V2ZXJpdHk6ICBJbiBXRyBMYXN0 IENhbGwgICAgICAgICAgICB8ICAgIEtleXdvcmRzOiAgICAgICAgIA0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KPiAgU2VjdGlvbiA1DQo+IA0KPiAgICAgREVT MiAtIFRoZSBtZWNoYW5pc20gU0hPVUxEIHNjYWxlIHRvIFNJUC1QQlhzIG9mIHNldmVyYWwgdGhv dXNhbmQNCj4gICAgIGFzc2lnbmVkIHRlbGVwaG9uZSBudW1iZXJzLg0KPiANCj4gIFtCQV0gRG8g d2UgcmVhbGx5IHRoaW5rIHRoYXQgdGhlIE1BUlRJTkkgbWVjaGFuaXNtIHdpbGwgYmUgDQo+IHVz ZWQgdG8gIHJlZ2lzdGVyIHNldmVyYWwgdGhvdXNhbmQgQU9Scz8/ICBJIGhhZCB0aG91Z2h0IHRo YXQgDQo+IGlzIG1lY2hhbmlzbSBpcyBtb3N0ICBsaWtlbHkgdG8gYXBwZWFsIHRvIHNtYWxsIGJ1 c2luZXNzZXMgb3IgDQo+IGJyYW5jaCBvZmZpY2VzIHdpdGggYSBtb2Rlc3QgIG51bWJlciBvZiBl eHRlbnNpb25zIChlLmcuIA0KPiB0eXBpY2FsbHkgYSBmZXcgaHVuZHJlZCBhdCBtb3N0KS4NCj4g DQo+ICBSZWNvbW1lbmRpbmcgdGhhdCB0aGUgbWVjaGFuaXNtIHdvcmsgd2l0aCBzZXZlcmFsIHRo b3VzYW5kIA0KPiBBT1JzIGhhcyAgaW1wbGljYXRpb25zIGZvciBpc3N1ZXMgc3VjaCBhcyByZXF1 ZXN0IG9yIHJlc3BvbnNlIA0KPiBmcmFnbWVudGF0aW9uLCBTSVAgIG1lc3NhZ2Ugc2l6ZSwgZXRj LiAgU28gYmVmb3JlIHB1dHRpbmcgaW4gDQo+IGEgcmVxdWlyZW1lbnQgbGlrZSB0aGlzIChldmVu IGlmICBpdCBpcyBvbmx5IGRlc2lyYWJsZSksIEknZCANCj4gbGlrZSB0byBzZWUgY29uY3JldGUg ZXZpZGVuY2UgdGhhdCB0aGVyZSBhcmUgIHJlYWwgY3VzdG9tZXJzIA0KPiBvdXQgdGhlcmUgd2hv IGJvdGggbWlnaHQgIHVzZSBpdCB0aGF0IHdheSwgYW5kIGhhdmUgZ29vZCANCj4gcmVhc29ucyB0 byBkbyBzbyAoZS5nLiB0aGVyZSBpcyBhIGdvb2QgIHJlYXNvbiB3aHkgdGhleSBjYW4ndCANCj4g dXNlIFJGQyAzMjYzIGRvbWFpbiByb3V0aW5nIGluc3RlYWQgd2l0aCBhIHN0YXRpYyBvciAgZXZl biBhIA0KPiBkeW5hbWljYWxseSBhc3NpZ25lZCBhZGRyZXNzIGFuZCBkeW5hbWljIEROUykuDQo+ IA0KPiAtLQ0KPiBUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvbWFy dGluaS90cmFjL3RpY2tldC8yPg0KPiBtYXJ0aW5pIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvbWFy dGluaS8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBtYXJ0aW5pIG1haWxpbmcgbGlzdA0KPiBtYXJ0aW5pQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFydGluaQ0KPiA= From BLINDSAY@nortel.com Mon Feb 22 09:16:24 2010 Return-Path: <BLINDSAY@nortel.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A96A28C340 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 xvOCHVUIGT5T for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:16:22 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0EA8C28C170 for <martini@ietf.org>; Mon, 22 Feb 2010 09:16:18 -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 o1MHIAH28556; Mon, 22 Feb 2010 17:18:11 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, 22 Feb 2010 12:17:50 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C9D885E@zcarhxm1.corp.nortel.com> In-Reply-To: <877ACFA2914F4A5B9336B80718E233D0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers Thread-Index: Acqz4HbM/aBsr0u6SMiwE2aw2UHC6QAAerbw References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org><A444A0F8084434499206E78C106220CAB93E0FAC@MCHP058A.global-ad.net> <877ACFA2914F4A5B9336B80718E233D0@china.huawei.com> From: "Brian Lindsay" <blindsay@nortel.com> To: "Spencer Dawkins" <spencer@wonderhamster.org>, "Elwell, John" <john.elwell@siemens-enterprise.com>, <martini@ietf.org> Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 17:16:24 -0000 Hi Spencer, Regarding "Are there other alterntives I'm missing?", there is an option (e) in which is the MARTINI register transaction doesn't contain the associated E.164 numbers. The MARTINI mechanism has no scalability issue in that case. Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Monday, February 22, 2010 11:59 AM To: Elwell, John; martini@ietf.org Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers (speaking as co-chair) > Yes, there was some discussion on this way back, and I guess there was > not clear consensus. I think Spencer suggested it should be removed=20 > and Jack wanted to retain it, so it stayed. I don't know if anyone=20 > else spoke for or against. > > I believe there should be some sort of figure given here as a=20 > desirable target, but "several thousand" might be too high. Clearly a=20 > solution that scales only to 10 AORs, say, would not be adequate. Just to explicitly state where I'm coming from... I don't care (as participant) whether we have a requirement like this. Since we have one now, and are discussing technical issues based on that requirement, I'm fairly sure that just deleting the requirement is not the right thing to do - the first time someone uses MARTINI to mass-register several thousand AoRs and it doesn't work, this will still be a technical issue. What I would like to do is to avoid the situation where we get to IETF Last Call and get review comments that ask nosy questions like, "so, I see that this request (or response, doesn't matter) can carry several thousand AoRs.=20 Let's pretend that each AoR is 10 bytes long. What's your story for IP fragmentation? What's your story for intermediate devices that might not expect REGISTER request/responses that are that big?", and go down the rabbit hole about whether TCP fallback is realistic, etc. We've played out discussions like that on this list already, and that's before the INT and TSV guys got hold of the specifications, which would happen at IETF Last Call/IESG Evaluation time. I'm not saying that we couldn't force that through, I'm saying that we're trying to converge quickly, and ignoring known open technical issues isn't the fast path to IETF consensus. If we keep this requirement, I see a few paths forward. (a) We can ignore the likelihood that this will be noticed and discussed (and perhaps even DISCUSSed, in the IESG balloting sense). (b) We can try to figure out how we would carry several thousand 10-byte AoRs, and include that in the solutions spec (whether range encoding, byte compression, or some other clever plan). (c) We can submit a solutions draft that supports a specific number of AoRs without the enhanced encoding/compression mechanisms, and say "this will work in all reasonable deployments, even with UDP as transport". (d) We can submit a draft that says "note that MARTINI REGISTER request/responses will be bigger than ordinary REGISTER request/responses, based on the number of AoRs that you're mass-registering. If you start having problems because of the increased size, here are some things that you should do". Are there other alterntives I'm missing? I'd prefer not to do (a), because we're trying to converge quickly, and ignoring technical concerns that have already been raised is just shooting ourselves in the foot from an IETF process perspective. If Bernard and I make the decision to request publication with known technical issues, someone should appeal that decision. Even if you don't, we'll still have long discussions outside the working group that we're trying to avoid. (b) would be lovely if we can come up with a story quickly. If you agree with this alternative, please send text that takes account the Gospel according to Shockey ("number ranges fragment"). (c) isn't likely to give us "several thousand AoRs". Dean did helpful math which was more scientific than my back-of-the-envelope (see http://www.ietf.org/mail-archive/web/martini/current/msg00833.html), and came up with 70. That's more than an order of magnitude less than the requirement requires, and (unfortunately) it may be optimistic outside North America, where AoRs can be longer than 10 digits. (d) would be OK with me if we can (1) agree on some reasonable mitigations ("if TCP doesn't work on the path to your SP, you need to make it work"), and (2) include a bailout, which is probably something like "if you have tried all the successful mitigations and still can't use MARTINI, either get another SP or get a domain and start using RFC 3263". Again, if you agree with this alternative, please send text. Thanks, Spencer, as co-chair=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From keith.drage@alcatel-lucent.com Mon Feb 22 09:29:57 2010 Return-Path: <keith.drage@alcatel-lucent.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA713A7664 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.579, 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 qn50lZCV5kHc for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:29:56 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 77D153A6F50 for <martini@ietf.org>; Mon, 22 Feb 2010 09:29:56 -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.14.3/8.14.3/ICT) with ESMTP id o1MHVrL6001607 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 22 Feb 2010 18:31:53 +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; Mon, 22 Feb 2010 18:31:53 +0100 From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> To: Richard Shockey <richard@shockey.us>, "'MARTINI'" <martini@ietf.org> Date: Mon, 22 Feb 2010 18:31:47 +0100 Thread-Topic: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers Thread-Index: Acqx8TBbRtdPrnhpQcavA/7YjDk24gASkqFQAGpNIGA= Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20B05B616@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> <000001cab23c$092d3520$1b879f60$@us> In-Reply-To: <000001cab23c$092d3520$1b879f60$@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 17:29:57 -0000 That is because the market has the vast majority of PBXx in that size. 50% of the market is below 100 lines.=20 So where do you put the break point? You have not made any technical argume= nt for excluding any size of PBX, merely said that most PBXs are small. Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: Saturday, February 20, 2010 2:50 PM > To: 'MARTINI' > Subject: Re: [martini] #2: Scaling to Several Thousand=20 > Assigned Telephone Numbers >=20 > I think this requirement can safely be removed. The vast=20 > majority of installations I'm aware of that use Implicit=20 > Registration are typically sub 24 CUA's in the single site SMB market. >=20 >=20 >=20 > Section 5 >=20 > DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand > assigned telephone numbers. >=20 > [BA] Do we really think that the MARTINI mechanism will be=20 > used to register several thousand AORs?? I had thought that=20 > is mechanism is most likely to appeal to small businesses or=20 > branch offices with a modest number of extensions (e.g.=20 > typically a few hundred at most). >=20 > Recommending that the mechanism work with several thousand=20 > AORs has implications for issues such as request or response=20 > fragmentation, SIP message size, etc. So before putting in=20 > a requirement like this (even if it is only desirable), I'd=20 > like to see concrete evidence that there are real customers=20 > out there who both might use it that way, and have good=20 > reasons to do so (e.g. there is a good reason why they can't=20 > use RFC 3263 domain routing instead with a static or even a=20 > dynamically assigned address and dynamic DNS). >=20 > -- > Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2> > martini <http://tools.ietf.org/martini/> >=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 john.elwell@siemens-enterprise.com Mon Feb 22 09:33:46 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB66B28C16E for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 6z9RhjuzecMw for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:33:45 -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 387C228C187 for <martini@ietf.org>; Mon, 22 Feb 2010 09:33:09 -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-969835; Mon, 22 Feb 2010 18:35:06 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 7B6631EB82AB; Mon, 22 Feb 2010 18:35:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Feb 2010 18:35:06 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Spencer Dawkins <spencer@wonderhamster.org>, "martini@ietf.org" <martini@ietf.org> Date: Mon, 22 Feb 2010 18:35:04 +0100 Thread-Topic: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers Thread-Index: Acqz4HQJoAAQFVBrRuudCu/RJPDJTAAAfBeg Message-ID: <A444A0F8084434499206E78C106220CAB93E1502@MCHP058A.global-ad.net> References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org> <A444A0F8084434499206E78C106220CAB93E0FAC@MCHP058A.global-ad.net> <877ACFA2914F4A5B9336B80718E233D0@china.huawei.com> In-Reply-To: <877ACFA2914F4A5B9336B80718E233D0@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 Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 17:33:47 -0000 Spencer,=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 22 February 2010 16:59 > To: Elwell, John; martini@ietf.org > Subject: Re: [martini] #2: Scaling to Several Thousand=20 > Assigned Telephone Numbers >=20 > (speaking as co-chair) >=20 >=20 > > Yes, there was some discussion on this way back, and I=20 > guess there was not=20 > > clear consensus. I think Spencer suggested it should be=20 > removed and Jack=20 > > wanted to retain it, so it stayed. I don't know if anyone=20 > else spoke for=20 > > or against. > > > > I believe there should be some sort of figure given here as=20 > a desirable=20 > > target, but "several thousand" might be too high. Clearly a=20 > solution that=20 > > scales only to 10 AORs, say, would not be adequate. >=20 > Just to explicitly state where I'm coming from... >=20 > I don't care (as participant) whether we have a requirement=20 > like this. Since=20 > we have one now, and are discussing technical issues based on that=20 > requirement, I'm fairly sure that just deleting the=20 > requirement is not the=20 > right thing to do - the first time someone uses MARTINI to=20 > mass-register=20 > several thousand AoRs and it doesn't work, this will still be=20 > a technical=20 > issue. >=20 > What I would like to do is to avoid the situation where we=20 > get to IETF Last=20 > Call and get review comments that ask nosy questions like,=20 > "so, I see that=20 > this request (or response, doesn't matter) can carry several=20 > thousand AoRs.=20 > Let's pretend that each AoR is 10 bytes long. What's your=20 > story for IP=20 > fragmentation? What's your story for intermediate devices=20 > that might not=20 > expect REGISTER request/responses that are that big?", and go=20 > down the=20 > rabbit hole about whether TCP fallback is realistic, etc. [JRE] Whilst the chances of picking on this at IETF last call might be redu= ced if we don't explicitly mention a requirement, I don't think we can igno= re that possibility. The idea is to try to cover everything before we get t= o that stage, to minimise the risk at IETF last call. >=20 > We've played out discussions like that on this list already,=20 > and that's=20 > before the INT and TSV guys got hold of the specifications,=20 > which would=20 > happen at IETF Last Call/IESG Evaluation time. I'm not saying that we=20 > couldn't force that through, I'm saying that we're trying to converge=20 > quickly, and ignoring known open technical issues isn't the=20 > fast path to=20 > IETF consensus. >=20 > If we keep this requirement, I see a few paths forward. >=20 > (a) We can ignore the likelihood that this will be noticed=20 > and discussed=20 > (and perhaps even DISCUSSed, in the IESG balloting sense). >=20 > (b) We can try to figure out how we would carry several=20 > thousand 10-byte=20 > AoRs, and include that in the solutions spec (whether range=20 > encoding, byte=20 > compression, or some other clever plan). >=20 > (c) We can submit a solutions draft that supports a specific=20 > number of AoRs=20 > without the enhanced encoding/compression mechanisms, and say=20 > "this will=20 > work in all reasonable deployments, even with UDP as transport". >=20 > (d) We can submit a draft that says "note that MARTINI REGISTER=20 > request/responses will be bigger than ordinary REGISTER=20 > request/responses,=20 > based on the number of AoRs that you're mass-registering. If=20 > you start=20 > having problems because of the increased size, here are some=20 > things that you=20 > should do". >=20 > Are there other alterntives I'm missing? [JRE] The one path you don't mention is having a solution that does not inv= olve conveying the list of AORs in a SIP message, and this comes down to th= e discussion whether there is a need for an intermediary to know the list o= f currently registered AORs. >=20 > I'd prefer not to do (a), because we're trying to converge=20 > quickly, and=20 > ignoring technical concerns that have already been raised is=20 > just shooting=20 > ourselves in the foot from an IETF process perspective. If=20 > Bernard and I=20 > make the decision to request publication with known technical issues,=20 > someone should appeal that decision. Even if you don't, we'll=20 > still have=20 > long discussions outside the working group that we're trying to avoid. [JRE] I agree, but just omitting to state a requirement on number of AORs d= oes not necessarily prevent a DISCUSS. >=20 > (b) would be lovely if we can come up with a story quickly.=20 > If you agree=20 > with this alternative, please send text that takes account the Gospel=20 > according to Shockey ("number ranges fragment"). [JRE] I guess one possibility is draft-roach-http-subscribe, where anyone w= ishing to find out the list of AORs currently registered can use HTTP(S) an= d can receive a NOTIFY request if the list changes (telling you to go do an= other GET). I am not suggesting MARTINI should specify this, but it would b= e our answer. >=20 > (c) isn't likely to give us "several thousand AoRs". Dean did=20 > helpful math=20 > which was more scientific than my back-of-the-envelope (see=20 > http://www.ietf.org/mail-archive/web/martini/current/msg00833. > html), and=20 > came up with 70. That's more than an order of magnitude less than the=20 > requirement requires, and (unfortunately) it may be=20 > optimistic outside North=20 > America, where AoRs can be longer than 10 digits. [JRE] I don't think that we can have a solution that limits you to 70 (or l= ess outside NA) AORs. This is true whether or not we have an explicit requi= rement for a higher number. >=20 > (d) would be OK with me if we can (1) agree on some=20 > reasonable mitigations=20 > ("if TCP doesn't work on the path to your SP, you need to=20 > make it work"),=20 > and (2) include a bailout, which is probably something like=20 > "if you have=20 > tried all the successful mitigations and still can't use=20 > MARTINI, either get=20 > another SP or get a domain and start using RFC 3263". Again,=20 > if you agree=20 > with this alternative, please send text. [JRE] Or use non-MARTINI means to obtain the list of AORs as a possible mit= igation (e.g., HTTP(S) + draft-roach-http-subscribe). John (as individual) From john.elwell@siemens-enterprise.com Mon Feb 22 09:34:10 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7183A8325 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 OiJr2BkUrVCe for <martini@core3.amsl.com>; Mon, 22 Feb 2010 09:34:08 -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 AF0DB3A8103 for <martini@ietf.org>; Mon, 22 Feb 2010 09:34:02 -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-970096; Mon, 22 Feb 2010 18:36:01 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7C9BA23F028E; Mon, 22 Feb 2010 18:36:01 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Feb 2010 18:36:01 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Brian Lindsay <blindsay@nortel.com>, Spencer Dawkins <spencer@wonderhamster.org>, "martini@ietf.org" <martini@ietf.org> Date: Mon, 22 Feb 2010 18:36:00 +0100 Thread-Topic: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers Thread-Index: Acqz4HbM/aBsr0u6SMiwE2aw2UHC6QAAerbwAADDRwA= Message-ID: <A444A0F8084434499206E78C106220CAB93E1505@MCHP058A.global-ad.net> References: <067.e23bbafa45eb4b09f274936404f0f091@tools.ietf.org><A444A0F8084434499206E78C106220CAB93E0FAC@MCHP058A.global-ad.net> <877ACFA2914F4A5B9336B80718E233D0@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C9D885E@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C9D885E@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] #2: Scaling to Several Thousand Assigned TelephoneNumbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 17:34:10 -0000 Thanks, you beat me to it. John =20 > -----Original Message----- > From: Brian Lindsay [mailto:blindsay@nortel.com]=20 > Sent: 22 February 2010 17:18 > To: Spencer Dawkins; Elwell, John; martini@ietf.org > Subject: RE: [martini] #2: Scaling to Several Thousand=20 > Assigned TelephoneNumbers >=20 > Hi Spencer, >=20 > Regarding "Are there other alterntives I'm missing?", there is an > option (e) in which is the MARTINI register transaction=20 > doesn't contain > the associated E.164 numbers. The MARTINI mechanism has no scalability > issue in that case. >=20 > Thanks > Brian >=20 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Spencer Dawkins > Sent: Monday, February 22, 2010 11:59 AM > To: Elwell, John; martini@ietf.org > Subject: Re: [martini] #2: Scaling to Several Thousand Assigned > TelephoneNumbers >=20 > (speaking as co-chair) >=20 >=20 > > Yes, there was some discussion on this way back, and I=20 > guess there was >=20 > > not clear consensus. I think Spencer suggested it should be removed=20 > > and Jack wanted to retain it, so it stayed. I don't know if anyone=20 > > else spoke for or against. > > > > I believe there should be some sort of figure given here as a=20 > > desirable target, but "several thousand" might be too high.=20 > Clearly a=20 > > solution that scales only to 10 AORs, say, would not be adequate. >=20 > Just to explicitly state where I'm coming from... >=20 > I don't care (as participant) whether we have a requirement like this. > Since we have one now, and are discussing technical issues=20 > based on that > requirement, I'm fairly sure that just deleting the requirement is not > the right thing to do - the first time someone uses MARTINI to > mass-register several thousand AoRs and it doesn't work, this=20 > will still > be a technical issue. >=20 > What I would like to do is to avoid the situation where we get to IETF > Last Call and get review comments that ask nosy questions like, "so, I > see that this request (or response, doesn't matter) can carry several > thousand AoRs.=20 > Let's pretend that each AoR is 10 bytes long. What's your story for IP > fragmentation? What's your story for intermediate devices=20 > that might not > expect REGISTER request/responses that are that big?", and go down the > rabbit hole about whether TCP fallback is realistic, etc. >=20 > We've played out discussions like that on this list already,=20 > and that's > before the INT and TSV guys got hold of the specifications,=20 > which would > happen at IETF Last Call/IESG Evaluation time. I'm not saying that we > couldn't force that through, I'm saying that we're trying to converge > quickly, and ignoring known open technical issues isn't the=20 > fast path to > IETF consensus. >=20 > If we keep this requirement, I see a few paths forward. >=20 > (a) We can ignore the likelihood that this will be noticed=20 > and discussed > (and perhaps even DISCUSSed, in the IESG balloting sense). >=20 > (b) We can try to figure out how we would carry several=20 > thousand 10-byte > AoRs, and include that in the solutions spec (whether range encoding, > byte compression, or some other clever plan). >=20 > (c) We can submit a solutions draft that supports a specific number of > AoRs without the enhanced encoding/compression mechanisms,=20 > and say "this > will work in all reasonable deployments, even with UDP as transport". >=20 > (d) We can submit a draft that says "note that MARTINI REGISTER > request/responses will be bigger than ordinary REGISTER > request/responses, based on the number of AoRs that you're > mass-registering. If you start having problems because of the=20 > increased > size, here are some things that you should do". >=20 > Are there other alterntives I'm missing? >=20 > I'd prefer not to do (a), because we're trying to converge=20 > quickly, and > ignoring technical concerns that have already been raised is just > shooting ourselves in the foot from an IETF process perspective. If > Bernard and I make the decision to request publication with known > technical issues, someone should appeal that decision. Even if you > don't, we'll still have long discussions outside the working=20 > group that > we're trying to avoid. >=20 > (b) would be lovely if we can come up with a story quickly.=20 > If you agree > with this alternative, please send text that takes account the Gospel > according to Shockey ("number ranges fragment"). >=20 > (c) isn't likely to give us "several thousand AoRs". Dean did helpful > math which was more scientific than my back-of-the-envelope (see > http://www.ietf.org/mail-archive/web/martini/current/msg00833. > html), and > came up with 70. That's more than an order of magnitude less than the > requirement requires, and (unfortunately) it may be optimistic outside > North America, where AoRs can be longer than 10 digits. >=20 > (d) would be OK with me if we can (1) agree on some reasonable > mitigations ("if TCP doesn't work on the path to your SP, you need to > make it work"), and (2) include a bailout, which is probably something > like "if you have tried all the successful mitigations and still can't > use MARTINI, either get another SP or get a domain and start using RFC > 3263". Again, if you agree with this alternative, please send text. >=20 > Thanks, >=20 > Spencer, as co-chair=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From dean.willis@softarmor.com Mon Feb 22 11:57:56 2010 Return-Path: <dean.willis@softarmor.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8E93A81F6 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 11:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 1Tp9YlAm2rZ3 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 11:57:56 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EAAA33A7D20 for <martini@ietf.org>; Mon, 22 Feb 2010 11:57:52 -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 o1MJxXEU003034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 22 Feb 2010 13:59:46 -0600 Message-Id: <E90A17CF-0A83-4276-80BF-816AEBA86647@softarmor.com> From: Dean Willis <dean.willis@softarmor.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com> In-Reply-To: <A444A0F8084434499206E78C106220CAB93E0FFC@MCHP058A.global-ad.net> 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, 22 Feb 2010 13:59:45 -0600 References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B7858E0.90602@cisco.com> <BLU137-DS63E176E102BA391145310934A0@phx.gbl> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <E978C357371446AD9B8F123582D1C28C@china.huawei.com> <A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> <BLU137-DS78E5C8A1CC7F9A0EAA04F93470@phx.gbl> <D743D3DA3D88485E834338B60E4CB2F7@china.huawei.com> <4B7DCEB7.9010501@nostrum.com> <BLU137-DS5C0DF93FD0B84C7E0FA3A93470@phx.g! bl> <4B7E2D47.9060501@softarmor.com> <A444A0F8084434499206E78C106220CAB93E0833@MCHP058A.global-ad.net> <4B7F8C58.406@softarmor.com> <A444A0F8084434499206E78C106220CA! B93E0FFC@MCHP058A.global-ad.net> X-Mailer: Apple Mail (2.936) Cc: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 19:57:56 -0000 On Feb 22, 2010, at 3:26 AM, Elwell, John wrote: > Dean, > > I don't agree with a requirement for supporting the admission of > outbound requests based on whether the caller has registered. This > would prevent, for example, a call from A to B being forwarded to C > via the SSP, where A is not one of the registered AORs at this > particular PBX (unless you do horrible things that I don't think we > want to condone, like pretending the caller is B, who is registered). Well, considering the call needs to be paid for by B, given that A has no billing relationship with the SSP, that's not completely off the wall. > > If you want to pursue the question of being able to support > admitting both inbound requests and outbound requests on the basis > of the current registration state of the AOR, I think we should > consider these as separate issues. Do you want to raise issues on > the tracker for one or both of these? Well heck, I don't agree with the requirement either. I think it's a royally stupid idea in either direction. However, people have been claiming that it's necessary in one direction or the other for their deployments. I was just translating the rather vaguely worded requirements I was hearing so that we'd all know what the argument was about. Will the middlebox vendors and their victims please step forward and tell us whether they really need to be able to do this? -- Dean From BLINDSAY@nortel.com Mon Feb 22 12:04:22 2010 Return-Path: <BLINDSAY@nortel.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166173A7C42 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 12:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 iWiyuOLUD33T for <martini@core3.amsl.com>; Mon, 22 Feb 2010 12:04:21 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E6F833A81F6 for <martini@ietf.org>; Mon, 22 Feb 2010 12:04:20 -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 o1MK6Et13344; Mon, 22 Feb 2010 20:06:15 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, 22 Feb 2010 15:06:02 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C9D8C61@zcarhxm1.corp.nortel.com> In-Reply-To: <E90A17CF-0A83-4276-80BF-816AEBA86647@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Middlebox needs - admitting inbound requests Thread-Index: Acqz+aNdbZq3IbVvRq+7auvVuZGw0wAAElow References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B7858E0.90602@cisco.com><BLU137-DS63E176E102BA391145310934A0@phx.gbl><7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com><7026622AD49444D2AFAD40F584A08028@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com><E978C357371446AD9B8F123582D1C28C@china.huawei.com><A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net><4B7C1923.2020506@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com><BLU137-DS78E5C8A1CC7F9A0EAA04F93470@phx.gbl><D743D3DA3D88485E834338B60E4CB2F7@china.huawei.com><4B7DCEB7.9010501@nostrum.com> <BLU137-DS5C0DF93FD0B84C7E0FA3A93470@phx.g!bl> <4B7E2D47.9060501@softarmor.com><A444A0F8084434499206E78C106220CAB93E0833@MCHP058A.global-ad.net><4B7F8C58.406@softarmor.com> <A444A0F8084434499206E78C106220CA!B93E0FFC@MCHP0! 58A.globa l-ad.net> <E90A17CF-0A83-4276-80BF-816AEBA86647@softarmor.com> From: "Brian Lindsay" <blindsay@nortel.com> To: "Dean Willis" <dean.willis@softarmor.com>, "Elwell, John" <john.elwell@siemens-enterprise.com> Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 20:04:22 -0000 Hi, I thought this email was pretty clear, from an operators perspective, on the topic: http://www.ietf.org/mail-archive/web/martini/current/msg00814.html=20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, February 22, 2010 3:00 PM To: Elwell, John Cc: Bernard Aboba; 'MARTINI' Subject: Re: [martini] Middlebox needs - admitting inbound requests On Feb 22, 2010, at 3:26 AM, Elwell, John wrote: > Dean, > > I don't agree with a requirement for supporting the admission of=20 > outbound requests based on whether the caller has registered. This=20 > would prevent, for example, a call from A to B being forwarded to C=20 > via the SSP, where A is not one of the registered AORs at this=20 > particular PBX (unless you do horrible things that I don't think we=20 > want to condone, like pretending the caller is B, who is registered). Well, considering the call needs to be paid for by B, given that A has no billing relationship with the SSP, that's not completely off the wall. > > If you want to pursue the question of being able to support admitting=20 > both inbound requests and outbound requests on the basis of the=20 > current registration state of the AOR, I think we should consider=20 > these as separate issues. Do you want to raise issues on the tracker=20 > for one or both of these? Well heck, I don't agree with the requirement either. I think it's a royally stupid idea in either direction. However, people have been claiming that it's necessary in one direction or the other for their deployments. I was just translating the rather vaguely worded requirements I was hearing so that we'd all know what the argument was about. Will the middlebox vendors and their victims please step forward and tell us whether they really need to be able to do this? -- Dean _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Mon Feb 22 12:11:33 2010 Return-Path: <spencer@wonderhamster.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB50F28C164 for <martini@core3.amsl.com>; Mon, 22 Feb 2010 12:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.009, 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 dNNzIT6zGQge for <martini@core3.amsl.com>; Mon, 22 Feb 2010 12:11:31 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 56FE828C154 for <martini@ietf.org>; Mon, 22 Feb 2010 12:11:31 -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 0M6zfx-1NXdVR3FNV-00x8Mq; Mon, 22 Feb 2010 15:13:16 -0500 Message-ID: <0DBBDD0E8162414EB8CEE821C93B5CA2@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "Brian Lindsay" <blindsay@nortel.com>, "Dean Willis" <dean.willis@softarmor.com>, "Elwell, John" <john.elwell@siemens-enterprise.com> References: 58A.global-ad.net> <E90A17CF-0A83-4276-80BF-816AEBA86647@softarmor.com> <09B7DBFE70A9E24BBB21689DAD3A06141C9D8C61@zcarhxm1.corp.nortel.com> Date: Mon, 22 Feb 2010 14:12:56 -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+qS7j7KWOGtb25iUoAAnT2BNQOBdsTAIj93Qr GNEL0ea+pxVr/HkayNjjkGh5rnMS9G7xZ4ROZg/JxrYI/HIUlx SmjeyQHjiyGGK6OncSvtRc6/PpVxq+7wRLD0aNJJsM= Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 20:11:33 -0000 Posting as co-chair, Groovy. So, my next question is, how much, if anything, would we need to say about this in a MARTINI specification? I'm not saying that we would require that all SPs have this as their policy, I'm asking whether we need to say anything about the practice. Thanks, Spencer ----- Original Message ----- From: "Brian Lindsay" <blindsay@nortel.com> To: "Dean Willis" <dean.willis@softarmor.com>; "Elwell, John" <john.elwell@siemens-enterprise.com> Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "MARTINI" <martini@ietf.org> Sent: Monday, February 22, 2010 2:06 PM Subject: Re: [martini] Middlebox needs - admitting inbound requests > Hi, > > I thought this email was pretty clear, from an operators perspective, > on the topic: > > http://www.ietf.org/mail-archive/web/martini/current/msg00814.html > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Monday, February 22, 2010 3:00 PM > To: Elwell, John > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] Middlebox needs - admitting inbound requests > > > On Feb 22, 2010, at 3:26 AM, Elwell, John wrote: > >> Dean, >> >> I don't agree with a requirement for supporting the admission of >> outbound requests based on whether the caller has registered. This >> would prevent, for example, a call from A to B being forwarded to C >> via the SSP, where A is not one of the registered AORs at this >> particular PBX (unless you do horrible things that I don't think we >> want to condone, like pretending the caller is B, who is registered). > > Well, considering the call needs to be paid for by B, given that A has > no billing relationship with the SSP, that's not completely off the > wall. > >> >> If you want to pursue the question of being able to support admitting >> both inbound requests and outbound requests on the basis of the >> current registration state of the AOR, I think we should consider >> these as separate issues. Do you want to raise issues on the tracker >> for one or both of these? > > > Well heck, I don't agree with the requirement either. I think it's a > royally stupid idea in either direction. However, people have been > claiming that it's necessary in one direction or the other for their > deployments. I was just translating the rather vaguely worded > requirements I was hearing so that we'd all know what the argument was > about. > > Will the middlebox vendors and their victims please step forward and > tell us whether they really need to be able to do this? > > -- > 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 john.elwell@siemens-enterprise.com Mon Feb 22 13:07:59 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804E128C1FA for <martini@core3.amsl.com>; Mon, 22 Feb 2010 13:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 Q+lDsqtHKugx for <martini@core3.amsl.com>; Mon, 22 Feb 2010 13:07: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 51AC028C3A8 for <martini@ietf.org>; Mon, 22 Feb 2010 13:07:57 -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-972330; Mon, 22 Feb 2010 22:09:57 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 3D68C23F0278; Mon, 22 Feb 2010 22:09:57 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 22 Feb 2010 22:09:57 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Dean Willis <dean.willis@softarmor.com> Date: Mon, 22 Feb 2010 22:09:55 +0100 Thread-Topic: Middlebox needs - admitting inbound requests Thread-Index: Acqz+ZzMe+KiL48sRPCiv6YDs3wx2wACQTAw Message-ID: <A444A0F8084434499206E78C106220CAB93E163E@MCHP058A.global-ad.net> References: <1E8E2700-18FA-4DC1-8147-18EC9423C266@softarmor.com><4B7858E0.90602@cisco.com> <BLU137-DS63E176E102BA391145310934A0@phx.gbl> <7B10FC5A-270D-4A97-A40E-1F4AEF49FAE5@softarmor.com><4B79EFB9.8000209@cisco.com><4B7AE641.70904@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C876A41@zcarhxm1.corp.nortel.com> <7026622AD49444D2AFAD40F584A08028@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C8F06DB@zcarhxm1.corp.nortel.com> <E978C357371446AD9B8F123582D1C28C@china.huawei.com> <A444A0F8084434499206E78C106220CAB939D5F7@MCHP058A.global-ad.net> <4B7C1923.2020506@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C94955B@zcarhxm1.corp.nortel.com> <BLU137-DS78E5C8A1CC7F9A0EAA04F93470@phx.gbl> <D743D3DA3D88485E834338B60E4CB2F7@china.huawei.com> <4B7DCEB7.9010501@nostrum.com> <BLU137-DS5C0DF93FD0B84C7E0FA3A93470@phx.g! bl> <4B7E2D47.9060501@softarmor.com> <A444A0F8084434499206E78C106220CAB93E0833@MCHP058A.global-ad.net> <4B7F8C58.406@softarmor.com> <A444A0F8084434499206E78C106220CA! B93E0FFC@MCHP058A.global-ad.net> <E90A17CF-0A83-4276-80BF-816AEBA86647@softarmor.com> In-Reply-To: <E90A17CF-0A83-4276-80BF-816AEBA86647@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: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 22 Feb 2010 21:07:59 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 22 February 2010 20:00 > To: Elwell, John > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: Middlebox needs - admitting inbound requests >=20 >=20 > On Feb 22, 2010, at 3:26 AM, Elwell, John wrote: >=20 > > Dean, > > > > I don't agree with a requirement for supporting the admission of =20 > > outbound requests based on whether the caller has registered. This =20 > > would prevent, for example, a call from A to B being=20 > forwarded to C =20 > > via the SSP, where A is not one of the registered AORs at this =20 > > particular PBX (unless you do horrible things that I don't=20 > think we =20 > > want to condone, like pretending the caller is B, who is=20 > registered). >=20 > Well, considering the call needs to be paid for by B, given=20 > that A has =20 > no billing relationship with the SSP, that's not completely off the =20 > wall. [JRE] The SSP can only bill somebody on the basis of what has been authenti= cated. Neither From (without SIP Identity) nor PAI has any means of authent= ication. The SSP instead has to bill the PBX on the basis of whatever authe= ntication it provides. John >=20 > > > > If you want to pursue the question of being able to support =20 > > admitting both inbound requests and outbound requests on the basis =20 > > of the current registration state of the AOR, I think we should =20 > > consider these as separate issues. Do you want to raise issues on =20 > > the tracker for one or both of these? >=20 >=20 > Well heck, I don't agree with the requirement either. I think it's a =20 > royally stupid idea in either direction. However, people have been =20 > claiming that it's necessary in one direction or the other for their =20 > deployments. I was just translating the rather vaguely worded =20 > requirements I was hearing so that we'd all know what the=20 > argument was =20 > about. >=20 > Will the middlebox vendors and their victims please step forward and =20 > tell us whether they really need to be able to do this? >=20 > -- > Dean >=20 > = From richard@shockey.us Tue Feb 23 09:36:32 2010 Return-Path: <richard@shockey.us> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121B628C155 for <martini@core3.amsl.com>; Tue, 23 Feb 2010 09:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 qf6csGUBkW2Y for <martini@core3.amsl.com>; Tue, 23 Feb 2010 09:36:31 -0800 (PST) Received: from outbound-mail-354.bluehost.com (outbound-mail-354.bluehost.com [66.147.249.15]) by core3.amsl.com (Postfix) with SMTP id 0F59028C14F for <martini@ietf.org>; Tue, 23 Feb 2010 09:36:31 -0800 (PST) Received: (qmail 11917 invoked by uid 0); 23 Feb 2010 17:38:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 23 Feb 2010 17:38:34 -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=KaPpO6Apuqg0QxvytJ/BauiISLmnWTY7U31otJQEu57gyFQUADxCkCvUlS+cHxYifTVK4EeJ593iTl9+kf6cNaeL98rqH1OeaPpB8IH9mnIPTaQNGIIizOE8fOQRUdtj; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1NjyiQ-0005ky-4t for martini@ietf.org; Tue, 23 Feb 2010 10:38:34 -0700 Message-ID: <4B841298.2010308@shockey.us> Date: Tue, 23 Feb 2010 12:38:32 -0500 From: Richard Shockey <richard@shockey.us> 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: <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> <A7B13555BEF54DDFB185662CB530CA54@china.huawei.com> <4B630672.5040208@nostrum.com> In-Reply-To: <4B630672.5040208@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.62.33 authed with richard+shockey.us} 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 <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 23 Feb 2010 17:36:32 -0000 The short answer IMHO is no it does not include private numbering plans _ at this time_ but that is because of some specific market conditions that SIP trunking addresses. The marked preference of consumers and small businesses is to issue DID numbers to all extensions from the PBX and implicit registration permits incremental issuance of those numbers as needed and not in blocks as is customary in classic PRI installations. That is a HUGE cost savings to SMBs' and a principal market driver for SIP trunking in the marketplace. That is different in Europe where "local numbers" are much more extensive it of course depends on which EC country you are talking about. I suspect that DID are more popular where formal database LNP systems are in place such as Sweden or the Netherlands. The largest single inhibitor to SIP trunking is the lack of true LNP in many countries since businesses are highly reluctant to change their E.164 numbers just to get lower costs. Plus the current dominat practice of number porting by simply call forwarding from the donor (incumbent) switch kills many of the features that the recipient SSP can offer. That is now changing with new EC rules that are coming into effect in the next few years. I completely appreciate Keiths' concerns here but I worry the further we expand the scope of the task at hand the further we are from the kind of incremental solution that is needed. On 1/29/2010 11:01 AM, Adam Roach wrote: > 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 > _______________________________________________ > 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 bernard_aboba@hotmail.com Tue Feb 23 18:54:25 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9E43A82B5 for <martini@core3.amsl.com>; Tue, 23 Feb 2010 18:54:25 -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.585, 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 1Fjv6PvomH7f for <martini@core3.amsl.com>; Tue, 23 Feb 2010 18:54:24 -0800 (PST) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id 354CB3A829F for <martini@ietf.org>; Tue, 23 Feb 2010 18:54:24 -0800 (PST) Received: from BLU137-DS13 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 18:56:29 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: <BLU137-DS13DBFC0C138CBE6AAB547293410@phx.gbl> From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: "'MARTINI'" <martini@ietf.org> Date: Tue, 23 Feb 2010 18:56:28 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0484_01CAB4B9.E85144B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq0/PYzyj8oRBeSRKa4JTi/s71z+A== Content-Language: en-us X-OriginalArrivalTime: 24 Feb 2010 02:56:29.0103 (UTC) FILETIME=[F65563F0:01CAB4FC] Subject: [martini] Internet Drafts Cut-Off Date Reminder (fwd) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 24 Feb 2010 02:54:25 -0000 ------=_NextPart_000_0484_01CAB4B9.E85144B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit From: IETF Secretariat <ietf-secretariat <mailto:ietf-secretariat%20at%20ietf.org> at ietf.org> Date: February 22, 2010 9:00:01 PM CEST To: ietf-announce at ietf.org <mailto:ietf-announce%20at%20ietf.org> Subject: Internet Draft Cut-off Dates Reminder This is a reminder that the Internet Draft Cut-off Dates are approaching. The initial draft (version -00) cut-off date is Monday, March 1, 2010. These submissions are due by 17:00 PST (01:00 Tuesday, March 2 UTC). The Internet Draft final submission (version -01 and up) cut-off is Monday, March 8, 2010 at 17:00 PST (01:00 Tuesday, March 2 UTC). All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/idst/upload.cgi _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------=_NextPart_000_0484_01CAB4B9.E85144B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:a=3D"urn:schemas-microsoft-com:office:access" = xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" = xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" = xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" = xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" = xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" = xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" = xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" = xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" = xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" = xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" = xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" = xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" = xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" = xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" = xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" = xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" = xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" = xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" = xmlns:udc=3D"http://schemas.microsoft.com/data/udc" = xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" = xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"= xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" = xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" = xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" = xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" = xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" = xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" = xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" = xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" = xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" = xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig= nature" = xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006= " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi= ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" = xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"= = xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag= es" = xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/= " = xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub= lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" = xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.apple-converted-space {mso-style-name:apple-converted-space;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><br> <br> <o:p></o:p></p> <p class=3DMsoNormal><b><span = style=3D'font-size:10.5pt;font-family:"Helvetica","sans-serif"; color:black'>From: </span></b><span = style=3D'font-size:10.5pt;font-family:"Helvetica","sans-serif"'>IETF Secretariat <<a = href=3D"mailto:ietf-secretariat%20at%20ietf.org">ietf-secretariat at ietf.org</a>></span><o:p></o:p></p> <p class=3DMsoNormal><b><span = style=3D'font-size:10.5pt;font-family:"Helvetica","sans-serif"; color:black'>Date: </span></b><span = style=3D'font-size:10.5pt;font-family:"Helvetica","sans-serif"'>February 22, 2010 9:00:01 PM CEST</span><o:p></o:p></p> <p class=3DMsoNormal><b><span = style=3D'font-size:10.5pt;font-family:"Helvetica","sans-serif"; color:black'>To: </span></b><span = style=3D'font-size:10.5pt;font-family:"Helvetica","sans-serif"'><a href=3D"mailto:ietf-announce%20at%20ietf.org">ietf-announce at = ietf.org</a></span><o:p></o:p></p> <p class=3DMsoNormal><b><span = style=3D'font-size:10.5pt;font-family:"Helvetica","sans-serif"; color:black'>Subject: </span></b><b><span = style=3D'font-size:10.5pt;font-family: "Helvetica","sans-serif"'>Internet Draft Cut-off Dates Reminder<span class=3Dapple-converted-space> </span></span></b><o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><br> This is a reminder that the Internet Draft Cut-off Dates are = approaching.<br> <br> <br> The initial draft (version -00) cut-off date is Monday, March 1, 2010. = <br> These submissions are due by 17:00 PST (01:00 Tuesday, March 2 UTC).<br> <br> The Internet Draft final submission (version -01 and up) cut-off is<br> Monday, March 8, 2010 at 17:00 PST (01:00 Tuesday, March 2 UTC).<br> <br> All drafts can be uploaded using the ID submission tool located = here:<br> <a = href=3D"https://datatracker.ietf.org/idst/upload.cgi">https://datatracker= .ietf.org/idst/upload.cgi</a><br> _______________________________________________<br> IETF-Announce mailing list<br> IETF-Announce at ietf.org<br> https://www.ietf.org/mailman/listinfo/ietf-announce<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> </div> </body> </html> ------=_NextPart_000_0484_01CAB4B9.E85144B0-- From tyler@foxfam.com Thu Feb 25 12:59:07 2010 Return-Path: <tyler@foxfam.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C4E3A8583 for <martini@core3.amsl.com>; Thu, 25 Feb 2010 12:59:07 -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 lkfQgXGH1pq7 for <martini@core3.amsl.com>; Thu, 25 Feb 2010 12:59:06 -0800 (PST) Received: from smtp04.atlngahp.sys.nuvox.net (smtp-out4.atlngahp.sys.nuvox.net [70.43.63.22]) by core3.amsl.com (Postfix) with ESMTP id 488AE3A8497 for <martini@ietf.org>; Thu, 25 Feb 2010 12:59:02 -0800 (PST) Received: from LT6KW7CD1 (fw.newsouth.com [209.177.200.190]) by smtp04.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o1PL17LM018674; Thu, 25 Feb 2010 16:01:07 -0500 Message-ID: <007f01cab65d$a7239060$430510ac@CORPORATE.VOX.NET> From: "Tyler Parkin" <tyler@foxfam.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "Dean Willis" <dean.willis@softarmor.com> References: <4B7E2D47.9060501@softarmor.com><A444A0F8084434499206E78C106220CAB93E0833@MCHP058A.global-ad.net><4B7F8C58.406@softarmor.com> <A444A0F8084434499206E78C106220CA!B93E0FFC@MCHP058A.global-ad.net><E90A17CF-0A83-4276-80BF-816AEBA86647@softarmor.com> <A444A0F8084434499206E78C106220CAB93E163E@MCHP058A.global-ad.net> Date: Thu, 25 Feb 2010 16:01:07 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 20:59:08 -0000 I'll throw my $.02 in just for fun. I'm not sure I'm clear on what you mean, John, but it sounds like you're saying you think most people who cut CDR's do it based on the authentication credentials. You're right and wrong. As an SSP we can only bill based on what's authenticated (to verify that's the person actually making the call). However, most softswitch vendors use From/PAI to find the correct account and generate billing records, not the authentication credentials. As such, we can (and do) bill off of from and PAI when the situation dictates, like the example below. There are various implimentations to ensure that the credentials provided match From/PAI, which conceivably would have already registered. If you base it only on credentials then it means any deployments where the registrar isn't also the device that cuts billing records couldn't bill their customers. As far as the middle box ~ there are reasons to deploy them that actually do support "running your voip system 'the right way'," which is why they're so prevalent. One of the obvious ones is to mask core network components from untrusted sources. Today, our UA's (internal and external) send a register request and the SBC caches the URI and IP address (presumably the same most of the time), manipulates the headers, and forwards the requests to the registrar using the internal/trusted IP address of the SBC. When a request comes into the registrar destined for a UA, the registrar sends the request to the SBC using the internal IP (because that's what it received the request from), and the SBC maps it from the internal IP to the original/external IP and sends it to the UA. Again, the registrar doesn't see different originating IP addresses, it only sees the single internal address of the SBC. My concern here is that the UA is expected to register using an AOR that apparently won't be used in subsequent messaging for associated/child addresses. When a call comes into the registrar for a child address, it's going to send it to the SBC for delivery and the SBC won't have the child address mapping required to send it to the UA. This is issue has come up with other implimentations for bulk reg, and each vendor has their own solution outside RFC spec. One of those was to put the AOR in the request URI and the child address in the To field, and have the SBC substitute when it sends it to the UA. Regards, Tyler Parkin tyler@foxfam.com ----- Original Message ----- From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "Dean Willis" <dean.willis@softarmor.com> Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "'MARTINI'" <martini@ietf.org> Sent: Monday, February 22, 2010 4:09 PM Subject: Re: [martini] Middlebox needs - admitting inbound requests > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: 22 February 2010 20:00 >> To: Elwell, John >> Cc: Bernard Aboba; 'MARTINI' >> Subject: Re: Middlebox needs - admitting inbound requests >> >> >> On Feb 22, 2010, at 3:26 AM, Elwell, John wrote: >> >> > Dean, >> > >> > I don't agree with a requirement for supporting the admission of >> > outbound requests based on whether the caller has registered. This >> > would prevent, for example, a call from A to B being >> forwarded to C >> > via the SSP, where A is not one of the registered AORs at this >> > particular PBX (unless you do horrible things that I don't >> think we >> > want to condone, like pretending the caller is B, who is >> registered). >> >> Well, considering the call needs to be paid for by B, given >> that A has >> no billing relationship with the SSP, that's not completely off the >> wall. > [JRE] The SSP can only bill somebody on the basis of what has been > authenticated. Neither From (without SIP Identity) nor PAI has any means > of authentication. The SSP instead has to bill the PBX on the basis of > whatever authentication it provides. > > John > >> >> > >> > If you want to pursue the question of being able to support >> > admitting both inbound requests and outbound requests on the basis >> > of the current registration state of the AOR, I think we should >> > consider these as separate issues. Do you want to raise issues on >> > the tracker for one or both of these? >> >> >> Well heck, I don't agree with the requirement either. I think it's a >> royally stupid idea in either direction. However, people have been >> claiming that it's necessary in one direction or the other for their >> deployments. I was just translating the rather vaguely worded >> requirements I was hearing so that we'd all know what the >> argument was >> about. >> >> Will the middlebox vendors and their victims please step forward and >> tell us whether they really need to be able to do this? >> >> -- >> Dean >> >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Thu Feb 25 13:04:57 2010 Return-Path: <adam@nostrum.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A9D28C27F for <martini@core3.amsl.com>; Thu, 25 Feb 2010 13:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.039, 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 kN7X3PdBGY9W for <martini@core3.amsl.com>; Thu, 25 Feb 2010 13:04: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 0A5883A6D0F for <martini@ietf.org>; Thu, 25 Feb 2010 13:04:55 -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 o1PL6vDj086182 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Thu, 25 Feb 2010 15:06:58 -0600 (CST) (envelope-from adam@nostrum.com) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 25 Feb 2010 15:06:57 -0600 From: Adam Roach <adam@nostrum.com> To: Tyler Parkin <tyler@foxfam.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, Dean Willis <dean.willis@softarmor.com> Message-ID: <C7AC4291.14C39%adam@nostrum.com> Thread-Topic: [martini] Middlebox needs - admitting inbound requests Thread-Index: Acq2XnbPqEB+kEblPUSOWw7qz/FKtw== In-Reply-To: <007f01cab65d$a7239060$430510ac@CORPORATE.VOX.NET> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 21:04:58 -0000 And, of course, if we indicate the list of extensions at registration time, then the SBC can extract the necessary information from the REGISTER messages (just like they do now). /a On 2/25/10 3:01 PM, "Tyler Parkin" <tyler@foxfam.com> wrote: > I'll throw my $.02 in just for fun. > > I'm not sure I'm clear on what you mean, John, but it sounds like you're > saying you think most people who cut CDR's do it based on the authentication > credentials. You're right and wrong. As an SSP we can only bill based on > what's authenticated (to verify that's the person actually making the call). > However, most softswitch vendors use From/PAI to find the correct account > and generate billing records, not the authentication credentials. As such, > we can (and do) bill off of from and PAI when the situation dictates, like > the example below. There are various implimentations to ensure that the > credentials provided match From/PAI, which conceivably would have already > registered. If you base it only on credentials then it means any > deployments where the registrar isn't also the device that cuts billing > records couldn't bill their customers. > > As far as the middle box ~ there are reasons to deploy them that actually do > support "running your voip system 'the right way'," which is why they're so > prevalent. One of the obvious ones is to mask core network components from > untrusted sources. Today, our UA's (internal and external) send a register > request and the SBC caches the URI and IP address (presumably the same most > of the time), manipulates the headers, and forwards the requests to the > registrar using the internal/trusted IP address of the SBC. When a request > comes into the registrar destined for a UA, the registrar sends the request > to the SBC using the internal IP (because that's what it received the > request from), and the SBC maps it from the internal IP to the > original/external IP and sends it to the UA. Again, the registrar doesn't > see different originating IP addresses, it only sees the single internal > address of the SBC. > > My concern here is that the UA is expected to register using an AOR that > apparently won't be used in subsequent messaging for associated/child > addresses. When a call comes into the registrar for a child address, it's > going to send it to the SBC for delivery and the SBC won't have the child > address mapping required to send it to the UA. This is issue has come up > with other implimentations for bulk reg, and each vendor has their own > solution outside RFC spec. One of those was to put the AOR in the request > URI and the child address in the To field, and have the SBC substitute when > it sends it to the UA. > > Regards, > > Tyler Parkin > tyler@foxfam.com > > > > ----- Original Message ----- > From: "Elwell, John" <john.elwell@siemens-enterprise.com> > To: "Dean Willis" <dean.willis@softarmor.com> > Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "'MARTINI'" > <martini@ietf.org> > Sent: Monday, February 22, 2010 4:09 PM > Subject: Re: [martini] Middlebox needs - admitting inbound requests > > >> >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: 22 February 2010 20:00 >>> To: Elwell, John >>> Cc: Bernard Aboba; 'MARTINI' >>> Subject: Re: Middlebox needs - admitting inbound requests >>> >>> >>> On Feb 22, 2010, at 3:26 AM, Elwell, John wrote: >>> >>>> Dean, >>>> >>>> I don't agree with a requirement for supporting the admission of >>>> outbound requests based on whether the caller has registered. This >>>> would prevent, for example, a call from A to B being >>> forwarded to C >>>> via the SSP, where A is not one of the registered AORs at this >>>> particular PBX (unless you do horrible things that I don't >>> think we >>>> want to condone, like pretending the caller is B, who is >>> registered). >>> >>> Well, considering the call needs to be paid for by B, given >>> that A has >>> no billing relationship with the SSP, that's not completely off the >>> wall. >> [JRE] The SSP can only bill somebody on the basis of what has been >> authenticated. Neither From (without SIP Identity) nor PAI has any means >> of authentication. The SSP instead has to bill the PBX on the basis of >> whatever authentication it provides. >> >> John >> >>> >>>> >>>> If you want to pursue the question of being able to support >>>> admitting both inbound requests and outbound requests on the basis >>>> of the current registration state of the AOR, I think we should >>>> consider these as separate issues. Do you want to raise issues on >>>> the tracker for one or both of these? >>> >>> >>> Well heck, I don't agree with the requirement either. I think it's a >>> royally stupid idea in either direction. However, people have been >>> claiming that it's necessary in one direction or the other for their >>> deployments. I was just translating the rather vaguely worded >>> requirements I was hearing so that we'd all know what the >>> argument was >>> about. >>> >>> Will the middlebox vendors and their victims please step forward and >>> tell us whether they really need to be able to do this? >>> >>> -- >>> 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 spencer@wonderhamster.org Thu Feb 25 14:19:09 2010 Return-Path: <spencer@wonderhamster.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D6D3A8726 for <martini@core3.amsl.com>; Thu, 25 Feb 2010 14:19:09 -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.115, 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 ugri4GSZrEvw for <martini@core3.amsl.com>; Thu, 25 Feb 2010 14:19:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 030913A872C for <martini@ietf.org>; Thu, 25 Feb 2010 14:19: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 0LpKCT-1NEzUW2eSz-00fdgw; Thu, 25 Feb 2010 17:20:38 -0500 Message-ID: <99BF4620352B4F9C9E090F9004C31924@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "Adam Roach" <adam@nostrum.com>, "Tyler Parkin" <tyler@foxfam.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Dean Willis" <dean.willis@softarmor.com> References: <C7AC4291.14C39%adam@nostrum.com> Date: Thu, 25 Feb 2010 16:20:25 -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: V01U2FsdGVkX18F+ImzYcyurg5CQwuSY9REQbghIbBkXlWwS0W mz4hSneGIplfL5ctYGbD7oY5M9lduwHsEIjAvM4XxTfXwUhT+Q wfFBOQDht+6Y5OvUFYuow1ZCPFWR15UONhB75LjPjs= Cc: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 22:19:09 -0000 Hi, Adam, > And, of course, if we indicate the list of extensions at registration > time, > then the SBC can extract the necessary information from the REGISTER > messages (just like they do now). > > /a Just making sure I understand - do you mean "just like they do now with one-line-at-a-time REGISTERs", or something else? Thanks, Spencer From adam@nostrum.com Thu Feb 25 14:21:48 2010 Return-Path: <adam@nostrum.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006E128C43E for <martini@core3.amsl.com>; Thu, 25 Feb 2010 14:21:48 -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 BjrRf-WGelfn for <martini@core3.amsl.com>; Thu, 25 Feb 2010 14:21:47 -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 881AE28C465 for <martini@ietf.org>; Thu, 25 Feb 2010 14:21:46 -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 o1PMNnha091659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Feb 2010 16:23:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B86F875.6070902@nostrum.com> Date: Thu, 25 Feb 2010 16:23:49 -0600 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Spencer Dawkins <spencer@wonderhamster.org> References: <C7AC4291.14C39%adam@nostrum.com> <99BF4620352B4F9C9E090F9004C31924@china.huawei.com> In-Reply-To: <99BF4620352B4F9C9E090F9004C31924@china.huawei.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: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 22:21:48 -0000 On 2/25/10 4:20 PM, Spencer Dawkins wrote: > Hi, Adam, > >> And, of course, if we indicate the list of extensions at registration >> time, >> then the SBC can extract the necessary information from the REGISTER >> messages (just like they do now). >> >> /a > > Just making sure I understand - do you mean "just like they do now > with one-line-at-a-time REGISTERs", or something else? Yes. I mean they can know which AORs correspond to which registrations by examining the REGISTER messages. Which is what they do with one-AOR-at-a-time REGISTER messages currently. /a From tyler@foxfam.com Thu Feb 25 14:43:25 2010 Return-Path: <tyler@foxfam.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D963A8579 for <martini@core3.amsl.com>; Thu, 25 Feb 2010 14:43: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.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 7Lg+pBrxdjDA for <martini@core3.amsl.com>; Thu, 25 Feb 2010 14:43:24 -0800 (PST) Received: from smtp04.atlngahp.sys.nuvox.net (smtp-out4.atlngahp.sys.nuvox.net [70.43.63.22]) by core3.amsl.com (Postfix) with ESMTP id 647C43A85C5 for <martini@ietf.org>; Thu, 25 Feb 2010 14:43:24 -0800 (PST) Received: from LT6KW7CD1 (fw.newsouth.com [209.177.200.190]) by smtp04.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o1PMjVNd022583; Thu, 25 Feb 2010 17:45:32 -0500 Message-ID: <00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET> From: "Tyler Parkin" <tyler@foxfam.com> To: "Adam Roach" <adam@nostrum.com>, "Spencer Dawkins" <spencer@wonderhamster.org> References: <C7AC4291.14C39%adam@nostrum.com> <99BF4620352B4F9C9E090F9004C31924@china.huawei.com> <4B86F875.6070902@nostrum.com> Date: Thu, 25 Feb 2010 17:45:31 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, 'MARTINI' <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 22:43:25 -0000 For what it's worth, SBC utilization isn't expected to decline, whether you like them or not. Most carriers use them, and a lot of end customers are deploying products like Edgewater/Ingate in front of their PBX's as well. Chances are, there will be one or more "middleboxes" in any deployment excluding (possibly) peer to peer. Whether inbound or oubound, if they're not explicitly made aware of the extensions or AOR as described earlier, they're going to have issues unless the behavior is accounted for in the standard. http://sip-trunking.tmcnet.com/topics/security/articles/58263-new-enterprise-sbc-report-projects-48-percent-annual.htm Tyler ----- Original Message ----- From: "Adam Roach" <adam@nostrum.com> To: "Spencer Dawkins" <spencer@wonderhamster.org> Cc: "Tyler Parkin" <tyler@foxfam.com>; "Elwell, John" <john.elwell@siemens-enterprise.com>; "Dean Willis" <dean.willis@softarmor.com>; "Bernard Aboba" <bernard_aboba@hotmail.com>; "'MARTINI'" <martini@ietf.org> Sent: Thursday, February 25, 2010 5:23 PM Subject: Re: [martini] Middlebox needs - admitting inbound requests > On 2/25/10 4:20 PM, Spencer Dawkins wrote: >> Hi, Adam, >> >>> And, of course, if we indicate the list of extensions at registration >>> time, >>> then the SBC can extract the necessary information from the REGISTER >>> messages (just like they do now). >>> >>> /a >> >> Just making sure I understand - do you mean "just like they do now with >> one-line-at-a-time REGISTERs", or something else? > > Yes. I mean they can know which AORs correspond to which registrations by > examining the REGISTER messages. Which is what they do with > one-AOR-at-a-time REGISTER messages currently. > > /a From adam@nostrum.com Thu Feb 25 14:43:54 2010 Return-Path: <adam@nostrum.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD113A85C4 for <martini@core3.amsl.com>; Thu, 25 Feb 2010 14:43: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=[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 fhGeQonHBAah for <martini@core3.amsl.com>; Thu, 25 Feb 2010 14:43:54 -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 1F34A3A8579 for <martini@ietf.org>; Thu, 25 Feb 2010 14:43:53 -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 o1PMk39d093374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <martini@ietf.org>; Thu, 25 Feb 2010 16:46:04 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B86FDAB.4090803@nostrum.com> Date: Thu, 25 Feb 2010 16:46:03 -0600 From: Adam Roach <adam@nostrum.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: "martini@ietf.org" <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] New GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 22:43:54 -0000 I've made a few changes to the GIN draft, to reflect the comments so far on the mailing list and at the last interim call. http://www.ietf.org/id/draft-roach-martini-gin-01.txt Diffs can be found here: http://tools.ietf.org/rfcdiff?url2=draft-roach-martini-gin-01.txt Comments, as always, are encouraged. /a From bernard_aboba@hotmail.com Thu Feb 25 15:11:08 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427283A8557 for <martini@core3.amsl.com>; Thu, 25 Feb 2010 15:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.593, 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 vTgllWJT0Caq for <martini@core3.amsl.com>; Thu, 25 Feb 2010 15:11:06 -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 CCE2E3A85F8 for <martini@ietf.org>; Thu, 25 Feb 2010 15:11:02 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.73]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 15:13:14 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: <BLU137-DS2E54304DB122C020172BA93400@phx.gbl> From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: <martini@ietf.org> Date: Thu, 25 Feb 2010 15:12:35 -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: Acq2a8Sf9LQvpMD+TI6mGMVXHGl/AgABDTHw Content-Language: en-us X-OriginalArrivalTime: 25 Feb 2010 23:13:14.0999 (UTC) FILETIME=[1BA6D070:01CAB670] Subject: [martini] FW: New GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 23:11:08 -0000 -----Original Message----- From: Adam Roach [mailto:adam@estacado.net] Sent: Thursday, February 25, 2010 2:44 PM To: martini@ietf.org Subject: New GIN Draft I've made a few changes to the GIN draft, to reflect the comments so far on the mailing list and at the last interim call. http://www.ietf.org/id/draft-roach-martini-gin-01.txt Diffs can be found here: http://tools.ietf.org/rfcdiff?url2=draft-roach-martini-gin-01.txt Comments, as always, are encouraged. /a From BLINDSAY@nortel.com Thu Feb 25 15:26:08 2010 Return-Path: <BLINDSAY@nortel.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC85D28C49F for <martini@core3.amsl.com>; Thu, 25 Feb 2010 15:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 2eRx6kw9idWM for <martini@core3.amsl.com>; Thu, 25 Feb 2010 15:26:07 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 140A628C4AE for <martini@ietf.org>; Thu, 25 Feb 2010 15:26:06 -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 o1PNRaG19668; Thu, 25 Feb 2010 23:27: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: Thu, 25 Feb 2010 18:26:51 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141CB0F52A@zcarhxm1.corp.nortel.com> In-Reply-To: <00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Middlebox needs - admitting inbound requests Thread-Index: Acq2bEuV4Tb6d7w/RVO/dkRsOJDc/wAA6umw References: <C7AC4291.14C39%adam@nostrum.com><99BF4620352B4F9C9E090F9004C31924@china.huawei.com><4B86F875.6070902@nostrum.com> <00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET> From: "Brian Lindsay" <blindsay@nortel.com> To: "Tyler Parkin" <tyler@foxfam.com>, "Adam Roach" <adam@nostrum.com>, "Spencer Dawkins" <spencer@wonderhamster.org> Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 25 Feb 2010 23:26:09 -0000 Hi, There was a carrier who posted on this topic last week, who indicated their middleboxes have no issues in an implicit registration environment: http://www.ietf.org/mail-archive/web/martini/current/msg00814.html Why would basic routing should be a problem? I would assume most SBC B2BUA's might simply maintain some binding between the southbound contact/routing info and northbound contact/routing info, or use some other technique.=20 Regards Brian =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Tyler Parkin Sent: Thursday, February 25, 2010 5:46 PM To: Adam Roach; Spencer Dawkins Cc: Bernard Aboba; 'MARTINI' Subject: Re: [martini] Middlebox needs - admitting inbound requests For what it's worth, SBC utilization isn't expected to decline, whether you like them or not. Most carriers use them, and a lot of end customers are deploying products like Edgewater/Ingate in front of their PBX's as well.=20 Chances are, there will be one or more "middleboxes" in any deployment excluding (possibly) peer to peer. Whether inbound or oubound, if they're not explicitly made aware of the extensions or AOR as described earlier, they're going to have issues unless the behavior is accounted for in the standard. http://sip-trunking.tmcnet.com/topics/security/articles/58263-new-enterp rise-sbc-report-projects-48-percent-annual.htm Tyler ----- Original Message ----- From: "Adam Roach" <adam@nostrum.com> To: "Spencer Dawkins" <spencer@wonderhamster.org> Cc: "Tyler Parkin" <tyler@foxfam.com>; "Elwell, John"=20 <john.elwell@siemens-enterprise.com>; "Dean Willis"=20 <dean.willis@softarmor.com>; "Bernard Aboba" <bernard_aboba@hotmail.com>; "'MARTINI'" <martini@ietf.org> Sent: Thursday, February 25, 2010 5:23 PM Subject: Re: [martini] Middlebox needs - admitting inbound requests > On 2/25/10 4:20 PM, Spencer Dawkins wrote: >> Hi, Adam, >> >>> And, of course, if we indicate the list of extensions at=20 >>> registration time, then the SBC can extract the necessary=20 >>> information from the REGISTER messages (just like they do now). >>> >>> /a >> >> Just making sure I understand - do you mean "just like they do now=20 >> with one-line-at-a-time REGISTERs", or something else? > > Yes. I mean they can know which AORs correspond to which registrations > by examining the REGISTER messages. Which is what they do with=20 > one-AOR-at-a-time REGISTER messages currently. > > /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From tyler@foxfam.com Thu Feb 25 16:25:31 2010 Return-Path: <tyler@foxfam.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C6A28C270 for <martini@core3.amsl.com>; Thu, 25 Feb 2010 16:25:31 -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 L5eS2V4jHcfT for <martini@core3.amsl.com>; Thu, 25 Feb 2010 16:25:29 -0800 (PST) Received: from smtp05.atlngahp.sys.nuvox.net (smtp-out5.atlngahp.sys.nuvox.net [70.43.63.23]) by core3.amsl.com (Postfix) with ESMTP id 885EB28C25C for <martini@ietf.org>; Thu, 25 Feb 2010 16:25:29 -0800 (PST) Received: from LT6KW7CD1 (fw.newsouth.com [209.177.200.190]) by smtp05.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o1Q0RbOD008129; Thu, 25 Feb 2010 19:27:37 -0500 Message-ID: <00ca01cab67a$7fd21460$430510ac@CORPORATE.VOX.NET> From: "Tyler Parkin" <tyler@foxfam.com> To: "Brian Lindsay" <blindsay@nortel.com>, "Adam Roach" <adam@nostrum.com>, "Spencer Dawkins" <spencer@wonderhamster.org> References: <C7AC4291.14C39%adam@nostrum.com><99BF4620352B4F9C9E090F9004C31924@china.huawei.com><4B86F875.6070902@nostrum.com> <00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET> <09B7DBFE70A9E24BBB21689DAD3A06141CB0F52A@zcarhxm1.corp.nortel.com> Date: Thu, 25 Feb 2010 19:27:36 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 00:25:31 -0000 There were two discussions in that link, and I think the one Jack addressed was inbound (from the PBX). He's correct, it's usually up to the SP to permit/deny calls from unregistered endpoints and they can do various things to them. The comment "While the PBX is registered, any methods originating from it's IP address are considered registered." -- this is also configurable in most cases, user@host or just host. Defaults and what can be configured depends on the middlebox vendor and not all behave the same way. My concern is outbound from the SP to the PBX. The middlebox needs a way to map the child/extension address to the implicit reg it initially received. IMO that method or identifier should be part of the standard, whether it's a list of extensions or a cookie as proposed in the link provided, or something else. As an operator, I spend a lot of my time telling vendors that they aren't following RFC spec and therefore they're not working correctly with another vendor. It's particularily frustrating when the RFC leaves something vague or just plain omits it. Acknowledging that middleboxes exist, and that implict reg could (will) cause an issue for them, and then not specifying something in the standard for them to use basically ensures no two vendors use the standard the same way. A middlebox could support a cookie, a registrar might include the original AOR or GRUU, etc. Leaving it undetermined isn't enough in my opinion. 3261 defines the behavior for B2BUA's, so specifying behavior in this regard isn't out of the question. *How* they do it might be out of spec, but what they use shouldn't be. But then, discussions like this are new to me, so I might be crazy. =) Respectfully, Tyler ----- Original Message ----- From: "Brian Lindsay" <blindsay@nortel.com> To: "Tyler Parkin" <tyler@foxfam.com>; "Adam Roach" <adam@nostrum.com>; "Spencer Dawkins" <spencer@wonderhamster.org> Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "MARTINI" <martini@ietf.org> Sent: Thursday, February 25, 2010 6:26 PM Subject: RE: [martini] Middlebox needs - admitting inbound requests Hi, There was a carrier who posted on this topic last week, who indicated their middleboxes have no issues in an implicit registration environment: http://www.ietf.org/mail-archive/web/martini/current/msg00814.html Why would basic routing should be a problem? I would assume most SBC B2BUA's might simply maintain some binding between the southbound contact/routing info and northbound contact/routing info, or use some other technique. Regards Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Tyler Parkin Sent: Thursday, February 25, 2010 5:46 PM To: Adam Roach; Spencer Dawkins Cc: Bernard Aboba; 'MARTINI' Subject: Re: [martini] Middlebox needs - admitting inbound requests For what it's worth, SBC utilization isn't expected to decline, whether you like them or not. Most carriers use them, and a lot of end customers are deploying products like Edgewater/Ingate in front of their PBX's as well. Chances are, there will be one or more "middleboxes" in any deployment excluding (possibly) peer to peer. Whether inbound or oubound, if they're not explicitly made aware of the extensions or AOR as described earlier, they're going to have issues unless the behavior is accounted for in the standard. http://sip-trunking.tmcnet.com/topics/security/articles/58263-new-enterp rise-sbc-report-projects-48-percent-annual.htm Tyler ----- Original Message ----- From: "Adam Roach" <adam@nostrum.com> To: "Spencer Dawkins" <spencer@wonderhamster.org> Cc: "Tyler Parkin" <tyler@foxfam.com>; "Elwell, John" <john.elwell@siemens-enterprise.com>; "Dean Willis" <dean.willis@softarmor.com>; "Bernard Aboba" <bernard_aboba@hotmail.com>; "'MARTINI'" <martini@ietf.org> Sent: Thursday, February 25, 2010 5:23 PM Subject: Re: [martini] Middlebox needs - admitting inbound requests > On 2/25/10 4:20 PM, Spencer Dawkins wrote: >> Hi, Adam, >> >>> And, of course, if we indicate the list of extensions at >>> registration time, then the SBC can extract the necessary >>> information from the REGISTER messages (just like they do now). >>> >>> /a >> >> Just making sure I understand - do you mean "just like they do now >> with one-line-at-a-time REGISTERs", or something else? > > Yes. I mean they can know which AORs correspond to which registrations > by examining the REGISTER messages. Which is what they do with > one-AOR-at-a-time REGISTER messages currently. > > /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Fri Feb 26 02:32:42 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7833A3A847F for <martini@core3.amsl.com>; Fri, 26 Feb 2010 02:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 8Sstkvwp26k3 for <martini@core3.amsl.com>; Fri, 26 Feb 2010 02:32: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 AB29C28C115 for <martini@ietf.org>; Fri, 26 Feb 2010 02:32:40 -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-1026034; Fri, 26 Feb 2010 11:34:47 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 052021EB82AB; Fri, 26 Feb 2010 11:34:47 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 26 Feb 2010 11:34:47 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Tyler Parkin <tyler@foxfam.com>, Brian Lindsay <blindsay@nortel.com>, Adam Roach <adam@nostrum.com>, Spencer Dawkins <spencer@wonderhamster.org> Date: Fri, 26 Feb 2010 11:34:44 +0100 Thread-Topic: [martini] Middlebox needs - admitting inbound requests Thread-Index: Acq2eoU+WRDR+bt2Q8GnKvTQk1OiZAAUtR/Q Message-ID: <A444A0F8084434499206E78C106220CABBB22E97@MCHP058A.global-ad.net> References: <C7AC4291.14C39%adam@nostrum.com><99BF4620352B4F9C9E090F9004C31924@china.huawei.com><4B86F875.6070902@nostrum.com> <00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET> <09B7DBFE70A9E24BBB21689DAD3A06141CB0F52A@zcarhxm1.corp.nortel.com> <00ca01cab67a$7fd21460$430510ac@CORPORATE.VOX.NET> In-Reply-To: <00ca01cab67a$7fd21460$430510ac@CORPORATE.VOX.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 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 10:32:42 -0000 Tyler, I found this thread a little mixed up between outbound requests from the PB= X and inbound requests to the PBX, so I am not sure I understood everythin= g. As far as inbound request are concerned, I think with gin-01 the problems y= ou raise should be solvable, but it perhaps requires use of Proxy-Require, = as already discussed. The middlebox does not need to know exactly which E.1= 64s are implicitly registered, but when it gets a request to the PBX's IP a= ddress (presumably with Route indicating the IP address of the middlebox) i= t should assume the E.164 in the user part is indeed a registered AOR. Now concerning outbound requests (this was what my earlier message was abou= t, although somewhere further back that got brought across to this thread r= ather than the thread concerning outbound requests, so the thread title was= wrong). Assuming an entity has knowledge of registered E.164 numbers, it i= s not clear to me how it would deal with a request where the From/PAI in th= e request from the PBX is not one of the implicitly registered ones. This c= an arise, for example, if the request originates elsewhere in the enterpris= e and "breaks out" to the SSP via this particular PBX. Or if the call origi= nated elsewhere and was forwarded by the PBX to the SSP. I appreciate that = there may be some arrangements between PBX and SSP where this is forbidden = by policy, but in the general case I would expect it to work, so that the c= allee has a correct AOR to which it can make a return call. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Tyler Parkin > Sent: 26 February 2010 00:28 > To: Brian Lindsay; Adam Roach; Spencer Dawkins > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] Middlebox needs - admitting inbound requests >=20 > There were two discussions in that link, and I think the one=20 > Jack addressed=20 > was inbound (from the PBX). He's correct, it's usually up to=20 > the SP to=20 > permit/deny calls from unregistered endpoints and they can do=20 > various things=20 > to them. The comment "While the PBX is registered, any=20 > methods originating=20 > from it's IP address are considered registered." -- this is also=20 > configurable in most cases, user@host or just host. Defaults=20 > and what can=20 > be configured depends on the middlebox vendor and not all=20 > behave the same=20 > way. >=20 > My concern is outbound from the SP to the PBX. The middlebox=20 > needs a way to=20 > map the child/extension address to the implicit reg it=20 > initially received.=20 > IMO that method or identifier should be part of the standard,=20 > whether it's a=20 > list of extensions or a cookie as proposed in the link provided, or=20 > something else. >=20 > As an operator, I spend a lot of my time telling vendors that=20 > they aren't=20 > following RFC spec and therefore they're not working=20 > correctly with another=20 > vendor. It's particularily frustrating when the RFC leaves=20 > something vague=20 > or just plain omits it. >=20 > Acknowledging that middleboxes exist, and that implict reg=20 > could (will)=20 > cause an issue for them, and then not specifying something in=20 > the standard=20 > for them to use basically ensures no two vendors use the=20 > standard the same=20 > way. A middlebox could support a cookie, a registrar might=20 > include the=20 > original AOR or GRUU, etc. Leaving it undetermined isn't=20 > enough in my=20 > opinion. 3261 defines the behavior for B2BUA's, so specifying=20 > behavior in=20 > this regard isn't out of the question. *How* they do it=20 > might be out of=20 > spec, but what they use shouldn't be. But then, discussions=20 > like this are=20 > new to me, so I might be crazy. =3D) >=20 > Respectfully, >=20 > Tyler >=20 > ----- Original Message -----=20 > From: "Brian Lindsay" <blindsay@nortel.com> > To: "Tyler Parkin" <tyler@foxfam.com>; "Adam Roach"=20 > <adam@nostrum.com>;=20 > "Spencer Dawkins" <spencer@wonderhamster.org> > Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "MARTINI"=20 > <martini@ietf.org> > Sent: Thursday, February 25, 2010 6:26 PM > Subject: RE: [martini] Middlebox needs - admitting inbound requests >=20 >=20 > Hi, >=20 > There was a carrier who posted on this topic last week, who=20 > indicated > their middleboxes have no issues in an implicit registration > environment: > http://www.ietf.org/mail-archive/web/martini/current/msg00814.html >=20 > Why would basic routing should be a problem? I would assume most SBC > B2BUA's might simply maintain some binding between the southbound > contact/routing info and northbound contact/routing info, or use some > other technique. >=20 > Regards > Brian >=20 >=20 >=20 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Tyler Parkin > Sent: Thursday, February 25, 2010 5:46 PM > To: Adam Roach; Spencer Dawkins > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] Middlebox needs - admitting inbound requests >=20 > For what it's worth, SBC utilization isn't expected to=20 > decline, whether > you like them or not. Most carriers use them, and a lot of end > customers are deploying products like Edgewater/Ingate in=20 > front of their > PBX's as well. > Chances are, there will be one or more "middleboxes" in any deployment > excluding (possibly) peer to peer. Whether inbound or oubound, if > they're not explicitly made aware of the extensions or AOR as=20 > described > earlier, they're going to have issues unless the behavior is accounted > for in the standard. >=20 > http://sip-trunking.tmcnet.com/topics/security/articles/58263- > new-enterp > rise-sbc-report-projects-48-percent-annual.htm >=20 > Tyler >=20 > ----- Original Message ----- > From: "Adam Roach" <adam@nostrum.com> > To: "Spencer Dawkins" <spencer@wonderhamster.org> > Cc: "Tyler Parkin" <tyler@foxfam.com>; "Elwell, John" > <john.elwell@siemens-enterprise.com>; "Dean Willis" > <dean.willis@softarmor.com>; "Bernard Aboba" > <bernard_aboba@hotmail.com>; "'MARTINI'" <martini@ietf.org> > Sent: Thursday, February 25, 2010 5:23 PM > Subject: Re: [martini] Middlebox needs - admitting inbound requests >=20 >=20 > > On 2/25/10 4:20 PM, Spencer Dawkins wrote: > >> Hi, Adam, > >> > >>> And, of course, if we indicate the list of extensions at > >>> registration time, then the SBC can extract the necessary > >>> information from the REGISTER messages (just like they do now). > >>> > >>> /a > >> > >> Just making sure I understand - do you mean "just like they do now > >> with one-line-at-a-time REGISTERs", or something else? > > > > Yes. I mean they can know which AORs correspond to which=20 > registrations >=20 > > by examining the REGISTER messages. Which is what they do with > > one-AOR-at-a-time REGISTER messages currently. > > > > /a >=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 > = From tyler@foxfam.com Fri Feb 26 07:06:35 2010 Return-Path: <tyler@foxfam.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F8328C182 for <martini@core3.amsl.com>; Fri, 26 Feb 2010 07:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 wfE0pvjykpDk for <martini@core3.amsl.com>; Fri, 26 Feb 2010 07:06:33 -0800 (PST) Received: from smtp02.atlngahp.sys.nuvox.net (smtp-out2.atlngahp.sys.nuvox.net [70.43.63.19]) by core3.amsl.com (Postfix) with ESMTP id 83F183A862F for <martini@ietf.org>; Fri, 26 Feb 2010 07:06:33 -0800 (PST) Received: from LT6KW7CD1 (216.215.202.1.nw.nuvox.net [216.215.202.1]) by smtp02.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o1QF8gxq019771; Fri, 26 Feb 2010 10:08:43 -0500 Message-ID: <000901cab6f5$968a9df0$010c030a@CORPORATE.VOX.NET> From: "Tyler Parkin" <tyler@foxfam.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "Brian Lindsay" <blindsay@nortel.com>, "Adam Roach" <adam@nostrum.com>, "Spencer Dawkins" <spencer@wonderhamster.org> References: <C7AC4291.14C39%adam@nostrum.com><99BF4620352B4F9C9E090F9004C31924@china.huawei.com><4B86F875.6070902@nostrum.com><00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET><09B7DBFE70A9E24BBB21689DAD3A06141CB0F52A@zcarhxm1.corp.nortel.com> <00ca01cab67a$7fd21460$430510ac@CORPORATE.VOX.NET> <A444A0F8084434499206E78C106220CABBB22E97@MCHP058A.global-ad.net> Date: Fri, 26 Feb 2010 10:08:42 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 15:06:35 -0000 ----- Original Message ----- From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: "Tyler Parkin" <tyler@foxfam.com>; "Brian Lindsay" <blindsay@nortel.com>; "Adam Roach" <adam@nostrum.com>; "Spencer Dawkins" <spencer@wonderhamster.org> Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "MARTINI" <martini@ietf.org> Sent: Friday, February 26, 2010 5:34 AM Subject: RE: [martini] Middlebox needs - admitting inbound requests Tyler, I found this thread a little mixed up between outbound requests from the PBX and inbound requests to the PBX, so I am not sure I understood everything. [tyler] sorry for the confusion, I think we're looking at it in different directions... inbound to me is inbound to the SSP, where to you inbound is to the PBX. I guess we'll stick w/ inbound = to the PBX As far as inbound request are concerned, I think with gin-01 the problems you raise should be solvable, but it perhaps requires use of Proxy-Require, as already discussed. The middlebox does not need to know exactly which E.164s are implicitly registered, but when it gets a request to the PBX's IP address (presumably with Route indicating the IP address of the middlebox) it should assume the E.164 in the user part is indeed a registered AOR. [tyler] my point is that the middlebox doesn't get a request to the PBX's IP address. The softswitch/registrar generating the call doesn't know the PBX's IP because it was masked during the initial registration. Any requests from from the registrar/softswitch to the middlebox (destined for the PBX) will only have user@middlebox, perhaps w/ a cookie. The middelbox needs to map user@middlebox to whatever IP/host originally registered. Today, the middlebox keeps a cache where the initial (individual) registration might be user@1.1.1.1, and the registration forwarded to the registrar is user@2.2.2.2. That way when the registrar sends a request to the middlebox for user@2.2.2.2 it maps it to user@1.1.1.1 and all is good. If the middelbox doesn't have knowledge of the user (because of implicit), it can't make the mapping unless it has something else to associate to the original implicit reg (like a cookie, or knowledge of the extensions). Now concerning outbound requests (this was what my earlier message was about, although somewhere further back that got brought across to this thread rather than the thread concerning outbound requests, so the thread title was wrong). Assuming an entity has knowledge of registered E.164 numbers, it is not clear to me how it would deal with a request where the From/PAI in the request from the PBX is not one of the implicitly registered ones. This can arise, for example, if the request originates elsewhere in the enterprise and "breaks out" to the SSP via this particular PBX. Or if the call originated elsewhere and was forwarded by the PBX to the SSP. I appreciate that there may be some arrangements between PBX and SSP where this is forbidden by policy, but in the general case I would expect it to work, so that the callee has a correct AOR to which it can make a return call. [tyler] methods dealing with this situation today (A calls B, B forwards the call to C) would use from=A and PAI=B, where B is a registered endpoint (and billable by the SSP). Not sure if that's what you're asking? John > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Tyler Parkin > Sent: 26 February 2010 00:28 > To: Brian Lindsay; Adam Roach; Spencer Dawkins > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] Middlebox needs - admitting inbound requests > > There were two discussions in that link, and I think the one > Jack addressed > was inbound (from the PBX). He's correct, it's usually up to > the SP to > permit/deny calls from unregistered endpoints and they can do > various things > to them. The comment "While the PBX is registered, any > methods originating > from it's IP address are considered registered." -- this is also > configurable in most cases, user@host or just host. Defaults > and what can > be configured depends on the middlebox vendor and not all > behave the same > way. > > My concern is outbound from the SP to the PBX. The middlebox > needs a way to > map the child/extension address to the implicit reg it > initially received. > IMO that method or identifier should be part of the standard, > whether it's a > list of extensions or a cookie as proposed in the link provided, or > something else. > > As an operator, I spend a lot of my time telling vendors that > they aren't > following RFC spec and therefore they're not working > correctly with another > vendor. It's particularily frustrating when the RFC leaves > something vague > or just plain omits it. > > Acknowledging that middleboxes exist, and that implict reg > could (will) > cause an issue for them, and then not specifying something in > the standard > for them to use basically ensures no two vendors use the > standard the same > way. A middlebox could support a cookie, a registrar might > include the > original AOR or GRUU, etc. Leaving it undetermined isn't > enough in my > opinion. 3261 defines the behavior for B2BUA's, so specifying > behavior in > this regard isn't out of the question. *How* they do it > might be out of > spec, but what they use shouldn't be. But then, discussions > like this are > new to me, so I might be crazy. =) > > Respectfully, > > Tyler > > ----- Original Message ----- > From: "Brian Lindsay" <blindsay@nortel.com> > To: "Tyler Parkin" <tyler@foxfam.com>; "Adam Roach" > <adam@nostrum.com>; > "Spencer Dawkins" <spencer@wonderhamster.org> > Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "MARTINI" > <martini@ietf.org> > Sent: Thursday, February 25, 2010 6:26 PM > Subject: RE: [martini] Middlebox needs - admitting inbound requests > > > Hi, > > There was a carrier who posted on this topic last week, who > indicated > their middleboxes have no issues in an implicit registration > environment: > http://www.ietf.org/mail-archive/web/martini/current/msg00814.html > > Why would basic routing should be a problem? I would assume most SBC > B2BUA's might simply maintain some binding between the southbound > contact/routing info and northbound contact/routing info, or use some > other technique. > > Regards > Brian > > > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Tyler Parkin > Sent: Thursday, February 25, 2010 5:46 PM > To: Adam Roach; Spencer Dawkins > Cc: Bernard Aboba; 'MARTINI' > Subject: Re: [martini] Middlebox needs - admitting inbound requests > > For what it's worth, SBC utilization isn't expected to > decline, whether > you like them or not. Most carriers use them, and a lot of end > customers are deploying products like Edgewater/Ingate in > front of their > PBX's as well. > Chances are, there will be one or more "middleboxes" in any deployment > excluding (possibly) peer to peer. Whether inbound or oubound, if > they're not explicitly made aware of the extensions or AOR as > described > earlier, they're going to have issues unless the behavior is accounted > for in the standard. > > http://sip-trunking.tmcnet.com/topics/security/articles/58263- > new-enterp > rise-sbc-report-projects-48-percent-annual.htm > > Tyler > > ----- Original Message ----- > From: "Adam Roach" <adam@nostrum.com> > To: "Spencer Dawkins" <spencer@wonderhamster.org> > Cc: "Tyler Parkin" <tyler@foxfam.com>; "Elwell, John" > <john.elwell@siemens-enterprise.com>; "Dean Willis" > <dean.willis@softarmor.com>; "Bernard Aboba" > <bernard_aboba@hotmail.com>; "'MARTINI'" <martini@ietf.org> > Sent: Thursday, February 25, 2010 5:23 PM > Subject: Re: [martini] Middlebox needs - admitting inbound requests > > > > On 2/25/10 4:20 PM, Spencer Dawkins wrote: > >> Hi, Adam, > >> > >>> And, of course, if we indicate the list of extensions at > >>> registration time, then the SBC can extract the necessary > >>> information from the REGISTER messages (just like they do now). > >>> > >>> /a > >> > >> Just making sure I understand - do you mean "just like they do now > >> with one-line-at-a-time REGISTERs", or something else? > > > > Yes. I mean they can know which AORs correspond to which > registrations > > > by examining the REGISTER messages. Which is what they do with > > one-AOR-at-a-time REGISTER messages currently. > > > > /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 john.elwell@siemens-enterprise.com Fri Feb 26 09:31:29 2010 Return-Path: <john.elwell@siemens-enterprise.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F6B28C294 for <martini@core3.amsl.com>; Fri, 26 Feb 2010 09:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_31=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 RJTzZjzMGHOg for <martini@core3.amsl.com>; Fri, 26 Feb 2010 09:31:28 -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 53FFC28C285 for <martini@ietf.org>; Fri, 26 Feb 2010 09:31:28 -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-1032304; Fri, 26 Feb 2010 18:33:42 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 834A323F0278; Fri, 26 Feb 2010 18:33:41 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 26 Feb 2010 18:33:41 +0100 From: "Elwell, John" <john.elwell@siemens-enterprise.com> To: Tyler Parkin <tyler@foxfam.com>, Brian Lindsay <blindsay@nortel.com>, Adam Roach <adam@nostrum.com>, Spencer Dawkins <spencer@wonderhamster.org> Date: Fri, 26 Feb 2010 18:33:39 +0100 Thread-Topic: [martini] Middlebox needs - admitting inbound requests Thread-Index: Acq29bD8s9e5MQE+QZmcmsK+R8BaqQAEl7PQ Message-ID: <A444A0F8084434499206E78C106220CABBB232D7@MCHP058A.global-ad.net> References: <C7AC4291.14C39%adam@nostrum.com><99BF4620352B4F9C9E090F9004C31924@china.huawei.com><4B86F875.6070902@nostrum.com><00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET><09B7DBFE70A9E24BBB21689DAD3A06141CB0F52A@zcarhxm1.corp.nortel.com> <00ca01cab67a$7fd21460$430510ac@CORPORATE.VOX.NET> <A444A0F8084434499206E78C106220CABBB22E97@MCHP058A.global-ad.net> <000901cab6f5$968a9df0$010c030a@CORPORATE.VOX.NET> In-Reply-To: <000901cab6f5$968a9df0$010c030a@CORPORATE.VOX.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 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 17:31:29 -0000 =20 > -----Original Message----- > From: Tyler Parkin [mailto:tyler@foxfam.com]=20 > Sent: 26 February 2010 15:09 > To: Elwell, John; Brian Lindsay; Adam Roach; Spencer Dawkins > Cc: Bernard Aboba; MARTINI > Subject: Re: [martini] Middlebox needs - admitting inbound requests >=20 >=20 > ----- Original Message -----=20 > From: "Elwell, John" <john.elwell@siemens-enterprise.com> > To: "Tyler Parkin" <tyler@foxfam.com>; "Brian Lindsay"=20 > <blindsay@nortel.com>; "Adam Roach" <adam@nostrum.com>;=20 > "Spencer Dawkins"=20 > <spencer@wonderhamster.org> > Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "MARTINI"=20 > <martini@ietf.org> > Sent: Friday, February 26, 2010 5:34 AM > Subject: RE: [martini] Middlebox needs - admitting inbound requests >=20 >=20 > Tyler, >=20 > I found this thread a little mixed up between outbound=20 > requests from the PBX=20 > and inbound requests to the PBX, so I am not sure I=20 > understood everything. > [tyler] sorry for the confusion, I think we're looking at it=20 > in different=20 > directions... inbound to me is inbound to the SSP, where to=20 > you inbound is=20 > to the PBX. I guess we'll stick w/ inbound =3D to the PBX >=20 > As far as inbound request are concerned, I think with gin-01=20 > the problems=20 > you raise should be solvable, but it perhaps requires use of=20 > Proxy-Require,=20 > as already discussed. The middlebox does not need to know=20 > exactly which=20 > E.164s are implicitly registered, but when it gets a request=20 > to the PBX's IP=20 > address (presumably with Route indicating the IP address of=20 > the middlebox)=20 > it should assume the E.164 in the user part is indeed a=20 > registered AOR. > [tyler] my point is that the middlebox doesn't get a request=20 > to the PBX's IP=20 > address. =20 [JRE] Why not? If the Contact URI contains the IP address (as in gin-01), t= his will be registered at the registrar and will be returned as the target = of an inbound request to the PBX. > The softswitch/registrar generating the call=20 > doesn't know the=20 > PBX's IP because it was masked during the initial registration. =20 [JRE] Why would it be masked? I understand that the registrar would not see= the IP address at the transport level from which the REGISTER request arri= ved at the middlebox, but it would see the IP address in the Contact URI. > Any=20 > requests from from the registrar/softswitch to the middlebox=20 > (destined for=20 > the PBX) will only have user@middlebox, perhaps w/ a cookie. =20 > The middelbox=20 > needs to map user@middlebox to whatever IP/host originally=20 > registered.=20 > Today, the middlebox keeps a cache where the initial (individual)=20 > registration might be user@1.1.1.1, and the registration=20 > forwarded to the=20 > registrar is user@2.2.2.2. That way when the registrar sends=20 > a request to=20 > the middlebox for user@2.2.2.2 it maps it to user@1.1.1.1 and=20 > all is good.=20 > If the middelbox doesn't have knowledge of the user (because=20 > of implicit), [JRE] Are you suggesting that each user behind the PBX would register with = a different IP address, so you need to know whether it is user1 or user2 in= order to send requests to 11.11.11.11 or 22.22.22.22? If so, that is not t= he scenario that MARTINI is addressing. MARTINI is addressing the case wher= e requests to user1, user2 etc. on a given PBX all need to be routed to the= PBX's IP address. So as long as the middlebox knows the request needs to g= o to the PBX, it doesn't need to know that particular user. =20 > it can't make the mapping unless it has something else to=20 > associate to the=20 > original implicit reg (like a cookie, or knowledge of the extensions). >=20 > Now concerning outbound requests (this was what my earlier=20 > message was=20 > about, although somewhere further back that got brought=20 > across to this=20 > thread rather than the thread concerning outbound requests,=20 > so the thread=20 > title was wrong). Assuming an entity has knowledge of=20 > registered E.164=20 > numbers, it is not clear to me how it would deal with a=20 > request where the=20 > From/PAI in the request from the PBX is not one of the=20 > implicitly registered=20 > ones. This can arise, for example, if the request originates=20 > elsewhere in=20 > the enterprise and "breaks out" to the SSP via this=20 > particular PBX. Or if=20 > the call originated elsewhere and was forwarded by the PBX to=20 > the SSP. I=20 > appreciate that there may be some arrangements between PBX=20 > and SSP where=20 > this is forbidden by policy, but in the general case I would=20 > expect it to=20 > work, so that the callee has a correct AOR to which it can=20 > make a return=20 > call. > [tyler] methods dealing with this situation today (A calls B,=20 > B forwards the=20 > call to C) would use from=3DA and PAI=3DB, where B is a=20 > registered endpoint (and=20 > billable by the SSP). Not sure if that's what you're asking? [JRE] Yes, that was what I was asking, and I know that it sometimes works t= he way you describe, but this is bad because PAI=3DB is wrong - it is not c= ompliant with RFC 3325, since it is not the source of the request. If the c= allee used that to make a return call, the return call would arrive at the = wrong place. For example, if a customer calls me on my office number and th= e PBX forwards it to my home via the SSP, if my phone stores the PAI as the= caller's number and I try to make a return call, the return call goes to m= y office phone, not to my customer. John From tyler@foxfam.com Fri Feb 26 10:01:42 2010 Return-Path: <tyler@foxfam.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64CDB28C2CD for <martini@core3.amsl.com>; Fri, 26 Feb 2010 10:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 1td+dmZvL1oV for <martini@core3.amsl.com>; Fri, 26 Feb 2010 10:01:41 -0800 (PST) Received: from smtp05.atlngahp.sys.nuvox.net (smtp-out5.atlngahp.sys.nuvox.net [70.43.63.23]) by core3.amsl.com (Postfix) with ESMTP id 0CA7E28C13A for <martini@ietf.org>; Fri, 26 Feb 2010 10:01:40 -0800 (PST) Received: from LT6KW7CD1 (216.215.202.1.nw.nuvox.net [216.215.202.1]) by smtp05.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o1QI3o5I019069; Fri, 26 Feb 2010 13:03:50 -0500 Message-ID: <008201cab70e$0d82c6e0$010c030a@CORPORATE.VOX.NET> From: "Tyler Parkin" <tyler@foxfam.com> To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "Brian Lindsay" <blindsay@nortel.com>, "Adam Roach" <adam@nostrum.com>, "Spencer Dawkins" <spencer@wonderhamster.org> References: <C7AC4291.14C39%adam@nostrum.com><99BF4620352B4F9C9E090F9004C31924@china.huawei.com><4B86F875.6070902@nostrum.com><00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET><09B7DBFE70A9E24BBB21689DAD3A06141CB0F52A@zcarhxm1.corp.nortel.com> <00ca01cab67a$7fd21460$430510ac@CORPORATE.VOX.NET> <A444A0F8084434499206E78C106220CABBB22E97@MCHP058A.global-ad.net> <000901cab6f5$968a9df0$010c030a@CORPORATE.VOX.NET> <A444A0F8084434499206E78C106220CABBB232D7@MCHP058A.global-ad.net> Date: Fri, 26 Feb 2010 13:03:50 -0500 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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 18:01:42 -0000 > ----- Original Message ----- > From: "Elwell, John" <john.elwell@siemens-enterprise.com> > To: "Tyler Parkin" <tyler@foxfam.com>; "Brian Lindsay" > <blindsay@nortel.com>; "Adam Roach" <adam@nostrum.com>; > "Spencer Dawkins" > <spencer@wonderhamster.org> > Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "MARTINI" > <martini@ietf.org> > Sent: Friday, February 26, 2010 5:34 AM > Subject: RE: [martini] Middlebox needs - admitting inbound requests > > > Tyler, > > I found this thread a little mixed up between outbound > requests from the PBX > and inbound requests to the PBX, so I am not sure I > understood everything. > [tyler] sorry for the confusion, I think we're looking at it > in different > directions... inbound to me is inbound to the SSP, where to > you inbound is > to the PBX. I guess we'll stick w/ inbound = to the PBX > > As far as inbound request are concerned, I think with gin-01 > the problems > you raise should be solvable, but it perhaps requires use of > Proxy-Require, > as already discussed. The middlebox does not need to know > exactly which > E.164s are implicitly registered, but when it gets a request > to the PBX's IP > address (presumably with Route indicating the IP address of > the middlebox) > it should assume the E.164 in the user part is indeed a > registered AOR. > [tyler] my point is that the middlebox doesn't get a request > to the PBX's IP > address. [JRE] Why not? If the Contact URI contains the IP address (as in gin-01), this will be registered at the registrar and will be returned as the target of an inbound request to the PBX. > The softswitch/registrar generating the call > doesn't know the > PBX's IP because it was masked during the initial registration. [JRE] Why would it be masked? I understand that the registrar would not see the IP address at the transport level from which the REGISTER request arrived at the middlebox, but it would see the IP address in the Contact URI. [Tyler] In most scenarios where a middlebox (aka SBC) exists, the SBC performs two-way NAT functions, and NAT's the headers/URI's for inbound and outbound messaging. Therefore, a request received on the public side from user@PBXIP is sent to the registrar as user@SBCPRIVATEIP. The oposite direction (SSP -> PBX) is received by the SBC as user@SSPIP and NAT'd to user@SBCPUBLICIP. > Any > requests from from the registrar/softswitch to the middlebox > (destined for > the PBX) will only have user@middlebox, perhaps w/ a cookie. > The middelbox > needs to map user@middlebox to whatever IP/host originally > registered. > Today, the middlebox keeps a cache where the initial (individual) > registration might be user@1.1.1.1, and the registration > forwarded to the > registrar is user@2.2.2.2. That way when the registrar sends > a request to > the middlebox for user@2.2.2.2 it maps it to user@1.1.1.1 and > all is good. > If the middelbox doesn't have knowledge of the user (because > of implicit), [JRE] Are you suggesting that each user behind the PBX would register with a different IP address, so you need to know whether it is user1 or user2 in order to send requests to 11.11.11.11 or 22.22.22.22? If so, that is not the scenario that MARTINI is addressing. MARTINI is addressing the case where requests to user1, user2 etc. on a given PBX all need to be routed to the PBX's IP address. So as long as the middlebox knows the request needs to go to the PBX, it doesn't need to know that particular user. [Tyler] Agreed, I shouldn't have used the term user. The middlebox in this scenario wouldn't care about individual users, it's point of contact is the PBX. All PBX's send register requests to the middlebox from different IP's/domains, granted. After NAT, however, all the requests from the SBC to the registrar appear to come from the same IP. We NAT in both directions, which is pretty standard, so we don't expose core equipment to the public, and we don't expose end user IP's to peers. Plus it allows virtual route tables internally and resolves any issues with overlapping address space. > it can't make the mapping unless it has something else to > associate to the > original implicit reg (like a cookie, or knowledge of the extensions). > > Now concerning outbound requests (this was what my earlier > message was > about, although somewhere further back that got brought > across to this > thread rather than the thread concerning outbound requests, > so the thread > title was wrong). Assuming an entity has knowledge of > registered E.164 > numbers, it is not clear to me how it would deal with a > request where the > From/PAI in the request from the PBX is not one of the > implicitly registered > ones. This can arise, for example, if the request originates > elsewhere in > the enterprise and "breaks out" to the SSP via this > particular PBX. Or if > the call originated elsewhere and was forwarded by the PBX to > the SSP. I > appreciate that there may be some arrangements between PBX > and SSP where > this is forbidden by policy, but in the general case I would > expect it to > work, so that the callee has a correct AOR to which it can > make a return > call. > [tyler] methods dealing with this situation today (A calls B, > B forwards the > call to C) would use from=A and PAI=B, where B is a > registered endpoint (and > billable by the SSP). Not sure if that's what you're asking? [JRE] Yes, that was what I was asking, and I know that it sometimes works the way you describe, but this is bad because PAI=B is wrong - it is not compliant with RFC 3325, since it is not the source of the request. If the callee used that to make a return call, the return call would arrive at the wrong place. For example, if a customer calls me on my office number and the PBX forwards it to my home via the SSP, if my phone stores the PAI as the caller's number and I try to make a return call, the return call goes to my office phone, not to my customer. [Tyler] The source of the forward leg of the call is B, not A. Calling area requirements and n11 need to be based on B. Why would the callee use PAI to return a call? That would be in violation of 3325 as well since it would obviate any callerid blocking/suppression requirements. I guess whether the PBX should strip PAI before sending it to your phone is arguable. Agreed, using PAI to assert a different ID than From (where from isn't private) might not strictly adhere to 3325, but I think alternate ID's vs suppressed ID's is splitting hairs a little. John From bernard_aboba@hotmail.com Fri Feb 26 13:02:41 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1534D28C349 for <martini@core3.amsl.com>; Fri, 26 Feb 2010 13:02:41 -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.578, 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 UB7YgzliZ4zV for <martini@core3.amsl.com>; Fri, 26 Feb 2010 13:02:39 -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 A958628C345 for <martini@ietf.org>; Fri, 26 Feb 2010 13:02:39 -0800 (PST) Received: from BLU137-DS11 ([65.55.111.72]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Feb 2010 13:04:55 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: <blu137-ds1105B219C8F7A606992A95933F0@phx.gbl> From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: "'MARTINI'" <martini@ietf.org> Date: Fri, 26 Feb 2010 13:04:54 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0160_01CAB6E4.4A087F30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq3J1fxN8kFuUQ3TKSX/09uaQDUtA== Content-Language: en-us X-OriginalArrivalTime: 26 Feb 2010 21:04:55.0502 (UTC) FILETIME=[58CE8EE0:01CAB727] Subject: [martini] REMINDER: MARTINI WG last call on the "Requirements" document X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 21:02:41 -0000 ------=_NextPart_000_0160_01CAB6E4.4A087F30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This is a reminder of an ongoing MARTINI WG Last Call on the "Requirements" document, prior to sending it on to the IESG for publication as an Informational RFC. The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-martini-reqs-01.txt The MARTINI WG last call will last until Friday, March 5, 2010. Please respond to this WG last call, whether you have comments or not. If you have no comments, please reply to this message and indicate in the body of your message whether youthink the document is ready for consideration by the IESG or not. If you have comments, please provide them to the WG in one of the following ways: 1. If you have an account on the IETF Tools server, or can open one, please login and enter your issue(s) in the MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. 2. If you don't have an account on the IETF Tools server, please post your Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format: To: martini at ietf.org Subject: Requirements-Issue: <title of your issue> Priority: blocker, critical, major, minor or trivial <Explanation of your issue, including a proposal for specific text changes to resolve the issue> ------=_NextPart_000_0160_01CAB6E4.4A087F30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:a=3D"urn:schemas-microsoft-com:office:access" = xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" = xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" = xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" = xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" = xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" = xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" = xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" = xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" = xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" = xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" = xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" = xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" = xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" = xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" = xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" = xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" = xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" = xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" = xmlns:udc=3D"http://schemas.microsoft.com/data/udc" = xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" = xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"= xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" = xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" = xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" = xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" = xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" = xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" = xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" = xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" = xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" = xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig= nature" = xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006= " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi= ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" = xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"= = xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag= es" = xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/= " = xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub= lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" = xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:1117213359; mso-list-type:hybrid; mso-list-template-ids:-2040637184 -1958558062 67698713 67698715 = 67698703 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:21.0pt; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>This is = a reminder of an ongoing MARTINI WG Last Call on the "Requirements" = document, prior to sending it on to the IESG for publication as an Informational = RFC.  The document is available for inspection here: = <o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><a href=3D"http://tools.ietf.org/html/draft-ietf-martini-reqs-01.txt">http:/= /tools.ietf.org/html/draft-ietf-martini-reqs-01.txt</a><o:p></o:p></span>= </p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>The = MARTINI WG last call will last until Friday, March 5, 2010.<o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>Please = respond to this WG last call, whether you have comments or not.  If you = have no comments, please reply to this message and indicate in the body of your = message whether youthink the document is ready for consideration by the IESG or = not. If you have comments, please provide them to the WG in one of the following = ways: <o:p></o:p></span></p> <p class=3DMsoListParagraph = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt: auto;margin-left:21.0pt;text-indent:-.25in;mso-list:l0 level1 = lfo1'><![if !supportLists]><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><span style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span></span><![endif]><span = style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>If you have an account on the IETF Tools server, or can open one, please = login and enter your issue(s) in the MARTINI Issue tracking database (TRAC), which = is available here: <a = href=3D"http://trac.tools.ietf.org/wg/martini/trac/newticket">http://trac= .tools.ietf.org/wg/martini/trac/newticket</a> Note that if you submit an issue in TRAC, it will automatically also be = posted to the MARTINI WG mailing list. <o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New = Roman","serif"'> 2. If you don't have an account on the IETF Tools server, please post your Issue = to the MARTINI WG mailing list (martini at ietf.org) in the following format: = <o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Courier New"'>To:  martini = at ietf.org<o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Courier New"'>Subject: = Requirements-Issue: <title of your issue><o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Courier New"'>Priority: blocker, = critical, major, minor or trivial<o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Courier New"'><Explanation of = your issue, including a proposal for specific text changes to resolve the = issue><o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-family:"Courier = New"'><o:p> </o:p></span></p> </div> </body> </html> ------=_NextPart_000_0160_01CAB6E4.4A087F30-- From spencer@wonderhamster.org Fri Feb 26 14:17:47 2010 Return-Path: <spencer@wonderhamster.org> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E3E3A8875 for <martini@core3.amsl.com>; Fri, 26 Feb 2010 14:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.008, 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 bQ1S4WA0Z0iP for <martini@core3.amsl.com>; Fri, 26 Feb 2010 14:17:45 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A67A83A886A for <martini@ietf.org>; Fri, 26 Feb 2010 14:17:45 -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 0MQiRh-1OAfdw0kZx-00Ufpq; Fri, 26 Feb 2010 17:20:01 -0500 Message-ID: <AF4647416F284B059EF9C57722E8718A@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "Bernard Aboba" <bernard_aboba@hotmail.com>, "'MARTINI'" <martini@ietf.org> References: <blu137-ds1105B219C8F7A606992A95933F0@phx.gbl> Date: Fri, 26 Feb 2010 16:19:50 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0624_01CAB6FF.85B5CB80" 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: V01U2FsdGVkX18BjFmsSWw9BO+1bw30qF55/FbBg7X3uhyHvdU aa2X/WFlVSCdb+Waoy3nMnjyKLM6V5VijocoIBUbofFcgzKDPw /6EUKjxLo5rhk6GX6k5Mvk8xOahzuNNF8/yxSx2TU0= Subject: Re: [martini] REMINDER: MARTINI WG last call on the "Requirements"document X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 26 Feb 2010 22:17:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0624_01CAB6FF.85B5CB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To the working group... To Bernard's "prior to sending it on to the IESG for publication as an = Informational RFC", I might also add "prior to asking the working group = if we have consensus to adopt one of the protocol proposals as a working = group draft and expeditiously requesting that the IESG approve THAT = draft for publication as a Proposed Standard". We've already had some exchanges on the mailing list that included = statements like "but we don't have a requirement for that in the = requirements draft". I would like to head off as many statements of that = ilk as possible. We will converge more quickly if the requirements draft is complete and = accurate when we discuss protocol drafts. Thanks, Spencer, speaking as co-chair. ----- Original Message -----=20 From: Bernard Aboba=20 To: 'MARTINI'=20 Sent: Friday, February 26, 2010 3:04 PM Subject: [martini] REMINDER: MARTINI WG last call on the = "Requirements"document This is a reminder of an ongoing MARTINI WG Last Call on the = "Requirements" document, prior to sending it on to the IESG for = publication as an Informational RFC. The document is available for = inspection here:=20 http://tools.ietf.org/html/draft-ietf-martini-reqs-01.txt The MARTINI WG last call will last until Friday, March 5, 2010. Please respond to this WG last call, whether you have comments or not. = If you have no comments, please reply to this message and indicate in = the body of your message whether youthink the document is ready for = consideration by the IESG or not. If you have comments, please provide = them to the WG in one of the following ways:=20 1. If you have an account on the IETF Tools server, or can open = one, please login and enter your issue(s) in the MARTINI Issue tracking = database (TRAC), which is available here: = http://trac.tools.ietf.org/wg/martini/trac/newticket Note that if you = submit an issue in TRAC, it will automatically also be posted to the = MARTINI WG mailing list.=20 2. If you don't have an account on the IETF Tools server, please post = your Issue to the MARTINI WG mailing list (martini at ietf.org) in the = following format:=20 To: martini at ietf.org Subject: Requirements-Issue: <title of your issue> Priority: blocker, critical, major, minor or trivial <Explanation of your issue, including a proposal for specific text = changes to resolve the issue> =20 -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_0624_01CAB6FF.85B5CB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:x =3D=20 "urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20 "urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20 "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20 "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20 "urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b = =3D=20 "urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20 "urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20 "urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20 "urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20 "http://www.w3.org/TR/REC-html40" xmlns:q =3D=20 "http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc =3D=20 "http://microsoft.com/officenet/conferencing" XMLNS:D =3D "DAV:" = XMLNS:Repl =3D=20 "http://schemas.microsoft.com/repl/" xmlns:mt =3D=20 "http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2 =3D=20 "http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda =3D=20 "http://www.passport.com/NameSpace.xsd" xmlns:ois =3D=20 "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20 "http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20 "http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20 "http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20 "http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20 "http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20 "http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec = =3D=20 "http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20 "http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20 "http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20 "http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs =3D=20 "http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf =3D=20 "http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p =3D=20 "http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf =3D=20 "http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss =3D=20 "http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi =3D=20 "http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi =3D=20 "http://schemas.openxmlformats.org/package/2006/digital-signature" = xmlns:mver =3D=20 "http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = =3D=20 "http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20 "http://schemas.openxmlformats.org/package/2006/relationships" = xmlns:spwp =3D=20 "http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t =3D=20 "http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m = =3D=20 "http://schemas.microsoft.com/exchange/services/2006/messages" = xmlns:pptsl =3D=20 "http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl = =3D=20 "http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksSe= rvice"=20 XMLNS:Z =3D "urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18876"> <STYLE>@font-face { font-family: Cambria Math; } @font-face { font-family: Calibri; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; } P.MsoNormal { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: = 11pt } LI.MsoNormal { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: = 11pt } DIV.MsoNormal { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: = 11pt } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } P.MsoListParagraph { MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; = FONT-SIZE: 11pt; mso-style-priority: 34 } LI.MsoListParagraph { MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; = FONT-SIZE: 11pt; mso-style-priority: 34 } DIV.MsoListParagraph { MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; = FONT-SIZE: 11pt; mso-style-priority: 34 } SPAN.EmailStyle17 { FONT-FAMILY: "Calibri","sans-serif"; COLOR: windowtext; mso-style-type: = personal-compose } .MsoChpDefault { mso-style-type: export-only } DIV.Section1 { page: Section1 } OL { MARGIN-BOTTOM: 0in } UL { MARGIN-BOTTOM: 0in } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-US link=3Dblue bgColor=3D#ffffff vLink=3Dpurple> <DIV>To the working group...</DIV> <DIV> </DIV> <DIV>To Bernard's "prior to sending it on to the IESG for publication as = an=20 Informational RFC", I might also add "prior to asking the working group = if we=20 have consensus to adopt one of the protocol proposals as a working group = draft=20 and expeditiously requesting that the IESG approve THAT draft for=20 publication as a Proposed Standard".</DIV> <DIV> </DIV> <DIV>We've already had some exchanges on the mailing list that included=20 statements like "but we don't have a requirement for that in the = requirements=20 draft". I would like to head off as many statements of that ilk as=20 possible.</DIV> <DIV> </DIV> <DIV>We will converge more quickly if the requirements draft is complete = and=20 accurate when we discuss protocol drafts.</DIV> <DIV> </DIV> <DIV>Thanks,</DIV> <DIV> </DIV> <DIV>Spencer, speaking as co-chair.</DIV> <DIV><FONT face=3D"Times New Roman"></FONT> </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; = PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: = black"><B>From:</B>=20 <A title=3Dbernard_aboba@hotmail.com=20 href=3D"mailto:bernard_aboba@hotmail.com">Bernard Aboba</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dmartini@ietf.org = href=3D"mailto:martini@ietf.org">'MARTINI'</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, February 26, 2010 = 3:04=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [martini] REMINDER: = MARTINI WG=20 last call on the "Requirements"document</DIV> <DIV><BR></DIV> <DIV class=3DSection1> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 12pt">This = is a=20 reminder of an ongoing MARTINI WG Last Call on the "Requirements" = document,=20 prior to sending it on to the IESG for publication as an Informational = RFC.=20  The document is available for inspection here: = <o:p></o:p></SPAN></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 12pt"><A=20 = href=3D"http://tools.ietf.org/html/draft-ietf-martini-reqs-01.txt">http:/= /tools.ietf.org/html/draft-ietf-martini-reqs-01.txt</A><o:p></o:p></SPAN>= </P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 12pt">The = MARTINI WG=20 last call will last until Friday, March 5, 2010.<o:p></o:p></SPAN></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: = 12pt">Please respond=20 to this WG last call, whether you have comments or not.  If you = have no=20 comments, please reply to this message and indicate in the body of = your=20 message whether youthink the document is ready for consideration by = the IESG=20 or not. If you have comments, please provide them to the WG in one of = the=20 following ways: <o:p></o:p></SPAN></P> <P=20 style=3D"TEXT-INDENT: -0.25in; MARGIN-LEFT: 21pt; mso-margin-top-alt: = auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1"=20 class=3DMsoListParagraph><![if !supportLists]><SPAN=20 style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: = 12pt"><SPAN=20 style=3D"mso-list: Ignore">1.<SPAN=20 style=3D"FONT: 7pt 'Times New Roman'">     =20 </SPAN></SPAN></SPAN><![endif]><SPAN=20 style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 12pt">If = you have an=20 account on the IETF Tools server, or can open one, please login and = enter your=20 issue(s) in the MARTINI Issue tracking database (TRAC), which is = available=20 here: <A=20 = href=3D"http://trac.tools.ietf.org/wg/martini/trac/newticket">http://trac= .tools.ietf.org/wg/martini/trac/newticket</A>=20 Note that if you submit an issue in TRAC, it will automatically also = be posted=20 to the MARTINI WG mailing list. <o:p></o:p></SPAN></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: = 12pt"> 2. If=20 you don't have an account on the IETF Tools server, please post your = Issue to=20 the MARTINI WG mailing list (martini at ietf.org) in the following = format:=20 <o:p></o:p></SPAN></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 12pt">To:  = martini at=20 ietf.org<o:p></o:p></SPAN></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 12pt">Subject:=20 Requirements-Issue: <title of your issue><o:p></o:p></SPAN></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 12pt">Priority: = blocker,=20 critical, major, minor or trivial<o:p></o:p></SPAN></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 12pt"><Explanation = of your=20 issue, including a proposal for specific text changes to resolve the=20 issue><o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Courier = New'"><o:p> </o:p></SPAN></P></DIV> <P> <HR> <P></P>_______________________________________________<BR>martini = mailing=20 = list<BR>martini@ietf.org<BR>https://www.ietf.org/mailman/listinfo/martini= <BR></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0624_01CAB6FF.85B5CB80-- From bernard_aboba@hotmail.com Fri Feb 26 20:03:14 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E4A28C1B7 for <martini@core3.amsl.com>; Fri, 26 Feb 2010 20:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.558, 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 sCaIF1CjCXU1 for <martini@core3.amsl.com>; Fri, 26 Feb 2010 20:03:08 -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 6FC0B28C362 for <martini@ietf.org>; Fri, 26 Feb 2010 20:03:08 -0800 (PST) Received: from BLU137-DS11 ([65.55.111.73]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Feb 2010 20:05:25 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: <blu137-ds11A3CF838F97186AE35C47933E0@phx.gbl> From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: "'MARTINI'" <martini@ietf.org> Date: Fri, 26 Feb 2010 20:06:11 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C7_01CAB71F.248D4E30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqx8OuUhV84+L0ARaauciJ6BsBcpgFcMTiQ Content-Language: en-us X-OriginalArrivalTime: 27 Feb 2010 04:05:25.0381 (UTC) FILETIME=[16FC9350:01CAB762] Subject: [martini] REPOST: The MARTINI User's Guide to TRAC X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 27 Feb 2010 04:03:14 -0000 ------=_NextPart_000_01C7_01CAB71F.248D4E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The MARTINI WG uses the TRAC database to keep track of issues relating to work in progress, including working group work items and individual submissions undergoing review. This document provides some basic information on how MARTINI WG participants can use TRAC to submit or edit issues. Documentation relating to the TRAC Issue Tracking database is available here: http://trac.tools.ietf.org/wg/martini/trac/wiki Since this documentation is somewhat lengthy (and mostly relevant to Admins), here is a pithy synopsis. 1. To submit an issue in the MARTINI Issues database (known as TRAC), you first need to login to the MARTINI WG site on the tools server (http://tools.ietf.org/wg/martini/trac/login ) 2. If you don't already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http://trac.tools.ietf.org/wg/martini/trac/newticket 4. When opening an issue: a. The Type: field should be set to "defect" for an issue with the current document text, or "enhancement" for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically "minor" or "trivial". c. The Milestone: field should be set to milestone1 (useless, I know). d. The Component: field should be set to the document you are filing the issue on. Currently "Reqs" is the only available choice, since this is the only WG work item. e. The Version: field should be set to "1.0". f. The Severity: field should be set to based on the status of the document (e.g. "In WG Last Call" for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you. h. The Assign To: field is generally filled in with the email address of the editor. 5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select "I have files to attach to this ticket". 6. If you want to preview your Issue, click on the "Preview" button. When you're ready to submit the issue, click on the "Create Ticket" button. That's it! If you have an problems in dealing with TRAC, send email to me and I'll try to figure out what's going on. Happy TRACing, Bernard ------=_NextPart_000_01C7_01CAB71F.248D4E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:a=3D"urn:schemas-microsoft-com:office:access" = xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" = xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" = xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" = xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" = xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" = xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" = xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" = xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" = xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" = xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" = xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" = xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" = xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" = xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" = xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" = xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" = xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" = xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" = xmlns:udc=3D"http://schemas.microsoft.com/data/udc" = xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" = xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"= xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" = xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" = xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" = xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" = xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" = xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" = xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" = xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" = xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" = xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig= nature" = xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006= " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi= ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" = xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"= = xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag= es" = xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/= " = xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub= lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" = xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:478423222; mso-list-type:hybrid; mso-list-template-ids:-2125976136 67698713 67698713 67698715 67698703 = 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} @list l0:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1 {mso-list-id:1806116149; mso-list-type:hybrid; mso-list-template-ids:-1027539962 67698703 67698713 67698715 67698703 = 67698713 67698715 67698703 67698713 67698715;} @list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} @list l1:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l1:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span style=3D'color:black'>The MARTINI WG uses the = TRAC database to keep track of issues relating to work in progress, including working = group work items and individual submissions undergoing review. =    This document provides some basic information on how MARTINI WG participants can use = TRAC to submit or edit issues.  <o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'color:black'><o:p> </o:p></span></p> <p class=3DMsoNormal>Documentation relating to the TRAC Issue Tracking = database is available here:<o:p></o:p></p> <p class=3DMsoNormal><a = href=3D"http://trac.tools.ietf.org/wg/martini/trac/wiki">http://trac.tool= s.ietf.org/wg/martini/trac/wiki</a><o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Since this documentation is somewhat lengthy (and = mostly relevant to Admins), here is a pithy synopsis. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>To submit an issue in the MARTINI Issues = database (known as TRAC), you first need to login to the MARTINI WG site on the = tools server (<a = href=3D"http://tools.ietf.org/wg/martini/trac/login">http://tools.ietf.or= g/wg/martini/trac/login</a> ) <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>2.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>If you don’t already have a login ID, you = can obtain one by navigating to this site:   <a href=3D"http://trac.tools.ietf.org/newlogin">http://trac.tools.ietf.org/n= ewlogin</a><o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>3.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>Once you have obtained an account, and have = logged in, you can file an issue by navigating to the  ticket entry form: <a href=3D"http://trac.tools.ietf.org/wg/martini/trac/newticket">http://trac= .tools.ietf.org/wg/martini/trac/newticket</a><o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>4.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>When opening an issue:<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'><![if !supportLists]><span style=3D'mso-list:Ignore'>a.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>The Type: field should be set to = “defect” for an issue with the current document text, or “enhancement” for a = proposed addition of functionality (such as an additional requirement). <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'><![if !supportLists]><span style=3D'mso-list:Ignore'>b.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span><![endif]>The Priority: field is set based on the severity = of the Issue.   For example, editorial issues are typically = “minor” or “trivial”. <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'><![if !supportLists]><span style=3D'mso-list:Ignore'>c.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>The Milestone: field should be set to milestone1 (useless, I know). <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'><![if !supportLists]><span style=3D'mso-list:Ignore'>d.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span><![endif]>The Component: field should be set to the = document you are filing the issue on.  Currently “Reqs” is the only = available choice, since this is the only WG work item. <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'><![if !supportLists]><span style=3D'mso-list:Ignore'>e.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span><![endif]>The Version: field should be set to = “1.0”. <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'><![if !supportLists]><span style=3D'mso-list:Ignore'>f.<span style=3D'font:7.0pt "Times New = Roman"'>        </span></span><![endif]>The Severity: field should be set to based on = the status of the document (e.g. “In WG Last Call” for a = document in WG last call)<o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'><![if !supportLists]><span style=3D'mso-list:Ignore'>g.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]> The Keywords: and CC: fields can be left = blank unless inspiration seizes you. <o:p></o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo4'><![if !supportLists]><span style=3D'mso-list:Ignore'>h.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span><![endif]>The Assign To: field is generally filled in with = the email address of the editor. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>5.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>Typically it won’t be necessary to enclose = a file with the ticket, but if you need to, select “I have files to attach to = this ticket”. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 = level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>6.<span style=3D'font:7.0pt "Times New = Roman"'>       </span></span><![endif]>If you want to preview your Issue, click on the “Preview” button.  When you’re ready to submit = the issue, click on the “Create Ticket” button. <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>That’s it!  <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>If you have an problems in dealing with TRAC, send = email to me and I’ll try to figure out what’s going on. = <o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Happy TRACing,<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Bernard<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> </div> </body> </html> ------=_NextPart_000_01C7_01CAB71F.248D4E30-- From bernard_aboba@hotmail.com Fri Feb 26 20:09:26 2010 Return-Path: <bernard_aboba@hotmail.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F143A88B8 for <martini@core3.amsl.com>; Fri, 26 Feb 2010 20:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.554, 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 84EZIy2kc5uo for <martini@core3.amsl.com>; Fri, 26 Feb 2010 20:09:21 -0800 (PST) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by core3.amsl.com (Postfix) with ESMTP id 5C2F43A8504 for <martini@ietf.org>; Fri, 26 Feb 2010 20:09:21 -0800 (PST) Received: from BLU137-DS12 ([65.55.116.73]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Feb 2010 20:11:38 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: <BLU137-DS12C51770F99851B276DC99933E0@phx.gbl> From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: "'Bernard Aboba'" <bernard_aboba@hotmail.com>, "'MARTINI'" <martini@ietf.org> References: <blu137-ds1105B219C8F7A606992A95933F0@phx.gbl> In-Reply-To: <blu137-ds1105B219C8F7A606992A95933F0@phx.gbl> Date: Fri, 26 Feb 2010 20:12:24 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DE_01CAB720.02F1D4C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq3J1fp8PAUwYFERHKxF1wP0jVtOwAOy4aQ Content-Language: en-us X-OriginalArrivalTime: 27 Feb 2010 04:11:38.0402 (UTC) FILETIME=[F5531020:01CAB762] Subject: Re: [martini] REMINDER: MARTINI WG last call on the "Requirements" document (Approve) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 27 Feb 2010 04:09:26 -0000 ------=_NextPart_000_01DE_01CAB720.02F1D4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For my 2 pence (chair hat off), I believe that the "Requirements" document is ready to be sent off to the IESG for publication as an Informational RFC, with the exception of Issue #2 and some trivial NITs (Issue #1, already fixed). Since I approve of the document, neither issue should be considered binding. From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Friday, February 26, 2010 1:05 PM To: 'MARTINI' Subject: [martini] REMINDER: MARTINI WG last call on the "Requirements" document This is a reminder of an ongoing MARTINI WG Last Call on the "Requirements" document, prior to sending it on to the IESG for publication as an Informational RFC. The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-martini-reqs-01.txt The MARTINI WG last call will last until Friday, March 5, 2010. Please respond to this WG last call, whether you have comments or not. If you have no comments, please reply to this message and indicate in the body of your message whether youthink the document is ready for consideration by the IESG or not. If you have comments, please provide them to the WG in one of the following ways: 1. If you have an account on the IETF Tools server, or can open one, please login and enter your issue(s) in the MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. 2. If you don't have an account on the IETF Tools server, please post your Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format: To: martini at ietf.org Subject: Requirements-Issue: <title of your issue> Priority: blocker, critical, major, minor or trivial <Explanation of your issue, including a proposal for specific text changes to resolve the issue> ------=_NextPart_000_01DE_01CAB720.02F1D4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:a=3D"urn:schemas-microsoft-com:office:access" = xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" = xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" = xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" = xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" = xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" = xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" = xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" = xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" = xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" = xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" = xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" = xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" = xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" = xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" = xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" = xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" = xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" = xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" = xmlns:udc=3D"http://schemas.microsoft.com/data/udc" = xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" = xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"= xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" = xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" = xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" = xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" = xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" = xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" = xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" = xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" = xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" = xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig= nature" = xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006= " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi= ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" = xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"= = xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag= es" = xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/= " = xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub= lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" = xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:1117213359; mso-list-type:hybrid; mso-list-template-ids:-2040637184 -1958558062 67698713 67698715 = 67698703 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:21.0pt; text-indent:-.25in;} @list l0:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span style=3D'color:#1F497D'>For my 2 pence (chair = hat off), I believe that the “Requirements” document is ready to be = sent off to the IESG for publication as an Informational RFC, with the exception = of  Issue #2 and some trivial NITs (Issue #1, already fixed).  Since I = approve of the document, neither issue should be considered binding. = <o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in'> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Bernard = Aboba [mailto:bernard_aboba@hotmail.com] <br> <b>Sent:</b> Friday, February 26, 2010 1:05 PM<br> <b>To:</b> 'MARTINI'<br> <b>Subject:</b> [martini] REMINDER: MARTINI WG last call on the "Requirements" document<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>This is = a reminder of an ongoing MARTINI WG Last Call on the = "Requirements" document, prior to sending it on to the IESG for publication as an Informational = RFC.  The document is available for inspection here: = <o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><a href=3D"http://tools.ietf.org/html/draft-ietf-martini-reqs-01.txt">http:/= /tools.ietf.org/html/draft-ietf-martini-reqs-01.txt</a><o:p></o:p></span>= </p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>The = MARTINI WG last call will last until Friday, March 5, 2010.<o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>Please = respond to this WG last call, whether you have comments or not.  If you = have no comments, please reply to this message and indicate in the body of your = message whether youthink the document is ready for consideration by the IESG or = not. If you have comments, please provide them to the WG in one of the following = ways: <o:p></o:p></span></p> <p class=3DMsoListParagraph = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt: auto;margin-left:21.0pt;text-indent:-.25in;mso-list:l0 level1 = lfo2'><![if !supportLists]><span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><span style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times New = Roman"'>      </span></span></span><![endif]><span = style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>If you have an account on the IETF Tools server, or can open one, please = login and enter your issue(s) in the MARTINI Issue tracking database (TRAC), which = is available here: <a = href=3D"http://trac.tools.ietf.org/wg/martini/trac/newticket">http://trac= .tools.ietf.org/wg/martini/trac/newticket</a> Note that if you submit an issue in TRAC, it will automatically also be = posted to the MARTINI WG mailing list. <o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Times New = Roman","serif"'> 2. If you don't have an account on the IETF Tools server, please post your Issue = to the MARTINI WG mailing list (martini at ietf.org) in the following format: = <o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Courier New"'>To:  martini = at ietf.org<o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Courier New"'>Subject: = Requirements-Issue: <title of your issue><o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Courier New"'>Priority: blocker, = critical, major, minor or trivial<o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:12.0pt;font-family:"Courier New"'><Explanation of = your issue, including a proposal for specific text changes to resolve the = issue><o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'font-family:"Courier = New"'><o:p> </o:p></span></p> </div> </body> </html> ------=_NextPart_000_01DE_01CAB720.02F1D4C0-- From BLINDSAY@nortel.com Sun Feb 28 12:52:28 2010 Return-Path: <BLINDSAY@nortel.com> X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4593128C1C7 for <martini@core3.amsl.com>; Sun, 28 Feb 2010 12:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.14 X-Spam-Level: X-Spam-Status: No, score=-4.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duNYua9h32Lp for <martini@core3.amsl.com>; Sun, 28 Feb 2010 12:52:27 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B66BC28C18D for <martini@ietf.org>; Sun, 28 Feb 2010 12:52:26 -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 o1SKpeK26252; Sun, 28 Feb 2010 20:51:40 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: Sun, 28 Feb 2010 15:51:31 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141CB5DF53@zcarhxm1.corp.nortel.com> In-Reply-To: <008201cab70e$0d82c6e0$010c030a@CORPORATE.VOX.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Middlebox needs - admitting inbound requests Thread-Index: Acq3DhVedCe9ueLhSy6la+jrT0lQfwBp1v2w References: <C7AC4291.14C39%adam@nostrum.com><99BF4620352B4F9C9E090F9004C31924@china.huawei.com><4B86F875.6070902@nostrum.com><00b101cab66c$3ce34150$430510ac@CORPORATE.VOX.NET><09B7DBFE70A9E24BBB21689DAD3A06141CB0F52A@zcarhxm1.corp.nortel.com> <00ca01cab67a$7fd21460$430510ac@CORPORATE.VOX.NET> <A444A0F8084434499206E78C106220CABBB22E97@MCHP058A.global-ad.net> <000901cab6f5$968a9df0$010c030a@CORPORATE.VOX.NET> <A444A0F8084434499206E78C106220CABBB232D7@MCHP058A.global-ad.net> <008201cab70e$0d82c6e0$010c030a@CORPORATE.VOX.NET> From: "Brian Lindsay" <blindsay@nortel.com> To: "Tyler Parkin" <tyler@foxfam.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Adam Roach" <adam@nostrum.com>, "Spencer Dawkins" <spencer@wonderhamster.org> Cc: Bernard Aboba <bernard_aboba@hotmail.com>, MARTINI <martini@ietf.org> Subject: Re: [martini] Middlebox needs - admitting inbound requests X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/martini> List-Post: <mailto:martini@ietf.org> List-Help: <mailto:martini-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 28 Feb 2010 20:52:28 -0000 Hi Tyler, I believe some SBCs that "NAT" as you describe would (or could) use a unique port on the northbound side per registered entity. So the SBC would be able to maintain a mapping from the client-side contact/routing info to a unique northbound address/port that it would receive requests on (for requests towards the SIP PBX). In this case, there shouldn't be any problems routing the request. Also, I think the MARTINI-Shaken approach wouldn't have a problem in this case either, since the domain portion of the request uri (from the "SSP") contains a domain name representing the enterprise/PBX, rather than an IP address derived from the contact. Thanks Brian -----Original Message----- From: Tyler Parkin [mailto:tyler@foxfam.com]=20 Sent: Friday, February 26, 2010 1:04 PM To: Elwell, John; Lindsay, Brian (CAR:AR00); Adam Roach; Spencer Dawkins Cc: Bernard Aboba; MARTINI Subject: Re: [martini] Middlebox needs - admitting inbound requests > ----- Original Message ----- > From: "Elwell, John" <john.elwell@siemens-enterprise.com> > To: "Tyler Parkin" <tyler@foxfam.com>; "Brian Lindsay" > <blindsay@nortel.com>; "Adam Roach" <adam@nostrum.com>; "Spencer=20 > Dawkins" > <spencer@wonderhamster.org> > Cc: "Bernard Aboba" <bernard_aboba@hotmail.com>; "MARTINI" > <martini@ietf.org> > Sent: Friday, February 26, 2010 5:34 AM > Subject: RE: [martini] Middlebox needs - admitting inbound requests > > > Tyler, > > I found this thread a little mixed up between outbound requests from=20 > the PBX and inbound requests to the PBX, so I am not sure I=20 > understood everything. > [tyler] sorry for the confusion, I think we're looking at it in=20 > different directions... inbound to me is inbound to the SSP, where to=20 > you inbound is to the PBX. I guess we'll stick w/ inbound =3D to the=20 > PBX > > As far as inbound request are concerned, I think with gin-01 the=20 > problems you raise should be solvable, but it perhaps requires use of=20 > Proxy-Require, as already discussed. The middlebox does not need to=20 > know exactly which E.164s are implicitly registered, but when it gets=20 > a request to the PBX's IP address (presumably with Route indicating=20 > the IP address of the middlebox) it should assume the E.164 in the=20 > user part is indeed a registered AOR. > [tyler] my point is that the middlebox doesn't get a request to the=20 > PBX's IP address. [JRE] Why not? If the Contact URI contains the IP address (as in gin-01), this will be registered at the registrar and will be returned as the target of an inbound request to the PBX. > The softswitch/registrar generating the call doesn't know the PBX's IP > because it was masked during the initial registration. [JRE] Why would it be masked? I understand that the registrar would not see the IP address at the transport level from which the REGISTER request arrived at the middlebox, but it would see the IP address in the Contact URI. [Tyler] In most scenarios where a middlebox (aka SBC) exists, the SBC performs two-way NAT functions, and NAT's the headers/URI's for inbound and outbound messaging. Therefore, a request received on the public side from user@PBXIP is sent to the registrar as user@SBCPRIVATEIP. The oposite direction (SSP -> PBX) is received by the SBC as user@SSPIP and NAT'd to user@SBCPUBLICIP. > Any > requests from from the registrar/softswitch to the middlebox (destined > for the PBX) will only have user@middlebox, perhaps w/ a cookie. > The middelbox > needs to map user@middlebox to whatever IP/host originally registered. > Today, the middlebox keeps a cache where the initial (individual)=20 > registration might be user@1.1.1.1, and the registration forwarded to=20 > the registrar is user@2.2.2.2. That way when the registrar sends a=20 > request to the middlebox for user@2.2.2.2 it maps it to user@1.1.1.1=20 > and all is good. > If the middelbox doesn't have knowledge of the user (because of=20 > implicit), [JRE] Are you suggesting that each user behind the PBX would register with a different IP address, so you need to know whether it is user1 or user2 in order to send requests to 11.11.11.11 or 22.22.22.22? If so, that is not the scenario that MARTINI is addressing. MARTINI is addressing the case where requests to user1, user2 etc. on a given PBX all need to be routed to the PBX's IP address. So as long as the middlebox knows the request needs to go to the PBX, it doesn't need to know that particular user. [Tyler] Agreed, I shouldn't have used the term user. The middlebox in this scenario wouldn't care about individual users, it's point of contact is the PBX. All PBX's send register requests to the middlebox from different IP's/domains, granted. After NAT, however, all the requests from the SBC to the registrar appear to come from the same IP. We NAT in both directions, which is pretty standard, so we don't expose core equipment to the public, and we don't expose end user IP's to peers. Plus it allows virtual route tables internally and resolves any issues with overlapping address space. > it can't make the mapping unless it has something else to associate to > the original implicit reg (like a cookie, or knowledge of the=20 > extensions). > > Now concerning outbound requests (this was what my earlier message was > about, although somewhere further back that got brought across to this > thread rather than the thread concerning outbound requests, so the=20 > thread title was wrong). Assuming an entity has knowledge of=20 > registered E.164 numbers, it is not clear to me how it would deal with > a request where the From/PAI in the request from the PBX is not one of > the implicitly registered ones. This can arise, for example, if the=20 > request originates elsewhere in the enterprise and "breaks out" to the > SSP via this particular PBX. Or if the call originated elsewhere and=20 > was forwarded by the PBX to the SSP. I appreciate that there may be=20 > some arrangements between PBX and SSP where this is forbidden by=20 > policy, but in the general case I would expect it to work, so that the > callee has a correct AOR to which it can make a return call. > [tyler] methods dealing with this situation today (A calls B, B=20 > forwards the call to C) would use from=3DA and PAI=3DB, where B is a=20 > registered endpoint (and billable by the SSP). Not sure if that's=20 > what you're asking? [JRE] Yes, that was what I was asking, and I know that it sometimes works the way you describe, but this is bad because PAI=3DB is wrong - = it is not compliant with RFC 3325, since it is not the source of the request. If the callee used that to make a return call, the return call would arrive at the wrong place. For example, if a customer calls me on my office number and the PBX forwards it to my home via the SSP, if my phone stores the PAI as the caller's number and I try to make a return call, the return call goes to my office phone, not to my customer. [Tyler] The source of the forward leg of the call is B, not A. Calling area requirements and n11 need to be based on B. Why would the callee use PAI to return a call? That would be in violation of 3325 as well since it would obviate any callerid blocking/suppression requirements. I guess whether the PBX should strip PAI before sending it to your phone is arguable. Agreed, using PAI to assert a different ID than From (where from isn't private) might not strictly adhere to 3325, but I think alternate ID's vs suppressed ID's is splitting hairs a little. John=20