Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Feb 2010 12:29:41 -0500

Christer Holmberg wrote:
> Hi, 
> 
>> 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]".
> 
> 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 beg to differ. The contact address is the ultimate target.
There have been many documents pointing that out.
And as long as you register each AOR independently it can be handled 
very cleanly.

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

Its clumsy precisely because of implicit registration.
Adam's proposal provided a way to do that mapping under the control of 
the recipient so that only expected contact addresses are used.

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

The only clean way to treat the pbx as a single address is via loose 
routing. But there are issues with establishing loose routing tables via 
REGISTER.

	Thanks,
	Paul

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Feb 2010 16:23:52 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, February 01, 2010 12:30 PM
> To: Christer Holmberg
> 

Why does the method name impact the ability to establish a loose routing table?

If the method was FOOBAR, would it suddenly be ok to route to AoR's using path info learned from FOOBAR as a loose-route set?

ISTM there is a distinction between the REGISTER method transaction updating a database, and the request routing mechanism based on the info in that database.  

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Feb 2010 16:52:10 -0500

> ISTM there is a distinction between the REGISTER method transaction updating a database, and the request routing mechanism based on the info in that database.  

I am not fundamentally opposed to this approach. But the same thing that 
makes REGISTER attractive (e.g. Path and Service-Route) raises questions 
of how those will work with loose routing. It can probably be made to 
work, but has it been fully understood?

	Thanks,
	Paul

---

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

On Jan 31, 2010, at 7:29 PM, Hadriel Kaplan wrote:

>
> 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 believe that's correct.

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

The problem with SIP URIs  is: what domain would go in the To:?  
Clearly it has to be the domain of the SSP, for all of our domain- 
authority work to do what it is supposed to do.

There are still some questions about the security implications of  
multiple registrations over one Outbound connection, but I'm thinking  
(hoping?) those could be resolved by a carefully worded applicability  
statement.

--
Dean

---

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

On Feb 1, 2010, at 1:30 AM, Christer Holmberg wrote:
>>
>
> 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'm using it for carrying the contact URI that I expect the proxy- 
registrar t retarget to. That's what REGISTER is SUPPOSED to do,

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

Actually, I think it;s the only way to NOT have the security  
implications. We have here a single REGISTER that results in exactly  
the same set of AOR-Contact mappings that would result from a  
multiplicity of requests using REGISTER as speced in RFC 261.

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

Exactly. That's why this approach works. Absolutely nothing is  
"implicit", everything is explicit. But it has very little more  
overhead than the hackneyed implicit registrations, and entirely  
solves the "how does the PBX figure out which user" mess that happens  
if there is only one Contact for many different AORs.

--
Dean

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Mon, 1 Feb 2010 20:50:05 -0500

Every user registering is not implementable.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Monday, February 01, 2010 8:28 PM
To: Christer Holmberg
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [martini] Proposed work split:
tackletelephone-numberregistration first

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 1 Feb 2010 20:35:28 -0600

> Every user registering is not implementable.

I didn't suggest they would. I suggested PBX would use one wild-card  
registration which would have the effect of registering a whole bunch  
of users with a single request.

But the effect on the registration database is the same as it would be  
if every user registered separately: we get one (or more) Contact for  
each AOR, and one AOR for each phone number.

There are many different possible syntaxes for the "wild-card" effect.  
My usage of X as a numeric-placeholder is just an example. The syntax  
from Adam's draft is probably better, just slightly harder to explain  
in a singe email.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2010 07:12:03 +0100

Hi, 

>>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.
> 
>And as long as you register each AOR independently it can be 
>handled very cleanly.

In my opinion Contact is not meant to be used for informing the UA about what number was called etc in order to reach the UA.

>>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).
> 
>Adam's proposal provided a way to do that mapping under the 
>control of the recipient so that only expected contact 
>addresses are used.

Again, as far as I understand, from a SIP network perspective the PBX only has a single contact.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2010 07:13:44 +0100

Hi, 

>>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.
> 
>The only clean way to treat the pbx as a single address is 
>via loose routing. But there are issues with establishing 
>loose routing tables via REGISTER.

Well, then we have to work on those issues.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2010 07:16:49 +0100

Hi, 

>>view, the PBX is seen as a single Contact, but in your 
>>solution every PBX user explicitly (eventhough a wildcard mechanism is used) 
>Exactly. That's why this approach works. Absolutely nothing 
>is "implicit", everything is explicit. But it has very little 
>more overhead than the hackneyed implicit registrations, and 
>entirely solves the "how does the PBX figure out which user" 
>mess that happens if there is only one Contact for many 
>different AORs.

