Subject: [martini] #28: GIN: user=phone in the Contact

From: "martini issue tracker" <[email-masked]>
Date: Sat, 10 Apr 2010 19:50:16 -0000

#28: GIN: user=phone in the Contact
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:     
     Type:  defect                  |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  gin                     |     Version:     
 Severity:  Active WG Document      |    Keywords:     
------------------------------------+---------------------------------------
 The current example in section 8 and elsewhere in the draft uses a
 "user=phone" URI param in the Contact of the REGISTER. Since the URI does
 not actually have a user portion, it does not follow the format of
 telephone-suscriber and should not have this param.

 For example, when expanded and used for routing to the IP-PBX, the user
 portion of the resultant req-uri is not in fact a phone number but rather
 just a URI (though it sure will look like a phone number ;)

 As another example, depending on how the temp-gruu concept ends up, it may
 be incompatible with a temp-gruu mechanism, since a request to the IP-PBX
 with its temp-gruu would not have a phone user.

 Likewise, there should be text stipulating a user=dialstring is not
 appropriate for the Registered Contact.

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

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 00:20:33 +0200

On Sat, Apr 10, 2010 at 9:50 PM, martini issue tracker
<[email-masked]>wrote:

> ?? Is it a number or not ??

An incoming INVITE carrying a SIP version of a number needs to carry
user=phone, otherwise it is not a number. Period.

/Hans Erik

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 19:07:50 -0400

The gin-draft doesn't say, but IMO it's not a "phone number".  It's a registered contact URI.  Since the URI's host portion is the IP-PBX's, the IP-PBX can do what it wants with it, including treating it as a phone number of course. (which is undoubtedly what it should and will do with it)

Let me put it a different way: if a UA registers normally today, and thus does NOT use a "user=phone" in its Registered Contact-URI, what happens?  Answer: the SSP's proxy gets a Request for the E.164, and replaces the Req-uri with the Registered contact.  What breaks?

It's true that this means "sip:[email-masked];user=phone" and "sip:[email-masked]", and probably "sip:[email-masked]", would all have to resolve to the same registered user.  Is that a problem?

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Monday, April 12, 2010 6:21 PM

On Sat, Apr 10, 2010 at 9:50 PM, martini issue tracker <[email-masked]> wrote:
#28: GIN: user=phone in the Contact

An incoming INVITE carrying a SIP version of a number needs to carry user=phone, otherwise it is not a number. Period.
 
/Hans Erik

---

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

Hans Erik van Elburg wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

The user=phone thing is really very ugly - confusing and inadequate 
definition.

If you look at 3261, the logic for updating the location service during 
a REGISTER uses only the user part to select the entry, ignoring all the 
parameters. So while it might be possible for the server to route 
incoming requests differently based on the presence/absence of 
user=phone, you can't really have two unique entries in your location 
service for those cases.

However, you could have a policy that incoming requests to be routed are 
treated differently if user=phone is present. For instance, in that case 
the user part might be canonicalized - stripping out separator 
characters - before a location service dip is made. It might even reject 
values where the user part matches telephone-subscriber syntax but 
user=phone is not present.

But these are policies. Its not something that MUST be done. (Unless it 
is made mandatory for martini.)

	Thanks,
	Paul

---

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

> It's true that this means "sip:[email-masked];user=phone" and "sip:[email-masked]", and probably "sip:[email-masked]", would all have to resolve to the same registered user.  Is that a problem?

I just posted something on this subject.

The server will have to go out of its way to make the first two of those 
behave differently.

But to make the third resolve the same is going to require some 
configuration or policy algorithm to map it to the other form. No 
regular location service lookup is going to make that fall out by default.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 22:26:54 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> 

Totally.  A hack, really.
 
> user=phone, you can't really have two unique entries in your location

Right, it would break in a heart-beat.
 
> is made mandatory for martini.)

Actually, it was my impression that since RFC 3966 said the visual-separators aren't used for URI comparison, that the Registrar processing of the REGISTER for a user=phone would remove them as part of the canonicalization step, and proxies would too as part of the location service lookup.

But clearly it's too brittle all around, and the reality is you have to treat "sip:[email-masked]" the same as "sip:[email-masked];user=phone" unless you want things to break left and right.  

-hadriel

