Subject: [martini] GIN Draft

From: Adam Roach <[email-masked]>
Date: Tue, 02 Feb 2010 18:09:24 -0600

I have put together a draft to address Globally Identifiable Numbers for 
PBX registration. (Sorry, "Identifiable" was the best near-synonym I 
could find for "Unique" starting with I -- and everyone knows real 
martinis are made with gin. ;-) )

The contents of this draft are based on several factors from the phone 
calls and mailing list; in particular:

    * The (tentative) agreement to move forward with phone numbers as an
      initial, narrowed scope.
    * A perceived consensus to use REGISTER for the phone number use case.
    * A perceived consensus to have the specific phone numbers being
      registered to be "implicit" (i.e., provisioned in both the SSP and
      the PBX, and not exchanged on the wire).
    * A perceived consensus not to carry the registered extensions in
      the REGISTER response
    * A perceived consensus _not_ to use TEL URIs between the SSP and
      the PBX

I have also started an analysis (in the document) of how this kind of 
mechanism can play nicely with GRUU and reg-event. We need to do the 
same thing for Path, Service-Info, and Outbound, but I think they may be 
less problematic than the other two.

The document is available here:

http://www.ietf.org/id/draft-roach-martini-gin-00.txt

If I have time, I plan to flesh this out a bit more before the virtual 
interim meeting on Tuesday. But I wanted to make sure I got an early 
version out there for everyone to look at so I don't spring it on you 
the day before the call like last time.

/a

---

From: David Hancock <[email-masked]>
Date: Tue, 2 Feb 2010 21:39:05 -0700

Adam,

Interesting mechanism - I like the fact it uses REGISTER, and therefore can take advantage of already defined REGISTER extensions. I still prefer the "shaken" mechanism since it's more aligned with IMS, and, I reckon, closer to the majority of PBX implementations.

Question is - does this mechanism offer sufficient advantages to warrant its adoption over "shaken"?

A couple of comments on GRUU...
 - The PBX doesn't have sufficient info to coin public GRUUs for its endpoints until it registers with the SSP. So how to handle the case where the PBX endpoints register with the PBX before the PBX registers with the SSP?
 - I don't understand the restriction for temp-GRUUs, where the PBX must be able to accept requests destined for its own self-made GRUUs from sources other than the SSP. Wouldn't these GRUUs have the domain of the PBX, and therefore route via the SSP? The problem with temp-GRUUs is that the user part could be anything (and therefore not an E.641 number).

Thanks
David

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, February 02, 2010 5:09 PM
To: MARTINI
Subject: [martini] GIN Draft

I have put together a draft to address Globally Identifiable Numbers for PBX registration. (Sorry, "Identifiable" was the best near-synonym I could find for "Unique" starting with I -- and everyone knows real martinis are made with gin. ;-) )

The contents of this draft are based on several factors from the phone calls and mailing list; in particular:

 *   The (tentative) agreement to move forward with phone numbers as an initial, narrowed scope.
 *   A perceived consensus to use REGISTER for the phone number use case.
 *   A perceived consensus to have the specific phone numbers being registered to be "implicit" (i.e., provisioned in both the SSP and the PBX, and not exchanged on the wire).
 *   A perceived consensus not to carry the registered extensions in the REGISTER response
 *   A perceived consensus _not_ to use TEL URIs between the SSP and the PBX

I have also started an analysis (in the document) of how this kind of mechanism can play nicely with GRUU and reg-event. We need to do the same thing for Path, Service-Info, and Outbound, but I think they may be less problematic than the other two.

If I have time, I plan to flesh this out a bit more before the virtual interim meeting on Tuesday. But I wanted to make sure I got an early version out there for everyone to look at so I don't spring it on you the day before the call like last time.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Feb 2010 22:52:16 -0600

Adam, 

Thank you for producing this very helpful draft. We need to work through it as a group, including what you've identified as open issues and analysis that needs to be performed, but I'm feeling better about us converging in finite time (and I believe Bernard is, as well).

Spencer
  ----- Original Message ----- 
  From: Adam Roach 
  To: MARTINI 
  Sent: Tuesday, February 02, 2010 6:09 PM
  Subject: [martini] GIN Draft

    a.. The (tentative) agreement to move forward with phone numbers as an initial, narrowed scope.

    b.. A perceived consensus to use REGISTER for the phone number use case. 
    c.. A perceived consensus to have the specific phone numbers being registered to be "implicit" (i.e., provisioned in both the SSP and the PBX, and not exchanged on the wire).

    d.. A perceived consensus not to carry the registered extensions in the REGISTER response 
    e.. A perceived consensus _not_ to use TEL URIs between the SSP and the PBX 

  /a

