Subject: [martini] #15: support for non E.164 numbers

From: "martini issue tracker" <[email-masked]>
Date: Thu, 18 Mar 2010 22:02:38 -0000

#15: support for non E.164 numbers
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |       Owner:            
     Type:  defect                   |      Status:  new       
 Priority:  critical                 |   Milestone:  milestone1
Component:  reqs                     |     Version:  1.0       
 Severity:  In WG Last Call          |    Keywords:            
-------------------------------------+--------------------------------------
 REQ19 - The mechanism MUST allow a set of assigned telephone numbers to
 comprise local numbers as specified in RFC3966, which can be in
 contiguous ranges, discrete, or in any combination of the two.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/15>
martini <http://tools.ietf.org/martini/>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Mar 2010 11:55:18 +0100

As an individual, I don't see an urgent need to solve this in the initial phase. Present deployments use fully-qualified E.164 numbers (or numbers that can be turned into fully-qualified E.164 numbers), and it is for these deployments that we urgently need a standard on which to converge. Support for non-E.164-based (private numbers) might be nice to have, but not essential. 

I guess an important point is whether these non-E.164 numbers are globally unique (as a result of a phone-context parameter), in which case they might be easier to accommodate, but even then I am not sure. If I have a telephone number in the form tel:1234;phone-context=pbx.com, how does this get routed to ssp.com in order to get onward-routed to the PBX? It might work if you start off with sip:1234;phone-context=[email-masked];user=phone, but how would the calling UA construct such a URI in the first place (unless returning a received URI)?

It seems to me that considerations are similar to non-number-based SIP URIs, and therefore this should be treated in the same way as #16 (depending on what we decide for that - see my recommendation in my previous email).

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of martini issue tracker
> Sent: 18 March 2010 22:03
> To: [email-masked]
> Cc: [email-masked]
> Subject: [martini] #15: support for non E.164 numbers
> 
>  Reporter:  ietf.hanserik@...          |       Owner:            
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 13:02:11 +0100

Again the question is not how such requests reach the SSP, the question is
how given that such requests are handled by the SSP such can be delivered to
an IP-PBX to which they are assigned.

The point is that an SSP may have more complete enterprise offering that
would require calls to be delivered via the SSP cloud to enterprise private
numbers that do not have a DID E.164 number, but which are assigned to a
PBX. Such private numbers are completely under control of the enterprise and
do not require reservation of E.164 for no good reason.

The current solution should not prohibit such service offerings and I
haven't seen a good reason why this should not be covered.

#16 is a different topic.

/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 11:55 AM, Elwell, John <
[email-masked]> wrote:

> As an individual, I don't see an urgent need to solve this in the initial
> phase. Present deployments use fully-qualified E.164 numbers (or numbers
> that can be turned into fully-qualified E.164 numbers), and it is for these
> deployments that we urgently need a standard on which to converge. Support
> for non-E.164-based (private numbers) might be nice to have, but not
> essential.
>
> I guess an important point is whether these non-E.164 numbers are globally
> unique (as a result of a phone-context parameter), in which case they might
> be easier to accommodate, but even then I am not sure. If I have a telephone
> number in the form tel:1234;phone-context=pbx.com, how does this get
> routed to ssp.com in order to get onward-routed to the PBX? It might work
> if you start off with sip:1234;phone-context=[email-masked];user=phone,
> but how would the calling UA construct such a URI in the first place (unless
> returning a received URI)?
>
> It seems to me that considerations are similar to non-number-based SIP
> URIs, and therefore this should be treated in the same way as #16 (depending
> on what we decide for that - see my recommendation in my previous email).
>
> John
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Mar 2010 09:35:59 -0400

Jon,

I agree with you here.

Solving this in general will require coming up with an approach for 
routing local TEL URIs based on phone-context. I can think of various 
ways to do that, but fear there would be as much politics involved as 
there has been with ENUM.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 14:50:45 +0100

So the argument here goes: we don't know how local numbers would be routed
to the SSP therefore we will not allow local numbers to be delivered to
IP-PBX's by that SSP even if they only have significance within the SSP
domain and are understood by the PBX.

I can not really follow that logic. Seems like forced limitation of freedom
by design.

/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 2:35 PM, Paul Kyzivat <[email-masked]> wrote:

> Jon,
>
> I agree with you here.
>
> Solving this in general will require coming up with an approach for routing
> local TEL URIs based on phone-context. I can think of various ways to do
> that, but fear there would be as much politics involved as there has been
> with ENUM.
>
>        Thanks,
>        Paul
>
>
> Elwell, John wrote:
>
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of martini issue tracker
>>> Type:  defect                   |      Status:  new        Priority:
>>>  critical                 |   Milestone:  milestone1
>>> Component:  reqs                     |     Version:  1.0        Severity:
>>>  In WG Last Call          |    Keywords:

---

From: <[email-masked]>
Date: Fri, 19 Mar 2010 14:50:31 +0100

Hi,

My understanding is that the term non-E.164 numbers is not only used for private numbering plans, but also for short numbers like 911 or 112.
If that is the case, it would not categorise this as "non-essential"

Kind regards

Jan Van Geel 
IT and Network Development Specialist 
Belgacom SDE/SDV/PSE/NST/NCP 
Tel: +32 2 202 1035 
Tel: +32 2 207 9032 
Email : [email-masked] 
www.cyberwezz.tk 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 19 March 2010 14:36
To: Elwell, John
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] #15: support for non E.164 numbers

Jon,

I agree with you here.

	Thanks,
	Paul

**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Mar 2010 10:05:46 -0400

I think numbers like 911 and 112 are not an issue for martini *unless* 
we expect that there is a requirement that they be *terminated* on the 
pbx, and be routed to it via the SSP.

Is that kind of case in scope right now?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Mar 2010 15:15:59 +0100

> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 19 March 2010 12:02
> To: Elwell, John
> Again the question is not how such requests reach the SSP, 
> the question is how given that such requests are handled by 
> the SSP such can be delivered to an IP-PBX to which they are assigned.
[JRE] I agree. But on the other hand, requiring we have a solution for routing such requests to the SIP-PBX when it is unclear how such requests might arrive at the SSP in the first place seems pointless. We just need to be clear whether this is a common enough situation that we need a solution for this on day one, and that there are indeed solutions in existence for getting requests to the SSP.

John

> 
> The point is that an SSP may have more complete enterprise 
> offering that would require calls to be delivered via the SSP 
> cloud to enterprise private numbers that do not have a DID 
> E.164 number, but which are assigned to a PBX. Such private 
> numbers are completely under control of the enterprise and do 
> not require reservation of E.164 for no good reason.
> 
> The current solution should not prohibit such service 
> offerings and I haven't seen a good reason why this should 
> not be covered.
> 
> On Fri, Mar 19, 2010 at 11:55 AM, Elwell, John 
> <[email-masked]> wrote:
> 
> 
> 	As an individual, I don't see an urgent need to solve 
> this in the initial phase. Present deployments use 
> fully-qualified E.164 numbers (or numbers that can be turned 
> into fully-qualified E.164 numbers), and it is for these 
> deployments that we urgently need a standard on which to 
> converge. Support for non-E.164-based (private numbers) might 
> be nice to have, but not essential.
> 	
> 	I guess an important point is whether these non-E.164 
> numbers are globally unique (as a result of a phone-context 
> parameter), in which case they might be easier to 
> accommodate, but even then I am not sure. If I have a 
> telephone number in the form tel:1234;phone-context=pbx.com, 
> how does this get routed to ssp.com in order to get 
> onward-routed to the PBX? It might work if you start off with 
> sip:1234;phone-context=[email-masked];user=phone, but how 
> would the calling UA construct such a URI in the first place 
> (unless returning a received URI)?
> 	
> 	It seems to me that considerations are similar to 
> non-number-based SIP URIs, and therefore this should be 
> treated in the same way as #16 (depending on what we decide 
> for that - see my recommendation in my previous email).
> 	
> 	John
> 	
> 
> 
> 	> Ticket URL: 
> <http://trac.tools.ietf.org/wg/martini/trac/ticket/15>

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Mar 2010 09:18:59 -0500

On 3/19/10 08:50, Mar 19, Hans Erik van Elburg wrote:
> So the argument here goes: we don't know how local numbers would be 
> routed to the SSP therefore we will not allow local numbers to be 
> delivered to IP-PBX's by that SSP even if they only have significance 
> within the SSP domain and are understood by the PBX.

The issue really comes down to global uniqueness. I don't think GIN 
currently forbids private numbers; it's just not something we're taking 
on as a design constraint. If an SSP and their customers can guarantee 
uniqueness of user portions among all PBXes, they would be free (within 
the current GIN framework) to try to make that work. And it probably will.

But we're explicitly in an unprecedented hurry here (when else has a WG 
had three interims in two months?), and taking on the additional 
analysis to ensure that private numbering works, and making adjustments 
to the protocol to accommodate it, don't fit into that mode of operation.

