Subject: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 14:02:31 -0400

Howdy,
The discussion about limiting the scope of the current Martini work to E.164's raises an issue that is a bit concerning.  We have now heard from several folks that one issue with [draft-gin] is that it does not cover as many use-cases as other mechanisms.  Essentially the question is whether our requirements list is correct.

While we had consensus that E.164 formats were our scope, because we mostly see those in daily life, if other mechanisms claim to support more then Martini, we have a problem.  Lots of SSP's and Enterprises (the actual customers!) do not attend the IETF, and do not have time to go through mailing list archives, or RFCs, etc.  They will pay attention to whatever powerpoint slides the marketing folks generate, and the perception will be that Martini is not as generally useful as something else.

It doesn't matter what the technical details are, nor what the Opex cost differences will ultimately be.  It's a perception problem.

Therefore, if folks are interested, I have submitted an I-D which is part-1 of a two-part draft set to try to address the "other" use cases.

Part-1 (draft-olive) linked below is to address any AoR of the registered-to SSP's domain.  This follows [draft-gin] pretty tightly.  

Any comments/flames/concerns are appreciated.
If people want this type of thing, then we could put the olive in the gin for a better martini.

-hadriel

A New Internet-Draft is available from the on-line Internet-Drafts directories.
	Title           : SIP MARTINI with Other Logical Identifier Values which are not E.164 (OLIVE)
	Author(s)       : H. Kaplan
	Filename        : draft-kaplan-martini-with-olive-00.txt
	Pages           : 17
	Date            : 2010-04-08

The Martini Working Group is defining a mechanism for SIP IP-PBX type devices to REGISTER and obtain SIP service for E.164-based Address of Records.  This document defines a means for other, non-
E.164 AoRs to be used with Martini-based IP-PBXs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-martini-with-olive-00.txt

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 19:41:20 -0400

Hadriel,

You have been busy!

I quickly read this, and I think there is a lot to like here, though I 
definitely need to think about it further.

One thing that is definitely bothering me is the removal of the 
phone-context from local numbers when it matches the ssp's domain. I 
don't like the resulting number without a phone context for reasons that 
are to some extent still subliminal.

For one, in the degenerate case where there are no other user 
parameters, this is ambiguous with an "email-style" address that happens 
to be all numeric.

Is there some reason not to leave the ssp domain name in the 
phone-context in this case?

I was also worried about the reg event package, but you already 
identified that as a potential issue.

Nevertheless, I think potentially this direction might bear fruit.

	Thanks,
	Paul

Hadriel Kaplan wrote:
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 21:40:40 -0400

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 7:41 PM
> To: Hadriel Kaplan
> 

Right, so Local-Numbers are rather tricky/ugly in practice, as far as I can tell.  But I'm also not sure how much of what I see in the field is "normal" vs. just the error cases my product has to go fix to/from, which could well also be abnormal cases altogether. (so my impression could be way off)

Anyway, afaict, when the phone-context is something like ssp.com (which is not often), then the IP-PBX has no idea about that phone-context, and the URI is modified to strip it or change it on its way to the IP-PBX.  Because when it's the SSP's domain it's basically the SSP's private numbers, which an IP-PBX may just happen to be in the private-dialing plan for (unbeknownst to it).

I guess the real question is what does the IP-PBX expect to see?

> parameters, this is ambiguous with an "email-style" address that happens

Good point. 

> identified that as a potential issue.

Yeah, but in talking with Adam Roach about this concept earlier today, he thought we wouldn't need to have it in reg-event, because ultimately its not really an AoR you could get meaningful info for (and is private as well) so we could just say the Local-Number ones don't apply for reg-event. 

> Nevertheless, I think potentially this direction might bear fruit.

Cool!
Also, Adam suggested I put back into the draft how this would work for a phone-context of an E.164 (which was in a previous incarnation of the draft). 

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Apr 2010 11:53:11 +0200

Hadriel,

Thanks for writing this up. I like the direction this is heading, but I am not sure this really addresses the full population of use cases that we might like to cover at some stage.

One concern is email-style AORs based on the SSP's domain. This might work for some enterprises. What it means is a lack of portability. For example, if I agree with ssp1.example.com that I can use sip:[email-masked], it is quite likely that if I try to move to ssp2.example.com, bob will not be available. I look forward to your planned further draft on the subject of using the enterprise domain name.

Another concern is whether non-E.164 numbers based on phone-context of domain name is sufficiently widespread. In fact I don't have much knowledge of deployments based on non-E.164 numbers (excluding things like national numbers, which can be expanded to fully-qualified E.164 numbers). For use in the scenarios you describe, do people use domain- or E.164-based phone-contexts? I note your intention to give further consideration to E.164-based phone-contexts.