But, that is not how PBXs work.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Feb 2010 08:52:32 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 02 February 2010 06:17
> To: Dean Willis
> Subject: Re: [martini] Proposed work split: tackle 
> telephone-numberregistration first
> 
> 
> Hi, 
> 
[JRE] Taking the example from the "Implications" thread, the PBX would receive:
sip:[email-masked] or
sip:[email-masked]
In either case, it is a contact URI as far as the SSP is concerned, but the PBX can treat those as AORs from its own perspective. I think there are practical examples of it working like this today.

John

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2010 09:18:26 +0100

Hi, 

>>>solves the "how does the PBX figure out which user"
>>>mess that happens if there is only one Contact for many different 
>>>AORs.
>> 
>In either case, it is a contact URI as far as the SSP is 
>concerned, but the PBX can treat those as AORs from its own 
>perspective. I think there are practical examples of it 
>working like this today.

Ok, you probably know more about SIPConnect etc than I do.

But, what if the PBX is using outbound? I assume the same instance id and gr values are going to be used for all PBX users, eventhough each PBX user has a unique Contact within the SSP?

Regards,

Christer

---

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

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 02 February 2010 08:18
> To: Elwell, John; Dean Willis
> Subject: RE: [martini] Proposed work split: tackle 
> But, what if the PBX is using outbound? I assume the same 
> instance id and gr values are going to be used for all PBX 
> users, eventhough each PBX user has a unique Contact within the SSP?
[JRE] Yes - this was touched on in the other recent thread.

John

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2010 11:53:35 +0100

> different 
> concerned, 
> > >but the PBX can treat those as AORs from its own 
> perspective. I think 
> > >there are practical examples of it working like this today.
> > 
> instance id 
> > and gr values are going to be used for all PBX users, 
> eventhough each 
> > PBX user has a unique Contact within the SSP?

In that case, why would we need to send a wildcarded Contact (as suggested by Dean)? Why not simply register the IPX IP address, and the registrar then adds the user part for inbound requests?

Regards,

Christer

---

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

> Sent: 02 February 2010 10:54
> In that case, why would we need to send a wildcarded Contact 
> (as suggested by Dean)? Why not simply register the IPX IP 
> address, and the registrar then adds the user part for 
> inbound requests?
[JRE] I think this is a second order discussion, whether plain substitution of the user part will do or whether some sort of manipulation is required.

John

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 2 Feb 2010 10:25:50 -0500

You know Dean you have a good point here that a tightly written
applicibality statement could bound these issues pretty well.

First: as we all seem to agree its about telephone numbers.

Second ..in general the deployments using this scheme are PRI swaps.. by
that I mean the SSP is also responsible for the Layer 1 connection hence the
security issues are bounded. This is why there has been little or no push to
deploy TLS in these environments.

And for what its worth .. I don't think using TEL URI's here is going to
work.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean Willis
Sent: Monday, February 01, 2010 8:24 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] Proposed work split: tackle
telephone-numberregistration first

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 11:33:17 -0500

> In my opinion Contact is not meant to be used for informing the UA about what number was called etc in order to reach the UA.

I will have to hunt to find the references, but there have been plenty 
of them discussing things like multi-line phones that have pointed out 
the importance of using distinct contacts when registering each "line" 
so that you can unambiguously distinguish which of your registrations a 
call is coming from. These have been discussed for many years, so IMO it 
falls into the category of "meant to be used that way".

> Again, as far as I understand, from a SIP network perspective the PBX only has a single contact.

That is why we are having this long discussion.
For a SIP perspective the PBX *ought* to be reached via 3263 procedures.

It is the desire to use REGISTER for a purpose outside its original 
intent that has introduced the complexity. Same for "implicit" 
registration as defined by IMS.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 11:43:39 -0500

> In that case, why would we need to send a wildcarded Contact (as suggested by Dean)? Why not simply register the IPX IP address, and the registrar then adds the user part for inbound requests?

This is really more a matter of perspective (or "spin") rather than 
substance:

If the SSP is going to be retargetting to different "contact" addresses 
depending on the target phone number, we can describe that in two ways:

1) there is a single contact address registered and kept in the location
    database, but with permission to replace the user part according to
    some agreed upon algorithm