>
> I can not really follow that logic. Seems like forced limitation of 
> freedom by design.

Perhaps -- that might be the other side of the coin that I would 
characterize as "restricting the solution space for the sake of expediency."

Some projects are planned based on "how long would it take to design X 
so that it is perfect." Others are planned based on "we have X amount of 
time; what can you design in that timeframe?" In the IETF, we tend to 
deal with the former, and the answer is "3 to 5 years, unless someone 
disagrees with something, in which case it will take longer." For the 
first MARTINI deliverables, we're dealing with the latter, where the 
timeframe is "within 3 to 6 months."

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Mar 2010 10:23:24 -0400

> I can not really follow that logic. Seems like forced limitation of 

The issue is simply one of how to reduce scope to something manageable.
The way that has been proposed is to reduce the scope to E.164 numbers.

The value of doing so is that we then don't have to consider the issues 
that might arise for cases outside that scope.

IIUC you are proposing to change the scope to include something beyond 
E.164 numbers. (I don't know how much beyond.) Increasing the scope will 
at least require people to reconsider what new issues might arise with 
that expanded scope. Its certainly easier not to do that reevaluation.

Nevertheless, maybe it is an important thing to do. IMO the discussion 
of how such numbers might be needed is merely a way to get at the 
importance of expanding the scope. If we can't think of good reasons why 
this expansion is needed, then there is less motivation to consider it 
right now.

As an example of the implications of expanding the scope beyond E.164 
numbers:

When a request arrives for any of the implicitly registered numbers, its 
going to be mapped to a different URL with the same user part but a 
domain part belonging to the pbx. (At least that is the Gin proposal.)

The pbx needs to know which user parts are valid for such uses, and also 
which user parts will never arise from such mappings and which may be 
used for other internal purposes. With the scope limited to E.164 
numbers, the pbx knows that it should reserve user parts of form +digits 
for such use, and that any user part of another form is "safe" for other 
internal uses. Once we expand the scope that assumption must change.

	Thanks,
	Paul

> /Hans Erik van Elburg
> 
> On Fri, Mar 19, 2010 at 2:35 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Jon,
> 
>     I agree with you here.
> 
>     routing local TEL URIs based on phone-context. I can think of
>     various ways to do that, but fear there would be as much politics
>     involved as there has been with ENUM.
> 
>            Thanks,
>            Paul
> 
> 
>     Elwell, John wrote:
> 
>         As an individual, I don't see an urgent need to solve this in
>         the initial phase. Present deployments use fully-qualified E.164
>         numbers (or numbers that can be turned into fully-qualified
>         E.164 numbers), and it is for these deployments that we urgently
>         need a standard on which to converge. Support for
>         non-E.164-based (private numbers) might be nice to have, but not
>         essential.
>         I guess an important point is whether these non-E.164 numbers
>         are globally unique (as a result of a phone-context parameter),
>         in which case they might be easier to accommodate, but even then
>         I am not sure. If I have a telephone number in the form
>         tel:1234;phone-context=pbx.com <http://pbx.com>, how does this
>         get routed to ssp.com <http://ssp.com> in order to get
>         sip:1234;phone-context=pbx.com <http://pbx.com>@ssp.com
>         <http://ssp.com>;user=phone, but how would the calling UA
>         construct such a URI in the first place (unless returning a
>         received URI)?
> 
>         non-number-based SIP URIs, and therefore this should be treated
>         in the same way as #16 (depending on what we decide for that -
>         see my recommendation in my previous email).
> 
>         John
> 
> 
>             <mailto:[email-masked]>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of martini
>             issue tracker
>             To: [email-masked] <mailto:[email-masked]>
>             Cc: [email-masked] <mailto:[email-masked]>
>                       Type:  defect                   |      Status:
>              new        Priority:  critical                 |  
>             Milestone:  milestone1
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 19 Mar 2010 15:25:21 +0100

It seems that you are in hurry to provide a solution to a problem, for which another forum already provided a solution.
In order to win time, why not envisaging adopting that solution and study possible enhancements.

Kind regards

Jan Van Geel 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 19 March 2010 15:19
To: Hans Erik van Elburg
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] #15: support for non E.164 numbers

/a

**** DISCLAIMER ****

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Mar 2010 09:53:37 -0500

> In order to win time, why not envisaging adopting that solution and study possible enhancements.

