Subject: [martini] Proposed work split: tackle telephone-number registration first

From: Dean Willis <[email-masked]>
Date: Wed, 27 Jan 2010 00:16:19 -0600

We seem to have an urgent need for a near-term solution for dealing  
with the subset of the MARTINI problem that, loosely defined, covers  
the "telephone number" problem.

The typical scenario here is SIP trunking, wherein a SIP Service  
Provider (SSP) provides an ISDN-PRI like service over IP to a  
customer's PBX (or PBXes). In this model, the SSP maps a whole bunch   
of phone numbers to the PBXes. This mapping is somewhat dynamic,  
because the PBXes usually have DHCP addresses, and don't have DNS  
entries that point A records at the PBX in any sort of particularly  
useful way (maybe something like dhcp-10-1-2-3-example.com).

So what we need is a way for a PBX, when it reboots (or perhaps  
periodically) to say to the SSP "Here I Am; You may now send any calls  
for my assigned phone numbers to my current Contact."

This is indeed a "registration" problem, but it isn't necessarily a  
"domain registration problem". The only reason domains get mixed into  
this scenario at all is that we sometimes encode telephone numbers as  
the user parts of SIP URIs, and those SIP URIs have a domain part  
attached to them.

More interestingly, this problem is a tiny subset of the whole MARTINI  
dynamic binding problem, and it potentially can be solved much more  
simply than the general problem.

On today's Interim II call, Richard, Adam and I raised the idea of  
dividing our problem space, and taking on a near-term milestone for  
delivering a MARTINI solution for registering contacts to a proxy,  
where that proxy maps one or more telephone numbers to the contact.

We certainly intend to go on and tackle the more general domain- 
registration problem, but I (and I believe Adam and Richard) believe  
that we get a lot out of tackling the telephone-number subset first.

In particular, we believe that this approach solves many of the domain  
"responsibility" questions, simplifies the TLS keying/certification  
model immensely, eliminates the cognitive overload of using REGISTER  
to bind a "domain" to a Contact, "route authentication", and a good  
many other open issues that plague our current drafts.

Open questions relating to this approach include:

1) Do we deal only with E.164 numbers, or do we need to deal with  
private-number "phone contexts"?

2) D owe need to explicitly encode the telephone numbers being  
registered in the REGISTER request (either directly or through some  
sort of regexp), or is it adequate to rely on provisioning of the SSP  
and PBX (and any UAs) to statically bind the numbers to the PBX  
identity, and then dynamically only register the PBX identity to the  
PBX contact?

3) Can we "register" with a tel: URI as the "To" value? (this seems to  
require extending RFC 3261)? Note that "tel:" can express both E.164  
numbers and private phone-contexts in one format.

4) What happens with GRUUs?

I believe all of these issues are quite tractable, if we accept the  
fundamental idea of splitting the phone-number problem off from the  
more general domain-registration, and recognize the possibility that  
the solutions to the two problem may reasonably be quite different  
from each other.

So, what do you people think? Is it worth trying to drink the MARTINI  
elephant one sip at a time, or are we going to treat the whole thing  
like a tequila shot and just slam it down?

--
Dean

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 27 Jan 2010 00:38:32 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Dean Willis
> Sent: Wednesday, January 27, 2010 11:46 AM
> To: [email-masked]
> Subject: [martini] Proposed work split: tackle telephone-number
registrationfirst
> private-number "phone contexts"?

For call between different administrative domains, I think having a
normative statement about E.164 numbers only or following RFC 3966
syntax, will make life much simpler.

Sanjay

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jan 2010 11:19:42 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 27 January 2010 06:16
> To: [email-masked]
> Subject: [martini] Proposed work split: tackle 
> telephone-number registration first
> 
> 
[JRE] I indicated on the call that I would be prepared to go along with this approach. However, I did this on the understanding that it would give a sufficiently complete approach for the short term, and also on the assumption that it really can be shown to represent a simplification. It is true that what the market needs in the short term is a solution for E.164 numbers, but we need to be careful about whether or not we can exclude private numbers (I am on the fence on that one) and what would be our solution for call transfer (which might involve the use of gruus). It could be that in satisfying these issues we would end up with a solution that really is not significantly simpler, or could deal with email-style AORs too. So we need to drill down into what really is meant. Thanks, Dean, for kicking this off.

The motivation for restricting to AORs based on E.164 numbers was basically that E.164 numbers are not tied to domains, and the practice of changing the domain part of a SIP URI without changing the user part is more palatable. However, Hadriel has recently argued (and found support from some people) that this is outside the scope of MARTINI. Either my request starts off being targeted at sip:[email-masked] and DNS takes it first to the SP (the SP having delegated responsibility for pbx.com), which then uses MARTINI procedures to route to pbx.com. Or my request starts off being targeted at sip:[email-masked], and on arrival at the SP there is some manipulation of the Request-URI so that it becomes sip:[email-masked]. It is this manipulation that seems to be acceptable for E.164-based AORs but not for others. But, as Hadriel points out, MARTINI does not need to cover the issue of how the request reaches the SP, only the fact that the SP has a request targeted at pbx.com and needs a means of routing it there. So in my opinion, motivation for limiting to E.164-based AORs is rather weak. Nevertheless, if we can indeed come up with something simpler by having this limitation, that would be fine if we have a suitable story for related issues (private number, call transfer, etc.).

By the way, I don't think the fact that numbers are more amenable to regex is a particularly compelling argument for limiting to numbers. Number portability is fragmenting the number space anyway, and a solution that works only in the absence of major fragmentation would not be acceptable.

More below in response to Dean's individual points.

> private-number "phone contexts"?
[JRE] We need support for private numbers at some stage. If we can show that a satisfactory solution can be found more easily and quickly for E.164 numbers only, I would accept that.

> identity, and then dynamically only register the PBX identity to the  
[JRE] It is not necessary to explicitly encode the telephone numbers in the REGISTER request. If we can use reg-event without modification to obtain that information, that would be fine. If reg-event requires enhancement, or we need to rely on a provisioning protocol, that should not be allowed to delay the basic MARTINI mechanism.

> numbers and private phone-contexts in one format.
[JRE]I am not enthusiastic about using tel URIs. I don't see what it would solve, and it would introduce issues. Unless we still limit it to E.164-based tel URIs, we would still have the issue of domain-specific AORs.

> 4) What happens with GRUUs?
[JRE] I think the fundamental question is what is our story for call transfer. One possible story would be to rely on 3PCC, so the PBX and SP would not send REFER and/or Replaces across the interface. I hear cries of horror, but in practice this is what happens mostly today. In particular, policy issues can make a domain nervous about accepting a REFER request from another domain.

Another possibility would be for the SP to treat contact URIs from the PBX as local and map to global contact URIs (in its own domain) for passing onwards, so that any inbound request to the contact will arrive at the SP and be mapped back to the local contact URI provided by the PBX. It means the SP has to operate as a B2BUA.

To do the job properly, the PBX needs to issue a gruu (I use lower case here, to mean that the contact URI needs to be globally routable, without necessarily implying that the PBX has used GRUU procedures between it and its local UA). Public gruus can be based on E.164 numbers (they just have a parameter attached), but temporary gruus cannot be done in this way and effectively are "email-style". If we decide we have to allow the PBX to mint temporary gruus, we lose any benefit of limiting to E.164-based AORs.

Besides call transfer, gruus have been suggested in the context of ECRIT, for making a call-back to the device that made an emergency call. A mechanism whereby the SP maps local contacts to global contacts should work for this too.

> like a tequila shot and just slam it down?
[JRE] In summary, I am not yet convinced that the problem with non-E.164-based or non-number-based AORs is intractable or that limiting to E.164-based or number-based AORs represents a feasible simplification, but I am willing to explore further.

John

---

From: Dean Willis <[email-masked]>
Date: Wed, 27 Jan 2010 10:04:18 -0600

On Jan 27, 2010, at 4:19 AM, Elwell, John wrote:

>
>
> The motivation for restricting to AORs based on E.164 numbers was  
> basically that E.164 numbers are not tied to domains, and the  
> practice of changing the domain part of a SIP URI without changing  
> the user part is more palatable. However, Hadriel has recently  
> argued (and found support from some people) that this is outside the  
> scope of MARTINI. Either my request starts off being targeted at sip:[email-masked] 
>  and DNS takes it first to the SP (the SP having delegated  
> responsibility for pbx.com), which then uses MARTINI procedures to  
> route to pbx.com. Or my request starts off being targeted at sip:[email-masked] 
> , and on arrival at the SP there is some manipulation of the Request- 
> URI so that it becomes sip:[email-masked]. It is this manipulation  
> that seems to be acceptable for E.164-based AORs but not for others.  
> But, as Hadriel points out, MARTINI does not need to cover the issue  
> of how the request reaches the SP, only the fact that the SP has a  
> request targeted at pbx.com and needs a means of routing it there.  
> So in my opinion, motivation for limiting to E.164-based AORs is  
> rather weak. Nevertheless, if we can indeed come up with something  
> simpler by having this limitation, that would be fine if we have a  
> suitable story for related issues (private number, call transfer,  
> etc.).

Richard sees to be  saying that the use case "A call shows up at SSP  
with a URI of @pbx.com" is out-of-scope for his use case (except  
POSSIBLY for the result of call transfer).

The fundamental SIPConnect use cases, as I understand them, are:

1) A call shows up at an SSP's gateway for some phone number, say  
"+15125551212". The gateway sends the resulting INVITE to SSP's proxy.  
How does this proxy know which PBX to send the call to?

2) An INVITE shows up at an SSP's SBC for some phone number, say  
"+15125551212" that is scoped to the SSP's domain by being  
"@ssp.com"". The SBC forwards the INVITE to SSP's proxy.  How does  
this proxy know which PBX to send the call to?

Where, in the SIPConnect model, does "@pbx.com" come into play? We've  
suggested that it might do so, if PBX mints and uses a GRUU, and that  
GRUU is scoped into the domain of "pbx.com". But this is silly; the  
whole reason for using MARTINI is that "@pbx.com" is either useless,  
or points to the SSP. So really, what we need to do is have the SSP  
mint a GRUU, scoped to "@ssp.com", which is then used by PBX in call- 
transfer scenarios.

Is there any other reason to have "@pbx.com" in the current problem  
scope?

Yes, figuring out how to do dynamically-associated relay services for  
domain-scoped messages is important. But it's a different and  
completely separable problem (although once solved, we might find that  
the solution backward-applies to the telephone problem). However, I  
firmly believe that solving it requires solving some of the  
fundamental design problems in SIP, such as the fact that our model  
for registering a multi-hop route is pretty hokey (combining RFC  
3261's REGISTER, Service-Route, Path, Outbound, connect-Reuse, and a  
mess of unimplemented public keys stuff). I think it's gonna be a  
while before we solve the general dynamically-associated relay  
services for domain-scoped messages problem.

  --
Dean

---

From: Doug Sauder <[email-masked]>
Date: Wed, 27 Jan 2010 20:22:49 -0500

Hi, all!

I have been wanting to jump into the discussion here as a contributor who has experience with the SSP-side software.  I have been at BroadSoft for long time, and I have extensive knowledge of BroadSoft's SIP trunking technology.  I point this out, because I'm not using my BroadSoft email address, which would have made my affiliation more obvious.

Sorry that I can't speak from the perspective of an actual SSP -- only from that of a technology provider.

As a B2BUA at the SSP, we make a clear distinction between the network side interface (facing a PSTN gateway, for example) and the access side interface (facing a PBX, most likely behind an SBC or two).  On the network side, outside of an IMS deployment, we deal almost exclusively with telephone numbers.  From the PSTN, those would be E.164 numbers.  On the access side, there are a number of options that can be configured ("contact routing" being one of them).  A key point is that every PBX subscriber is provisioned by the SSP, and it is not necessary for a REGISTER to tie AORs and contact URIs explicitly.  Of course, the SSP wants to provide not only PSTN connectivity to their customers, but also value-added services, such as services for teleworkers (as was brought up earlier on the Martini list).  Thus, the explicit provisioning of subscribers by the SSP is pretty standard practice.  This provides the answer to John's question below, about how the "proxy" knows which PBX to route to: it is explicitly provisioned by the SSP.