2) There is a single contact address registered. But something in
    the register causes it to be expanded into a number of distinct
    contact addresses that are placed in the location database.
    Incoming requests choose an appropriate entry from that db and
    use it without change.

When you view the SSP as a black box these can be indistinguishable.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Feb 2010 11:24:14 -0600

> And for what its worth .. I don't think using TEL URI's here is going to

<speaking-as-participant>

Everyone I'm talking to is talking about SIP-URI-with-E.164-as-user-part, 
and not TEL URI, when they are talking about "telephone numbers".

</speaking-as-participant>

<speaking-as-co-chair>

So, just to check consensus here ... is anyone willing to argue AGAINST 
dropping TEL URIs from consideration? I haven't seen support for basing a 
solution on TEL URIs on-list, and I don't want us to head down blind alleys 
if no one is following ...

Thanks,

Spencer

</speaking-as-co-chair>

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Feb 2010 12:36:49 -0600

On 2/2/10 11:24, Feb 2, Spencer Dawkins wrote:
>
> So, just to check consensus here ... is anyone willing to argue 
> AGAINST dropping TEL URIs from consideration?

Although I was originally thinking this was the best way forward, I have 
concluded that we can achieve the same effect using SIP URIs, if *and* 
*only* *if* we use the PBX's IP address as the host portion. I think we 
can all agree that the PBX is uniquely responsible for URIs addressed to 
the PBX's IP address.

However, if we decide (for whatever reason) that using IP addresses in 
the R-URIs from the SSP to the PBX is unacceptable, then it is my 
opinion that we're back to needing to use TEL URIs here.

So, provisionally, I'm okay dropping TEL URIs from consideration as long 
as we can come up with a R-URI from the SSP to the PBX that is 
uncontroversially the PBX's responsibility.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 2 Feb 2010 15:06:24 -0500

RS> As in a domain like customerornumber.ssp.net where the delegation is
unambiguous since I'm guessing 99.99% of these domains are getting their IP
addressing from the SSP as well.

RS> In general a very tight biding of the solution to an even tighter set of
operational parameters certainly makes sense. As in ..use this technique
ONLY if ..A. Only phone numbers are involved B. security bindings between
PBX and SSP are inconsequential due to Layer One control C. SSP MUST issue
the domain to the pbx? 

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 2 Feb 2010 15:07:33 -0500

+1  Thank you Marty ..that is the central problem. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of DOLLY, MARTIN C (ATTLABS)
Sent: Monday, February 01, 2010 8:50 PM
To: Dean Willis; Christer Holmberg
Cc: Hadriel Kaplan; [email-masked]
Subject: Re: [martini] Proposed work split:
tackletelephone-numberregistration first

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Feb 2010 14:53:46 -0600

(speaking as participant)

> addressing from the SSP as well.

We're obviously miles past the part where people get everything they need 
(including the parts that conflict with other parts they need, plus a pony), 
but SIPconnect 1.1 is also trying to wean carriers off using IP addresses 
(as in Adam's Use Cases 3 and 4, for example), as a way of preparing for 
IPv6 deployment.

So I'd like to hear opinions about whether using per-PBX SP subdomains in 
the request URI between the SP and the SIP-PBX could have the same happy 
attributes that using an IP address would have in Use Cases 3 and 4. If the 
answer is "no", that's fine, and we can remove that advice, but I wanted to 
ask the question early in the MARTINI discussion.

But I'm not asking us to violate physics, right? :D

> PBX and SSP are inconsequential due to Layer One control C. SSP MUST issue

I think this discussion (applicability statement) is going to be really 
important in getting this work approved, but I'm wondering (still speaking 
as a participant) if we should see what Use Cases we settle on, because I'm 
thinking the solution characteristics would affect where we can recommend 
using the solution. Richard, please make sure we return to that discussion 
at an appropriate time!

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 15:58:00 -0500

Adam,

I just posted a reply to david that is a different spin, but getting at 
the same point. Specifically, if a domain name is used, the SSP needs a 
way to know, legally, that the pbx customer is entitled to that domain 
name, and that can be a problem.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Feb 2010 15:01:02 -0600