---

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

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, April 12, 2010 7:55 PM
> 
> Hadriel Kaplan wrote:
> >
> > Let me put it a different way: if a UA registers normally today, and
> thus does NOT use a "user=phone" in its Registered Contact-URI, what
> happens?  Answer: the SSP's proxy gets a Request for the E.164, and
> replaces the Req-uri with the Registered contact.  What breaks?
> >
> > It's true that this means "sip:[email-masked];user=phone" and
> "sip:[email-masked]", and probably "sip:[email-masked]", would all
> have to resolve to the same registered user.  Is that a problem?
> 

You're right - just the first two then.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Apr 2010 09:14:42 -0400

> Actually, it was my impression that since RFC 3966 said the visual-separators aren't used for URI comparison, that the Registrar processing of the REGISTER for a user=phone would remove them as par…

Well, I can find nothing in 3261 section 19.1.4 (URI Comparison) that 
would suggest you should. Nor do I see anything in registration 
procedures that would suggest doing this. I'm not even certain if you 
would be compliant if you did so. (I expect us spec-lawyers could argue 
over that for a long time.)

The place with the most latitude is retargeting, where you can do pretty 
much as you wish.

> But clearly it's too brittle all around, and the reality is you have to treat "sip:[email-masked]" the same as "sip:[email-masked];user=phone" unless you want things to break left and right.  

Yup. Once upon a time I thought you could in effect have two namespaces 
within your domain - one for user=phone, and another for user=ip. But I 
eventually realized that isn't possible.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Apr 2010 16:06:37 -0500

I think a large part of this comes down to what the PBX needs to happen. 
Ultimately, the thing it sends in its contact header field for a 
registration is what it needs to get back from the SSP. If its internal 
processing needs a ";foo=bar" parameter to properly associate the 
incoming URI with the bulk registration, that's really its own private 
business.

Given that the semantics of ";user=" are so thorougly ill-defined, I 
don't think it makes any sense at all to special case it. As paul points 
out, the URI comparison rules don't really let you maintain multiple 
userportion namespaces, with ";user=" as your differentiator. So it 
really all comes down to local policy at the PBX.

If the PBX needs or wants a parameter to be there on inbound URIs, it 
includes it in the registration. If it doesn't, it doesn't. I think a 
normative requiring or prohibition on ";user=" in GIN would be 
specification for its own sake. It definitely doesn't help 
interoperability in any way.

/a

Paul Kyzivat wrote:
>> Actually, it was my impression that since RFC 3966 said the 
>> visual-separators aren't used for URI comparison, that the Registrar 
>> processing of the REGISTER for a user=phone would remove them as part 
>> of the canonicalization step, and proxies would too as part of the 
>> location service lookup.
>
> would be compliant if you did so. (I expect us spec-lawyers could 
> argue over that for a long time.)
>
> The place with the most latitude is retargeting, where you can do 
> pretty much as you wish.
>
>> But clearly it's too brittle all around, and the reality is you have 
>> to treat "sip:[email-masked]" the same as 
>> "sip:[email-masked];user=phone" unless you want things to break 
>> left and right. 
>
> Yup. Once upon a time I thought you could in effect have two 
> namespaces within your domain - one for user=phone, and another for 
> user=ip. But I eventually realized that isn't possible.
>
>     Thanks,
>     Paul
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: "martini issue tracker" <[email-masked]>
Date: Mon, 19 Apr 2010 21:18:22 -0000

#28: GIN: user=phone in the Contact
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:  adam@…          
     Type:  defect                  |      Status:  assigned        
 Priority:  minor                   |   Milestone:                  
Component:  gin                     |     Version:                  
 Severity:  Active WG Document      |    Keywords:                  
------------------------------------+---------------------------------------
Changes (by adam@…):

  * owner:  => adam@…
  * status:  new => assigned

Comment:

 Propose the following text for -01:

       Although it is not a special case from a protocol perspective,
       implementors are reminded that this behavior includes any
       "user" parameter on the URI. For example, if the registering
       PBX requires incoming messages to include a "user=phone"
       parameter on their Request-URI, it will include "user=phone"
       on the URI in the "Contact" header field of its registration.
       Because of the requirement on the SSP to copy parameters into
       the location service, it will appear on any Request-URIs that
       are retargeted to the PBX based on that registration. Conversely,
       if the registering PBX does not include a "user=phone"
       parameter, any SSP using the procedures defined in this
       document would not be at liberty to include one on the
       Request-URI.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/28#comment:1>
martini <http://tools.ietf.org/martini/>

---

From: Brett Tate <[email-masked]>
Date: Tue, 20 Apr 2010 09:19:43 -0700

> Given that the semantics of ";user=" are so thorougly 
> ill-defined, I don't think it makes any sense at all 
> to special case it.