On some of the points that were raised in the last few days, my two cents...

1. I definitely agree that narrowing the problem to focus on E.164 numbers yields a lot of bang for the buck.  I don't see a problem with non-E.164 numbers, though, as the phone context provides a namespace and doesn't imply anything about routing.

2. The "contact routing" option makes a lot of sense to me, in that it avoids a lot of the problems that have been discussed.

3. I see no need to use a P-Associated-URI header field or similar header field in a REGISTER response.  I don't see how it is that useful for troubleshooting, as the administrative staff of the PBX and has some self-service administrative privileges at the SSP.

--
Doug

On Jan 27, 2010, at 11:04 , Dean Willis wrote:

> Richard sees to be  saying that the use case "A call shows up at SSP with a URI of @pbx.com" is out-of-scope for his use case (except POSSIBLY for the result of call transfer).
> 
> 1) A call shows up at an SSP's gateway for some phone number, say "+15125551212". The gateway sends the resulting INVITE to SSP's proxy. How does this proxy know which PBX to send the call to?
> 
> 2) An INVITE shows up at an SSP's SBC for some phone number, say "+15125551212" that is scoped to the SSP's domain by being "@ssp.com"". The SBC forwards the INVITE to SSP's proxy.  How does this proxy know which PBX to send the call to?
> 
> 
> Where, in the SIPConnect model, does "@pbx.com" come into play? We've suggested that it might do so, if PBX mints and uses a GRUU, and that GRUU is scoped into the domain of "pbx.com". But this is silly; the whole reason for using MARTINI is that "@pbx.com" is either useless, or points to the SSP. So really, what we need to do is have the SSP mint a GRUU, scoped to "@ssp.com", which is then used by PBX in call-transfer scenarios.
> 
> Is there any other reason to have "@pbx.com" in the current problem scope?
> 
> 
> Yes, figuring out how to do dynamically-associated relay services for domain-scoped messages is important. But it's a different and completely separable problem (although once solved, we might find that the solution backward-applies to the telephone problem). However, I firmly believe that solving it requires solving some of the fundamental design problems in SIP, such as the fact that our model for registering a multi-hop route is pretty hokey (combining RFC 3261's REGISTER, Service-Route, Path, Outbound, connect-Reuse, and a mess of unimplemented public keys stuff). I think it's gonna be a while before we solve the general dynamically-associated relay services for domain-scoped messages problem.
> 
> 
> --
> Dean

---

From: <[email-masked]>
Date: Thu, 28 Jan 2010 11:05:40 +0100

Looking  to this proposal, another question comes to my mind. There is something that I don't understand from an Industry viewpoint.

- 3GPP/ETSI have defined a solution that applies to all types of identities (E.164 numbers, private numbers and email-style URI). For various reasons this solution is not deemed suitable by the MARTINI community. 

- The alternative proposal seems to be to first create a near-time solution that works for E.164 numbers only and address the other cases at a later stage, possibly through a totally different solution. 

Considering that the three types of identities will have to be supported at some point in time anyway, I'm wondering what could be the motivation of the Industry to adopt the E.164-only solution as a near-term solution rather than the 3GPP/ETSI solution? This can only happen if the E-164 solution has very strong benefits and the 3GPP/ETSI solution has major flaws that prevents its implementation.

/BC

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Dean Willis
> Envoyé : mercredi 27 janvier 2010 07:16
> À : [email-masked]
> Objet : [martini] Proposed work split: tackle 
> telephone-number registrationfirst
> 
> 
> We seem to have an urgent need for a near-term solution for 
> dealing with the subset of the MARTINI problem that, loosely 
> defined, covers the "telephone number" problem.
> 
> The typical scenario here is SIP trunking, wherein a SIP 
> Service Provider (SSP) provides an ISDN-PRI like service over 
> IP to a  
> of phone numbers to the PBXes. This mapping is somewhat 
> dynamic, because the PBXes usually have DHCP addresses, and 
> don't have DNS entries that point A records at the PBX in any 
> sort of particularly useful way (maybe something like 
> dhcp-10-1-2-3-example.com).
> 
> periodically) to say to the SSP "Here I Am; You may now send 
> any calls for my assigned phone numbers to my current Contact."
> 
> This is indeed a "registration" problem, but it isn't 
> necessarily a "domain registration problem". The only reason 
> domains get mixed into this scenario at all is that we 
> sometimes encode telephone numbers as the user parts of SIP 
> URIs, and those SIP URIs have a domain part attached to them.
> 
> More interestingly, this problem is a tiny subset of the 
> whole MARTINI dynamic binding problem, and it potentially can 
> be solved much more simply than the general problem.
> 
> On today's Interim II call, Richard, Adam and I raised the 
> idea of dividing our problem space, and taking on a near-term 
> milestone for delivering a MARTINI solution for registering 
> contacts to a proxy, where that proxy maps one or more 
> telephone numbers to the contact.
> 
> We certainly intend to go on and tackle the more general 
> domain- registration problem, but I (and I believe Adam and 
> Richard) believe that we get a lot out of tackling the 
> telephone-number subset first.
> 
> In particular, we believe that this approach solves many of 
> the domain "responsibility" questions, simplifies the TLS 
> keying/certification model immensely, eliminates the 
> cognitive overload of using REGISTER to bind a "domain" to a 
> Contact, "route authentication", and a good many other open 
> issues that plague our current drafts.
> 
> 
> 1) Do we deal only with E.164 numbers, or do we need to deal 
> with private-number "phone contexts"?
> 
> 2) D owe need to explicitly encode the telephone numbers 
> being registered in the REGISTER request (either directly or 
> through some sort of regexp), or is it adequate to rely on 
> provisioning of the SSP and PBX (and any UAs) to statically 
> bind the numbers to the PBX identity, and then dynamically 
> only register the PBX identity to the PBX contact?
> 
> 3) Can we "register" with a tel: URI as the "To" value? (this 
> seems to require extending RFC 3261)? Note that "tel:" can 
> express both E.164 numbers and private phone-contexts in one format.
> 
> I believe all of these issues are quite tractable, if we 
> accept the fundamental idea of splitting the phone-number 
> problem off from the more general domain-registration, and 
> recognize the possibility that the solutions to the two 
> problem may reasonably be quite different from each other.
> 
> So, what do you people think? Is it worth trying to drink the 
> MARTINI elephant one sip at a time, or are we going to treat 
> the whole thing like a tequila shot and just slam it down?
> 
> --
> Dean
> 
> 
> 
> 
> 
> 

*********************************
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: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jan 2010 11:58:41 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Doug Sauder
> Sent: Wednesday, January 27, 2010 8:23 PM
> To: Dean Willis
> A key point is that every PBX
> subscriber is provisioned by the SSP, and it is not necessary for a
> REGISTER to tie AORs and contact URIs explicitly.  Of course, the SSP
> wants to provide not only PSTN connectivity to their customers, but also
> value-added services, such as services for teleworkers (as was brought up
> earlier on the Martini list).  Thus, the explicit provisioning of
> subscribers by the SSP is pretty standard practice.  This provides the
> answer to John's question below, about how the "proxy" knows which PBX t
>  o route to: it is explicitly provisioned by the SSP.

Yes but we're trying to avoid that - obviously the phone numbers and shared secret password stuff has to be provisioned in the SSP, but we're trying to avoid provisioning the IP:port and transport of the PBX and which specific proxies/SBCs to traverse to reach it (so that, for example, the proxies/SBCs can dynamically change easily).  This wouldn't be for large company IP-PBX's really - someone like WalMart or GE or whatever would get white-glove treatment by their SSP's anyway... this is more for the SMB market.

> 3. I see no need to use a P-Associated-URI header field or similar header
> field in a REGISTER response.  I don't see how it is that useful for
> troubleshooting, as the administrative staff of the PBX and has some self-
> service administrative privileges at the SSP.

It was for two reasons: (1) the troubleshooting aspect, where an SMB doesn't have an "administrative staff" for PBX's and even for the SSP it would be nice to get a log/alarm of mismatched numbers a priori, and (2) for the P-CSCF/edge-proxy/SBC's which do P-Asserted-ID assertion or call blocking of unknown/unregistered sources.  But I don't know if it's worth it in the end, if folks get hung up over it here.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jan 2010 12:24:34 -0500

Hi Bruno, comments inline...

> Of [email-masked]
> Sent: Thursday, January 28, 2010 5:06 AM
> 
> Looking  to this proposal, another question comes to my mind. There is
> something that I don't understand from an Industry viewpoint.
> 
> - 3GPP/ETSI have defined a solution that applies to all types of
> identities (E.164 numbers, private numbers and email-style URI). For
> various reasons this solution is not deemed suitable by the MARTINI
> community.

Martini was instigated from work we were doing in SIP-Forum, and in the SIP-Forum at one point we were nearly identical to the 3gpp/etsi mechanism, but technical objections and issues were raised, which drove us to go to the IETF.  The 50,000ft view of the issues were that the 3gpp/etsi model "works" as long as everyone's on the same page - that they all happen to be provisioned to implement the exact same procedures from the same version of the specs.  They all have to know that the "normal" procedures of 3261 are not being followed, and they have to know which procedures are being followed, without any on-the-wire indication that or what they are.  For example, they have to know that the request-URI is or is not going to be the registered contact (it can be either way, just based on a provisioned field). 

That's all fine on the SSP-side, because presumably they control all their own equipment.  But on the Enterprise side it's harder.  In particular, while we've seen plenty of IMS equipment support it, we've seen a very small percentage of PBX's do so, relatively.

Obviously the same will/can be said of any Martini or SIP-Forum work - all the devices will have to do Martini (whatever it is) for it to work.  There will be an on-the-wire indication of it, so at least one can know what the other device does or needs, so that's better, but at the end of the day as you said the question is whether the industry will adopt it.  In the best case scenario 3GPP, ETSI, SIP-Forum, and CableLabs will all adopt the Martini work - possibly as an alternative, or maybe even as the new way.  For example the draft-shaken model is very close/similar to the current 3gpp model.  

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jan 2010 12:29:16 -0500

This is a great summary of the issues.  I don't actually think focusing on E.164 numbers will make this any easier, and my guess is the solution we come up with for that will work for private numbers and email-style too, but just to move forward I'm game to focus on just E.164.

BTW, the concerns raised on the call/list kept using the phrase "domain registration" as an issue - were you referring to the draft-stirred model?  Is the draft-shaken model more palatable then?  I was all for dismissing the draft-stirred one at the first Virtual meeting, and still am. :)

-hadriel

> Of Dean Willis
> Sent: Wednesday, January 27, 2010 1:16 AM
> To: [email-masked]
> registration first

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jan 2010 12:36:01 -0500

BTW, I find it funny how folks are all concerned about Domain ownership and the security properties of allowing a device to Register a Domain name for SIP request routing to, but when it comes to whole blocks of E.164 numbers we're all fine and dandy with a device claiming ownership of that.  This despite the fact that E.164's are the 99% use case for SIP at large.  Like it's scary that a device could claim to be responsible for SIP of cisco.com, but it's ok if it claims to be all of Cisco's E.164 numbers. :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Jan 2010 12:50:48 -0500

> BTW, I find it funny how folks are all concerned about Domain ownership and the security properties of allowing a device to Register a Domain name for SIP request routing to, but when it comes to w…

There is, I think, a big difference.

Claiming ownership doesn't mean that you will be granted ownership.
In the case of phone numbers, I have been assuming that the SSP knows 
which numbers it has control over, and which have been contractually 
agreed to be delegated to the PBX.

But the SSP isn't in charge of domain names.
If I register with the SSP and say I want to receive requests for 
whitehouse.gov, how can it determine if that is proper or not?

It could if *it* registered the domain names on behalf of the customers. 
But if the customer says to the SSP "I already own this domain and will 
arrange for requests to it to be routed to you, so when you get them 
please forward them on to my pbx", how is the SSP to decide if that is 
ok or not?

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Jan 2010 13:18:01 -0500

And, I know of providers out there that can vouch for the voracity of  
TN ownership :-)

On Jan 28, 2010, at 12:50 PM, Paul Kyzivat wrote:

>
>
> Hadriel Kaplan wrote:
>> BTW, I find it funny how folks are all concerned about Domain  
>> ownership and the security properties of allowing a device to  
>> Register a Domain name for SIP request routing to, but when it  
>> comes to whole blocks of E.164 numbers we're all fine and dandy  
>> with a device claiming ownership of that.  This despite the fact  
>> that E.164's are the 99% use case for SIP at large.  Like it's  
>> scary that a device could claim to be responsible for SIP of  
>> cisco.com, but it's ok if it claims to be all of Cisco's E.164  
>> numbers. :)
>
> In the case of phone numbers, I have been assuming that the SSP  
> knows which numbers it has control over, and which have been  
> contractually agreed to be delegated to the PBX.
>
> It could if *it* registered the domain names on behalf of the  
> customers. But if the customer says to the SSP "I already own this  
> domain and will arrange for requests to it to be routed to you, so  
> when you get them please forward them on to my pbx", how is the SSP  
> to decide if that is ok or not?
>
> 	Thanks,
> 	Paul
>
>> -hadriel
>>> seems to
>>> MARTINI

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Jan 2010 13:19:45 -0500

More to the point, we have absolutely no intention of doing the ETSI/ 
3GPP thing of creating something that looks almost compatible with  
SIP, but really is not. The mechanism here, while it needs MARTINI- 
aware devices to be aware of MARTINI (no sequitur of the day), non- 
MARTINI-aware devices will still be able to communicate with MARTINI- 
aware devices, and vice-versa.  The same is NOT true of the ETSI/3GPP  
approach.

On Jan 28, 2010, at 12:24 PM, Hadriel Kaplan wrote:

>> Behalf
> Martini was instigated from work we were doing in SIP-Forum, and in  
> the SIP-Forum at one point we were nearly identical to the 3gpp/etsi  
> mechanism, but technical objections and issues were raised, which  
> drove us to go to the IETF.  The 50,000ft view of the issues were  
> that the 3gpp/etsi model "works" as long as everyone's on the same  
> page - that they all happen to be provisioned to implement the exact  
> same procedures from the same version of the specs.  They all have  
> to know that the "normal" procedures of 3261 are not being followed,  
> and they have to know which procedures are being followed, without  
> any on-the-wire indication that or what they are.  For example, they  
> have to know that the request-URI is or is not going to be the  
> registered contact (it can be either way, just based on a  
> provisioned field).
>
> That's all fine on the SSP-side, because presumably they control all  
> their own equipment.  But on the Enterprise side it's harder.  In  
> particular, while we've seen plenty of IMS equipment support it,  
> we've seen a very small percentage of PBX's do so, relatively.
>
> Obviously the same will/can be said of any Martini or SIP-Forum work  
> - all the devices will have to do Martini (whatever it is) for it to  
> work.  There will be an on-the-wire indication of it, so at least  
> one can know what the other device does or needs, so that's better,  
> but at the end of the day as you said the question is whether the  
> industry will adopt it.  In the best case scenario 3GPP, ETSI, SIP- 
> Forum, and CableLabs will all adopt the Martini work - possibly as  
> an alternative, or maybe even as the new way.  For example the draft- 
> shaken model is very close/similar to the current 3gpp model.
>
> -hadriel

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Jan 2010 13:32:25 -0500

If you ask me (why can't I stay in retirement?), the E.164 situation  
is not only a simplification, but just about the only thing that is  
sensible for MARTINI to work on.

The E.164 situation is a clear, present, industry-is-begging-for-a- 
solution problem.  It is so pressing, the industry will tell us (the  
IETF) to get stuffed and do something stupid if we cannot deliver  
something that is not at its core fundamentally broken.

I do not think anyone can have an issue with mechanisms that translate  
a string of digits into an AOR that might cross domain boundaries.   
This is the E.164 problem statement.

If think everyone (with a brain) SHOULD have issues with a mechanism  
that magically mungs "sip:[email-masked]" into "sip:[email-masked] 
" while at the same time www.neustar.biz is really a neustar.biz  
domain.  That really would be creating a parallel DNS, which, as one  
of the major DNS operators, would really, really be "less than ideal"  
and have a whole host of security and integrity issues.

THEREFORE, I would propose that we split this work into two phases:
   Phase 1: Deliver an E.164 solution, preferably in the next few  
months, so the industry does not ignore the IETF.

   Phase 2: Deliver the generic solution in the normal, 3-5 year IETF  
cycle.  This generic solution may or may not encompass E.164 numbers.   
As Doug Sauder points out, E.164 numbers and their infrastructure are  
different.  Thus a different E.164 registration model from generic SIP  
URI provisioning models would neither be a burden on industry nor  
create backwards-compatibility issues for the generic solution.

Note that if we do not deliver Phase 1 in a very, very timely manner,  
the less-than-idea industry solution just might blow up the  
possibility for the generic solution, which would be considerably less  
than ideal.

On Jan 27, 2010, at 1:16 AM, Dean Willis wrote:

> customer's PBX (or PBXes). In this model, the SSP maps a whole  
> bunch  of phone numbers to the PBXes. This mapping is somewhat  
> dynamic, because the PBXes usually have DHCP addresses, and don't  
> have DNS entries that point A records at the PBX in any sort of  
> particularly useful way (maybe something like dhcp-10-1-2-3- 
> example.com).
>
> periodically) to say to the SSP "Here I Am; You may now send any  
> calls for my assigned phone numbers to my current Contact."
>
> "domain registration problem". The only reason domains get mixed  
> into this scenario at all is that we sometimes encode telephone  
> numbers as the user parts of SIP URIs, and those SIP URIs have a  
> domain part attached to them.
>
> More interestingly, this problem is a tiny subset of the whole  
> MARTINI dynamic binding problem, and it potentially can be solved  
> much more simply than the general problem.
>
> In particular, we believe that this approach solves many of the  
> domain "responsibility" questions, simplifies the TLS keying/ 
> certification model immensely, eliminates the cognitive overload of  
> using REGISTER to bind a "domain" to a Contact, "route  
> authentication", and a good many other open issues that plague our  
> current drafts.
>
>
> sort of regexp), or is it adequate to rely on provisioning of the  
> SSP and PBX (and any UAs) to statically bind the numbers to the PBX  
> 3) Can we "register" with a tel: URI as the "To" value? (this seems  
> to require extending RFC 3261)? Note that "tel:" can express both E. 
> 164 numbers and private phone-contexts in one format.
>
> MARTINI elephant one sip at a time, or are we going to treat the  
> whole thing like a tequila shot and just slam it down?
>
> --
> Dean
>
>
>
>
>
>

---

From: Doug Sauder <[email-masked]>
Date: Thu, 28 Jan 2010 13:46:16 -0500

Below...

> Yes but we're trying to avoid that - obviously the phone numbers and shared secret password stuff has to be provisioned in the SSP, but we're trying to avoid provisioning the IP:port and transport…
[DWS] Well, the IP address is not provisioned in most cases, but 
typically comes from a registration from the PBX.  My point was, that 
the SSP knows the association of phone numbers -- hence subscribers -- 
to the PBX.  It is not necessary for any registration from the PBX to 
tell the SSP who its subscribers are, or which DIDs it's claiming.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 28 Jan 2010 15:39:18 -0600

OK, this discussion continues to be lovely. Thanks again for listening to 
the people you're talking to ("plays well with others" is under-appreciated, 
once we get out of primary school, but *I* appreciate it!)

After reading this thread down through Eric's note below, I have a few 
requests, as co-chair.

We're talking about E.164 numbers like we can easily identify them. My
understanding from Tuesday's call was that people on the call thought the
only way we could unambiguously know that we had an E.164 number was if we
had a tel: URI. If people on this list want to challenge that assertion, 
this would
be a great time to say so - please push back Real Soon Now.

If that's true, we're talking about using Tel: URIs. Dean has asserted that 
this would require an update to 3261. I'm not a genius of 3261, but some of 
you guys are - could you point us to what you think needs to be updated?

My quick read turned up this text in Section 4, page 17:

   Registration is another common operation in SIP.  Registration is one
   way that the biloxi.com server can learn the current location of Bob.
   Upon initialization, and at periodic intervals, Bob's SIP phone sends
   REGISTER messages to a server in the biloxi.com domain known as a SIP
   registrar.  The REGISTER messages associate Bob's SIP or SIPS URI
   (sip:[email-masked]) with the machine into which he is currently
   logged (conveyed as a SIP or SIPS URI in the Contact header field).

Dean, Is this what you were thinking of? Are there other places that also 
need to change?

As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, 
Section 2.1, this change would have to go through SIPCORE, because it's an 
update to 3261. If you know of obvious land mines that we would be walking 
into if we propose this change, please say so Real Soon Now. (One obvious 
land mine is that DISPATCH isn't meeting in Anaheim, so the proposal would 
have to be DISPATCHed on the mailing list in order to do something before 
IETF 78 - are there OTHERS?)

Finally, if you believe that embracing tel: URIs is the wrong thing to do, 
please say so, Real Soon Now.

The milestones that we committed to in 
http://tools.ietf.org/wg/martini/charters have us adopting a working group 
SOLUTION draft in January. We're not late yet, but it's the 28th of January 
in my time zone. If we are late, where late is measured in days, I can live 
with that, but if we are late, where late is measured in IETF meeting 
cycles, that's going to be a problem.

Thanks,

Spencer, as co-chair

----- Original Message ----- 
From: "Eric Burger" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 28, 2010 12:32 PM
Subject: Re: [martini] Proposed work split: tackle
telephone-numberregistration first

> If you ask me (why can't I stay in retirement?), the E.164 situation  is
> not only a simplification, but just about the only thing that is  sensible
> for MARTINI to work on.
>
> I do not think anyone can have an issue with mechanisms that translate  a
> string of digits into an AOR that might cross domain boundaries.   This is
> the E.164 problem statement.
>
> If think everyone (with a brain) SHOULD have issues with a mechanism  that
> magically mungs "sip:[email-masked]" into "sip:[email-masked] "
> while at the same time www.neustar.biz is really a neustar.biz  domain.
> That really would be creating a parallel DNS, which, as one  of the major
> DNS operators, would really, really be "less than ideal"  and have a whole
> host of security and integrity issues.
>
>   Phase 1: Deliver an E.164 solution, preferably in the next few  months,
> so the industry does not ignore the IETF.
>
> cycle.  This generic solution may or may not encompass E.164 numbers.   As
> Doug Sauder points out, E.164 numbers and their infrastructure are
> URI provisioning models would neither be a burden on industry nor  create
> backwards-compatibility issues for the generic solution.
>
> Note that if we do not deliver Phase 1 in a very, very timely manner,  the
> less-than-idea industry solution just might blow up the  possibility for
> the generic solution, which would be considerably less  than ideal.
>
>> We seem to have an urgent need for a near-term solution for dealing  with
>> the subset of the MARTINI problem that, loosely defined, covers  the
>> "telephone number" problem.
>>
>> Provider (SSP) provides an ISDN-PRI like service over IP to a  customer's
>> PBX (or PBXes). In this model, the SSP maps a whole  bunch  of phone
>> numbers to the PBXes. This mapping is somewhat  dynamic, because the
>> PBXes usually have DHCP addresses, and don't  have DNS entries that point
>> A records at the PBX in any sort of  particularly useful way (maybe
>> something like dhcp-10-1-2-3- example.com).
>>
>> delivering a MARTINI solution for registering contacts to a proxy,  where
>> that proxy maps one or more telephone numbers to the contact.
>>
>> "responsibility" questions, simplifies the TLS keying/ certification
>> model immensely, eliminates the cognitive overload of  using REGISTER to
>> bind a "domain" to a Contact, "route  authentication", and a good many
>> other open issues that plague our  current drafts.
>>
>>
>> registered in the REGISTER request (either directly or through some  sort
>> of regexp), or is it adequate to rely on provisioning of the  SSP and PBX
>> (and any UAs) to statically bind the numbers to the PBX  identity, and
>> then dynamically only register the PBX identity to the  PBX contact?
>>
>> require extending RFC 3261)? Note that "tel:" can express both E. 164
>> fundamental idea of splitting the phone-number problem off from the  more
>> general domain-registration, and recognize the possibility that  the
>> solutions to the two problem may reasonably be quite different  from each
>> other.
>>

