Subject: [martini] Implications of multiple AOR/contact mapping

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 1 Feb 2010 13:07:57 -0800

Why couldn't this approach also be used to register sip:[email-masked]
and map it to sip:[email-masked] or sip:[email-masked] ?

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

---

From: Dean Willis <[email-masked]>
Date: Mon, 1 Feb 2010 19:45:04 -0600

On Feb 1, 2010, at 3:07 PM, Bernard Aboba wrote:

> Why couldn’t this approach also be used to register sip:[email-masked] 
>  and map it tosip:[email-masked] or sip:[email-masked] ?
>

Yes, I think this could work: You would have a To: of "sip:[email-masked] 
" and a Contact of "sip:[email-masked]".

It requires that PBX know how to remap its own users to  @ssp.com  
domain users.

--
Dean

---

From: Doug Sauder <[email-masked]>
Date: Tue, 2 Feb 2010 05:15:32 -0500

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:

>> Why couldn’t this approach also be used to register sip:[email-masked] and map it tosip:[email-masked] or sip:[email-masked] ?
>> 
> Yes, I think this could work: You would have a To: of "sip:[email-masked]" and a Contact of "sip:[email-masked]".
> 
> It requires that PBX know how to remap its own users to  @ssp.com domain users.
> 
> 
> --
> Dean
> 
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: "Jack Burton" <[email-masked]>
Date: Tue, 02 Feb 2010 06:02:43 -0500

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
[email-masked] 
516-803-9733

>>> Doug Sauder <[email-masked]> 2/2/2010 10:15 >>>
Dean,

--
Doug

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

---

From: Chris Gatch <[email-masked]>
Date: Tue, 2 Feb 2010 07:22:33 -0500

> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Jack Burton
Sent: Tuesday, February 02, 2010 6:03 AM
To: Doug Sauder; Dean Willis
Cc: Bernard Aboba; [email-masked]
Subject: Re: [martini] Implications of multiple AOR/contact mapping

Doug,

-Jack

Jack Burton
Dir. Systems Engineering
Cablevision
[email-masked]
516-803-9733

Dean,

--
Doug

---

From: "Jack Burton" <[email-masked]>
Date: Tue, 02 Feb 2010 08:22:20 -0500

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 <[email-masked]> 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:[email-masked] [mailto:[email-masked]] On
Behalf Of Jack Burton

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
[email-masked] 
516-803-9733

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

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

---

From: Doug Sauder <[email-masked]>
Date: Tue, 2 Feb 2010 08:25:47 -0500

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

---

From: "Jack Burton" <[email-masked]>
Date: Tue, 02 Feb 2010 08:41:54 -0500

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 <[email-masked]> 2/2/2010 13:25 >>>

--
Doug

Doug,

 
 
-Jack

Jack Burton
Dir. Systems Engineering
Cablevision
[email-masked] 
516-803-9733

Dean,

--
Doug

---

From: Chris Gatch <[email-masked]>
Date: Tue, 2 Feb 2010 09:27:39 -0500

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 provisioning related data from the SSP to the PBX, but that is clearly out of scope 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 provisioning data, and this is supported on a couple of PBXs.  That being said, there are many ways to handle this, and the value is in the agreement among 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 identify the IP-PBX to the SSP.

-Jack

>>> Chris Gatch <[email-masked]<mailto:[email-masked]>> 2/2/2010 12:22 >>>

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

Doug,

-Jack

Jack Burton
Dir. Systems Engineering
Cablevision
[email-masked]<mailto:[email-masked]>
516-803-9733

>>> Doug Sauder <[email-masked]<mailto:[email-masked]>> 2/2/2010 10:15 >>>
Dean,

--
Doug

--------------------------------------------------------
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.
--------------------------------------------------------<ATT00001..txt>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Feb 2010 16:04:39 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jack Burton
> Sent: 02 February 2010 13:42
> To: Doug Sauder
> Cc: [email-masked]
> 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.
[JRE] I agree. A single AOR in the REGISTER request should be sufficient to cover the needs of MARTINI.

John

> 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.
> 
> 	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
> 	[email-masked]
> 	516-803-9733
> 	
> 	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
> 	
> 	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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 12:32:13 -0500

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:
> 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.
> 
>> 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.
>>  
>> [email-masked] <mailto:[email-masked]>
>> 516-803-9733
>>
>> 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.
>>
>> 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, 
>> 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.
> ------------------------------------------------------------------------
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Feb 2010 23:25:51 -0600

On Feb 2, 2010, at 4:15 AM, Doug Sauder wrote:

> deployment, but I believe it's where the SMB-market service  
> providers want to go.
>
> 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 <[email-masked]>
Date: Thu, 4 Feb 2010 23:29:20 -0600

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 <[email-masked]>
Date: Thu, 4 Feb 2010 23:30:04 -0600

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: "Elwell, John" <[email-masked]>
Date: Fri, 5 Feb 2010 10:18:03 +0100

See gin-00.

John 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 05 February 2010 05:30
> To: Elwell, John
> Cc: Jack Burton; Doug Sauder; [email-masked]

---

From: "Tyler Parkin" <[email-masked]>
Date: Fri, 5 Feb 2010 08:47:21 -0500

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" <[email-masked]>
To: "Jack Burton" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 05, 2010 12:29 AM
Subject: Re: [martini] Implications of multiple AOR/contact mapping

> 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: Adam Roach <[email-masked]>
Date: Fri, 05 Feb 2010 09:13:58 -0600

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:
> 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.
>
> 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" 
> <[email-masked]>
>>> I am not counting on registration as a configuration tool, just as 
>>> a  way to authenticate and identify the IP-PBX to the SSP.
>>>
>>
>> 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: "Tyler Parkin" <[email-masked]>
Date: Fri, 5 Feb 2010 11:18:44 -0500

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" <[email-masked]>
To: "Tyler Parkin" <[email-masked]>
Cc: "Dean Willis" <[email-masked]>; "Jack Burton" 
<[email-masked]>; <[email-masked]>
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
>
>> 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.
>>
>> 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.
>>
>>>> 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.
>>>>
>>>
>>> them already so it can register them and so the SSP knows what IP

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 5 Feb 2010 11:59:29 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Friday, February 05, 2010 10:14 AM
To: Tyler Parkin
Cc: [email-masked]
Subject: Re: [martini] Implications of multiple AOR/contact mapping

Tyler:

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Feb 2010 11:02:07 -0600

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?
>
> 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: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Feb 2010 12:23:49 -0500

> override that model, nor do I think it's a good idea to do so.

amen

> useless operation. I would propose that we put a "don't do that, then" 

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 Parkin" <[email-masked]>
Date: Fri, 5 Feb 2010 12:30:27 -0500

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