------------------------------------------------------------------------------

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Feb 2010 11:12:55 +0100

Adam,

Thanks for this. It is a well-thought-through draft that reflects use case 3 in your earlier proposal, leaving open the possibility of the PBX using a domain name under certain conditions. It clear differs from some current practices, but it has some similarity to other current practices, and we can't please everyone.

Some initial questions:
1. I think more work is needed on how to populate other fields in non-REGISTER inbound and outbound requests, as discussed in the thread I started "Further details around use case 3".

2. I am pleased to see the proposals for GRUU in there. I think we also need to discuss the use of non-GRUU contact URIs (see also that other thread).

3. I have a concern about the public GRUU solution. Suppose a UA registered with the PBX uses one of these permanent GRUUs, and some other on-PBX UA ends up making an out-of-dialog request back to that GRUU. It seems the PBX would be required to route via the SSP, resulting in a hairpin.

4. Concerning the registration event package for individual extension registration state:
"If the SSP receives a SUBSCRIBE request for the registration event
   package with a Request-URI that indicates a contact registered via
   the "Bulk Number Contact" mechanism defined in this document, "
This assumes subscription would use the contact URI, rather than the AOR for subscription. This would imply a two-step approach, i.e., first subscribe to the single AOR that the PBX uses to register and get back a list of contacts, and then subscribe to the individual contact(s). Would it also be possible, knowing a given telephone number, to subscribe to that number and get the same result? I don't have a strong opinion either way - just curious.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 03 February 2010 00:09
> To: MARTINI
> I have put together a draft to address Globally Identifiable 
> Numbers for PBX registration. (Sorry, "Identifiable" was the 
> best near-synonym I could find for "Unique" starting with I 
> -- and everyone knows real martinis are made with gin. ;-) )
> 
> The contents of this draft are based on several factors from 
> the phone calls and mailing list; in particular:
> 
> 
> 
> *	A perceived consensus to have the specific phone 
> numbers being registered to be "implicit" (i.e., provisioned 
> in both the SSP and the PBX, and not exchanged on the wire).
> 	
> I have also started an analysis (in the document) of how this 
> kind of mechanism can play nicely with GRUU and reg-event. We 
> need to do the same thing for Path, Service-Info, and 
> Outbound, but I think they may be less problematic than the other two.
> 
> If I have time, I plan to flesh this out a bit more before 
> the virtual interim meeting on Tuesday. But I wanted to make 
> sure I got an early version out there for everyone to look at 
> so I don't spring it on you the day before the call like last time.
> 
> /a
> 
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Feb 2010 08:57:37 -0600

On 2/2/10 10:39 PM, David Hancock wrote:
>  - The PBX doesn't have sufficient info to coin public GRUUs for its 
> endpoints until it registers with the SSP. So how to handle the case 
> where the PBX endpoints register with the PBX before the PBX registers 
> with the SSP?
>

To be clear: the PBX doesn't have sufficient information to coin public 
GRUUs for its endpoints until it registers with the SSP /for the first 
time/. There's actually normative language around this in GRUU, but the 
non-normative summary it includes is: "The intent is that the registrar 
make every attempt to retain validity of the GRUU for as long as the AOR 
itself is known within the domain."

So, after the PBX makes first contact with the SSP, it can cache the 
resulting GRUU, and use it to mint public GRUUs for its own endpoints 
(even if, due to some set of circumstances, it doesn't happen to be 
registered at the moment).

Of course, those GRUUs won't actually work until it registers with the 
SSP, but that's the nature of being a MARTINI-attached PBX anyway.

Finally, since we're assuming some out-of-band provisioning mechanism: 
if implementations absolutely need the ability to create public GRUUs 
when a PBX is first switched on for the very first time, it would be 
perfectly fine to provision this public GRUU -- the one the PBX would be 
caching above -- into the PBX before it is put into service.

>  - I don't understand the restriction for temp-GRUUs, where the PBX 
> must be able to accept requests destined for its own self-made GRUUs 
> from sources other than the SSP. Wouldn't these GRUUs have the domain 
> of the PBX, and therefore route via the SSP?
>