---

From: "Brian Lindsay" <[email-masked]>
Date: Thu, 28 Jan 2010 16:48:00 -0500

Hi Spencer,

   I am not sure if this is going down the path that the actual register
request uses a Tel: URI.

   If so, I don't see why that needs to be the case. The REGISTER itself
can still be done per Martini-Shaken with a SIP URI representing the SIP
PBX. In fact, I am not sure too much has to change with Martini-Shaken
unless you want to enforce use of a Tel URI format for requests sent
towards the SIP PBX.

   Thanks
      Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: Thursday, January 28, 2010 4:39 PM
To: Eric Burger; Dean Willis
Cc: [email-masked]
Subject: Re: [martini] Proposed work split:
tackletelephone-numberregistration first

OK, this discussion continues to be lovely. Thanks again for listening
to the people you're talking to ("plays well with others" is
under-appreciated, once we get out of primary school, but *I* appreciate
it!)

We're talking about E.164 numbers like we can easily identify them. My
understanding from Tuesday's call was that people on the call thought
the only way we could unambiguously know that we had an E.164 number was
if we had a tel: URI. If people on this list want to challenge that
assertion, this would be a great time to say so - please push back Real
Soon Now.

If that's true, we're talking about using Tel: URIs. Dean has asserted
that this would require an update to 3261. I'm not a genius of 3261, but
some of you guys are - could you point us to what you think needs to be
updated?

Dean, Is this what you were thinking of? Are there other places that
also need to change?

As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt,
Section 2.1, this change would have to go through SIPCORE, because it's
an update to 3261. If you know of obvious land mines that we would be
walking into if we propose this change, please say so Real Soon Now.
(One obvious land mine is that DISPATCH isn't meeting in Anaheim, so the
proposal would have to be DISPATCHed on the mailing list in order to do
something before IETF 78 - are there OTHERS?)

Finally, if you believe that embracing tel: URIs is the wrong thing to
do, please say so, Real Soon Now.

The milestones that we committed to in
http://tools.ietf.org/wg/martini/charters have us adopting a working
group SOLUTION draft in January. We're not late yet, but it's the 28th
of January in my time zone. If we are late, where late is measured in
days, I can live with that, but if we are late, where late is measured
in IETF meeting cycles, that's going to be a problem.

Thanks,

Spencer, as co-chair

----- Original Message -----
From: "Eric Burger" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 28, 2010 12:32 PM
Subject: Re: [martini] Proposed work split: tackle

> If you ask me (why can't I stay in retirement?), the E.164 situation
is
> I do not think anyone can have an issue with mechanisms that translate
a
> If think everyone (with a brain) SHOULD have issues with a mechanism
that
>   Phase 1: Deliver an E.164 solution, preferably in the next few
months,
> cycle.  This generic solution may or may not encompass E.164 numbers.
As
> URI provisioning models would neither be a burden on industry nor
create
> Note that if we do not deliver Phase 1 in a very, very timely manner,
the
>> We seem to have an urgent need for a near-term solution for dealing
with
>> Provider (SSP) provides an ISDN-PRI like service over IP to a
customer's
>> periodically) to say to the SSP "Here I Am; You may now send any
calls
>> "domain registration problem". The only reason domains get mixed
into
MARTINI
>> delivering a MARTINI solution for registering contacts to a proxy,
where
>> In particular, we believe that this approach solves many of the
domain
>> model immensely, eliminates the cognitive overload of  using REGISTER
to
>> registered in the REGISTER request (either directly or through some
sort
>> 3) Can we "register" with a tel: URI as the "To" value? (this seems
to
>> fundamental idea of splitting the phone-number problem off from the
more
MARTINI

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 28 Jan 2010 15:58:31 -0600

Hi, Brian,

Thanks for the quick feedback. I'm mostly asking if I'm reading where we are 
going correctly (I GOTTA get the draft minutes out from that call!).

This is kind of twisty-little-passages-all-alike/different (for those of you 
that remember the "adventure" game in the early 1980s), but I'm trying to 
follow the chain. Where I thought we were, was that we didn't have a 
coherent story for how we get a call from outside the service provider, to 
the service provider, to the SIP-PBX, and I've heard a bunch of smart guys 
talk for a long time on a number of occasions about how that might work/not 
work, usually ending with "but if this was limited to E.164 numbers, a lot 
of these problems would go away".

So I'm trying to laces comments from the call that I remember together, and 
see what the resulting tapestry looks like.

Tell you what. I'll go work on draft minutes and stop typing e-mail, and 
we'll see if that works better :D

Spencer

----- Original Message ----- 
From: "Brian Lindsay" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Eric Burger" 
<[email-masked]>; "Dean Willis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 28, 2010 3:48 PM
Subject: RE: [martini] Proposed work split: 
tackletelephone-numberregistration first

Hi Spencer,

   Thanks
      Brian

-----Original Message-----

Thanks,

Spencer, as co-chair

----- Original Message -----
From: "Eric Burger" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 28, 2010 12:32 PM
Subject: Re: [martini] Proposed work split: tackle

is
a
that
months,
As
create
the
with
customer's
calls
into
MARTINI
where
domain
to
sort
to
more
MARTINI

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Jan 2010 23:01:09 +0100

Gee great - Lets all just throw in a few unspecific comments about the non-interoperability of 3GPP specs and we'll win all the IETF arguments.

I think you'll find it is the people who use the specs, be it IETF, 3GPP or whatever, that bend the rules that cause those problems. 

Keith 

> [mailto:[email-masked]] On Behalf Of Eric Burger
> Sent: Thursday, January 28, 2010 6:20 PM
> To: [email-masked]
> Cc: [email-masked]
> More to the point, we have absolutely no intention of doing 
> the ETSI/ 3GPP thing of creating something that looks almost 
> compatible with SIP, but really is not. The mechanism here, 
> while it needs MARTINI- aware devices to be aware of MARTINI 
> (no sequitur of the day), non- MARTINI-aware devices will 
> still be able to communicate with MARTINI- aware devices, and 
> vice-versa.  The same is NOT true of the ETSI/3GPP approach.
> 
> [mailto:[email-masked]] On 
> >> Behalf Of [email-masked]
> >> Looking  to this proposal, another question comes to my 
> mind. There 
> >> is something that I don't understand from an Industry viewpoint.
> >>
> > drove us to go to the IETF.  The 50,000ft view of the 
> issues were that 
> > the 3gpp/etsi model "works" as long as everyone's on the 
> same page - 
> > that they all happen to be provisioned to implement the exact same 
> > procedures from the same version of the specs.  They all 
> have to know 
> > that the "normal" procedures of 3261 are not being 
> followed, and they 
> > have to know which procedures are being followed, without any 
> > on-the-wire indication that or what they are.  For example, 
> they have 
> > to know that the request-URI is or is not going to be the 
> registered 
> > contact (it can be either way, just based on a provisioned field).
> >
> > particular, while we've seen plenty of IMS equipment 
> support it, we've 
> > seen a very small percentage of PBX's do so, relatively.
> >
> > work.  There will be an on-the-wire indication of it, so at 
> least one 
> > can know what the other device does or needs, so that's 
> better, but at 
> > the end of the day as you said the question is whether the industry 
> > will adopt it.  In the best case scenario 3GPP, ETSI, SIP- 
> Forum, and 
> > CableLabs will all adopt the Martini work - possibly as an 
> > alternative, or maybe even as the new way.  For example the draft-

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Jan 2010 16:33:15 -0600

On 1/28/10 3:39 PM, Spencer Dawkins wrote:
> had a tel: URI. If people on this list want to challenge that 
> assertion, this would

I believe that's true. A large part of what we've been arguing over 
relates directly to questions around who is responsible for which 
actions when domains are involved. It is squarely the domains themselves 
that cause so much consternation and confusion in this context, and any 
simplifications that arise from limiting the scope to E.164 numbers are 
predicated _completely_ on the elimination of domains.

As far as I can tell, we really have two approaches we can consider:

    * Use tel: URIs. Their lack of domains eliminates domain-related issues.

    * Define a new sip: URI parameter that effectively means "the user
      portion is an E.164 number that can be evaluated by anyone in the
      world regardless of the domain attached to it." This isn't quite
      the same thing as "user=phone," although they do seem
      superficially similar. We would need to define rules around this
      parameter that effectively say, "if you see this parameter on a
      URI, you are free to discard the domain and act as responsible for
      the URI" (this is the material difference from "user=phone").

I like the first one because it's already specified.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Jan 2010 16:48:18 -0600

On 1/28/10 4:05 AM, [email-masked] wrote:
> I'm wondering what could be the motivation of the Industry to adopt the E.164-only solution as a near-term solution rather than the 3GPP/ETSI solution? This can only happen if the E-164 solution has very strong benefits and the 3GPP/ETSI solution has major flaws that prevents its implementation.
>    

It does, and we've been discussing them. The 3GPP approach demonstrably 
works in walled gardens modeled after the IMS architecture. However, we 
are not the Walled Garden Engineering Task Force, so we need to ensure 
it works on the Internet at large, including a multitude of 
architectures that don't resemble IMS in any useful way.

As far as I can tell, SIPForum is antsy to get something specified now, 
even if its very limited in scope. We determined on the call that many 
of the really controversial issues become inapplicable if we're willing 
to accept certain restrictions, all of which require scoping the work to 
E.164 numbers. I suspect this is true, and that we can knock out a 
solution very quickly within this tightly constrained scope.

And, to be sure, the scope restriction is somewhat tighter than just 
"E.164 numbers" -- it actually relates predominantly to the elimination 
of domains in the SSP-PBX signaling (which is possibly only if the user 
portion is universally unique, as in the case of E.164 numbers).

/a

---

From: "eburger" <[email-masked]>
Date: Fri, 29 Jan 2010 01:19:48 +0000

Agreed. 

--
Eric Burger

Sent from my mobile device; sorry if terse. All mobile users need lemonade.  See <http://www.standardstrack.com/ietf/lemonade> for more information.

-----Original Message-----
From: Adam Roach <[email-masked]>
Date: Thu, 28 Jan 2010 16:33:15 
To: Spencer Dawkins<[email-masked]>
Cc: Eric Burger<[email-masked]>; Dean Willis<[email-masked]>; <[email-masked]>
Subject: Re: [martini] Proposed work split: tackle	telephone-numberregistration
 first

/a

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 29 Jan 2010 11:33:01 +0100

> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 28 January 2010 22:33
> To: Spencer Dawkins
> Cc: [email-masked]
> 	had a tel: URI. If people on this list want to 
> challenge that assertion, this would 
> I believe that's true. A large part of what we've been 
> arguing over relates directly to questions around who is 
> responsible for which actions when domains are involved. It 
> is squarely the domains themselves that cause so much 
> consternation and confusion in this context, and any 
> simplifications that arise from limiting the scope to E.164 
> numbers are predicated _completely_ on the elimination of domains.
> 
> *	Define a new sip: URI parameter that effectively means 
> "the user portion is an E.164 number that can be evaluated by 
> anyone in the world regardless of the domain attached to it." 
> This isn't quite the same thing as "user=phone," although 
> they do seem superficially similar. We would need to define 
> rules around this parameter that effectively say, "if you see 
> this parameter on a URI, you are free to discard the domain 
> and act as responsible for the URI" (this is the material 
> difference from "user=phone").
> 	
> 
> 
[JRE]Let's drill down a bit further. I am assuming a REGISTER-based solution, where the REGISTER request contains a single AOR (in To/From) and implicitly registers a bunch of tel URIs. Does that single AOR need to be a tel URI, or could it be a SIP/SIPS URI? If it can be a SIP/SIPS URI, perhaps we don't need to change REGISTER beyond the sort of changes we already anticipated in MARTINI.

Secondly, how would the PBX populate From and PAI in outbound requests such as INVITE when the call originates at a UA having credentials appropriate for one of the registered tel URIs? Would there be an expectation that the tel URI be used in this case? Although outside the scope of what we are doing with SIPconnect at present, bear in mind that RFC 4474 cannot be used with a tel: URI. Also a tel: URI-based solution would seem to prevent the PBX minting its own gruus, which implies the need for the SSP to map local contacts to gruus and vice versa, thereby legitimising one of the things that we know breaks RFC 4474. Is this the way we really want to go?