As far as I know, this would be the first RFC to explicitly and intentionally interpret RFC 3261 in a way which allows user=phone to be included when the userinfo does not decode into an rfc3966/rfc2806 telephone-subscriber.  Does MARTINI and SIPCORE really want RFC 3261 to be interpreted in this manor instead of fixing the ambiguity with another interpretation?

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 20 Apr 2010 21:32:24 +0200

Point.

Wouldn't it be better instead that the draft clarifies that user=phone
does not survive the Request-URI replacement with the pbx-contact.

And refrains from awkard examples where user=phone is attached to a
registered contact address. Really awkward. Without the example people
are still free to configure their PBX to do it if it makes them happy.

If user=phone needs to survive the gin contact routing transformation,
then that transformation better specifies that policy.

/Hans Erik van Elburg

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Apr 2010 14:56:47 -0500

Let me make sure I understand what you're lobbying for.

You both seem to be saying that you want to prevent a PBX from telling 
an SSP that it needs a "user=phone" on inbound URIs. Which means that 
PBXes that use this as some kind of optimization or necessity for 
internal processing are excluded from being able to use GIN for some 
artificial -- or, at best, aesthetic -- reason.

Keep in mind that the thing we're sending in the Contact header field 
isn't a traditional SIP URI, in that it will never, by itself, be used 
for routing anything. It's a *TEMPLATE*. It is *USELESS* until it is 
*INSTANTIATED*. And when it is instantiated, it will contain a telephone 
number. So, by the time it exists as a usable URI, it is correct.

As we went over in Anaheim, objections that the template itself doesn't 
contain a user portion while a "user" parameter are present are 
pedanticism of the highest degree. We're taking some rather extreme 
measures to ensure that all parties to the transaction are fully aware 
of the meaning of the "bnc" parameter, so nothing can possibly be broken 
by this syntax. Everything that can potentially be involved *knows* this 
is a template. It will *understand* that you can't use the URI until it 
has been instantiated.

Now, I'm happy to take it off the examples -- I don't have a strong 
opinion about whether PBXes should be doing this -- but I think 
artificially constraining the functionality can only make interop more 
difficult, not easier.

/a

On 4/20/10 2:32 PM, Hans Erik van Elburg wrote:
> On Tue, Apr 20, 2010 at 6:19 PM, Brett Tate<[email-masked]>  wrote:
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Apr 2010 16:09:59 -0400

No I think the concern is different, and more along the lines of why I submitted the tracker.

The UA is registering a template, of course, but any/all params other than the 'bnc' one are opaque to the SSP Registrar/proxy, right?  The SSP reg-proxy expands them into sip:foobar@<opaque stuff> in the DB.

And when doing a req-uri replacement the SSP proxy replaces the req-uri with the (now expanded) registered contact-URI, right?

So when routing to the PBX, the SSP proxy is sending a req-uri that now has a "user=phone" param, without having any idea if the user portion is in fact a telephone format.  For example, in draft-olive they're not.  The SSP proxy performing the req-uri routing replacement is just looking up an AoR and replacing it with a registered contact-URI.

-hadriel

> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2010 3:57 PM
> To: Hans Erik van Elburg
> Cc: Brett Tate; Paul Kyzivat; [email-masked]; Hadriel Kaplan
> Subject: Re: [martini] #28: GIN: user=phone in the Contact
> 
> >> As far as I know, this would be the first RFC to explicitly and
> intentionally interpret RFC 3261 in a way which allows user=phone to be
> included when the userinfo does not decode into an rfc3966/rfc2806
> telephone-subscriber.  Does MARTINI and SIPCORE really want RFC 3261 to be
> interpreted in this manor instead of fixing the ambiguity with another
> interpretation?
> >>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 20 Apr 2010 22:10:32 +0200

On Tue, Apr 20, 2010 at 9:56 PM, Adam Roach <[email-masked]> wrote:
> You both seem to be saying that you want to prevent a PBX from telling an
> SSP that it needs a "user=phone" on inbound URIs. Which means that PBXes
> that use this as some kind of optimization or necessity for internal
> processing are excluded from being able to use GIN for some artificial --
> or, at best, aesthetic -- reason.
>
No I wasn't implying that.

I was saying that it is an awkward example, if a pbx wants to do this
it can still do it.