So basically, I see this as useful material on how gin could be extended in future to accommodate a broader range of AOR types. I am not sure that we necessarily need to include these in the initial gin deliverable, but by being aware of such future extensions we could at least ensure that we don't build anything into gin that rules this out.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 08 April 2010 19:03
> To: [email-masked]
> Subject: [martini] Other AoR's than E.164: 
> draft-kaplan-martini-with-olive-00
> 
> 
> Howdy,
> The discussion about limiting the scope of the current 
> Martini work to E.164's raises an issue that is a bit 
> concerning.  We have now heard from several folks that one 
> issue with [draft-gin] is that it does not cover as many 
> use-cases as other mechanisms.  Essentially the question is 
> whether our requirements list is correct.
> 
> While we had consensus that E.164 formats were our scope, 
> because we mostly see those in daily life, if other 
> mechanisms claim to support more then Martini, we have a 
> problem.  Lots of SSP's and Enterprises (the actual 
> customers!) do not attend the IETF, and do not have time to 
> go through mailing list archives, or RFCs, etc.  They will 
> pay attention to whatever powerpoint slides the marketing 
> folks generate, and the perception will be that Martini is 
> not as generally useful as something else.
> 
> It doesn't matter what the technical details are, nor what 
> the Opex cost differences will ultimately be.  It's a 
> perception problem.
> 
> Therefore, if folks are interested, I have submitted an I-D 
> which is part-1 of a two-part draft set to try to address the 
> "other" use cases.
> 
> Part-1 (draft-olive) linked below is to address any AoR of 
> the registered-to SSP's domain.  This follows [draft-gin] 
> pretty tightly.  
> 
> 	Title           : SIP MARTINI with Other Logical 
> Identifier Values which are not E.164 (OLIVE)
> 	Author(s)       : H. Kaplan
> The Martini Working Group is defining a mechanism for SIP 
> IP-PBX type devices to REGISTER and obtain SIP service for 
> E.164-based Address of Records.  This document defines a 
> means for other, non-

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 9 Apr 2010 12:51:52 +0200

Hi Hadriel,

I'm impressed by how fast you create drafts ;-)

Still have concerns about being forced to do Request-URI replacement and
then having to fix things to make it work. An olive unfortunately does not
help in preventing a headache the day after.

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 8:02 PM, Hadriel Kaplan <[email-masked]>wrote:

>
> Howdy,
> The discussion about limiting the scope of the current Martini work to
> E.164's raises an issue that is a bit concerning.  We have now heard from
> several folks that one issue with [draft-gin] is that it does not cover as
> many use-cases as other mechanisms.  Essentially the question is whether our
> requirements list is correct.
>
> While we had consensus that E.164 formats were our scope, because we mostly
> see those in daily life, if other mechanisms claim to support more then
> Martini, we have a problem.  Lots of SSP's and Enterprises (the actual
> customers!) do not attend the IETF, and do not have time to go through
> mailing list archives, or RFCs, etc.  They will pay attention to whatever
> powerpoint slides the marketing folks generate, and the perception will be
> that Martini is not as generally useful as something else.
>
> It doesn't matter what the technical details are, nor what the Opex cost
> differences will ultimately be.  It's a perception problem.
>
> Therefore, if folks are interested, I have submitted an I-D which is part-1
> of a two-part draft set to try to address the "other" use cases.
>
> Part-1 (draft-olive) linked below is to address any AoR of the
> registered-to SSP's domain.  This follows [draft-gin] pretty tightly.
>
> The Martini Working Group is defining a mechanism for SIP IP-PBX type
> devices to REGISTER and obtain SIP service for E.164-based Address of
> Records.  This document defines a means for other, non-

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Apr 2010 09:13:28 -0400

> I guess the real question is what does the IP-PBX expect to see?

I get your point about the pbx not understanding the ssp's phone context.

Since the context "belongs to" the ssp (and the URI does too because of 
the domain), the ssp is free to translate to anything it wants. The 
trick is to have a clear understanding between it and the pbx of what 
that will be. The simple, answer is that it can be anything that the 
service agreement between the pbx and the ssp says it will be. But 
that's not a very good path to consistent interoperability. I don't have 
a great answer here for the moment.

Of course for local numbers to be useful, they will have to work in both 
directions. We have been avoiding that discussion, but maybe we need to 
have it. That might also also tie in with how to represent certain non 
E.164 numbers that have to go from the pbx to the ssp, such as service 
numbers. (0, 411, 911, etc.) IMO there are only a couple of rational 
choices for those: user=dialstring or local number syntax. (E.g. 
911;phone-context=+1) Perhaps that suggests doing something more 
specific about certain local number forms. And then maybe that would 
help in addressing the more general local number issues.

> Yeah, but in talking with Adam Roach about this concept earlier today, he thought we wouldn't need to have it in reg-event, because ultimately its not really an AoR you could get meaningful info fo…

When we are talking about the reg event package as "the" way of 
determining what your implicit registration actually yielded, I consider 
it a problem if the reg event package can't report on some of the 
numbers that have been enabled by the registration.

> Also, Adam suggested I put back into the draft how this would work for a phone-context of an E.164 (which was in a previous incarnation of the draft). 

Since I don't know what it said, I won't comment on whether I want you 
to put it back. :-)

But I agree it could be worth saying *something* about it (as I alluded 
above) as long as we find the *right* thing to say.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Apr 2010 10:14:29 -0400