I can see this might be a quick way of getting round the present predicament with needing a fast solution for E.164 numbers, but we really need to understand the limitations we are building into this mechanism.

Also, use of tel: URIs is currently fairly low compared with use of E.164-based SIP URIs. I can speak from the point of view of a PBX or a network of PBXs, and this would require either a change-out from using SIP URIs within the PBX or network, or a mapping between SIP and TEL URIs at the border. Not a particularly attractive scenario. But I would also like to hear the SSP perspective on this.

John

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 13:35:44 +0100

> De : Hadriel Kaplan [mailto:[email-masked]] 
> Envoyé : jeudi 28 janvier 2010 18:25
> À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; 
> [email-masked]
> Objet : RE: [martini] Proposed work split: tackle 
> telephone-numberregistrationfirst
> 
> mind. There is 
> Martini was instigated from work we were doing in SIP-Forum, 
> and in the SIP-Forum at one point we were nearly identical to 
> the 3gpp/etsi mechanism, but technical objections and issues 
> were raised, which drove us to go to the IETF.  The 50,000ft 
> view of the issues were that the 3gpp/etsi model "works" as 
> long as everyone's on the same page - that they all happen to 
> be provisioned to implement the exact same procedures from 
> the same version of the specs.  They all have to know that 
> the "normal" procedures of 3261 are not being followed, and 
> they have to know which procedures are being followed, 
> without any on-the-wire indication that or what they are.  
> For example, they have to know that the request-URI is or is 
> not going to be the registered contact (it can be either way, 
> just based on a provisioned field). 
> 
> That's all fine on the SSP-side, because presumably they 
> control all their own equipment.  But on the Enterprise side 
> it's harder.  In particular, while we've seen plenty of IMS 
> equipment support it, we've seen a very small percentage of 
> PBX's do so, relatively.

==>BC: I don't think a PBX needs to be "IMS aware" to accept an inbound INVITE request with a Request-URI containing either the registered contact or one of its AoRs.

> 
> Obviously the same will/can be said of any Martini or 
> SIP-Forum work - all the devices will have to do Martini 
> (whatever it is) for it to work.  There will be an 
> on-the-wire indication of it, so at least one can know what 
> the other device does or needs, so that's better, but at the 
> end of the day as you said the question is whether the 
> industry will adopt it.  In the best case scenario 3GPP, 
> ETSI, SIP-Forum, and CableLabs will all adopt the Martini 
> work - possibly as an alternative, or maybe even as the new 
> way.  For example the draft-shaken model is very 
> close/similar to the current 3gpp model.  

==>: That's true. However the draft-shaken is not restricted to E.614 numbers as far as I understand. The question I raised was in response to the proposal to work on an E.164-only solution.

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 14:39:48 +0100

Hi Spencer,

I have seen you request on the sip-ops list where you noted that MARTINI is not getting inputs from other operators (than CableLabs). I'm actually representing a fixed and mobile operator (France Telecom - Orange) and as you can guess from my previous posts we support a REGISTER-based solution and believe that a solution restricted to Tel URIs would be of limited interest.

/BC

> [mailto:[email-masked]] De la part de Spencer Dawkins
> Envoyé : jeudi 28 janvier 2010 22:59
> À : Brian Lindsay; Eric Burger; Dean Willis
> Cc : [email-masked]
> Objet : Re: [martini] Proposed work 
> split:tackletelephone-numberregistration first
> 
> Hi, Brian,
> 
> Thanks for the quick feedback. I'm mostly asking if I'm 
> reading where we are going correctly (I GOTTA get the draft 
> minutes out from that call!).
> 
> This is kind of twisty-little-passages-all-alike/different 
> (for those of you that remember the "adventure" game in the 
> early 1980s), but I'm trying to follow the chain. Where I 
> thought we were, was that we didn't have a coherent story for 
> how we get a call from outside the service provider, to the 
> service provider, to the SIP-PBX, and I've heard a bunch of 
> smart guys talk for a long time on a number of occasions 
> about how that might work/not work, usually ending with "but 
> if this was limited to E.164 numbers, a lot of these problems 
> would go away".
> 
> So I'm trying to laces comments from the call that I remember 
> together, and see what the resulting tapestry looks like.
> 
> Tell you what. I'll go work on draft minutes and stop typing 
> e-mail, and we'll see if that works better :D
> 
> Spencer
> 
> >> of regexp), or is it adequate to rely on provisioning of 
> the  SSP and
> PBX
> >> solutions to the two problem may reasonably be quite 
> different  from
> each
> >> other.
> >>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 29 Jan 2010 07:47:15 -0600

Hi, Bruno,

My apologies for not snapping when I saw your e-mail address - I'm currently 
chairing three working groups, and things are getting a little blurry 
(MEDIACTRL *really* needs to finish soon!).

Thanks for the input - it's helpful.

Spencer

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 29, 2010 7:39 AM
Subject: RE: [martini] Proposed work 
split:tackletelephone-numberregistration first

Hi Spencer,

I have seen you request on the sip-ops list where you noted that MARTINI is 
not getting inputs from other operators (than CableLabs). I'm actually 
representing a fixed and mobile operator (France Telecom - Orange) and as 
you can guess from my previous posts we support a REGISTER-based solution 
and believe that a solution restricted to Tel URIs would be of limited 
interest.

/BC

*********************************
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: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jan 2010 09:15:41 -0500

> be a great time to say so - please push back Real Soon Now.

I don't know that it is the *only* way, but it is an unambiguous way.

Of course sip URIs *can* contain E.164 numbers. The trick is in ensuring 
that everybody concerned agrees that's what they are. I think if the To of

> some of you guys are - could you point us to what you think needs to be 

That would come up *if* the intent is to *explicitly* register a TEL 
URI. The key issue is from section 10.2:

       To: The To header field contains the address of record whose
            registration is to be created, queried, or modified.  The To
            header field and the Request-URI field typically differ, as
            the former contains a user name.  This address-of-record MUST
            be a SIP URI or SIPS URI.

But if the goal is to register using a SIP URI, and cause the "implicit 
registration" of a number of TEL URIs, its not so clear that we have the 
same problems with 3261.

The more important issue is "constructing" an R-URI from a registered 
contact address as a part of implicit registration, and ensuring that 
the resulting URIs are unambiguous at the pbx. As long as the implicitly 
registered AORs are all TEL URIs, or sip URIs with a TEL user part, then 
the pbx can know what to expect as R-URIs for incoming requests. And it 
can know that the URI for a given telephone number will be the same 
regardless of what SSP it uses.

(To ensure that, we would want to specify that the E.164 number was 
represented in its canonical form, without any of the optional separator 
characters.)

	Thanks,
	Paul

> ----- Original Message ----- From: "Eric Burger" 
> <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jan 2010 09:36:00 -0500

I've been thinking about using TEL URIs for a long time.
A key distinction to me is that in addition to not specifying a domain, 
they also don't specify a protocol. So when a sip request is received 
with a tel: R-URI the recipient is free to switch to some other protocol 
that is available to it that can reach that number.

OTOH, if a request contains a SIP URI, even with user=phone, if the 
recipient isn't responsible for the domain, then it must route using 
SIP, and this will continue until it reaches the target domain. (Once 
there, it could retarget and switch to another protocol, but that is 
policy of the recipient.)

That can be a *feature*. For instance I may have an E.164 number as my 
AOR so that I am reachable via other protocols. But when the call is sip 
e2e I get more features, such as extra media, etc. In some cases I may 
had out TEL uris in order to be maximally reachable. In other cases I 
may hand out sip URIs with user=phone for use when I want to ensure that 
  the resulting session is sip e2e. And I may had out sips URIs when I 
want to ensure a "secure" session e2e.

That is a reason why it is wrong to use user=phone as an excuse to 
ignore the domain part of a URI. If we see a need to use SIP URIs but 
want the option to ignore the domain part, then I agree with what Adam 
says below - that we need a different parameter. But I'm not yet 
convinced that would be useful or wise.

	Thanks,
	Paul

Adam Roach wrote:
> ------------------------------------------------------------------------
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jan 2010 09:39:54 -0500

(I sent this out with an incomplete thought I meant to delete. Here is 
revised version.)

Of course sip URIs *can* contain E.164 numbers. The trick is in ensuring
that everybody concerned agrees that's what they are.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Fri, 29 Jan 2010 09:40:43 -0500

On the one hand, I agree we have to work on a general mechanism to  
enable the SP to provision IP PBXen as well as an efficient way for IP  
PBXen to register endpoints to an SP.

On the other hand, are you willing to wait 3-5 years for the general  
mechanism? More especially so given the industry today is 99.9% E.164  
numbers and needs a solution last year? This is a serious question: if  
service providers are saying, "This is going to be important, but we  
really do not need a solution in 3-5 years," then that informs our  
work: we can relax and engineer the perfect solution.  However, almost  
all of the service providers I speak with say, "A solution to this  
problem is already a year late.  If we do not see something soon [2-3  
months] we are going to codify and deploy the (admittedly broken)  
REGISTER method that we are already using, with or without the IETF.  
It would be nice if we could have a not-so-broken mechanism, but the  
market has lost its patience."

Again, doing the E.164-only solution today does not mean we ignore the  
long-term problem.

Does this work for you?

On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote:

> Hi, Bruno,
>
> My apologies for not snapping when I saw your e-mail address - I'm  
> currently chairing three working groups, and things are getting a  
> little blurry (MEDIACTRL *really* needs to finish soon!).
>
> ----- Original Message ----- From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked] 
> >; <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: [martini] Proposed work split:tackletelephone- 
> numberregistration first
>
>
> Hi Spencer,
>
> I have seen you request on the sip-ops list where you noted that  
> MARTINI is not getting inputs from other operators (than CableLabs).  
> I'm actually representing a fixed and mobile operator (France  
> Telecom - Orange) and as you can guess from my previous posts we  
> support a REGISTER-based solution and believe that a solution  
> restricted to Tel URIs would be of limited interest.
>
> /BC
>
>
>
>> > DNS operators, would really, really be "less than ideal"  and  
>> have a
>> whole
>> > less-than-idea industry solution just might blow up the   
>> possibility
>> for
>> dealing
>> >> PBXes usually have DHCP addresses, and don't  have DNS entries  
>> that
>> point
>> necessarily a
>> >> this scenario at all is that we sometimes encode telephone   
>> numbers
>> as
>> seems

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 29 Jan 2010 08:40:58 -0600

Hi, Paul,

A question, and a thank-you...

> that everybody concerned agrees that's what they are. I think if the To of

I'm guessing that your phone rang about here, because the sentence just 
stopped. I think I know where you were headed, but wanted to make sure that 
I understood what you were thinking, because I appreciate you spending the 
time to be helpful here! Did you need to type a little more?

> That would come up *if* the intent is to *explicitly* register a TEL URI. 
> The key issue is from section 10.2:
>
> contact address as a part of implicit registration, and ensuring that the 
> resulting URIs are unambiguous at the pbx. As long as the implicitly 

Yeah, I wondered if we were all talking about the same thing, when I was 
typing my note. I like your answer ("don't need to revise RFC 3261") better 
than the other answer. :-)

Do other people think we're talking about what Paul is talking about?

Thanks,

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 29 Jan 2010 08:44:13 -0600

Hi, Paul,

Ah - I was guessing that you'd moved the same topic lower in the note. 
Thanks for clueing me in for certain!

Spencer