As we've been over many times on the list and at interim meetings, the 
problems in those solutions are myriad. No one has stepped forward with 
plausible ways to address such problems -- probably because the problems 
are inherent in the mechanism itself, and not minor flaws.

I would be delighted if someone could prove me wrong by proposing 
acceptable changes to the solutions you reference that address the suite 
of problems that have been raised in MARTINI. I have no burning desire 
to author a draft that addresses a problem that I have no interest in. 
But no one else is coming up with solutions, and the problems inherent 
in shaken and its progenitors are profound enough that I do not believe 
the IETF can endorse them.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 19 Mar 2010 15:06:29 -0400

+1 as well. 

Politics in ENUM ???  Naaah. Whatever gave you that thought?  :-) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Friday, March 19, 2010 9:36 AM
To: Elwell, John
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] #15: support for non E.164 numbers

Jon,

I agree with you here.

	Thanks,
	Paul

unique (as a result of a phone-context parameter), in which case they might
be easier to accommodate, but even then I am not sure. If I have a telephone
number in the form tel:1234;phone-context=pbx.com, how does this get routed
to ssp.com in order to get onward-routed to the PBX? It might work if you
start off with sip:1234;phone-context=[email-masked];user=phone, but how
would the calling UA construct such a URI in the first place (unless
returning a received URI)?

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 19 Mar 2010 15:09:11 -0400

I do not agree that the 3GPP solution actually solves the problem we are
trying to address here.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, March 19, 2010 10:25 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] #15: support for non E.164 numbers

It seems that you are in hurry to provide a solution to a problem, for which
another forum already provided a solution.
In order to win time, why not envisaging adopting that solution and study
possible enhancements.

Kind regards

Jan Van Geel 

-----Original Message-----
Of Adam Roach

/a

**** DISCLAIMER ****

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Mar 2010 10:24:39 +0100

So what problem are you addressing then?

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Mar 2010 10:31:05 +0100

Can you explain the "unprecedented hurry"?

/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 3:18 PM, Adam Roach <[email-masked]> wrote:

> currently forbids private numbers; it's just not something we're taking on
> as a design constraint. If an SSP and their customers can guarantee
> uniqueness of user portions among all PBXes, they would be free (within the
> current GIN framework) to try to make that work. And it probably will.
>
> But we're explicitly in an unprecedented hurry here (when else has a WG had
> three interims in two months?), and taking on the additional analysis to
> ensure that private numbering works, and making adjustments to the protocol
> to accommodate it, don't fit into that mode of operation.
>
>
>
> Some projects are planned based on "how long would it take to design X so
> that it is perfect." Others are planned based on "we have X amount of time;
> what can you design in that timeframe?" In the IETF, we tend to deal with
> the former, and the answer is "3 to 5 years, unless someone disagrees with
> something, in which case it will take longer." For the first MARTINI
> deliverables, we're dealing with the latter, where the timeframe is "within
> 3 to 6 months."
>
> /a
>

---

From: <[email-masked]>
Date: Mon, 22 Mar 2010 10:36:41 +0100

As you said considerations are similar to non-number-based SIP URIs. Therefore my comment will be very similar as well. By designing an E.164 solution only in the first phase we run a risk that a PBX supporting both types of numbers will have to support two completely different solutions.

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Elwell, John
> Envoyé : vendredi 19 mars 2010 11:55
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Re: [martini] #15: support for non E.164 numbers
> 
> the initial phase. Present deployments use fully-qualified 
> E.164 numbers (or numbers that can be turned into 
> fully-qualified E.164 numbers), and it is for these 
> are globally unique (as a result of a phone-context 
> >  REQ19 - The mechanism MUST allow a set of assigned 
> telephone numbers 
> > to  comprise local numbers as specified in RFC3966, which 
> can be in  

*********************************
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: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Mar 2010 10:42:09 +0100

An acceptable change would be where the Request-URI would be kept unchanged
and a Contact header populated on the Route header, for example.

Have not understood what is so wrong with that.

/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 3:53 PM, Adam Roach <[email-masked]> wrote:

>> It seems that you are in hurry to provide a solution to a problem, for
>> which another forum already provided a solution.
> plausible ways to address such problems -- probably because the problems are
> inherent in the mechanism itself, and not minor flaws.
>
> acceptable changes to the solutions you reference that address the suite of
> problems that have been raised in MARTINI. I have no burning desire to
> author a draft that addresses a problem that I have no interest in. But no
> one else is coming up with solutions, and the problems inherent in shaken
> and its progenitors are profound enough that I do not believe the IETF can
> endorse them.
>
> /a
>