> From: Elwell, John [mailto:[email-masked]]
> Sent: Friday, April 09, 2010 5:53 AM
> 
> Thanks for writing this up. I like the direction this is heading, but I am
> not sure this really addresses the full population of use cases that we
> might like to cover at some stage.

That's coming in another draft (Part-2), which I wanted to separate from Olive becaue I thought it would be more contentious and it will use a different mechanism.

> Another concern is whether non-E.164 numbers based on phone-context of
> domain name is sufficiently widespread. In fact I don't have much
> knowledge of deployments based on non-E.164 numbers (excluding things like
> national numbers, which can be expanded to fully-qualified E.164 numbers).
> For use in the scenarios you describe, do people use domain- or E.164-
> based phone-contexts? I note your intention to give further consideration
> to E.164-based phone-contexts.

I had E.164-based local-numbers in an earlier private rev of the draft, but pulled it at the last minute because it (1) had problems with reg-event, and (2) it seemed like a similar problem as user@domain where the domain isn't under the SSP's authority, because the E.164 phone-context effectively makes its scope/knowledge/authority to be the E.164 not the SSP.
But I'm putting it back in in the next rev of the Olive draft.
 
> So basically, I see this as useful material on how gin could be extended
> in future to accommodate a broader range of AOR types. I am not sure that
> we necessarily need to include these in the initial gin deliverable, but
> by being aware of such future extensions we could at least ensure that we
> don't build anything into gin that rules this out.

The big question of whether it belongs in GIN or separate, in my mind, is: assume draft-gin by itself gets published, and at some later date Olive is published; would Olive require another option-tag, or can it simply use the draft-gin as is?  If it requires another option-tag again, or updates GIN in some way, then I'd say let's just stick it in GIN; if can stand alone as an informational then I'd say keep it separate.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 12:02:37 -0400

> Sent: Friday, April 09, 2010 9:13 AM
> 

Right, when the phone-context is the SSP's domain, it effectively means it's a local-number to the SSP, which is only meaningful to it, and only it has knowledge of how to handle.

In my simple caveman brain, draft-gin is effectively just a bulk registration mechanism, as if the PBX had really registered for each AoR separately.  So what AoR would the PBX register to for the local-number "12345;ext=678;phone-context=ssp.com"?

I *think* the actual answer is it would have registered for "sip: 12345;ext=678;phone-context=[email-masked]".  If that's true, draft-olive is currently wrong.  It should set the contact to "sip: 12345;ext=678;phone-context=[email-masked]".

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 12:29:59 -0400

> have it. 

There be dragons. :)
One of the problems with local-numbers is the device which actually knows what context it's in is sometimes not the PBX, and sometimes is the PBX.
In practice I know there are times when the ingress proxy of the SSP is the one which does it, but I think that from a spec and architectural model the PBX should be the one which inserts a phone-context.

> That might also also tie in with how to represent certain non
> specific about certain local number forms. 

In practice it seems to me that the user=dialstring param isn't used much.  If the request-uri is "sip:[email-masked]", it's handled as a dialed phone number of "411" regardless of a user=dialstring.  SSP's just don't allocate "411" as a username to some random SIP subscriber.  I would argue that's true for all service numbers, including "911" - you can send a sos URN or a user=dialstring param, but it's not like they're going to give the AoR of "sip:[email-masked]" to some random subscriber anyway, so it's not ambiguous in practice.  There's no real interop problem to solve, afaict.

If we *were* to specify a dialstring, then it would need a phone-context anyway (per rfc4967), and in my opinion that phone-context should be "ssp.com", ironically.

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 12 Apr 2010 11:37:59 +0200

On Sat, Apr 10, 2010 at 6:02 PM, Hadriel Kaplan <[email-masked]>wrote:

> In my simple caveman brain, draft-gin is effectively just a bulk
> registration mechanism, as if the PBX had really registered for each AoR
> separately.  So what AoR would the PBX register to for the local-number
> "12345;ext=678;phone-context=ssp.com"?
>
> I *think* the actual answer is it would have registered for "sip:
> 12345;ext=678;phone-context=[email-masked]".  If that's true, draft-olive
> is currently wrong.  It should set the contact to "sip:
> 12345;ext=678;phone-context=[email-masked]".
>
> Is it me being a Neanderthaler, or is this just a strange example?

The more natural case would be where "12345;ext=678;phone-context=
martini-enterprise.com" is passed unmodified to the pbx handling this number
and which belongs to martini-enterprise.

/Hans Erik

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 12 Apr 2010 12:21:29 +0200

We need to be careful here that we are not running before we can walk.

Yes I want to handle different numbers, more specifically private network numbers, but we do need to understand how they will be used in the SSP before we start writing protocol requirements.

The ETSI/3GPP model for this work was that the SSP could undertake to provide various logical entities within it's own equipment to support the enterprise. So where Centrex is provided (or hosted enterprise services in the ETSI terminology) essentially a logical PBX is hosted by the SSP. Nominally the enterprise is responsible for this logical entity, and the SSP manages it on behalf of the enteprise. It is part of the enterprise, and therefore it should be able to handle anything a physically provided IP-PBX can handle, including the numbering / addressing plans of the enterprise.

