Subject: [martini] comments on draft-roach-martini-gin-00

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Feb 2010 12:53:46 -0500

Hi Adam, 
Thanks for taking the time to write up the draft!

I have a few comments/questions:
1) Why bother having the "()" indicator in the Contact-URI username?  This implies that the Contact-URI could be "sip:foo()[email-masked]", or something similar, such that a placeholder is needed.  But why do we need to complicate the mechanism to handle that?  The PBX can already use URI params if it needs extra cookies, or it can even insert itself as a Path header.  I do, though, think the explicitly Registered contact-URI could be of the form "sip:[email-masked]", and have a username - but it would be replaced for the expanded entries. 

2) Why bother having the "*" indicator for GRUU?  We've talked about doing the GRUU manip that way (by having the pbx add on to the one the SSP gives it), but by either adding the pbx-specifics as a new param, or simple appending.  Again I don't see a need to support something like "uuid:foo*bar" (in fact it would be really bad to do that), so if it's always appending to the end then you don't need a star.

3) Why does the Contact-URI have a 'bnc' param, instead of in the AoR being Registered?  ISTM the expansion of the location service entries is actually a property of the AoR, not its location/contact.  And if we have it in the contact-uri, why remove it for the req-uri replacement?

4) Wrt the open issue of proxy-require, yes I think we should have that too, for the reasons we've discussed before on this list.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 04 Feb 2010 14:08:55 -0600

> 1) Why bother having the "()" indicator in the Contact-URI username?  This implies that the Contact-URI could be "sip:foo()[email-masked]", or something similar, such that a placeholder is needed.…

What would the username do in your example? If we get rid of the '()' 
syntax, then I'd propose heading directly for URIs of the form 
<sip:192.0.2.5;bnc> instead. But I think the ability for the PBX to 
specify the form of its own contact URIs (even if constrained by having 
the entire phone number inserted) is still a useful one.

I had originally toyed around with the idea of the PBX expressing a 
number of digits it was interested in -- for example: 
<sip:(4)@192.0.2.5;bnc> would transform <sip:[email-masked]> into 
<sip:[email-masked]>, but this seemed to be getting a bit complicated 
for the short timeframes we're applying.

> 2) Why bother having the "*" indicator for GRUU?  We've talked about doing the GRUU manip that way (by having the pbx add on to the one the SSP gives it), but by either adding the pbx-specifics as…

That's a good point. I'll remove the "*" mechanism, and simply propose 
appending in all cases.

> 3) Why does the Contact-URI have a 'bnc' param, instead of in the AoR being Registered?  ISTM the expansion of the location service entries is actually a property of the AoR, not its location/contact.

No, it's the Contact URI that's having something special done to it. 
We're saying "explode this URI into a bunch of different URIs according 
to this new procedure." It means "this is not the actual URI; it is a 
placeholder for the actual URI, and it must be modified to be the actual 
URI."

> And if we have [a 'bnc' parameter] in the contact-uri, why remove it for the req-uri replacement?
>    

As before: it means, "This is not the literal value of the URI to be 
used. You cannot use this URI as-is. You must transform this URI by 
putting a phone number in the correct place before you can use it."

After the replacement takes place, this is no longer true. It's just a 
normal URI at that point.

> 4) Wrt the open issue of proxy-require, yes I think we should have that too, for the reasons we've discussed before on this list.

I agree. But I didn't see a clear consensus on that point (and did see 
some pushback), so I wanted to leave it open for now.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Feb 2010 09:04:41 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 04 February 2010 20:09
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [martini] comments on draft-roach-martini-gin-00
> 
> > 1) Why bother having the "()" indicator in the Contact-URI 
> username?  This implies that the Contact-URI could be 
> "sip:foo()[email-masked]", or something similar, such that a 
> placeholder is needed.  But why do we need to complicate the 
> mechanism to handle that?  The PBX can already use URI params 
> if it needs extra cookies, or it can even insert itself as a 
> Path header.  I do, though, think the explicitly Registered 
> contact-URI could be of the form "sip:[email-masked]", and 
> have a username - but it would be replaced for the expanded entries.
> 
[JRE] Can we have some examples of why it would be useful? If useful, I would go for always appending the number to the user name, rather than having special characters to denote the position of insertion. If not useful, then the simple form above (no user name) would suffice.

John