On 2/2/10 14:53, Feb 2, Spencer Dawkins wrote:
> We're obviously miles past the part where people get everything they 
> need (including the parts that conflict with other parts they need, 
> plus a pony), but SIPconnect 1.1 is also trying to wean carriers off 
> using IP addresses (as in Adam's Use Cases 3 and 4, for example), as a 
> way of preparing for IPv6 deployment.

That's interesting -- we just did a lot of anthill kicking and 
apple-cart-overturning to get sip-ipv6-abnf-fix approved with the 
properly crossed t's and meticulously dotted i's (plus a multitude of 
other tiddles and dots in exactly the right places) to placate all 
interested parties. Admittedly, a lot of this went on behind the scenes, 
but this work didn't end up being the no-brainer that I think a lot of 
us assumed it would be.

Anyway, my point is that some people have done a lot of work to make 
sure that IPv6 addresses in SIP URIs work just fine.

> So I'd like to hear opinions about whether using per-PBX SP subdomains 
> in the request URI between the SP and the SIP-PBX could have the same 
> happy attributes that using an IP address would have in Use Cases 3 
> and 4. If the answer is "no", that's fine...

Unless application of RFC3263 to those domains somehow yields the IP 
address of the PBX, then the answer is a firm "no."

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Feb 2010 15:19:57 -0600

----- Original Message ----- 
From: "Adam Roach" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "Richard Shockey" <[email-masked]>; "'Dean Willis'" 
<[email-masked]>; "'Hadriel Kaplan'" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, February 02, 2010 3:01 PM
Subject: Re: [martini] Culling tel URIs

>> (including the parts that conflict with other parts they need, plus a 
>> pony), but SIPconnect 1.1 is also trying to wean carriers off using IP 
>> addresses (as in Adam's Use Cases 3 and 4, for example), as a way of 
>> preparing for IPv6 deployment.
>
> apple-cart-overturning to get sip-ipv6-abnf-fix approved with the properly 
> crossed t's and meticulously dotted i's (plus a multitude of other tiddles 
> and dots in exactly the right places) to placate all interested parties. 
> Admittedly, a lot of this went on behind the scenes, but this work didn't 
> end up being the no-brainer that I think a lot of us assumed it would be.
>
> Anyway, my point is that some people have done a lot of work to make sure 
> that IPv6 addresses in SIP URIs work just fine.

Thanks for the pointer - the discussions in the SIP Forum happened, like, 14 
months ago, and this was sufficiently behind-the-scenes that it hadn't 
fogged MY personal radar!

>> attributes that using an IP address would have in Use Cases 3 and 4. If 
>> the answer is "no", that's fine...
>

Thanks for the quick answer!

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 17:47:29 -0500

Spencer Dawkins wrote:
> Everyone I'm talking to is talking about 
> SIP-URI-with-E.164-as-user-part, and not TEL URI, when they are talking 
> about "telephone numbers".
> 
> dropping TEL URIs from consideration? I haven't seen support for basing 
> a solution on TEL URIs on-list, and I don't want us to head down blind 
> alleys if no one is following ...

I realize this isn't used much currently, and so I suppose there may 
need to be a solution that doesn't require it. But I still think this 
solves problems that people currently just sweep under the rug, so I 
would hate to take it off the table.

For instance, if my UA receives a request with From: 
sip:[email-masked], what is it supposed to display as the 
caller, and in my call history? The whole thing? Or just the phone 
number? Common practice is often to just display the phone number. Then 
If I want to make a followup call, how do I address it? To that same 
full URI, or to sip:[email-masked] or to 
sip:[email-masked]?

None of those questions even arise if the From: contains a TEL.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 19:05:25 -0500

Hadriel Kaplan wrote:
>> Of Paul Kyzivat
>> Sent: Friday, January 29, 2010 9:45 AM
>> To: Adam Roach
>>
>> 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.
> 
> 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.  

I said "when TEL URIs are used...there is no need to", and you just 
stated that they won't be used. You haven't made my statement false.

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

The purpose of standards is to get people to do things in a consistent 
way. The need for a mapping function is evidence that standards are 
lacking or not being used.

I guess you don't want usage to change in such a way as to put you out 
of business. :-)

But you are right - it is true that a pbx can live in blissful 
ignorance, assuming that all SIP URIs are of the form 
sip:<number>@my-name.com as long as its only communication with the 
external world is via an SBC that preserves that myth.

It could equally well live with the expectation that all those URIs are 
TEL:<number>. Then it wouldn't have to be configured with something 
different for each deployment.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Feb 2010 03:46:12 -0500

> Sent: Tuesday, February 02, 2010 7:05 PM
> To: Hadriel Kaplan
> 

I think we were talking past each other.  I meant that since the SIP request had SIP URI's to begin with when it reach the SSP, mandating a TEL URI doesn't avoid mapping, because something has to map it to the TEL URI before sending it to the PBX.

> external world is via an SBC that preserves that myth.

Actually, I've been pretty consistently trying to advocate for things so that SBC's don't have to do "mappings" or interop fix-its.  If I wanted to keep having to fix stuff to make SIP work, I'd ignore the IETF and SIP-Forum.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Feb 2010 09:46:42 -0500

> I think we were talking past each other.  I meant that since the SIP request had SIP URI's to begin with when it reach the SSP, mandating a TEL URI doesn't avoid mapping, because something has to m…

If everybody used TEL URIs in From/To when it was a phone number they 
are calling from or trying to reach, then no mapping of the From/To 
would be needed, end to end.

> Actually, I've been pretty consistently trying to advocate for things so that SBC's don't have to do "mappings" or interop fix-its.  If I wanted to keep having to fix stuff to make SIP work, I'd ig…

Yes, I know you have. I was just pulling your chain.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Feb 2010 23:03:12 +0100

>lacking or not being used.

Or both :)