If I want to connect two IP-PBX together in the same enterprise, then I can the option of establishing a direct IP connection between them, with all the QoS and numbering / addressing handling of the enterprise handled provided over this, in the same way as in the PSTN I can buy a tie line, or I can use the SSP to provide public network services to connect the two, in which case I am tied to the QoS and other capabilities provided by the SSP, including the numbering and addressing plans supported by the SSP (and which must be globally unique within the SSP).

In particular, as an inheritance of what has been done with the use of numbers in the past, a separate numbering plan probably exists in the enterprise, such that 777 1234 is a valid number within the enterprise, but would of course be meaningless outside the context of that enteprise. While some digits may correspond to an equivalent E.l64 number, e.g. +1 555 999 1234, that is not a fixed requirement.

So what happens if I want to connect two Centrex installations together. Yes I can always use the services of the SSP in which it is resident to connect the two together, in which case we are still tied to the QoS and other capabilities provided by the SSP, including the numbering and addressing plans supported by the SSP (and which must be globally unique within the SSP). Or I can negotiate a deal with the SSP that essentially for signalling purposes requires them to simulate what I would get from that direct IP connection (with all the QoS and numbering / addressing handling of the enterprise handled provided over this). The ETSI / 3GPP model provides for this, and the work in:

https://datatracker.ietf.org/doc/draft-vanelburg-dispatch-private-network-ind/

provides a tag for implementing identifying such traffic, such that it is handled according to the rules of the enterprise (which have of course been agreed with the SSP), rather than the rules of the SSP directly. It is within this context that the numbering / addressing plan of the enterprise can be used. Thus within IMS tel:1234;phone-context=enterprise.com can have meaning when it appears in a SIP message that contains the header field P-Private-Network-Indication:enterprise.com, but would probably not have meaning when such a header field is missing.

There is no need for this tag where it is known that the traffic is 100% belonging to the enterprise. So a UA registering with a registrar function within the Centrex environment, and sending and receiving traffic between the UA and outbound proxies / registrars within that Centrex environment, do not need this tag.

So that deals with two logical PBXs, i.e. Centrex connected. What happens if one is Centrex and one is a physically provided IP-PBX. Yes we should still be able to do the things we have been doing.

The PBX needs to "register" its private network numbers in the SSP location server. In the IMS model, this is performed implicitly, so there are no domain name issues here.

Incoming calls with the P-Private-Network-Indication: enterprise.com can assume the numbering / addressing plan of the enterprise, which would normally have a phone-context of enterprise.com, or some subdomain of that.

So where does this lead in terms of what I would like to do.

1)	I am less worried about being able to handle local number forms of E.164 numbers, although it probably drops out automatically from being able to handle private network numbers.

2)	I do want to handle numbers where phone-context is enterprise.com or some subdomain of that. These will only appear in incoming requests with an equivalent P-Private-Network-Indication, and handling such an indication involves more that just applying a special numbering plan (rather a full set of operational agreements with the enterprise operator).

regards