No. They'll need to have something in the machineport portion of the URI 
that resolves to the PBX via RFC 3263 mechanisms.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Feb 2010 09:09:37 -0600

> 1. I think more work is needed on how to populate other fields in non-REGISTER inbound and outbound requests, as discussed in the thread I started "Further details around use case 3".

Thanks. I'll comment in that thread.

> 2. I am pleased to see the proposals for GRUU in there. I think we also need to discuss the use of non-GRUU contact URIs (see also that other thread).

Ditto.

> 3. I have a concern about the public GRUU solution. Suppose a UA registered with the PBX uses one of these permanent GRUUs, and some other on-PBX UA ends up making an out-of-dialog request back to…

Yes, a naïve implementation would do that, and the signaling (but not 
the media) would end up going through the SSP. Everything would work 
okay, although the SSP would have to suffer through one (!) additional 
SIP message and its responses.

But this hairpinning isn't necessary. I'm assuming that all of those 
terminals will send outgoing requests through the PBX. This would give 
the PBX the opportunity, if it wanted, to optimize this hairpin: it 
would trivially be able to recognize the R-URI as matching the public 
GRUU it received from the SSP (there will be only one, so it's not an 
expensive comparison), and process it locally without sending it to the SSP.

It's pretty much the same behavior as recognizing a normal, non-GRUU URI 
as one of its own extensions and handling it locally instead of routing 
to the SSP.

> This assumes subscription would use the contact URI, rather than the AOR for subscription.

Sorry -- that was sloppy writing on my part. The intention is that 
they're subscribing to the AOR. It makes no sense to subscribe to the 
contact value.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Feb 2010 13:20:29 -0500

> Sent: Wednesday, February 03, 2010 10:10 AM
> 
> > 3. I have a concern about the public GRUU solution. Suppose a UA
> registered with the PBX uses one of these permanent GRUUs, and some other
> on-PBX UA ends up making an out-of-dialog request back to that GRUU. It
> seems the PBX would be required to route via the SSP, resulting in a
> hairpin.
> >
> 

