Subject: [martini] Requirements - rev2

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jan 2010 17:13:27 +0100

Although the "Requirement - rev1" thread had a lot of traffic over the last couple of weeks, very little of that traffic led to consensus on change to the requirements list. So below is the requirements list again with my comments inserted ("[JRE]") where there has been discussion.

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

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

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

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

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

- The mechanism MUST observe SIP backwards compatibility principles.

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

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

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

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

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

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

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

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

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

John

---

From: <[email-masked]>
Date: Mon, 25 Jan 2010 17:21:54 +0100

If there is no consensus on adding the requirements about intermediate proxies at the PBX side could we instead add something like "The mechanism MUST allow the PBX to uniquely identify the communication target based solely on the contents of the Request-URI on inbound requests."?

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Elwell, John
> Envoyé : lundi 25 janvier 2010 17:13
> À : [email-masked]
> Objet : [martini] Requirements - rev2
> 
> Although the "Requirement - rev1" thread had a lot of traffic 
> over the last couple of weeks, very little of that traffic 
> led to consensus on change to the requirements list. So below 
> is the requirements list again with my comments inserted 
> ("[JRE]") where there has been discussion.
> 
> - The mechanism MUST allow the PBX to be responsible for its 
> AORs and to handle requests to those AORs according to its rules.
> 
> - The mechanism MUST allow the PBX to receive requests to its 
> AORs that originate off-PBX and arrive via the SSP, so that 
> the PBX can handle those requests according to its rules.
> 
> - The mechanism MUST provide a means whereby the PBX knows 
> which of its AORs an inbound request is targeted at.
> 
> - The mechanism MUST provide a means of avoiding problems due 
> to one side using the mechanism and the other side not.
> 
> - The mechanism MUST work in the presence of intermediate 
> "proxies" on the SSP side of the interface (between the PBX 
> and the SSP's domain proxy), where those intermediate 
> "proxies" need to be on the path of inbound requests to the PBX.
> [JRE] There was a comment from Bruno to extend this to 
> proxies on the PBX side, but I didn't see any consensus to 
> accept this.
> 
> - The mechanism MUST work without requiring the PBX to 
> publish reachability information through the DNS.
> 
> Also some desiderata:
> - The mechanism SHOULD allow SSPs to exploit its mechanisms 
> for providing SIP service to ordinary subscribers in order to 
> provide a SIP trunking service to PBXs.
> 
> - The mechanism SHOULD scale to support several thousand 
> IP-PBXs on a single service provider network.
> 
> - The mechanism SHOULD require relatively modest changes to a 
> substantial population of existing SSP and PBX 
> implementations, in order to encourage a fast market adoption 
> of the standardized mechanism.
> 
> [JRE] The following proposal from Keith was discussed, but 
> with no conclusion (or was Adam's objection not so much to 
> the proposal but to Keith's subsequent assertion that it 
> means no change to the Request-URI on an inbound request?):
> 
> - The mechanism SHOULD allow handling of inbound requests and 
> outbound requests between SSP and PBX to be as common as 
> possible as with a normal peering arrangement (RFC 3263 
> based), as far as the PBX is concerned.
> 
> 
> John
> 
> 
> 
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
> 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Jan 2010 10:42:29 -0600

Hi, John,

(As co-chair) Thanks for continuing to herd this along the path.

(as individual) A couple of questions inline...

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

Are we crystal clear on what "responsible for its AORs" means? I am 
remembering conversations that centered around where DNS records pointed, 
for instance.

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

I am somewhat concerned about "proxies" in quotes. Do people think this 
requirement is talking about normal SIP-trapezoid proxies, or does it 
include other types of middleboxes like B2BUAs? I don't think we've been 
completely consistent about this.

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

I was hoping that someone else would ask about this one, but no one else 
has.

Does anyone on this list actually NEED mass registration for several 
thousand AORs?

We've been coy about defining values for "small" and "medium", but I've been 
in a lot of conversations that talked about "small" and "medium", and many 
of these conversations also included sentences like "of course, large PBXes 
would do RFC 3263".

I apologize if I'm connecting the wrong dots, but when I joined Nortel in 
1981, the largest PBXes they made topped out at 5000 lines. I wouldn't think 
of 5000 AORs as a small or medium PBX.

If this one stays, I'm going to be paying a lot more intention to state 
management, atomicity, etc. Rebooting a small PBX for a beauty shop is a lot 
more attractive than rebooting a PBX for 5000 AoRs...

> single service provider network.

FWIW, I agree with this addition.

Spencer (speaking as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jan 2010 18:05:08 +0100

Bruno,

We already have the requirement: "The mechanism MUST provide a means whereby the PBX knows which of its AORs an inbound request is targeted at."

You seem to suggest this should be further qualified by saying this should be in the Request-URI, but I am concerned this is more part of the solution than a requirement.

It is also related to the later point (still under discussion): "The mechanism SHOULD allow handling of inbound requests and outbound requests between SSP and PBX to be as common as possible as with a normal peering arrangement (RFC 3263 based), as far as the PBX is concerned."

So I am hesitant to add anything further. Let's see what others say.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 25 January 2010 16:22
> To: Elwell, John; [email-masked]
> Subject: RE: [martini] Requirements - rev2
> 
> If there is no consensus on adding the requirements about 
> intermediate proxies at the PBX side could we instead add 
> something like "The mechanism MUST allow the PBX to uniquely 
> identify the communication target based solely on the 
> contents of the Request-URI on inbound requests."?
> 
> 
> 
> This message and any attachments (the "message") are 
> confidential and intended solely for the addressees. 
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jan 2010 18:35:20 +0100

Spencer,

My feedback below. 

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 25 January 2010 16:42
> Subject: Re: [martini] Requirements - rev2
> 
> Hi, John,
> 
[JRE] Yes, I agree we need something more concrete. Any text proposals from anyone?

> "proxies" on the 
> proxies on the PBX 
[JRE] Yes, it certainly needs to work with B2BUAs in their various forms. Perhaps just changing it to "SIP entities"?

> of 5000 AORs as a small or medium PBX.
[JRE] I tend to agree, that scalability to perhaps a few 100 AORs should be sufficient, but I seem to remember suggestions that it should be scalable to even bigger deployments. Any other views?

John

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2010 12:45:55 -0500

> [JRE] I tend to agree, that scalability to perhaps a few 100 AORs should be sufficient, but I seem to remember suggestions that it should be scalable to even bigger deployments. Any other views?

Is there an implicit assumption here that however many of these there 
are, it must be possible to encode a list of them in a message that 
doesn't exceed PDU size?

The wildcard proposals certainly attempt to compress the encoding, but 
in general those only work if the majority of the AORs have some textual 
commonalities that can be exploited. But while that is the norm, there 
are no guarantees that a pbx might not have 100 distinct phone numbers 
that have no patterned relationship that can be exploited via regular 
expressions to encode the full set concisely.

	Thanks,
	Paul

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 25 Jan 2010 10:09:36 -0800

Spencer said:

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

thousand AORs?"

[BA] Question:  Are there existing installations that use "implicit
registration" at this kind of scale?
Or alternatively, are there specific customers that have made this request?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Jan 2010 13:16:47 -0600

Bernard is asking a much better-formed version of my question - thanks for 
clarifying!

Spencer

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 14:04:54 -0600

On 1/25/10 11:45 AM, Paul Kyzivat wrote:
> in general those only work if the majority of the AORs have some 
> textual commonalities that can be exploited. But while that is the 
> norm, there are no guarantees that a pbx might not have 100 distinct 
> phone numbers that have no patterned relationship that can be 
> exploited via regular expressions to encode the full set concisely.

Is this really a requirement? It seems a bit of a tortured use case.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 14:22:50 -0600

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

To be clear -- I object to the requirement as stated. If we're using 
REGISTER (or PUBLISH with the 'reg' event package), that means we're 
setting up AOR => Contact bindings. Inherently, that means contact 
routing, not the normal inter-domain RFC 3263-based routing.

On top of that, anything along these lines starts running into the DNS 
alt-root problems that have been pointed out repeatedly by myself and 
others. Anything that says "we're using RFC 3263 techniques, except 
without the DNS servers" is fraught with peril.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2010 15:26:51 -0500

> Is this really a requirement? It seems a bit of a tortured use case.

I don't know what sort of tortured cases exist out there in the wild.

I'm not arguing for anything specific. I'm just trying to understand the 
requirements proposed. If its "support up to N distinct AORs and/or 
AOR-ranges" where an AOR-range is suitably defined, then we can discuss 
what a suitable value of N might be, and it may be small. But if its 
"support up to N distinct AORs" with no restriction on what they might 
be then I think we will find a requirement for a larger value of N.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Jan 2010 16:44:45 -0600

Hi, Paul,

> "support up to N distinct AORs" with no restriction on what they might be 
> then I think we will find a requirement for a larger value of N.
>
> Thanks,
> Paul

(Caveat - I try to be pretty clear in my mind about when I'm speaking as an 
individual who is also SIP Forum's editor for SIPconnect 1.1 and when I'm 
wearing an IETF hat as MARTINI co-chair, but if you think I may be confused 
about that, please feel free to ask/challenge - it's not easy, and I won't 
be offended if someone helps me distinguish on a specific point)

Speaking as an individual, but from my perspective as SIPconnect 1.1 
editor...

After much jumping up and down by all interested parties, the current draft 
version of SIPconnect 1.1 explicitly prefers operation over TCP. The 
SIPconnect 1.1 team made this decision to accommodate a variety of SIP 
extensions that, taken together, are moving SIP request/response sizes 
closer to the maximum message size for SIP over UDP (as has been discussed 
at length on SIP-related IETF mailing lists).

Note that this preference has nothing to do with passing information about 
distinct AORs around at REGISTER time, because SIPconnect 1.1 doesn't assume 
that's happening at all - it might be lovely to pass this information 
around, but it isn't in SIPconnect 1.1 today.

So, at some level, the SIPconnect 1.1 guys don't care about the number of 
AORs supported, because their preferred answer is that if you're doing TCP 
and you decide to start passing complete information about distinct AORs in 
either direction, you can do that without worrying about request/response 
sizes.

If people in MARTINI are willing to "go there", then we don't need to worry 
about mandating support for N distict AORs in MARTINI.

If people in MARTINI are unwilling to "go there", I'd suggest that we be 
very intentional about what the requirement for passing information about 
the AORs that have been MARTINIed might be - because if we have to do this, 
and have to define it so that it works over UDP, that's going to be a 
painful discussion.

I am especially unexcited about this if MARTINI ends up describing a regex 
syntax, because that could lead to situations where you could register all 
your AORs over UDP using a regex expression, but then four of your customers 
renumber out of that numbering block and now you need to include additional 
expressions, which puts you over the UDP request/response size :-(

Again, I'm providing background as SIPconnect 1.1 editor here, which 
qualifies me to speak as an individual, but nothing more - so please feel 
free to tell the working group what you really think.

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Jan 2010 16:54:11 -0600

Dorks follow up to their own posts - my apologies for being a dork, but ...

> If people in MARTINI are willing to "go there", then we don't need to 
> worry about mandating support for N distict AORs in MARTINI.
>
> the AORs that have been MARTINIed might be - because if we have to do 
> this, and have to define it so that it works over UDP, that's going to be 
> a painful discussion.
>
> your AORs over UDP using a regex expression, but then four of your 
> customers renumber out of that numbering block and now you need to include 
> additional expressions, which puts you over the UDP request/response size 
> :-(

I don't want to leave this thought where it can be taken out of context - I 
actually LIKE the idea of regex or some other compression mechanism if 
information about distinct AORs is being passed back and forth. I understand 
the point Richard makes about numbering block pollution, but IMO it's worth 
looking at this and deciding if there's a compression mechanism that would 
still be useful when numbering blocks are polluted.

What I'm not excited about is the interaction between regex et al and UDP 
transport, and the resulting opportunity for things that once worked 
starting to fail - that's what I was intending to say.

Spencer, speaking as a dork ...

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2010 18:40:48 -0500

Spencer,

I guess this needs to be segmented into separate issues, which you have 
already more or less done:

- do the AORs need to be communicated at all in the REGISTER?

- if the AORs do need to be communicated in the REGISTER:

   - in request or response?

   - does this mechanism have to work for UDP, or only for TCP?

   - even with TCP, how big of a message is acceptable?

- Will contact routing or loose routing be used?

- If contact routing,

   - how will the prior r-uri be communicated?

     - if by manipulating the the registered contact,
       how is that defined? (And how is it discovered
       after the fact?)

I hear some saying that the AORs need to be communicated because the 
P-CSCF needs them.

I hear others saying they need to be communicated because otherwise 
there are problems keeping pbx and SSP in sync, or in cases where 
support for one AOR may move between pbxes for the same "customer".

I hear others saying "we don't need no stinking list of AORs, its all 
provisioned anyway, and that's the way we like it."

And *maybe* I'm hearing some saying "we don't need to mention 
communicating the AORs in *this* draft - send them if you like, or 
don't." (I don't buy this - it presents significant interop problems.)

	Thanks,
	Paul

Spencer Dawkins wrote:
>> If people in MARTINI are unwilling to "go there", I'd suggest that we 
>> be very intentional about what the requirement for passing information 
>> about the AORs that have been MARTINIed might be - because if we have 
>> to do this, and have to define it so that it works over UDP, that's 
>> going to be a painful discussion.
>>
>> I am especially unexcited about this if MARTINI ends up describing a 
>> regex syntax, because that could lead to situations where you could 
>> register all your AORs over UDP using a regex expression, but then 
>> four of your customers renumber out of that numbering block and now 
>> you need to include additional expressions, which puts you over the 
>> UDP request/response size :-(
> 
> I don't want to leave this thought where it can be taken out of context 
> - I actually LIKE the idea of regex or some other compression mechanism 
> if information about distinct AORs is being passed back and forth. I 
> understand the point Richard makes about numbering block pollution, but 
> IMO it's worth looking at this and deciding if there's a compression 
> mechanism that would still be useful when numbering blocks are polluted.
> 
> What I'm not excited about is the interaction between regex et al and 
> UDP transport, and the resulting opportunity for things that once worked

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jan 2010 08:18:19 +0100

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 25 January 2010 17:46
> To: Elwell, John
> Cc: Spencer Dawkins; [email-masked]
> > [JRE] I tend to agree, that scalability to perhaps a few 
> 100 AORs should be sufficient, but I seem to remember 
> suggestions that it should be scalable to even bigger 
> deployments. Any other views?
> 
[JRE] I would turn it around, and say that if we have a requirement for a large value of N, it would preclude a solution where the AORs have to be enumerated within a SIP message (assuming we want it to work over UDP, which perhaps should be an additional requirement, which I will post separately). Grouping into ranges might help in some cases, but it is difficult to rely on ranges to achieve a significant improvement in scalability. I tend to agree with the notion that registration mode would be applied to smaller PBXs, and that anything above a few hundred AORs would typically be solved using static mode. But I also agree that is unwise to build in an arbitrary limit unless we can be sure that practical deployments would stay well below that limit. So a solution with a limit of about 1000 AORs might be acceptable if we don't anticipate deployments exceeding about 100-200 AORs, but would be unwise if we can already envisage deployments of 500 AORs, say. I would like to hear opinions on what a likely practical limit would be.

John

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jan 2010 08:22:40 +0100

It tends not to be the case in Europe, but I have heard stories that the NA numbering plan is getting pretty fragmented.

John 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 25 January 2010 20:05
> To: Paul Kyzivat
> Cc: Elwell, John; [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 09:05:34 -0600

> [JRE] Yes, I agree we need something more concrete. Any text  

How about:

Such that the PBX or its operators have a trusted signing certificate  
(CA) for the domain, and can use that certificate to sign a shorter- 
lived certificate that will be delegated to SSP allowing the SSP to,  
for a limited duration, appear to be authoritative for that domain  
when contacted using the procedures of RFC 3263 and SIPS.

Of course, we need a mechanism for pushing that cert from PBX to SSP.

We may also need to talk about service-dispatch. The SSP MUST NOT do  
per-user service dispatch using Service-Route, since all users  
registered with a single request get the same Service-Route.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 09:32:18 -0600

On Jan 25, 2010, at 1:16 PM, Spencer Dawkins wrote:

> Bernard is asking a much better-formed version of my question -  
> thanks for clarifying!
>
> Spencer
>
>
>> Spencer said:
>>

A single Cisco Call Manager server might support ten thousand users,  
and I suspect that such a server at a large enterprise (or local  
government facility: the Dallas city offices use one)  is a potential  
customer for SSP services.

Given that we have IPv4 address space exhaustion and there's no chance  
of IPv6 happening any time soon, it wouldn't surprise me to see large  
(10,000 plus seat) organizations that don't have a single public IP  
address in their entire organization, but instead are issues an ISP- 
routable 10.x.x.x subnet for their access routers by their ISP.  
Address space exhaustion is a wet-dream opportunity for vendors of SBC- 
like dynamic-access services for all sorts of things, not just SIP.

Why not have dynamic registration between an enterprise web server and  
a carrier-hosted web proxy, such that clients use regular DNS  
procedures find the carrier-hosted proxy which then tunnels the  
request to the enterprise web server?  Wouldn't THAT have ugly  
security properties! But it's exactly the same thing we're doing to  
the security properties in SIP with domain registration.

I think I'm going to go patent that dynamic HTTP-proxy binding stuff;  
it's evil enough that I expect somebody to bring it to market.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 09:44:54 -0600

On Jan 25, 2010, at 5:40 PM, Paul Kyzivat wrote:

> Spencer,
>
> I guess this needs to be segmented into separate issues, which you  
> have already more or less done: ...

Excellent summary. One additional issue:

Are the user-part identifiers restricted to being only encoded E.164  
numbers? Or is a more general user-part syntax allowed?

If we restrict ourselves to E.164 user-parts, then a lot of the  
complexity evaporates.

This brings a related issue: Are we talking about sip: request URIs or  
tel: request URIs?

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jan 2010 16:58:51 +0100

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 26 January 2010 15:06
> To: Elwell, John
[JRE] It seems to me this might be getting a bit beyond requirements and into mechanism.  I can understand that a PBX responsible for a domain should be able to obtain a certificate from that domain from a well-known CA. The need to have a CA cert, use that for minting other certs and using them as you describe seems to be too much.

John

---

From: Richard Shockey <[email-masked]>
Date: Tue, 26 Jan 2010 11:30:58 -0500

Dean ...typically the business context for  MARTINI is almost 
exclusively E.164 naming where the SSP is in direct ownership/control of 
the Layer 1 connection.

And yes .. I need to respond to Paul on the issues with assuming block 
number routing. This will become increasingly relevant as LNP rolls out 
in the EC.

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

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 17:34:29 +0100

On the other hand it would be a bit odd to define a solution that works exclusively for E.164 numbers and have to use a different solution for email-style URI and private numbers. 

> [mailto:[email-masked]] De la part de Richard Shockey
> Envoyé : mardi 26 janvier 2010 17:31
> À : [email-masked]
> Objet : Re: [martini] Requirements - rev2
> 
> 
> exclusively E.164 naming where the SSP is in direct 
> ownership/control of the Layer 1 connection.
> 
> And yes .. I need to respond to Paul on the issues with 
> assuming block number routing. This will become increasingly 
> relevant as LNP rolls out in the EC.
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 10:49:59 -0600

On Jan 26, 2010, at 10:30 AM, Richard Shockey wrote:

> exclusively E.164 naming where the SSP is in direct ownership/ 
> control of the Layer 1 connection.
>
> And yes .. I need to respond to Paul on the issues with assuming  
> block number routing. This will become increasingly relevant as LNP  
> rolls out in the EC.

Well, if we're willing to constrain our solution to E.164, then it can  
be a whole heck of a lot simpler.

Or we could do a solution NOW that works for the E.164 restriction,  
and put off solving the general domain routing problem for phase 2.

I'd be willing to entertain a solution that is only applicable to E. 
164. Do we want to do it this way?

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jan 2010 10:55:16 -0600

On 1/26/10 10:49, Jan 26, Dean Willis wrote:
> I'd be willing to entertain a solution that is only applicable to 
> E.164. Do we want to do it this way?

The problem here, as has been raised before, is: how can you tell if the 
user portion is an E.164 number? The obvious answers are that it must 
not apply unless the R-URI is a tel: URL or contains a "user=phone" 
parameter. At that point, the issue of "proper" domain handling becomes 
much less important.

/a

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 18:29:37 +0100

To me it would be a pity if the agreed solution was working exclusively for E.164 numbers. This would mean that a separate solution would have to be used for email-style URI as well as for private numbers since these are not E.164 numbers and cannot always be converted into an E.164 number.

> [mailto:[email-masked]] De la part de Dean Willis
> Envoyé : mardi 26 janvier 2010 17:50
> À : Richard Shockey
> Cc : [email-masked]
> ownership/ control 
> > of the Layer 1 connection.
> >
> assuming block 
> > number routing. This will become increasingly relevant as LNP rolls 
> > out in the EC.
> 
> Well, if we're willing to constrain our solution to E.164, 
> then it can be a whole heck of a lot simpler.
> 
> Or we could do a solution NOW that works for the E.164 
> restriction, and put off solving the general domain routing 
> problem for phase 2.
>