Keith

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Friday, April 09, 2010 10:53 AM
> To: Hadriel Kaplan; [email-masked]
> Subject: Re: [martini] Other AoR's than E.164: 
> Thanks for writing this up. I like the direction this is 
> heading, but I am not sure this really addresses the full 
> population of use cases that we might like to cover at some stage.
> 
> One concern is email-style AORs based on the SSP's domain. 
> This might work for some enterprises. What it means is a lack 
> of portability. For example, if I agree with ssp1.example.com 
> that I can use sip:[email-masked], it is quite likely 
> that if I try to move to ssp2.example.com, bob will not be 
> available. I look forward to your planned further draft on 
> the subject of using the enterprise domain name.
> 
> Another concern is whether non-E.164 numbers based on 
> phone-context of domain name is sufficiently widespread. In 
> fact I don't have much knowledge of deployments based on 
> non-E.164 numbers (excluding things like national numbers, 
> which can be expanded to fully-qualified E.164 numbers). For 
> use in the scenarios you describe, do people use domain- or 
> E.164-based phone-contexts? I note your intention to give 
> further consideration to E.164-based phone-contexts.
> 
> So basically, I see this as useful material on how gin could 
> be extended in future to accommodate a broader range of AOR 
> types. I am not sure that we necessarily need to include 
> these in the initial gin deliverable, but by being aware of 
> such future extensions we could at least ensure that we don't 
> build anything into gin that rules this out.
> 
> John
>  
> 
> Martini work to 
> > E.164's raises an issue that is a bit concerning.  We have 
> now heard 
> > from several folks that one issue with [draft-gin] is that 
> it does not 
> > cover as many use-cases as other mechanisms.  Essentially 
> the question 
> > is whether our requirements list is correct.
> > 
> because we 
> > mostly see those in daily life, if other mechanisms claim 
> to support 
> > more then Martini, we have a problem.  Lots of SSP's and 
> Enterprises 
> > (the actual
> go through 
> > mailing list archives, or RFCs, etc.  They will pay attention to 
> > whatever powerpoint slides the marketing folks generate, and the 
> > perception will be that Martini is not as generally useful as 
> > something else.
> > 
> > It doesn't matter what the technical details are, nor what the Opex 
> > cost differences will ultimately be.  It's a perception problem.
> > 
> which is 
> > part-1 of a two-part draft set to try to address the "other" use 
> > cases.
> > 
> > If people want this type of thing, then we could put the 
> olive in the 
> > gin for a better martini.
> > 
> > -hadriel
> > 
> > 
> IP-PBX type

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 Apr 2010 13:04:31 +0200

Agreed we should not try to run before we can walk, and extending gin to cover these "private network traffic" situations can wait until later. It is useful to start the discussion now, however, to help ensure that we leave the door open to future extensibility of gin.

John 

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 12 April 2010 11:21
> To: Elwell, John; Hadriel Kaplan; [email-masked]
> Subject: RE: [martini] Other AoR's than E.164: 
> Yes I want to handle different numbers, more specifically 
> private network numbers, but we do need to understand how 
> they will be used in the SSP before we start writing protocol 
> requirements.
> 
> The ETSI/3GPP model for this work was that the SSP could 
> undertake to provide various logical entities within it's own 
> equipment to support the enterprise. So where Centrex is 
> provided (or hosted enterprise services in the ETSI 
> terminology) essentially a logical PBX is hosted by the SSP. 
> Nominally the enterprise is responsible for this logical 
> entity, and the SSP manages it on behalf of the enteprise. It 
> is part of the enterprise, and therefore it should be able to 
> handle anything a physically provided IP-PBX can handle, 
> including the numbering / addressing plans of the enterprise.
> 
> If I want to connect two IP-PBX together in the same 
> enterprise, then I can the option of establishing a direct IP 
> connection between them, with all the QoS and numbering / 
> addressing handling of the enterprise handled provided over 
> this, in the same way as in the PSTN I can buy a tie line, or 
> I can use the SSP to provide public network services to 
> connect the two, in which case I am tied to the QoS and other 
> capabilities provided by the SSP, including the numbering and 
> addressing plans supported by the SSP (and which must be 
> globally unique within the SSP).
> 
> In particular, as an inheritance of what has been done with 
> the use of numbers in the past, a separate numbering plan 
> probably exists in the enterprise, such that 777 1234 is a 
> valid number within the enterprise, but would of course be 
> meaningless outside the context of that enteprise. While some 
> digits may correspond to an equivalent E.l64 number, e.g. +1 
> 555 999 1234, that is not a fixed requirement.
> 
> So what happens if I want to connect two Centrex 
> installations together. Yes I can always use the services of 
> the SSP in which it is resident to connect the two together, 
> in which case we are still tied to the QoS and other 
> capabilities provided by the SSP, including the numbering and 
> addressing plans supported by the SSP (and which must be 
> globally unique within the SSP). Or I can negotiate a deal 
> with the SSP that essentially for signalling purposes 
> requires them to simulate what I would get from that direct 
> IP connection (with all the QoS and numbering / addressing 
> handling of the enterprise handled provided over this). The 
> ETSI / 3GPP model provides for this, and the work in:
> 
> provides a tag for implementing identifying such traffic, 
> such that it is handled according to the rules of the 
> enterprise (which have of course been agreed with the SSP), 
> rather than the rules of the SSP directly. It is within this 
> context that the numbering / addressing plan of the 
> enterprise can be used. Thus within IMS 
> tel:1234;phone-context=enterprise.com can have meaning when 
> it appears in a SIP message that contains the header field 
> P-Private-Network-Indication:enterprise.com, but would 
> probably not have meaning when such a header field is missing.
> 
> There is no need for this tag where it is known that the 
> traffic is 100% belonging to the enterprise. So a UA 
> registering with a registrar function within the Centrex 
> environment, and sending and receiving traffic between the UA 
> and outbound proxies / registrars within that Centrex 
> environment, do not need this tag.
> 
> So that deals with two logical PBXs, i.e. Centrex connected. 
> What happens if one is Centrex and one is a physically 
> provided IP-PBX. Yes we should still be able to do the things 
> we have been doing.
> 
> The PBX needs to "register" its private network numbers in 
> the SSP location server. In the IMS model, this is performed 
> implicitly, so there are no domain name issues here.
> 
> Incoming calls with the P-Private-Network-Indication: 
> enterprise.com can assume the numbering / addressing plan of 
> the enterprise, which would normally have a phone-context of 
> enterprise.com, or some subdomain of that.
> 
> 
> 1)	I am less worried about being able to handle local 
> number forms of E.164 numbers, although it probably drops out 
> automatically from being able to handle private network numbers.
> 
> 2)	I do want to handle numbers where phone-context is 
> enterprise.com or some subdomain of that. These will only 
> appear in incoming requests with an equivalent 
> P-Private-Network-Indication, and handling such an indication 
> involves more that just applying a special numbering plan 
> (rather a full set of operational agreements with the 
> enterprise operator).
> 
> 
> regards
> 
> Keith
> 
> 
>  
> 
> > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > directories.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 09:29:47 -0400