> Keep in mind that the thing we're sending in the Contact header field isn't
> a traditional SIP URI, in that it will never, by itself, be used for routing
> anything. It's a *TEMPLATE*. It is *USELESS* until it is *INSTANTIATED*. And
> when it is instantiated, it will contain a telephone number. So, by the time
> it exists as a usable URI, it is correct.
>
I was also saying that if user=phone needs to be carried over, then it
better be part of the transformation G(I,N) where I is a template and
N a number a template and constructs the new Request-URI.

> contain a user portion while a "user" parameter are present are pedanticism
> of the highest degree. We're taking some rather extreme measures to ensure
> that all parties to the transaction are fully aware of the meaning of the
> "bnc" parameter, so nothing can possibly be broken by this syntax.
> Everything that can potentially be involved *knows* this is a template. It
> will *understand* that you can't use the URI until it has been instantiated.
>
That is why it is good to explain the consequences of the chosen
mechanism, so that everybody understands them.
To be honest I did not understand the discussion in Anaheim, today
after reading Brett's reply I understood why I didn't understand it
;-)

> Now, I'm happy to take it off the examples -- I don't have a strong opinion
> about whether PBXes should be doing this -- but I think artificially
> constraining the functionality can only make interop more difficult, not
> easier.
Removing it from the examples does not constrain it in any way does it?

Having every PBX attach it to the PBX-Contact (or template), on the
other hand constrains the mechanisms extensibility.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 20 Apr 2010 22:12:30 +0200

Right. I realised after writing it that it is actually the point you
was trying to make when starting this thread.

/Hans Erik van Elburg

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Apr 2010 15:15:12 -0500

> So when routing to the PBX, the SSP proxy is sending a req-uri that now has a "user=phone" param, without having any idea if the user portion is in fact a telephone format.  For example, in draft-o…

So a PBX provisioned to use non-telephone-number user portions -- such 
as is described in olive -- would be misbehaving if it tacked on a 
"user=phone." It would effectively be a provisioning mismatch. And 
there's been a strong consensus that we're not detecting or correcting 
provisioning mismatches in GIN.

/a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 20 Apr 2010 22:22:17 +0200

On Tue, Apr 20, 2010 at 10:15 PM, Adam Roach <[email-masked]> wrote:
>> The UA is registering a template, of course, but any/all params other than
>> the 'bnc' one are opaque to the SSP Registrar/proxy, right?  The SSP
>> reg-proxy expands them into sip:foobar@<opaque stuff>  in the DB.
>>
>> And when doing a req-uri replacement the SSP proxy replaces the req-uri
>> with the (now expanded) registered contact-URI, right?
>>
>> So when routing to the PBX, the SSP proxy is sending a req-uri that now
>> has a "user=phone" param, without having any idea if the user portion is in
>> fact a telephone format.  For example, in draft-olive they're not.  The SSP
>> proxy performing the req-uri routing replacement is just looking up an AoR
>> and replacing it with a registered contact-URI.
>>
>
> So a PBX provisioned to use non-telephone-number user portions -- such as is
> described in olive -- would be misbehaving if it tacked on a "user=phone."
> It would effectively be a provisioning mismatch. And there's been a strong
> consensus that we're not detecting or correcting provisioning mismatches in
> GIN.

No, it is not.

The PBX may accept a mix of telephone numbers and non-telephone
numbers. Having user=phone on that template is plainly wrong.

/Hans Erik

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Apr 2010 16:23:34 -0400

> Sent: Tuesday, April 20, 2010 4:15 PM
> To: Hadriel Kaplan
> Cc: Hans Erik van Elburg; Brett Tate; Paul Kyzivat; [email-masked]

Yup, and in a draft of olive I actually use that as an indication of such, but then realized this would be in conflict with draft-gin, if draft-gin showed such things in examples and gave no guidance about it.  Which is what made me think about it more and triggered me to submit a tracker. :)

-hadriel

---

From: Brett Tate <[email-masked]>
Date: Tue, 20 Apr 2010 15:10:23 -0700

> Let me make sure I understand what you're lobbying for.

I'm not lobbying for anything.  I asked a question since #28 had been raised against GIN.

> You both seem to be saying that you want to prevent 
> a PBX from telling an SSP that it needs a "user=phone" 
> on inbound URIs.

No; I just asked a question.  I assume that there are a variety of answers; the following are few.

1) Yes.

2) No; however tolerating such an interpretation is required for devices that support gin.

3) No; #28 will be resolved in some other way.

<snip>

> telephone-subscriber.  Does MARTINI and SIPCORE really want RFC 3261 to
> be interpreted in this manor instead of fixing the ambiguity with
> another interpretation?