>> the people you're talking to ("plays well with others" is 
>> walking into if we propose this change, please say so Real Soon Now. (One 
>> obvious land mine is that DISPATCH isn't meeting in Anaheim, so the 
>> group SOLUTION draft in January. We're not late yet, but it's the 28th of 
>> January in my time zone. If we are late, where late is measured in days, 
>> I can live with that, but if we are late, where late is measured in IETF 
>> meeting cycles, that's going to be a problem.
>>
>> Thanks,
>>
>> Spencer, as co-chair
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jan 2010 09:44:45 -0500

Adam Roach wrote:
>> I'm wondering what could be the motivation of the Industry to adopt 
>> the E.164-only solution as a near-term solution rather than the 
>> 3GPP/ETSI solution? This can only happen if the E-164 solution has 
>> very strong benefits and the 3GPP/ETSI solution has major flaws that 
>> prevents its implementation.
>>    
> 

This may be slightly out of scope, but when TEL URIs are used in From, 
To, Refer-To, etc. then there is no need to deal with issues of whether 
to use the domain of the pbx, or the ssp, or to translate between them.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 29 Jan 2010 09:06:14 -0600

Hi, Paul,

Just trying to make sure that I'm in sync here...

>> even if its very limited in scope. We determined on the call that many of 
>> the really controversial issues become inapplicable if we're willing to 
>> accept certain restrictions, all of which require scoping the work to 
> This may be slightly out of scope, but when TEL URIs are used in From, To, 
> Refer-To, etc. then there is no need to deal with issues of whether to use 
> the domain of the pbx, or the ssp, or to translate between them.

So, if the TEL URI includes a globally unique number (trying to use RFC 3966 
terminology here, please question anything I say that doesn't make sense) 
that includes the country code and national number as described in RFC 3966, 
section 5.1.4, that's my understanding as well.

Keith was arguing fairly passionately that private numbers ("local numbers" 
in RFC 3966, section 5.1.5, right?) also needed to be included in anything 
we do. As I read RFC 3966, private numbers would need to include a 
phone-context parameter, that could be either a global number or any of its 
leading digits (but why would we do this and NOT do an E.164 number) or a 
domain name.

If we're back to having a domain name for phone-context, do we have problems 
similar to the problems that we're talking about with E.164-based SIP URIs?

Thanks,

Spencer

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Jan 2010 10:01:54 -0600

On 1/29/10 9:06 AM, Spencer Dawkins wrote:
> Keith was arguing fairly passionately that private numbers ("local 
> numbers" in RFC 3966, section 5.1.5, right?) also needed to be 
> included in anything we do.

I think it comes down to whether we need to address private numbering in 
the short-term quick-n-dirty solution that SIPConnect needs last year, 
or whether private numbering can wait for the more general solution. 
Where is the pain point that is driving the urgency? Does it include 
private numbering plans?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jan 2010 11:04:34 -0500

Spencer Dawkins wrote:
>>> As far as I can tell, SIPForum is antsy to get something specified 
>>> now, even if its very limited in scope. We determined on the call 
>>> that many of the really controversial issues become inapplicable if 
>>> we're willing to accept certain restrictions, all of which require 
>>> scoping the work to E.164 numbers. I suspect this is true, and that 
>>> we can knock out a solution very quickly within this tightly 
>>> constrained scope.
>>>
>>> "E.164 numbers" -- it actually relates predominantly to the 
>>> elimination of domains in the SSP-PBX signaling (which is possibly 
>>> only if the user portion is universally unique, as in the case of 
>>> E.164 numbers).
>>
>> To, Refer-To, etc. then there is no need to deal with issues of 
>> whether to use the domain of the pbx, or the ssp, or to translate 
>> between them.
> 
> So, if the TEL URI includes a globally unique number (trying to use RFC 
> 3966 terminology here, please question anything I say that doesn't make 
> sense) that includes the country code and national number as described 
> in RFC 3966, section 5.1.4, that's my understanding as well.
> 
> numbers" in RFC 3966, section 5.1.5, right?) also needed to be included 
> in anything we do. As I read RFC 3966, private numbers would need to 
> include a phone-context parameter, that could be either a global number 
> or any of its leading digits (but why would we do this and NOT do an 
> E.164 number) or a domain name.
> 
> If we're back to having a domain name for phone-context, do we have 
> problems similar to the problems that we're talking about with 
> E.164-based SIP URIs?

Not clear.

For the point I was making here that is a non-issue, because any domain 
in the phone-context is irrelevant to sip routing rules. The tel uri is 
still globally unique for those private numbers as long as the phone 
context is included.

But the *routing* of such private numbers may be a challenge.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Jan 2010 10:20:21 -0600

On 1/29/10 4:33 AM, Elwell, John wrote:
> Although outside the scope of what we are doing with SIPconnect at present, bear in mind that RFC 4474 cannot be used with a tel: URI.

It also doesn't do what people expect it to do when you use E.164-like 
identifiers in SIP URIs. I can easily make a valid RFC4474 assertion 
that I own the identity "sip:[email-masked];user=phone". 
And, from a pure SIP perspective, it would be 100% true.

But it's probably a bit surprising.

/a

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 17:28:00 +0100

Of course we do not need a solution in 3-5 years. However I hardly believe that a generic solution would require 3-5 years if the E.164-only solutions requires only 2 or 3 months. 

I also understand that doing the E.164-only solution today does not mean we ignore the long-term problem. However I still think that an E.164-only solution has almost no value compared to the current 3GPP/ETSI solution, especially if the long-term solution significantly differs from the E.164-only solution. I'm not convinced that the issues identified with the 3GPP/ETSI/IMS solution prevent implementing it even outside the context of the IMS. I'm aware of a number of PBX on the market than can already accept an inbound INVITE request with a Request-URI containing either the registered contact or one of the implictly or explictly registered AoRs. 

BC

> De : Eric Burger [mailto:[email-masked]] 
> Envoyé : vendredi 29 janvier 2010 15:41
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]
> On the one hand, I agree we have to work on a general 
> mechanism to enable the SP to provision IP PBXen as well as 
> an efficient way for IP PBXen to register endpoints to an SP.
> 
> On the other hand, are you willing to wait 3-5 years for the 
> general mechanism? More especially so given the industry 
> today is 99.9% E.164 numbers and needs a solution last year? 
> This is a serious question: if service providers are saying, 
> "This is going to be important, but we really do not need a 
> solution in 3-5 years," then that informs our
> work: we can relax and engineer the perfect solution.  
> However, almost all of the service providers I speak with 
> say, "A solution to this problem is already a year late.  If 
> we do not see something soon [2-3 months] we are going to 
> codify and deploy the (admittedly broken) REGISTER method 
> that we are already using, with or without the IETF.  
> It would be nice if we could have a not-so-broken mechanism, 
> but the market has lost its patience."
> 
> Again, doing the E.164-only solution today does not mean we 
> ignore the long-term problem.
> 
> Does this work for you?
> 
> > <[email-masked]
> > I'm actually representing a fixed and mobile operator 
> (France Telecom 
> > - Orange) and as you can guess from my previous posts we support a 
> > REGISTER-based solution and believe that a solution 
> restricted to Tel 
> >> After reading this thread down through Eric's note below, 
> I have a  
> >> few
> >> requests, as co-chair.
> >>
> >> We're talking about E.164 numbers like we can easily 
> identify them.  
> >> My
> >> Finally, if you believe that embracing tel: URIs is the 
> wrong thing  
> >> to
> >> > That really would be creating a parallel DNS, which, as 
> one  of the
> >> major
> >> >> dividing our problem space, and taking on a near-term 
> milestone  
> >> for
> >> >> bind a "domain" to a Contact, "route  authentication", 
> and a good
> >> many
> >> >> (and any UAs) to statically bind the numbers to the PBX 
>  identity,
> >> and
> >> >> I believe all of these issues are quite tractable, if 
> we accept  
> >> the
> >> >> fundamental idea of splitting the phone-number problem 
> off from  
> >> the
> >> more
> > France Telecom Group shall not be liable for the message if 
> altered,  
> > changed or falsified.
> > If you are not the intended addressee of this message, 
> please cancel  
> > it immediately and inform the sender.

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Jan 2010 10:39:50 -0600

On 1/29/10 10:28 AM, [email-masked] wrote:
> I'm not convinced that the issues identified with the 3GPP/ETSI/IMS solution prevent implementing it even outside the context of the IMS. I'm aware of a number of PBX on the market than can already accept an inbound INVITE request with a Request-URI containing either the registered contact or one of the implictly or explictly registered AoRs.

That's not really the major problem here. An incomplete list of the big 
issues off the top of my head are:

   1. Changing the semantics of REGISTER to indicate more than one human
      breaks certain security (policy) assumptions at intermediaries. It
      may also cause problems with Path, Service-Route, and connection
      re-use (that is, they may not "just work", as previously claimed,
      due to changing security properties).

   2. Changing the semantics of REGISTER (this is a different change) to
      mean "override RFC 3263 procedures with this mapping" instead of
      "add this AOR to Contact mapping to your database" breaks certain
      security assumptions at intermediaries.

   3. Using a mechanism other than DNS (a mechanism that returns
      different results than DNS) to map from domain names to IP
      addresses is effectively creating a parallel DNS system, which
      runs afoul ICANN and IAB stated positions.

   4. The current proposals don't clearly state who is "responsible" for
      a domain (as that terms is used in RFC 3261). Given that only the
      "responsible" party is allowed to retarget requests, problems
      arise with the basic model no matter who you choose as "responsible."

   5. There is some debate about whether the AORs being registered need
      to be indicated in the transaction at all (either in the request
      or in the response). Having them appear solves two separate
      problems: (a) it allows detection of mismatches between the SSP's
      idea of which AORs have been registered and the PBX's, and (b) it
      allows intermediaries to determine which AORs the registration
      pertains to. Using the 3GPP/ETSI approach would lead to
      potentially large responses, which causes issues when UDP is employed.

These are broad summaries -- the details of the problems have been given 
in prior emails and on the interim calls.

There are also the flat-out obvious protocol violations in the 3GPP/ETSI 
solution as specified, such as the syntactic violation of using 
unescaped POSIX regexes where nameaddrs are to appear, and the semantic 
violation of pushing these regexes into reg-event notifications (which 
is broken regardless of whether you escape them).

/a

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 29 Jan 2010 18:03:58 +0100

Agreed, but the assertion at least tells me the request came from estacado.net.

John 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 29 January 2010 16:20
> To: Elwell, John
> Cc: Spencer Dawkins; [email-masked]
> > Although outside the scope of what we are doing with 
> SIPconnect at present, bear in mind that RFC 4474 cannot be 
> used with a tel: URI.
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 29 Jan 2010 18:23:04 +0100

> [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: 29 January 2010 14:41
> To: Paul Kyzivat
> Cc: [email-masked]
> identify them. My
> >> only way we could unambiguously know that we had an E.164 
> number was if 
> >> we
[JRE] Yes, I think Paul sums it up nicely.

John

---

From: "Brian Lindsay" <[email-masked]>
Date: Fri, 29 Jan 2010 12:35:46 -0500

Hi,

   Just to chime in, I agree too. Per my note yesterday I don't think
there is any need to explicitly register with a Tel URI. The
MARTINI-Shaken approach of using a SIP URI representing the SIP PBX
should be fine. The question would be how you want to represent the
E.164 number in the request uri in requests to the SIP PBX (restrict to
Tel URI or not).

   Thanks
      Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: Friday, January 29, 2010 12:23 PM
To: Spencer Dawkins; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [martini] Proposed worksplit: tackle
telephone-numberregistration first

> I'm guessing that your phone rang about here, because the sentence 
> just stopped. I think I know where you were headed, but wanted to make

> sure that I understood what you were thinking, because I appreciate 
> you spending the time to be helpful here! Did you need to type a 
> little more?
> 
> Yeah, I wondered if we were all talking about the same thing, when I 
> was typing my note. I like your answer ("don't need to revise RFC
> 3261") better

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 29 Jan 2010 13:02:12 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, January 28, 2010 12:51 PM
> To: Hadriel Kaplan
> 

Ummm, not to belabor the idea of using domain name registration (though here I am belaboring it), but it *is* a domain owned by the SSP.  At least that's what draft-shaken says.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 29 Jan 2010 13:25:51 -0500

+1 plus it seems obvious to me that the proper direction of MARTINI is to
fix what is in the field now without potentially breaking a long term
solution in the future.

We all want SIP URI's to be the dominant form of addressing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Lindsay
Sent: Friday, January 29, 2010 12:36 PM
To: Elwell, John; Spencer Dawkins; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [martini] Proposed worksplit: tackle
telephone-numberregistration first

Hi,

   Thanks
      Brian

-----Original Message-----

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 29 Jan 2010 13:38:19 -0500

> Of Spencer Dawkins

I think it's the wrong thing to do.  It doesn't magically fix anything - it just lets us pretend the issues don't exist, when they either still do, or didn't either for draft-shaken, as follows:  

	a) What is the Req-URI going to be for a request when it reaches the registrar-proxy (RP) on its way to the PBX?  It's going to be sip:[email-masked].  What does the RP need to do to it?  Retarget to URI's of the PBX.  That's what we needed to do even with a draft-shaken model.

	b) What happens if the RP gets a request for sip:[email-masked]?  With Tel-URI we're going to claim that can't happen, or it's out of scope, or whatever.  Great!  Let's just claim that for draft-shaken too.  Claiming things are out of scope makes life easy.

	c) What are the security issues of a PBX Registering an AoR of tel:12345?  Well, in theory it's claiming to represent a global URI.  We assume that the SSP has the moral authority to approve/disapprove that claim.  Why?  Because presumably 12345 is actually assigned to SSP.  Great!  So draft-shaken Registers sip:[email-masked] - guess who owns ssp.com?  The SSP!  So how was that broken again??

	d) There was some concern about the various forms the identities of the PBX users could appear as, for example with or without leading + and country-codes, etc.  Those aren't going away with a tel URI.

	e) One of the major sticking points was whether the req-