Hans Erik van Elburg wrote:
> 
> On Sat, Apr 10, 2010 at 6:02 PM, Hadriel Kaplan <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > From: Paul Kyzivat [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     registration mechanism, as if the PBX had really registered for each
>     AoR separately.  So what AoR would the PBX register to for the
>     local-number "12345;ext=678;phone-context=ssp.com <http://ssp.com>"?
> 
>     12345;ext=678;phone-context=ssp.com <http://ssp.com>@ssp.com
>     <http://ssp.com>".  If that's true, draft-olive is currently wrong.
>      It should set the contact to "sip:
>     12345;ext=678;phone-context=ssp.com <http://ssp.com>@pbx.com
>     <http://pbx.com>".
> 
> The more natural case would be where 
> "12345;ext=678;phone-context=martini-enterprise.com 
> <http://martini-enterprise.com>" is passed unmodified to the pbx 
> handling this number and which belongs to martini-enterprise.

I gather you are suggesting that the original registration would have 
been (implicitly) to aor 
sip:12345;ext=678;phone-context=[email-masked]

That is certainly a possibility. But it raises again the ugly issue of 
domain name assignments for pbxes, and the notion of responsibility for 
domains.

I don't recall exactly what are the *semantics* of using a domain name 
in the phone-context. But I think it *ought* to have some notion of 
responsibility for the domain name. Specifically, if Cisco asked ssp.com 
to use acmepacket.com as the phone context for its local numbers, and 
then later on acmepacket got an account with ssp.com, I suspect things 
would get pretty ugly. So that kind of usage ought not be permitted.

So I don't think using pbx-specific domain-name style phone-context will 
work for pbxes that don't already have domain names.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 09:38:00 -0400

> In practice I know there are times when the ingress proxy of the SSP is the one which does it, but I think that from a spec and architectural model the PBX should be the one which inserts a phone-c…

I think I agree with both your solution and your warning about dragons. :-)

> In practice it seems to me that the user=dialstring param isn't used much.  If the request-uri is "sip:[email-masked]", it's handled as a dialed phone number of "411" regardless of a user=dialstrin…

While I understand the practicality of what you say, I would find it 
difficult to write that down in a standard. So I think it would be 
useful to have *some* standard, even if many SSPs accept other things as 
well. But we don't have to solve that as part of *this* effort.

> If we *were* to specify a dialstring, then it would need a phone-context anyway (per rfc4967), and in my opinion that phone-context should be "ssp.com", ironically.

There I disagree. The phone context in a dialstring needs to correlate 
directly to the dial plan for the phone that is dialing. Having it be 
ssp.com would mean that all the pbxes supported by that ssp would have 
the same dial plan. That obviously wouldn't work.

Instead, it again requires coming up with some unique phone-context for 
the pbx, or maybe even for each dial plan used by the pbx if it might 
have more than one.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 12 Apr 2010 16:53:52 +0200

When that happened the phonecontexts that it wishes to use below that
domainname for our_number_plan.company.com is completely under control of
that company. This is in fact the internet model. I do not see what is ugly
about that, it just makes perfect sense. (for once ;-)

This is not a pbx assignement, but just a unique name that identifies the
context (i.e. numberplan) within which this local number has meaning.

In principle there is no relation with the domain name used for routing and
the phone-context, but in practice I expect that the phone context is a
subdomain of the companies already registered DNS domain name. Because that
is just very practical.

/Hans Erik van Elburg

On Mon, Apr 12, 2010 at 3:29 PM, Paul Kyzivat <[email-masked]> wrote:

>> martini-enterprise.com <http://martini-enterprise.com>" is passed
>> unmodified to the pbx handling this number and which belongs to
>> martini-enterprise.
>>
>
> I gather you are suggesting that the original registration would have been
> (implicitly) to aor sip:12345;ext=678;phone-context=martini-enterprise.com
> @ssp.com
>
> I don't recall exactly what are the *semantics* of using a domain name in
> the phone-context. But I think it *ought* to have some notion of
> responsibility for the domain name. Specifically, if Cisco asked ssp.comto use
> acmepacket.com as the phone context for its local numbers, and then later
> on acmepacket got an account with ssp.com, I suspect things would get
> pretty ugly. So that kind of usage ought not be permitted.
>
> I would believe and hope that any company has a DNS domain name, or at
> least is in the possibility of easily obtaining one that it owns.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 11:08:37 -0400

Hans Erik van Elburg wrote:
> domainname for our_number_plan.company.com 
> <http://our_number_plan.company.com> is completely under control of that 
> company. This is in fact the internet model. I do not see what is ugly 
> This is not a pbx assignement, but just a unique name that identifies 
> the context (i.e. numberplan) within which this local number has meaning.
> 
> In principle there is no relation with the domain name used for routing 
> and the phone-context, but in practice I expect that the phone context 
> is a subdomain of the companies already registered DNS domain name. 
> Because that is just very practical.

3966 says:

>    The domain name does not have to resolve to any actual host but MUST
>    be under the administrative control of the entity managing the local
>    phone context.

That is all fine *if* the company with the pbx actually has a domain 
name under its administrative control. But IIUC we are considering cases 
where that may not be true.

	Thanks,
	Paul