Regards,

Christer

---

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

On Feb 2, 2010, at 12:12 AM, Christer Holmberg wrote:

> In my opinion Contact is not meant to be used for informing the UA  
> about what number was called etc in order to reach the UA.

No, but it IS the mechanism that a proxy uses to select the UA to  
which the INVITE should be sent. In other words it doesn't inform the  
UA as to which number was used; rather it informs the UA as to which  
handset to alert.

> PBX only has a single contact.

That depends on the PBX, doesn't it?

--
Dean

---

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

On Feb 2, 2010, at 2:18 AM, Christer Holmberg wrote:

>
>
> But, what if the PBX is using outbound? I assume the same instance  
> id and gr values are going to be used for all PBX users, eventhough  
> each PBX user has a unique Contact within the SSP?
>

I wouldn't think so: we should have a separate instance ID and gruu  
value for each "user" -- it's the only way I can see to make call  
transfers work right.

--
Dean

---

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

On Feb 2, 2010, at 11:24 AM, Spencer Dawkins wrote:
> AGAINST dropping TEL URIs from consideration? I haven't seen support  
> for basing a solution on TEL URIs on-list, and I don't want us to  
> head down blind alleys if no one is following ...
>
> Thanks,
>
> Spencer
>
> </speaking-as-co-chair>

I continue to support TEL as the cleanest solution. It's what people  
really want and don't know how to ask for, kind of like one of those  
Cosmo quiz things.

If all you want is "a phone number" without the overhead of "domain  
ownership" then you really do want TEL.  Yes, we don't have a history  
of doing it the right way. We could always start.

--
Dean

---

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

On Feb 2, 2010, at 12:36 PM, Adam Roach wrote:

> Although I was originally thinking this was the best way forward, I  
> have concluded that we can achieve the same effect using SIP URIs,  
> if *and* *only* *if* we use the PBX's IP address as the host  
> portion. I think we can all agree that the PBX is uniquely  
> responsible for URIs addressed to the PBX's IP address.

I'm still not sure I but this. For example, the PBX might have a valid  
DNS name, that just isn't interesting from a "company name"  
perspective. For example, my "PBX" is currently using  
cpe-66-25-30-183.tx.res.rr.com, which it discovers by doing a PTR  
lookup on its IP address. It's a perfectly valid thing to use to  
populate a Contact, even though it has only an ephemeral relationship  
with "softarmor.mine.nu".

--
Dean

---

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

On Feb 2, 2010, at 2:07 PM, Richard Shockey wrote:

> Behalf

Dangit Richard! I never suggested that every user register. As far as  
I know, NOBODY has suggested that.

I suggested (based on Adam's work) that the PBX send a single  
registration that creates multiple AOR/Contact/GRUU bindings in the  
SSP proxy, and that the SSP proxy work just exactly like an ordinary  
proxy when handling requests following the registration.

--
Dean

---

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

On Feb 2, 2010, at 2:58 PM, Paul Kyzivat wrote:

> Adam,
>
> I just posted a reply to david that is a different spin, but getting  
> at the same point. Specifically, if a domain name is used, the SSP  
> needs a way to know, legally, that the pbx customer is entitled to  
> that domain name, and that can be a problem.
>

If a domain name is used in a Contact, then no, the SSP doesn't need  
to know that a PBX customer is entitled to use that domain. We don't  
have any way in SIP to check for authorization at the Contact level  
based on DNS name or IP address.

If a user PBX installed at an IP address having an associated A record  
for "cisco.com" sends a REGISTER request with a "To:" of  
"baynetworks.com", and that PBX has the authentication credentials for  
baynetworks.com, then it can register!

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Feb 2010 00:07:35 -0600

On Feb 4, 2010, at 11:39 PM, Dean Willis wrote:

> I'm still not sure I but

Buy, not but ! mean I'm not sure I BUY this (aka, I think it's not  
true).