URI is replaced with the Registered contact, or left alone, or just retargeted.  Using a Tel-URI AoR makes that no easier a decision/argument/issue.

	f) One of the concerns raised so far has been on GRUU's.  Unless we figure out how to convert GRUU's to telephone numbers, there's going to be a need to route a request for a non-TEL-URI to the PBX and keep it a non-TEL-URI.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 29 Jan 2010 13:47:48 -0500

> Of Paul Kyzivat
> Sent: Friday, January 29, 2010 9:45 AM
> To: Adam Roach
> 

Au contraire.  The SSP registrar-proxy will be receiving requests ultimately destined to the PBX containing SIP URI's in req-URI, To, Refer-To, etc.  Thus they will either show up at the PBX, or the SSP will have to perform the "mapping" function we claim isn't going to be necessary with Tel-URI's.  There is no getting away from this "mapping" function.

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 29 Jan 2010 21:15:44 +0100

Is the market today 100% tel URIs or is it 100% telephone numbers masquerading as SIP URIs?

regards

Keith

> Sent: Friday, January 29, 2010 2:41 PM
> Subject: Re: [martini] Proposed work

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 29 Jan 2010 16:02:46 -0500

The latter ... as far as I've able to determine

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Friday, January 29, 2010 3:16 PM
To: Eric Burger; [email-masked]
Cc: [email-masked]
Subject: Re: [martini] Proposed work
split:tackletelephone-numberregistration first

Is the market today 100% tel URIs or is it 100% telephone numbers
masquerading as SIP URIs?

regards

Keith

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 29 Jan 2010 22:40:34 +0100

Hi Adam,

> Changing the semantics of REGISTER to indicate more than one human breaks
> certain security (policy) assumptions at intermediaries. It may also cause
> problems with Path, Service-Route, and connection re-use (that is, they may
> not "just work", as previously claimed, due to changing security
> properties).

I don't agree the semantic is broken: In RFC3261, a REGISTER registers
an AOR and its adress-of-contact. It is not said that the AOR has to
be a single human.
So examples of valid AOR could be: sip:[email-masked],
sip:[email-masked], sip:[email-masked],
sip:[email-masked]

My 2 cents,
Xavier

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Jan 2010 23:53:52 +0100

>More especially so given the industry today is 99.9% E.164

Do you assume all those E.164 numbers will be carried in a TEL-URI? That seems to be the assumption for the "short-term solution" people are talking about...

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 30 Jan 2010 01:08:49 +0100

Exactly - that is what I understood too - so they all tend to be encumbered by domain names.

And lots of them use things like [email-masked] internally as well if I understand correctly, which are neither fish nor fowl.

So arguing that we need a solution for tel URIs because that is what is currently supported is incorrect.

regards

Keith

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Friday, January 29, 2010 9:03 PM
> To: DRAGE, Keith (Keith); 'Eric Burger';
> [email-masked]
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> > numbers and needs a solution last year?
> > This is a serious question: if service providers are
> saying, "This is
> > going to be important, but we really do not need a solution in 3-5
> > years," then that informs our
> > However, almost all of the service providers I speak with say, "A
> > solution to this problem is already a year late.  If we do not see
> > something soon [2-3 months] we are going to codify and deploy the
> > (admittedly broken) REGISTER method that we are already
> using, with or
> > without the IETF.
> > >> Envoyé : jeudi 28 janvier 2010 22:59 À : Brian Lindsay; Eric
> > >> Burger; Dean Willis Cc : [email-masked] Objet : Re: [martini]
> > >> Proposed work split:tackletelephone-numberregistration first
> > >>
> > >> Hi, Brian,
> > >>
> > >> Thanks for the quick feedback. I'm mostly asking if I'm reading
> > >> where we are going correctly (I GOTTA get the draft minutes out
> > >> from that call!).
> > >>
> > >> (for those of you that remember the "adventure" game in
> the early
> > >> 1980s), but I'm trying to follow the chain. Where I thought we
> > >> were, was that we didn't have a coherent story for how we get a
> > >> call from outside the service provider, to the service
> provider, to
> > >> the SIP-PBX, and I've heard a bunch of smart guys talk
> for a long
> > >> time on a number of occasions about how that might
> work/not work,
> > >> usually ending with "but if this was limited to E.164 numbers, a
> > >> lot of these problems would go away".
> > >>
> > >>   I am not sure if this is going down the path that the actual
> > >> register request uses a Tel: URI.
> > >>
> > >>   If so, I don't see why that needs to be the case. The REGISTER
> > >> itself can still be done per Martini-Shaken with a SIP URI
> > >> representing the SIP PBX. In fact, I am not sure too much has to
> > >> change with Martini- Shaken unless you want to enforce
> use of a Tel
> > >> URI format for
> > requests sent
> > >> towards the SIP PBX.
> > >>
> > >>   Thanks
> > >>      Brian
> > >>
> > >>
> > >>
> > >> OK, this discussion continues to be lovely. Thanks again for
> > >> listening to the people you're talking to ("plays well
> with others"
> > >> is under-appreciated, once we get out of primary school, but *I*
> > >> appreciate
> > >> it!)
> > >>
> > >> the only way we could unambiguously know that we had an E.164
> > >> number was if we had a tel: URI. If people on this list want to
> > >> challenge that assertion, this would be a great time to say so -
> > >> please push back Real Soon Now.
> > >>
> > >> If that's true, we're talking about using Tel: URIs. Dean has
> > >> asserted that this would require an update to 3261. I'm not a
> > >> genius of 3261, but some of you guys are - could you point us to
> > >> what you think needs to be updated?
> > >>
> > >>   way that the biloxi.com server can learn the current
> location of
> > >> Bob.
> > >>   Upon initialization, and at periodic intervals, Bob's
> SIP phone
> > >> sends
> > >>   REGISTER messages to a server in the biloxi.com domain
> known as a
> > >> SIP
> > >> Section 2.1, this change would have to go through
> SIPCORE, because
> > >> it's an update to 3261. If you know of obvious land mines that
> > we would be
> > >> (One obvious land mine is that DISPATCH isn't meeting in
> Anaheim,
> > >> so the proposal would have to be DISPATCHed on the
> mailing list in
> > >> order to do something before IETF 78 - are there OTHERS?)
> > >>
> > >> group SOLUTION draft in January. We're not late yet, but
> it's the
> > >> 28th of January in my time zone. If we are late, where late is
> > measured in
> > >> days, I can live with that, but if we are late, where late is
> > >> measured in IETF meeting cycles, that's going to be a problem.
> > >>
> > >> Thanks,
> > >>
> > >> Spencer, as co-chair
> > >>
> > >> > not only a simplification, but just about the only
> thing that is
> > >> sensible
> > >> > for MARTINI to work on.
> > >> >
> > >> > string of digits into an AOR that might cross domain
> boundaries.
> > >> This is

---

From: Eric Burger <[email-masked]>
Date: Fri, 29 Jan 2010 19:13:00 -0500

Sorry, but the AVERAGE time to take something from ID-0 to RFC is 48  
months.

E.164-only has a chance because it has been worked on for over two  
years and there was virtually unanimous buy-in at the DRINKS BOF  
(which became the MARTINI work group) that if the problem domain was  
restricted to E.164 numbers, then the proposed approach would be  
acceptable.

Any generic approach will not have such support and will take the  
normal IETF discussion period of 3-5 years.

Longer if it involves INFO :-)  [Inside joke for old SIP folks]

On Jan 29, 2010, at 11:28 AM, <[email-masked]> <[email-masked] 
 > wrote:

> Of course we do not need a solution in 3-5 years. However I hardly  
> believe that a generic solution would require 3-5 years if the E.164- 
> only solutions requires only 2 or 3 months.
>
> I also understand that doing the E.164-only solution today does not  
> mean we ignore the long-term problem. However I still think that an  
> E.164-only solution has almost no value compared to the current 3GPP/ 
> ETSI solution, especially if the long-term solution significantly  
> differs from the E.164-only solution. I'm not convinced that the  
> issues identified with the 3GPP/ETSI/IMS solution prevent  
> implementing it even outside the context of the IMS. I'm aware of a  
> number of PBX on the market than can already accept an inbound  
> INVITE request with a Request-URI containing either the registered  
> contact or one of the implictly or explictly registered AoRs.
>
> BC
>
>>>> listening
>>>> number was
>>>> asserted
>>>> location of Bob.
>>>> known as a SIP
>>>> Anaheim, so the
>>>> measured

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 29 Jan 2010 18:36:29 -0600

Hi, Eric,

A couple of things:

- MARTINI came from DREGS (DRINKS is the OTHER alcohol-related working group
in RAI) - just in case anyone might be trying to trace the DRINKS-MARTINI 
link...

- it seems to me that we're leaping from "E.164 numbers" - and I agree that
DREGS and about a million other conversations keep telling us "E.164 numbers
would be easier, and are the only things that matter, anyway" - to tel:
URIs, which have only been under serious consideration for a few days.

We're only fascinated with tel: URIs because tel: URIs can be unambiguously
identified as globally unique, and we haven't come up with any other way of
doing that.

If we defined a new option tag that meant "globally unique E.164 number" for
SIP URIs, would that give us what we need, without moving to tel: URIs?

Thanks,

Spencer

----- Original Message ----- 
From: "Eric Burger" <[email-masked]>
To: <[email-masked]@orange-ftgroup.com>
Cc: <[email-masked]>
Sent: Friday, January 29, 2010 6:13 PM
Subject: Re: [martini] Proposed worksplit:tackletelephone-numberregistration
first

On Jan 29, 2010, at 11:28 AM, <[email-masked]>
<[email-masked]

> believe that a generic solution would require 3-5 years if the E.164- only
> solutions requires only 2 or 3 months.
>
> I also understand that doing the E.164-only solution today does not  mean
> we ignore the long-term problem. However I still think that an  E.164-only
> solution has almost no value compared to the current 3GPP/ ETSI solution,
> especially if the long-term solution significantly  differs from the
> E.164-only solution. I'm not convinced that the  issues identified with
> the 3GPP/ETSI/IMS solution prevent  implementing it even outside the
> context of the IMS. I'm aware of a  number of PBX on the market than can
> already accept an inbound  INVITE request with a Request-URI containing
> either the registered  contact or one of the implictly or explictly
> registered AoRs.
>
> BC
>

---

From: Eric Burger <[email-masked]>
Date: Fri, 29 Jan 2010 19:46:16 -0500

I know, a bunch of folks jumpped on me for confusing DRINKS and DREGS.  
Too many martinis and, if you follow my tweets, too much wine with  
real dregs in it, clearly...

I would offer a tag that means "this SIP URI is a phone number" is  
equivalent in work to "tel:mumble".  I was hoping to ignore that issue  
whole cloth...