> /Hans Erik van Elburg
> 
> 
> On Mon, Apr 12, 2010 at 3:29 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>         <http://martini-enterprise.com> <http://martini-enterprise.com>"
>         is passed unmodified to the pbx handling this number and which
>         belongs to martini-enterprise.
> 
> 
>     I gather you are suggesting that the original registration would
>     have been (implicitly) to aor
>     sip:12345;ext=678;phone-context=martini-enterprise.com
>     <http://martini-enterprise.com>@ssp.com <http://ssp.com>
> 
>     That is certainly a possibility. But it raises again the ugly issue
>     of domain name assignments for pbxes, and the notion of
>     responsibility for domains.
> 
>     I don't recall exactly what are the *semantics* of using a domain
>     name in the phone-context. But I think it *ought* to have some
>     notion of responsibility for the domain name. Specifically, if Cisco
>     asked ssp.com <http://ssp.com> to use acmepacket.com
>     <http://acmepacket.com> as the phone context for its local numbers,
>     and then later on acmepacket got an account with ssp.com
>     <http://ssp.com>, I suspect things would get pretty ugly. So that
>     kind of usage ought not be permitted.
> 
>     So I don't think using pbx-specific domain-name style phone-context
>     will work for pbxes that don't already have domain names.
>     I would believe and hope that any company has a DNS domain name, or
>     at least is in the possibility of easily obtaining one that it owns.
> 
>  
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 12 Apr 2010 17:33:09 +0200

On Mon, Apr 12, 2010 at 5:08 PM, Paul Kyzivat <[email-masked]> wrote:

> That is all fine *if* the company with the pbx actually has a domain name
> under its administrative control. But IIUC we are considering cases where
> that may not be true.
>
>  There are several possibilities to tackle those:
- The SSP providing the enterprise with the trunking service can give out
dedicated subdomains solely for the purpose to serve as a phone context of
its domain as a service to its customers. This makes sense as company might
not want tto bother about this, they want it to just work.
- A specialised company could do this. After all people earn money by
selling desert sand.

BUT in all honesty any company that is big enough to consider a private
numberplan already for sure has webpresence and hence owns a domain name.
And if that is not the case, it can obtain such domain name easily.

BR,
/Hans Erik

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 12:33:45 -0400

No you're not being a Neanderthal - we're only discussing a very narrow use-case, essentially for completeness.  What you describe is the more common example (or arguably an E.164 is the more common example), but the example you cite is purposefully not covered by draft-olive.

BTW, I'm not claiming draft-olive is very *useful* - it only covers the case for certain local-numbers and email-style AoRs *of the SSP's domain*.  It only does those, because those are similar conceptually to [draft-gin] and thus follow the same solution, which is basically: "follow rfc3261 as if they had individually registered".

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Monday, April 12, 2010 5:38 AM

The more natural case would be where "12345;ext=678;phone-context=martini-enterprise.com" is passed unmodified to the pbx handling this number and which belongs to martini-enterprise.

/Hans Erik

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 18:15:09 -0400

> Sent: Monday, April 12, 2010 9:38 AM
> 
> Hadriel Kaplan wrote:
> > In practice it seems to me that the user=dialstring param isn't used
> > much.  If the request-uri is "sip:[email-masked]", it's handled as a dialed
> > phone number of "411" regardless of a user=dialstring.  SSP's just don't
> > allocate "411" as a username to some random SIP subscriber.  I would argue
> > that's true for all service numbers, including "911" - you can send a sos
> > URN or a user=dialstring param, but it's not like they're going to give
> > the AoR of "sip:[email-masked]" to some random subscriber anyway, so it's not
> > ambiguous in practice.  There's no real interop problem to solve, afaict.
> 
> > If we *were* to specify a dialstring, then it would need a phone-context
> > anyway (per rfc4967), and in my opinion that phone-context should be
> > "ssp.com", ironically.
> 

Umm, we were talking about numbers like "411" and "911" and such, no?  The SSP *is* the "PBX" for those numbers.  It's the SSP's logical "dial-plan" you're hitting first.  Of course the SSP may retarget the request to a private numbering plan, or to an E.164, or to an emergency number.  But the "context" of the digits you pressed on a UA is the SSP initially, because it's the one making a decision for what the digits mean.  

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 18:42:42 -0400

Right, I'm with you on all that.  I was just avoiding the domain name case because of the concerns folks had raised over draft-shaken/stirred, one of which was on the alt-root issue.

And just to be clear - nothing Martini does can possibly remove or restrict configured local policies from doing what they need to.  All we're trying to do is define enough to get the REGISTER-based model to work for basic calls, avoid the basic/simple known interop issues, and not change SIP's current sipcore specs.  There was feedback that supporting just E.164 isn't sufficient, so I'm just trying to provide a strawman for how to handle the rest (although draft-olive only handles the easy half).

Although given the nature of local-numbers I'm tempted to just change draft-olive to say "any string user portion of the SSP domain", and leave it at that.  It would be local (provisioned) policy for how to handle whether a specific username of a phone-context is an AoR or not, whether it gets changed or not, etc.

-hadriel