I think we should mandate that behavior, because hair-pinning it through the SSP would be bad.  One of the definitions of a "PBX" is that it handles local calls locally, and the SSP is not going to expect or want the extra signaling. (and arguably the Enterprise shouldn't want the SSP involved in them either)

> as one of its own extensions and handling it locally instead of routing

You mean if a phone off the pbx sends a request to [email-masked] and the PBX says "hey, I have that number", then it's ok for it to route the request locally and not send it to the SSP?  I didn't see that in the draft.  

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 04 Feb 2010 13:42:41 -0600

On 2/4/10 12:20 PM, Hadriel Kaplan wrote:
> I think we should mandate that behavior...

I think we should ensure that the MARTINI mechanism doesn't preclude 
that behavior. And none of the proposals so far have precluded that 
behavior.

Mandating that behavior is more architectural. It's the kind of thing 
you might see come out of a body that defines concrete architectures -- 
like 3GPP, ETSI, PacketCable, SIPForum, etc.

> ...because hair-pinning it through the SSP would be bad.  One of the definitions of a "PBX" is that it handles local calls locally, and the SSP is not going to expect or want the extra signaling. (and arguably the Enterprise shouldn't want the SSP involved in them either)
>    

I agree. It's a good implementation choice to make.

> You mean if a phone off the pbx sends a request to [email-masked] and the PBX says "hey, I have that number", then it's ok for it to route the request locally and not send it to the SSP?  I didn't…

As with the other (related) issue, I don't think that's in scope for 
either the mechanism or for MARTINI.

/a

---

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

On Feb 3, 2010, at 4:12 AM, Elwell, John wrote:

> registered with the PBX uses one of these permanent GRUUs, and some  
> other on-PBX UA ends up making an out-of-dialog request back to that  
> GRUU. It seems the PBX would be required to route via the SSP,  
> resulting in a hairpin.
>

The PBX needs a table for mapping SSP-minted GRUUs to local contacts  
so that it can handle local routing without hairpinning.

--
Dean

---

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

Yes, I think as long as these things are possible and reasonable, they can be left out of scope of MARTINI and perhaps specified in SIPconnect 1.1.

John 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 04 February 2010 19:43
> To: Hadriel Kaplan
> Cc: Elwell, John; MARTINI
> Subject: Re: [martini] GIN Draft
> 
> >> expensive comparison), and process it locally without 
> sending it to the
> >> SSP.
> >>      
> > ...because hair-pinning it through the SSP would be bad.  
> One of the definitions of a "PBX" is that it handles local 
> calls locally, and the SSP is not going to expect or want the 
> extra signaling. (and arguably the Enterprise shouldn't want 
> the SSP involved in them either)
> >    
> 
> > You mean if a phone off the pbx sends a request to 
> [email-masked] and the PBX says "hey, I have that number", 
> then it's ok for it to route the request locally and not send 
> it to the SSP?  I didn't see that in the draft.
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 5 Feb 2010 05:46:03 -0600

<speaking-as-co-chair>

Adam, I appreciate the nudge in the direction of "does not preclude", and 
agree with your reasoning ("more architectural than we usually get in the 
IETF").

Just to be clear - are you suggesting that we can say "does not preclude" in 
a MARTINI specification? I would like to see that level of discussion 
captured, so we don't spend the next few years answering the question "did 
you guys think about hairpinning?" :-)

</speaking-as-chair>

Thanks,

Spencer

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Adam Roach" <[email-masked]>; "Hadriel Kaplan" 
<[email-masked]>
Cc: "MARTINI" <[email-masked]>
Sent: Friday, February 05, 2010 1:16 AM
Subject: Re: [martini] GIN Draft

Yes, I think as long as these things are possible and reasonable, they can 
be left out of scope of MARTINI and perhaps specified in SIPconnect 1.1.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Feb 2010 10:41:26 -0500

Adam,

This is good!!! A few comments:

* Use of () to mark insertion of number:

Why not just place the phone number in a uri-parameter?

* Need for Proxy-Require

You say we need because we are altering the semantics of REGISTER. But 
which semantics of register *that pertain to proxies* are we altering?

* Temp GRUUs

One possibility would be for the pbx to use the public GRUU seed of 
some single number (the attendant number?) of the pbx to mint its own 
temporary GRUUs. Their anonymity would be limited since they can all be 
traced to the same pbx, but that may be acceptable in some cases.

* Aggregate reg state

You say the () syntax and bnc can't appear. But reg event notifications 
should contain information on GRUUs too. (RFC 5628) And those gruus 
would have that syntax in them.

* Individual reg state

I think you neglected to mention something - perhaps because you assumed 
it was obvious:

If a subscription is received addressed to the a phone number the pbx 
services, then presumably it will first be mapped to the corresponding 
contact for the pbx, and *then* proxied on that basis.

	Thanks,
	Paul

---

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

On 2/5/10 5:46 AM, Spencer Dawkins wrote:
> <speaking-as-co-chair>
>
> Adam, I appreciate the nudge in the direction of "does not preclude", 
> and agree with your reasoning ("more architectural than we usually get 
> in the IETF").
>
> Just to be clear - are you suggesting that we can say "does not 
> preclude" in a MARTINI specification? I would like to see that level 
> of discussion captured, so we don't spend the next few years answering 
> the question "did you guys think about hairpinning?" :-)

If we want to capture this, I would argue it goes in the requirements 
document.

/a

---

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

Hi, Adam,

>> Just to be clear - are you suggesting that we can say "does not preclude" 
>> in a MARTINI specification? I would like to see that level of discussion 
>> captured, so we don't spend the next few years answering the question 
>> "did you guys think about hairpinning?" :-)
>

Thank you for clarifying... speaking as a participant, that would work for 
me.

Spencer

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Feb 2010 17:37:35 +0100

In principle, yes, but I am not sure how. The original concern was with GRUUs having xxxx.sp.com, where xxxx is recognised as being internal to the PBX. First, perhaps we need a requirement that the mechanism must allow the PBX to provide its UAs with public or temporary GRUUs.

Second, and this is the harder part, we seem to be asking for something to be said about not precluding direct on-PBX routing of requests to [email-masked], where xxx is known to be on-PBX. The difficulty I have with this is that it seems to assume a solution involving sp.com as the host part of a URI for an on-PBX entity. Any ideas what we should say?

John

> Sent: 05 February 2010 15:56
> To: Spencer Dawkins
> Cc: Elwell, John; Hadriel Kaplan; MARTINI

---

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

> Why not just place the phone number in a uri-parameter?

That would work also. Right now, based on Hadriel's input, I'm thinking 
the fastest way forward is simply to limit the Contact URIs to have no 
userpart at all, and use the 'bnc' parameter to indicate that the user 
part should be filled in with the phone number.

> which semantics of register *that pertain to proxies* are we altering?

Policy decisions that have historically applied to a single AOR will now 
be applied to REGISTER transactions that pertain to multiple AORs. 
That's a change.

Really: why else are you going to have proxies between the PBX and the 
SSP? It pretty much comes down to NAT traversal and application of policy.

> temporary GRUUs. Their anonymity would be limited since they can all 
> be traced to the same pbx, but that may be acceptable in some cases.

I thought through this, and decided that doing the temp-GRUUs at the SSP 
introduced far more complication than was gained. Since public GRUUs get 
you the ability to do all the call-control state, I'm not sure it's as 
important to make the temp-GRUUs as universally available.

I'm not really attached to this viewpoint, though. If someone wants to 
write up text about how to do temp-GRUUs through the SSP (including an 
analysis of why it works), then I'm happy to put it in.

> * Aggregate reg state
>
> You say the () syntax and bnc can't appear. But reg event 
> notifications should contain information on GRUUs too. (RFC 5628) And 
> those gruus would have that syntax in them.

Oh, good point. Interesting. The SSP won't actually know the mapping 
from public GRUU to AOR, since the substitution is done at the PBX. I 
think we probably won't be able to usefully put GRUU information into 
the aggregate registration state. I'll have to dig through some 
documents to determine whether this would be a valid thing to do.

> * Individual reg state
>
> I think you neglected to mention something - perhaps because you 
> assumed it was obvious:
>

Right. Just like an INVITE. Or an UNKNOWN_METHOD.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Feb 2010 11:21:29 -0600

> In principle, yes, but I am not sure how. The original concern was with GRUUs having xxxx.sp.com, where xxxx is recognised as being internal to the PBX. First, perhaps we need a requirement that th…

Ah, yes. That would be a good thing to add.

> Second, and this is the harder part, we seem to be asking for something to be said about not precluding direct on-PBX routing of requests to [email-masked], where xxx is known to be on-PBX. The dif…

I don't think we need to get that far into mechanism. What I think we 
want to say is that the mechanism must not preclude the ability of the 
PBX to route on-PBX calls directly, without hair-pinning the signaling 
through the SSP.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Feb 2010 12:48:01 -0500

> part should be filled in with the phone number.

I find that approach problematic. A pbx that only has one address may 
still have need to connect to multiple things, and to multiplex that one 
address other uses as well.

I guess you can argue that as long as this is just E.164 numbers, they 
will be unique across multiple providers, and other uses of the user 
part can avoid anything that looks like an E.164 number.

A URI parameter seems very straightforward, and one could be registered 
for the purpose. One of the arguments against URI parameters is that 
they don't survive address translation. But in this case the translation 
that would lose it is precisely the box that would consume this parameter.

OTOH, I suppose there will be a bunch of folk who have code that works 
for the user part, and that won't work for a URI parameter.

> SSP? It pretty much comes down to NAT traversal and application of policy.

AFAIK all of these things are making leaps of faith that aren't 
supported by the standards. As far as the standards say, there is no 
relationship between registration and being able to originate requests, 
or between registration and the possible addresses of requests that are 
allowed to come your way. Registration is simply a way to tell somebody 
"please establish a mapping from specified AOR to this URI".

The fact that others put other connotations on the register is *their* 
business, not ours.

If we want to support those other connotations then we ought to codify 
them first.

I guess the option tag can be defined, and the choice to use it in 
Proxy-Require can be a policy decision, based on whether you have 
devices that make such leaps of faith as require it.

> analysis of why it works), then I'm happy to put it in.