On Jan 29, 2010, at 7:36 PM, Spencer Dawkins wrote:

> in RAI) - just in case anyone might be trying to trace the DRINKS- 
> MARTINI link...
>
> ----- Original Message ----- From: "Eric Burger" <[email-masked] 
> >

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 30 Jan 2010 05:22:05 -0000 (UTC)

> please forward them on to my pbx", how is the SSP to decide if that is

Google mail solves exactly this problem by 1) making one prove that one
can receive emails to the address in question, and 2) making one prove
that one can make DNS changes by putting a "cookie" record into the zone.

--
dean

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 29 Jan 2010 21:27:02 -0800

Bruno Chatras said:

"I'm not convinced that the  issues identified with the 3GPP/ETSI/IMS
solution prevent implementing it even outside the context of the IMS. I'm
aware of a  number of PBX on the market than can already accept an inbound
INVITE request with a Request-URI containing either the registered  contact
or one of the implictly or explictly
registered AoRs."

[BA] Unfortunately, the same statements can be made with respect to some of
the other "implicit registration" approaches that exist in the field.  Each
scheme is supported by some PBXes and some service providers.  The problem
is that there is no one scheme that is supported by everyone. 

That said, it's not always the case that situations like this can be
improved by introduction of a new approach.   Sometimes the easiest road to
interoperability when there are multiple deployed variants is for vendors to
accept the inevitability of diversity and learn to live with it.   Once a
vendor has implemented the most popular variants, they can sometimes cope
with diversity well enough to make life tolerable.  At that point, vendors
typically consider the problem solved and move on to the next squeaky wheel.

So while today we might still be hoping for "change we can believe in", at
some point, we'll either have created a bridge that the SSP/PBX community is
willing to cross or we won't.   If we can get them to the other side, then
we *might* have a shot at moving beyond today's somewhat cluttered urban
landscape to the beautiful green field beyond.  But getting them to move
will not be easy, even given all the issues we have enumerated.

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 30 Jan 2010 05:29:06 -0000 (UTC)

> Dean, Is this what you were thinking of? Are there other places that also

Adam was asserting the need to change 3261, whereas I was asking if we
need to change it. I think we have a slight thought-disconnect, as I'm
considering registration with a SIP/SIPS URI as the Contact, but a TEL URI
as the "To:" value. Adam seems to want to register a TEL Contact, which
makes no sense to me.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 30 Jan 2010 05:37:02 -0000 (UTC)

>             be a SIP URI or SIPS URI.

Thanks, Paul. This is exactly the part of 3261 that I think would need to
be changed; the "To" field can be either a tel: URI, or perhaps a
wildcarded/regexed expression for a rane of tel: URIs.

--
dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 30 Jan 2010 10:07:55 -0600

Hi, Dean,

> as the "To:" value. Adam seems to want to register a TEL Contact, which

Dean and Adam:

My apologies for misattributing here.

I agree that we seem to be talking about multiple things at once. I'd love 
to see a call flow that discusses what we're talking about now - Adam has 
produced several helpful ones already, but he did so before we were focused 
on tel as a possibility.

Thanks,

Spencer

---

From: Adam Roach <[email-masked]>
Date: Sat, 30 Jan 2010 10:40:10 -0600

On 1/29/10 23:29, Jan 29, Dean Willis wrote:
> Adam was asserting the need to change 3261...

I don't recall making such an assertion. Perhaps you confused someone 
else with me?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 30 Jan 2010 13:13:23 -0500

> that one can make DNS changes by putting a "cookie" record into the zone.

But isn't the whole point here that the pbx *can't* be reached at its 
domain name using DNS lookup? This connection is supposed to be in lieu 
of such a direct connection.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 30 Jan 2010 13:25:51 -0500

> wildcarded/regexed expression for a rane of tel: URIs.

My understanding was that the To of the REGISTER would be a special sip 
URI. The phone numbers (perhaps TEL URIs) would be *implicitly* 
registered. As such they they would never be the To of a register, and 
so would not violate the letter of 3261. Whether it breaks the spirit of 
3261 to implicitly register a TEL is arguable.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 30 Jan 2010 13:28:37 -0500

> I don't recall making such an assertion. Perhaps you confused someone 

It may have been me. But I think it remains to be seen if what we are 
talking about requires any changes.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Sun, 31 Jan 2010 12:16:10 -0600

On Jan 29, 2010, at 8:44 AM, Paul Kyzivat wrote:

>
> This may be slightly out of scope, but when TEL URIs are used in  
> From, To, Refer-To, etc. then there is no need to deal with issues  
> of whether to use the domain of the pbx, or the ssp, or to translate  
> between them.

That's what makes them easier to specify the usage of.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sun, 31 Jan 2010 12:19:57 -0600

On Jan 29, 2010, at 12:02 PM, Hadriel Kaplan wrote:

>> Paul said:

>> customers.
> Ummm, not to belabor the idea of using domain name registration  
> (though here I am belaboring it), but it *is* a domain owned by the  
> SSP.  At least that's what draft-shaken says.

We seem to be going back and forth on "domain owned by SSP" and  
"domain owned by PBX".

While clear in "shaken", it's not clear in the larger context of this  
discussion as to which "domain" model we're talking about.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sun, 31 Jan 2010 12:26:20 -0600

On Jan 29, 2010, at 12:38 PM, Hadriel Kaplan wrote:

> URI is replaced with the Registered contact, or left alone, or just  
> retargeted.  Using a Tel-URI AoR makes that no easier a decision/ 
> argument/issue.

No, it makes it really easy. We use conventional contact routing (as  
per RFC 3261) and replace the request URI (a tel: URI) with the  
registered contact (a sip: URI in the domain of the PBX, or its ISP,  
or using the PBXes IP address, or whatever) just as we do for

>
> 	f) One of the concerns raised so far has been on GRUU's.  Unless we  
> figure out how to convert GRUU's to telephone numbers, there's going  
> to be a need to route a request for a non-TEL-URI to the PBX and  
> keep it a non-TEL-URI.

GRUUs don't convert to telephone numbers. They map SIP Contact URIs  
(in whatever domain they exist) to SIP URIs in the domain of the GRUU  
minter.  This is a pretty straightforward mapping, and the issues of  
"domain ownership" around it have already been solved.

Yes, we need more work on minting GRUUs for "wildcard" registrations,  
but that's a rather more tractable problem, although AFAIK untouched  
by any existing draft.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sun, 31 Jan 2010 12:30:32 -0600

On Jan 30, 2010, at 10:40 AM, Adam Roach wrote:

> I don't recall making such an assertion. Perhaps you confused  
> someone else with me?

I believe you're the one who, on our interim call, asserted that RFC  
3261 does not allow the use of tel: URIs in the To: field of a SIP  
REGISTER request.

Paul later cited RFC 3261 speciifcally proving this assertion, so I'm  
crediting you with something that was proven to be 100% correct.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 31 Jan 2010 15:13:06 -0500

> From: Dean Willis [mailto:[email-masked]]
> Sent: Sunday, January 31, 2010 1:26 PM
> To: Hadriel Kaplan
> 

The request-URI would not have been a Tel-URI when the registrar-proxy got it from the originator, but let's assume that it was: you still can't just/solely replace the req-URI with the registered contact URI, since that would lose the intended target info (the specific user phone number which is being targeted).  

> but that's a rather more tractable problem, although AFAIK untouched

Yes, that was my point: GRUU's don't map to telephone numbers. 

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sun, 31 Jan 2010 16:27:13 -0600

On Jan 31, 2010, at 2:13 PM, Hadriel Kaplan wrote:

> The request-URI would not have been a Tel-URI when the registrar- 
> proxy got it from the originator, but let's assume that it was: you  
> still can't just/solely replace the req-URI with the registered  
> contact URI, since that would lose the intended target info (the  
> specific user phone number which is being targeted).

Ahah! I think we have here the tip of the iceberg on what's not being  
understood. Thank you for your question!

To work fully transparently for contact-routing , a "wildcard"  
registration needs to provide a 1 to 1 mapping between AORs and  
Contacts. It isn't enough to specify a wildcarding for the AORs --  
there has to be an homomorphic wildcarding for the contacts as well.  
If we use regular expressions to indicate the AORs being registered,  
we need to apply a matching regex expansion on the contacts being  
registered to the AORs.

Here's one possible approach, using a non-regex model of expressing  
ranges (I believe Adam has proposed a regex model for the same thing).

Assume we're registering "tel:+1972519XXXX". It's not adequate to  
register a contact of "[email-masked]". We need to register a  
full set of contacts so that there is a one-to-one mapping from AOR to  
contact. So the "contact" being registered looks something like "sip:[email-masked] 
".

If a call arrives at SSP for "tel:+19725199190" or "sip:[email-masked];user=phone 
", the SSP can contact-route the request to "sip:[email-masked]".  
The PBX then has a fully-qualified URI to route the call to the  
correct extension. Of course, PBX could just has easily have  
registered using its IP address instead of a DNS name, and everything  
still works; contacts might look like "sip:[email-masked]".

> Yes, that was my point: GRUU's don't map to telephone numbers.

They don't have to! They only have to map to contacts. We just need a  
similar wildcard-registration mechanism to allow the SSP to mint a set  
of GRUUs congruent to the set of contacts being registered. If the PBX  
is in-itself a proxy registrar, it then has to set up its own mapping  
table for those GRUUs and make them available to the UAs registering  
to the UAs. These GRUUs are then used for all call-transfer activity,  
meaning we never have "domain authority" problems on the resulting  
calls and that whole problem space evaporates.

So when the PBX registers a wildcarded range like "tel:1972519XXXX" it  
uses a range-matching wildcarded contact like "sip: 
[email-masked]" and gets back a range-matching wildcarded GRUU  
like "sip:[email-masked];gr".

And we need a Require and Proxy-Require modifier that proves that the  
nodes know what to do when they see the wildcard syntax being used. We  
may also need a new REGISTER error response code for mismatched AOR/ 
contact sets.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 31 Jan 2010 20:29:37 -0500

So if I understand what you're proposing, on the wire the routed request would look like draft-shaken or whatever except the real registered Contact-URI is not inserted as a Route header.  And the description of the process taking place in the RP is that it is doing rfc3261-style AoR->Contact resolution, instead of "retargeting" to the domain/ip of the PBX.  Right?

I'm fine with that.  I still don't think it requires Registering a Tel-URI, though.  I.e., the To-URI of the REGISTER doesn't' need to be a Tel scheme for that to work.

-hadriel

> Sent: Sunday, January 31, 2010 5:27 PM
> To: Hadriel Kaplan
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Feb 2010 08:30:26 +0100

Hi, 

>Ahah! I think we have here the tip of the iceberg on what's 
>not being understood. Thank you for your question!
> 
>registration needs to provide a 1 to 1 mapping between AORs 
>and Contacts. It isn't enough to specify a wildcarding for 
>the AORs -- there has to be an homomorphic wildcarding for 
>the contacts as well.  
>If we use regular expressions to indicate the AORs being 
>registered, we need to apply a matching regex expansion on 
>the contacts being registered to the AORs.
> 
>Here's one possible approach, using a non-regex model of 
>expressing ranges (I believe Adam has proposed a regex model 
>for the same thing).
> 
>Assume we're registering "tel:+1972519XXXX". It's not 
>adequate to register a contact of "[email-masked]". We 
>need to register a full set of contacts so that there is a 
>one-to-one mapping from AOR to contact. So the "contact" 
>being registered looks something like "sip:[email-masked] ".
> 
>The PBX then has a fully-qualified URI to route the call to 
>the correct extension. Of course, PBX could just has easily 
>have registered using its IP address instead of a DNS name, 
>and everything still works; contacts might look like 
>"sip:[email-masked]".

I think that is wrong usage of the Contact header. You more or less use it for carrying target information. We have other mechanisms for that.

I also think it is a very "clumsy" solution, when you mandate a 1-to-1 mapping of the R-URI/Contact userpart values (maybe it could also have security impacts).

Last, my understanding is still that, from a SIP network point of view, the PBX is seen as a single Contact, but in your solution every PBX user explicitly (eventhough a wildcard mechanism is used) registers with the SIP network.

Regards,

Christer