> > 2) Why bother having the "*" indicator for GRUU?  We've 
> talked about doing the GRUU manip that way (by having the pbx 
> add on to the one the SSP gives it), but by either adding the 
> pbx-specifics as a new param, or simple appending.  Again I 
> don't see a need to support something like "uuid:foo*bar" (in 
> fact it would be really bad to do that), so if it's always 
> appending to the end then you don't need a star.
> >    
> 
> > 3) Why does the Contact-URI have a 'bnc' param, instead of 
> in the AoR being Registered?  ISTM the expansion of the 
> location service entries is actually a property of the AoR, 
> not its location/contact.
> 
> > 4) Wrt the open issue of proxy-require, yes I think we 
> should have that too, for the reasons we've discussed before 
> on this list.
> >    
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Feb 2010 10:00:45 -0600

> [JRE] Can we have some examples of why it would be useful? If useful, I would go for always appending the number to the user name, rather than having special characters to denote the position of in…

After giving it some additional thought in the context of "we need a 
fast solution for phone numbers," I realized that the ability to perform 
these kinds of manipulations on the user portions isn't likely to be 
useful for the target market for GIN. We certainly want something like 
this (but much more flexible) for the general solution, but for the 
numbers-only solution, I think the time spent engineering this feature 
won't be warranted by its utility.

So, yeah, I now agree that we just want to simplify this to the 
no-user-name variant.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Feb 2010 10:57:24 -0500

> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, February 04, 2010 3:09 PM
> To: Hadriel Kaplan
> 
> > 1) Why bother having the "()" indicator in the Contact-URI username?
> This implies that the Contact-URI could be "sip:foo()[email-masked]", or
> something similar, such that a placeholder is needed.  But why do we need
> to complicate the mechanism to handle that?  The PBX can already use URI
> params if it needs extra cookies, or it can even insert itself as a Path
> header.  I do, though, think the explicitly Registered contact-URI could
> be of the form "sip:[email-masked]", and have a username - but it would
> be replaced for the expanded entries.
> 

The username would be replaced for the expanded set, but would be a real URI username - of the PBX itself.  In other words, there is a real UA in the PBX which is performing the Registration, and sip:[email-masked] is its contact URI.

> > 3) Why does the Contact-URI have a 'bnc' param, instead of in the AoR
> being Registered?  ISTM the expansion of the location service entries is
> actually a property of the AoR, not its location/contact.
> 

Oh, but I'm thinking it *is* a real URI.  For example, I can send an OPTIONS request to it.  And the PBX can use it to send a SUBSCRIBE, for example to the reg-event package.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Sat, 06 Feb 2010 10:30:04 -0600

> The username would be replaced for the expanded set, but would be a real URI username - of the PBX itself.  In other words, there is a real UA in the PBX which is performing the Registration, and s…

No, that's a different thing, and there's a very real chance that you'll 
want different parameters on it.

For example, I would wager that the phone number contacts will end up in 
the form:

<sip:[email-masked];user=phone>

While this "main PBX contact" you're talking about would probably be of 
the form:

<sip:[email-masked]>

So, I think for the circumstance that you'll want this latter thing 
(which is feeling very much like the "general case", not the "phone 
numbers only" case), you'll need to register it separately.

But really, is this trying to pick up functionality for free, or is it 
driven by an actual use case? Remember, we're trying to keep this fast 
and simple.

/a

---

From: Adam Roach <[email-masked]>
Date: Sat, 06 Feb 2010 11:05:46 -0600

On 02/06/2010 10:30 AM, Adam Roach wrote:

On
02/06/2010 09:57 AM, Hadriel Kaplan wrote:

The username would be replaced for the
expanded set, but would be a real URI username - of the PBX itself.  In
other words, there is a real UA in the PBX which is performing the
Registration, and sip:[email-masked] is its contact URI.

No, that's a different thing, and there's a very real chance that
you'll want different parameters on it.

For example, I would wager that the phone number contacts will end up
in the form:

<sip:[email-masked]>

Reply to myself; sorry...

I realized that this could be read as "send two REGISTER requests,"
which is not what I mean (although it would work). What I mean is that
you could send a single REGISTER request with two contacts (which is
explicitly allowed by 3261). One Contact would be tagged "bnc" (and
therefore expand into the associated phone numbers), while the other
wouldn't (and would therefore be a literal URI).

That is, if you really want to do what you propose, you would send a
REGISTER that looks something like:

REGISTER sip:ssp.example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: <sip:[email-masked]>
From: <sip:[email-masked]>;tag=a23589
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: bulk-number-contact
Contact: <sip:198.51.100.3:5060;user=phone;bnc>
Contact: <sip:[email-masked]:5060>
Expires: 7200
Content-Length: 0

/a