I think you missed my point. What I was suggesting does not require the 
SSP to do anything more. Its simply local behavior that the pbx could 
use to mint its own temp gruus using one of its public gruus from the SSP.

> documents to determine whether this would be a valid thing to do.

What the aggregate registration state can provide is the template public 
gruu returned in response to the register. It can't provide public gruus 
for all the associated AORs.

	Thanks,
	Paul

---

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

Sounds good.

John 

> Sent: 05 February 2010 17:21
> To: Elwell, John
> Cc: Spencer Dawkins; Hadriel Kaplan; MARTINI
> > In principle, yes, but I am not sure how. The original 
> concern was with GRUUs having xxxx.sp.com, where xxxx is 
> recognised as being internal to the PBX. First, perhaps we 
> need a requirement that the mechanism must allow the PBX to 
> provide its UAs with public or temporary GRUUs.
> >    
> 
> > Second, and this is the harder part, we seem to be asking 
> for something to be said about not precluding direct on-PBX 
> routing of requests to [email-masked], where xxx is known to be 
> on-PBX. The difficulty I have with this is that it seems to 
> assume a solution involving sp.com as the host part of a URI 
> for an on-PBX entity. Any ideas what we should say?
> >    
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Feb 2010 13:32:02 -0600

On 2/5/10 11:48 AM, Paul Kyzivat wrote:
>> That would work also. Right now, based on Hadriel's input, I'm 
>> thinking the fastest way forward is simply to limit the Contact URIs 
>> to have no userpart at all, and use the 'bnc' parameter to indicate 
>> that the user part should be filled in with the phone number.
>
> still have need to connect to multiple things, and to multiplex that 
> one address other uses as well.
>
> A URI parameter seems very straightforward, and one could be 
> registered for the purpose. One of the arguments against URI 
> parameters is that they don't survive address translation. But in this 
> case the translation that would lose it is precisely the box that 
> would consume this parameter.
>