> this. For example, the PBX might have a valid DNS name, that just  
> isn't interesting from a "company name" perspective. For example, my  
> "PBX" is currently using cpe-66-25-30-183.tx.res.rr.com, which it  
> discovers by doing a PTR lookup on its IP address. It's a perfectly  
> valid thing to use to populate a Contact, even though it has only an  
> ephemeral relationship with "softarmor.mine.nu".

--
Dean, the typing impaired.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Feb 2010 08:32:06 +0100

There is a discussion of gr values in the gin draft. I don't see a need for multiple instance IDs.

John 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 05 February 2010 05:20
> To: Christer Holmberg
> Cc: Elwell, John; [email-masked]; Hadriel Kaplan

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 5 Feb 2010 06:16:08 -0600

Hi, Dean,

> ownership" then you really do want TEL.  Yes, we don't have a history  of 
> doing it the right way. We could always start.

<speaking-as-co-chair>

TEL URIs would really need to appear in a draft, for us to move in this 
direction. I thought that was where we were headed sometime around the V-I 
II timeframe, but then I had some e-mail exchanges with Adam and he produced 
GIN instead.

So I'm thinking that we might not be CULLING the TEL URI concept, but if we 
don't have a draft that proposes TEL URIs, we're not going to end up 
adopting a solution that uses them.

</speaking-as-co-chair>

Thanks,

Spencer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 5 Feb 2010 13:45:58 +0100

Just picking up on this one.

> > Again, as far as I understand, from a SIP network 
> perspective the PBX 
> > only has a single contact.
> 
> 
If I have a scenario for what used to be called a multi-tenant PBX, i.e. where the physical resources are being shared, including the ADSL link, it may well be that you need a separate key identifier for each tenant. 

Certainly in the TISPAN work we said that the registered contact should represent an endpoint that is able to act on behalf of all the other URIs that implicitly registered as part of that registration. Thus a URI that represents the attendent of tenant 1 can be used to register all the public URIs of users of tenant 1, but not should be responsible for those of tenant 2 (excluding a shared attendant of course).

How much this impacts the SSP depends on other things. To the SSP it may look like a set of independent PBXs, but in IMS land they could all share the same private user identity and use the same security association.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Friday, February 05, 2010 5:18 AM
> To: Christer Holmberg
> No, but it IS the mechanism that a proxy uses to select the 
> UA to which the INVITE should be sent. In other words it 
> doesn't inform the UA as to which number was used; rather it 
> informs the UA as to which handset to alert.
> 
> >
> >>> 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 
> >> Adam's proposal provided a way to do that mapping under 
> the control 
> >> of the recipient so that only expected contact addresses are used.
> >
> > Again, as far as I understand, from a SIP network 
> perspective the PBX 
> > only has a single contact.
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Feb 2010 09:14:53 -0500

Dean Willis wrote:
> If a domain name is used in a Contact, then no, the SSP doesn't need to 
> know that a PBX customer is entitled to use that domain. We don't have 
> any way in SIP to check for authorization at the Contact level based on 
> DNS name or IP address.
> 

My comment was in the context of doing something like the stirred 
approach. People seem to be taking that draft off the table, but I'm not 
certain that corresponding concept is off the table.

If it is entirely off the table, then you can ignore my comment.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Feb 2010 09:50:39 -0600

On 2/5/10 6:16 AM, Spencer Dawkins wrote:
> TEL URIs would really need to appear in a draft, for us to move in 
> this direction. I thought that was where we were headed sometime 
> around the V-I II timeframe, but then I had some e-mail exchanges with 
> Adam and he produced GIN instead.