> Sent: Monday, April 12, 2010 6:21 AM
> Subject: RE: [martini] Other AoR's than E.164: draft-kaplan-martini-with-
> olive-00
> 
> Yes I want to handle different numbers, more specifically private network
> numbers, but we do need to understand how they will be used in the SSP
> before we start writing protocol requirements.
> 
> The ETSI/3GPP model for this work was that the SSP could undertake to
> provide various logical entities within it's own equipment to support the
> enterprise. So where Centrex is provided (or hosted enterprise services in
> the ETSI terminology) essentially a logical PBX is hosted by the SSP.
> Nominally the enterprise is responsible for this logical entity, and the
> SSP manages it on behalf of the enteprise. It is part of the enterprise,
> and therefore it should be able to handle anything a physically provided
> IP-PBX can handle, including the numbering / addressing plans of the
> enterprise.
> 
> If I want to connect two IP-PBX together in the same enterprise, then I
> can the option of establishing a direct IP connection between them, with
> all the QoS and numbering / addressing handling of the enterprise handled
> provided over this, in the same way as in the PSTN I can buy a tie line,
> or I can use the SSP to provide public network services to connect the two,
> in which case I am tied to the QoS and other capabilities provided by the
> SSP, including the numbering and addressing plans supported by the SSP
> (and which must be globally unique within the SSP).
> 
> In particular, as an inheritance of what has been done with the use of
> numbers in the past, a separate numbering plan probably exists in the
> enterprise, such that 777 1234 is a valid number within the enterprise,
> but would of course be meaningless outside the context of that enteprise.
> While some digits may correspond to an equivalent E.l64 number, e.g. +1
> So what happens if I want to connect two Centrex installations together.
> Yes I can always use the services of the SSP in which it is resident to
> connect the two together, in which case we are still tied to the QoS and
> other capabilities provided by the SSP, including the numbering and
> addressing plans supported by the SSP (and which must be globally unique
> within the SSP). Or I can negotiate a deal with the SSP that essentially
> for signalling purposes requires them to simulate what I would get from
> that direct IP connection (with all the QoS and numbering / addressing
> handling of the enterprise handled provided over this). The ETSI / 3GPP
> model provides for this, and the work in:
> 
> provides a tag for implementing identifying such traffic, such that it is
> handled according to the rules of the enterprise (which have of course
> been agreed with the SSP), rather than the rules of the SSP directly. It
> is within this context that the numbering / addressing plan of the
> enterprise can be used. Thus within IMS tel:1234;phone-
> context=enterprise.com can have meaning when it appears in a SIP message
> that contains the header field P-Private-Network-Indication:enterprise.com,
> but would probably not have meaning when such a header field is missing.
> 
> There is no need for this tag where it is known that the traffic is 100%
> belonging to the enterprise. So a UA registering with a registrar function
> within the Centrex environment, and sending and receiving traffic between
> the UA and outbound proxies / registrars within that Centrex environment,
> do not need this tag.
> 
> So that deals with two logical PBXs, i.e. Centrex connected. What happens
> if one is Centrex and one is a physically provided IP-PBX. Yes we should
> still be able to do the things we have been doing.
> 
> The PBX needs to "register" its private network numbers in the SSP
> location server. In the IMS model, this is performed implicitly, so there
> are no domain name issues here.
> 
> Incoming calls with the P-Private-Network-Indication: enterprise.com can
> assume the numbering / addressing plan of the enterprise, which would
> normally have a phone-context of enterprise.com, or some subdomain of that.
> 
> 
> 1)	I am less worried about being able to handle local number forms of
> E.164 numbers, although it probably drops out automatically from being
> able to handle private network numbers.
> 
> 2)	I do want to handle numbers where phone-context is enterprise.com or
> some subdomain of that. These will only appear in incoming requests with
> an equivalent P-Private-Network-Indication, and handling such an
> indication involves more that just applying a special numbering plan
> (rather a full set of operational agreements with the enterprise operator).
> 
> 
> regards
> 
> Keith
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 19:33:35 -0400

> Umm, we were talking about numbers like "411" and "911" and such, no?  The SSP *is* the "PBX" for those numbers.  It's the SSP's logical "dial-plan" you're hitting first.  Of course the SSP may ret…

Well, maybe we are talking in circles.

I was talking about what to use *in general* as phone-context with 
user=dialstring, assuming it might contain anything the user might dial.

And that might be at issue here. For instance, I might have to dial 9411 
to get outside information. (Hopefully I don't have to dial 9911 for an 
emergency, but I have seen that happen too.)

If the calling phone, or the pbx, is generally processing the dial plan 
and converting to user=phone syntax in most cases, then I *suppose* you 
could use user=dialstring between the pbx and the SSP for certain cases 
where there is no other convenient representation. But that would then 
not be a *true* dialstring unless it is a matter of leaving the actual 
dialstring in selected cases.

For it to be the same value across multiple pbx clients of the ssp, then 
I think it is just an artiface, and it would be better to choose some 
other one, such as service:sos or at least a local number with 
user=phone and some agreed upon phone-context for that purpose.

	Thanks,
	Paul