That was the major consideration I had in mind when I suggested putting 
it in the user portion.

>
>
>>> * Need for Proxy-Require
>>>
>>> You say we need because we are altering the semantics of REGISTER. 
>>> But which semantics of register *that pertain to proxies* are we 
>>> altering?
>>
>> Policy decisions that have historically applied to a single AOR will 
>> now be applied to REGISTER transactions that pertain to multiple 
>> AORs. That's a change.
>>
>> Really: why else are you going to have proxies between the PBX and 
>> the SSP? It pretty much comes down to NAT traversal and application 
>> of policy.
>
> supported by the standards.

I think RFCs 3327 and 3608 actually provide such support, after a 
fashion. They're designed explicitly to put proxies in the path at 
registration time. What are these proxies ostensibly used for?

>>> some single number (the attendant number?) of the pbx to mint its 
>>> own temporary GRUUs. Their anonymity would be limited since they can 
>>> all be traced to the same pbx, but that may be acceptable in some 
>>> cases.
>>
>> I thought through this, and decided that doing the temp-GRUUs at the 
>> SSP introduced far more complication than was gained. Since public 
>> GRUUs get you the ability to do all the call-control state, I'm not 
>> sure it's as important to make the temp-GRUUs as universally available.
>>
>> I'm not really attached to this viewpoint, though. If someone wants 
>> to write up text about how to do temp-GRUUs through the SSP 
>> (including an analysis of why it works), then I'm happy to put it in.
>
> I think you missed my point. What I was suggesting does not require 
> the SSP to do anything more. Its simply local behavior that the pbx 
> could use to mint its own temp gruus using one of its public gruus 
> from the SSP.

Ah, I see. You're saying that the PBX does something to get a *PUBLIC* 
GRUU from the SSP, and then hands it out (with tokens appended) as a 
*PRIVATE* GRUU for its internal extensions. I missed that you were doing 
this public-to-private crossover.

Yes, that works, subject to the restrictions you placed on it. It does 
end up having the kind of bizarre property that they look like public 
URIs for one AOR, but are *actually* temp URIs for another.

I would suggest, if we want to go down this path, we define it in 
addition to what I currently have the draft, instead of replacing it. 
That is: if the PBX can make its own temp-gruus (as described in the 
current GIN draft), it does; otherwise, it makes use of the mechanism 
you describe.

>>> notifications should contain information on GRUUs too. (RFC 5628) 
>>> And those gruus would have that syntax in them.
>>
> What the aggregate registration state can provide is the template 
> public gruu returned in response to the register. It can't provide 
> public gruus for all the associated AORs.

I'm not sure I understand your proposal, then. Can you sketch out what 
such an XML document would look like?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Feb 2010 20:57:43 -0500

> registration time. What are these proxies ostensibly used for?

Putting a proxy in the path doesn't say anything about why it is there.
(Maybe just for data gathering/monitoring, ...)

There is still nothing that justifies such a proxy making assumptions 
such as: "only the registered contact will validly appear in outgoing 
requests on this path".

Of course there are deployments that make such an assumption. But that 
doesn't make them right.

You are suggesting that now a UA must include a Proxy-Require to ensure 
it is permitted to do something that it was never forbidden to do.