My original plan for the GIN draft was actually to use TEL instead of 
SIP. I took it the other direction for two reasons: (1) the temperature 
of the working group on TEL gave me the impression that a TEL-based 
proposal had less chance of satisfying everyone's desires; and (2) the 
mechanism for doing this with TEL became a bit more fiddly, since we had 
to clarify how TEL routing is performed in a MARTINI context.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 5 Feb 2010 10:04:43 -0600

Hi, Adam,

>> direction. I thought that was where we were headed sometime around the 
>> V-I II timeframe, but then I had some e-mail exchanges with Adam and he 
>> produced GIN instead.
>
> My original plan for the GIN draft was actually to use TEL instead of SIP. 
> I took it the other direction for two reasons: (1) the temperature of the 
> working group on TEL gave me the impression that a TEL-based proposal had 
> less chance of satisfying everyone's desires; and (2) the mechanism for 
> doing this with TEL became a bit more fiddly, since we had to clarify how 
> TEL routing is performed in a MARTINI context.

Speaking as a participant, I agree with your change of course, for reasons 
that people raised almost immediately when a TEL draft loomed just over the 
horizon.

Speaking as co-chair, my intention was to let people who think TEL would be 
awesome that they might have been expecting a TEL-ish draft to automagically 
appear, but it doesn't look that's going to happen unless THEY write one :D

Thanks,

Spencer

---

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

Brother Dean.. my intention was to remind everyone what the meta problem
really is problem and the consensus we have that it really is a two part
solution we will need to address. First is the Implicit Registration issue
in REGISTER and the second a long term problem to the provisioning of PBX's
to SSP's. The list had gotten much bigger over the last few week.

BTW IMHO using TEL: URI here is a non starter. Either the shaken or gin
approach _could_ work and in fact already does. The issue we have always had
is that there was no implicit indicator ( aka the option tag) in the
register message that let the SSP understand exactly what the semantic
meaning of the implicit registration actually was.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, February 05, 2010 12:43 AM
To: Richard Shockey
Cc: 'DOLLY, MARTIN C (ATTLABS)'; 'Christer Holmberg'; 'Hadriel Kaplan';
[email-masked]

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Feb 2010 19:25:07 +0100

Keith,

I think the gin-00 solution could handle that, by treating each as a logical PBX (i.e., registering separately on behalf of each). Rather like a multi-line UA would register separately on behalf of each of its lines. Anyway, if you believe we should address requirements in this area, we should say so in the requirements draft.

John

> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: 05 February 2010 12:46
> If I have a scenario for what used to be called a 
> multi-tenant PBX, i.e. where the physical resources are being 
> shared, including the ADSL link, it may well be that you need 
> a separate key identifier for each tenant. 
> 
> Certainly in the TISPAN work we said that the registered 
> contact should represent an endpoint that is able to act on 
> behalf of all the other URIs that implicitly registered as 
> part of that registration. Thus a URI that represents the 
> attendent of tenant 1 can be used to register all the public 
> URIs of users of tenant 1, but not should be responsible for 
> those of tenant 2 (excluding a shared attendant of course).
> 
> How much this impacts the SSP depends on other things. To the 
> SSP it may look like a set of independent PBXs, but in IMS 
> land they could all share the same private user identity and 
> use the same security association.
> 
> regards
> 
> Keith
> 
>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 23 Feb 2010 12:38:32 -0500

The short answer IMHO is no it does not include private numbering plans 
_ at this time_ but that is because of some specific market conditions 
that SIP trunking addresses. The marked preference of consumers and 
small businesses is to issue DID numbers to all extensions from the PBX 
and implicit registration permits incremental issuance of those numbers 
as needed and not in blocks as is customary in classic PRI 
installations.  That is a HUGE cost savings to SMBs' and a principal 
market driver for SIP trunking in the marketplace.  That is different in 
Europe where "local numbers" are much more extensive it of course 
depends on which EC country you are talking about. I suspect that DID 
are more popular where formal database LNP systems are in place such as 
Sweden or the Netherlands.

The largest single inhibitor to SIP trunking is the lack of true LNP in 
many countries since businesses are highly reluctant to change their 
E.164 numbers just to get lower costs. Plus the current dominat practice 
of number porting by simply call forwarding from the donor (incumbent) 
switch kills many of the features that the recipient SSP can offer.  
That is now changing with new EC rules that are coming into effect in 
the next few years.

I completely appreciate Keiths' concerns here but I worry the further we 
expand the scope of the task at hand the further we are from the kind of 
incremental solution that is needed.

On 1/29/2010 11:01 AM, Adam Roach wrote:
> 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

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