ISTM that in real life deployments where this might be an issue, it is 
the obligation of the proxy making the leap of faith to support the new 
behavior if it desires to permit anything on the side it is 
protecting/restricting to use the feature.

IOW, if my P-CSCF has been making these kinds of restrictions, it needs 
to get smarter in tandem with the S-CSCF behind it supporting this 
feature. It isn't really the problem of the UA on the other side.

> current GIN draft), it does; otherwise, it makes use of the mechanism 

Sure, I'm fine with both. Since what I suggest is a latent capability 
that can be implemented locally by the pbx, there is no need to even 
mention it. I just thought it might be a good note for those who might 
not think of it.

While that mechanism isn't *very* anonymizing for really small pbx's, 
the more I think about it the more I like it. It has exactly the 
property that many companies desire - not giving out direct numbers to 
their employees - while still providing controlled direct callback. 
Having the "attendant number" in those temp gruus will often be a good 
thing: if somebody picks it apart and calls the base number directly 
they will get the company attendant.

For your case, of the pbx minting its own private gruus - if it has a 
routable address that permits it to do so, it wouldn't need to use the 
martini mechanism. It could just give the SSP its publicly routable 
address and be done with it.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Feb 2010 21:07:40 -0600

On 2/8/10 19:57, Feb 8, Paul Kyzivat wrote:
>>>> Policy decisions that have historically applied to a single AOR 
>>>> will now be applied to REGISTER transactions that pertain to 
>>>> multiple AORs. That's a change.
>>>>

Or something less broken (although admittedly more baroque) like: "I 
know AOR sip:[email-masked] needs to go through proxy Y, so I'll 
add it to the Path list."

>> Ah, I see. You're saying that the PBX does something to get a 
>> *PUBLIC* GRUU from the SSP, and then hands it out (with tokens 
>> appended) as a *PRIVATE* GRUU for its internal extensions. I missed 
>> that you were doing this public-to-private crossover.
>>
>>
>> Yes, that works, subject to the restrictions you placed on it. It 
>> does end up having the kind of bizarre property that they look like 
>> public URIs for one AOR, but are *actually* temp URIs for another.
>>

We can do it that way, or we can make it slightly more anonymous by (a) 
having the PBX leave out the user portion for these private GRUUs, and 
(b) have the SSP route on "gr" instead of user if the user portion is 
missing.

> they will get the company attendant.

Actually, that's kind of an interesting property. Definitely something 
we should talk over on the call tomorrow (assuming my voice holds out -- 
I appear to be rapidly developing a cold).

> address and be done with it.

There's a qualitative difference between the level of permanence 
required for the SSP-PBX routing to work versus temp-gruus. If the PBX 
is going to be installed on an arbitrary IP address that can't be 
reasonably provisioned into the SSP, and may potentially be reassigned 
on an infrequent basis, then we need some means for the PBX to update 
the SSP with its address. That's what MARTINI is doing.

On the other hand, temp-gruus don't need the same level of permanence. 
Reassigning the IP address of a PBX in production would be highly 
disruptive: ongoing calls will fail, and there will likely be a short 
period of time before it has re-registered to the SSP, during which 
incoming calls will fail. In other words, while MARTINI makes allowances 
for this kind of thing to happen, it isn't *practical* for the PBX's 
address to change unless something quite exceptional has happened.

Temp-gruus are formed around the concept of periodic invalidation 
anyway. So the prospect that one of these highly disruptive events will 
invalidate the currently issued temp-gruus is well within the realm of 
what is expected for temp-gruus.

For what it's worth, I've had the same IP address at home for several 
months (it does change whenever the PPPoE link drops, but that is an 
infrequent event). My co-workers with cable modems report several years 
with the same IP address.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Feb 2010 23:27:12 +0100

Hi, 

>Or something less broken (although admittedly more baroque) like: "I know AOR sip:[email-masked] needs to go through proxy Y, so I'll add it to the Path list."

Such text exists in RFC 5626:

Section 5.1 says:

	"When an edge proxy receives a registration request with a "reg-id"
   	header field parameter in the Contact header field, it needs to
   	determine if it (the edge proxy) will have to be visited for any
   	subsequent requests sent to the User Agent identified in the Contact
   	header field, or not."

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Feb 2010 12:20:40 -0600

>     	subsequent requests sent to the User Agent identified in the Contact

So that strengthens the argument for using a Proxy-Require.

/a