Subject: [martini] Explicit DID indication in REGISTER

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

On today's call (and in his earlier email 
http://www.ietf.org/mail-archive/web/martini/current/msg00624.html), 
Dean raised an issue regarding the ability to indicate the DID numbers 
that the REGISTER corresponds to. There have been other concerns about 
this behavior (e.g. Tyler Parkin's message on Feb 
5:http://www.ietf.org/mail-archive/web/martini/current/msg00582.html).

Dean has started a thread on the semantics of this kind of registration, 
and a healthy dialog on the need for this property has begun. Some of 
the issues that people find objectionable may relate to the means that 
people might express this kind of thing syntactically.

ISTM that this kind of information, if we include it, goes along with 
the Contact URI. In particular, you can define a syntax like:

    Contact:<sip:@198.51.100.3:5060;bnc;range=+12143290500;5,+12143290440;30>

Which would mean "the range of 5 numbers starting with +12143290500, and 
the range of 30 numbers starting with +12143290440".

I'm personally of two minds about this. I think for the scenarios 
Richard Shockey has been describing -- "buy a PBX at CostCo, bring it to 
the office, and plug it in" -- this is perfectly tractable. Those are 
very small PBXes, and they won't have a ludicrous number of extensions. 
The list of ranges in the "range" parameter stays reasonable.

On the other hand, we have requirements the the MARTINI mechanism scale 
up to very, very large PBXes. In these circumstances, the list of ranges 
may become cumbersome.

I agree with Dean that we've experienced pain with implicit operations 
in SIP in the past, and have a mild bias towards making as much explicit 
as is possible. If we could settle on a reasonable means to do so, I 
think we'll all be happier in the long run if we figure out a way to 
make this explicit.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 9 Feb 2010 14:42:06 -0500

I just don't think that is in scope for now.

 It's a issue for a more specific set of requirements that I think we could
deal with now.  This is touching on the larger provisioning issue between
PBX systems and SSP that could take much more time than the limited scope of
MARTINI was designed to address.

 In addition A. the IETF isn't very good at provisioning issues (I could say
some things about CUA Config) . B. there are lots of proprietary solutions
out there that vendors use. Though the goal is laudable I just haven't seen
the SSP-PBX vendors agree that the pain point are sufficient to try and
standardize the solution for a comprehensive plug and play solution.

5 Yards at a time . 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Tuesday, February 09, 2010 1:41 PM
To: [email-masked]
Subject: [martini] Explicit DID indication in REGISTER

On today's call (and in his earlier email
http://www.ietf.org/mail-archive/web/martini/current/msg00624.html), Dean
raised an issue regarding the ability to indicate the DID numbers that the
REGISTER corresponds to. There have been other concerns about this behavior
(e.g. Tyler Parkin's message on Feb
5:http://www.ietf.org/mail-archive/web/martini/current/msg00582.html).

Dean has started a thread on the semantics of this kind of registration, and
a healthy dialog on the need for this property has begun. Some of the issues
that people find objectionable may relate to the means that people might
express this kind of thing syntactically.

ISTM that this kind of information, if we include it, goes along with the
Contact URI. In particular, you can define a syntax like:

   Contact:
<mailto:sip:@198.51.100.3:5060;bnc;range=+12143290500;5,+12143290440;30>
<sip:@198.51.100.3:5060;bnc;range=+12143290500;5,+12143290440;30>

Which would mean "the range of 5 numbers starting with +12143290500, and the
range of 30 numbers starting with +12143290440".

I'm personally of two minds about this. I think for the scenarios Richard
Shockey has been describing -- "buy a PBX at CostCo, bring it to the office,
and plug it in" -- this is perfectly tractable. Those are very small PBXes,
and they won't have a ludicrous number of extensions. The list of ranges in
the "range" parameter stays reasonable.

On the other hand, we have requirements the the MARTINI mechanism scale up
to very, very large PBXes. In these circumstances, the list of ranges may
become cumbersome. 

I agree with Dean that we've experienced pain with implicit operations in
SIP in the past, and have a mild bias towards making as much explicit as is
possible. If we could settle on a reasonable means to do so, I think we'll
all be happier in the long run if we figure out a way to make this explicit.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 09 Feb 2010 15:42:19 -0600

On 2/9/10 13:42, Feb 9, Richard Shockey wrote:
>
> In addition A. the IETF isn't very good at provisioning issues (I 
> could say some things about CUA Config) . B. there are lots of 
> proprietary solutions out there that vendors use. Though the goal is 
> laudable I just haven't seen the SSP-PBX vendors agree that the pain 
> point are sufficient to try and standardize the solution for a 
> comprehensive plug and play solution.
>

We're certainly in agreement that this mechanism isn't the way to 
provisioning.

But this issue is about much more than provisioning. I agree that some 
unrelated provisioning action is required to let each side know what 
extensions are associated with a customer.

On one end, this is about intermediary behavior. On the other, it is 
about terminal mobility between PBXes.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 Feb 2010 09:52:52 +0100

Adam,

I don't believe this is about terminal mobility between PBXs, as I have detailed in another thread. Although inter-PBX mobility is an issue for which we don't necessarily have all the answers at present, I don' think dynamic changing of the set of AORs registered through MARTINI is a necessary and sufficient solution. If we were to take on board inter-PBX mobility, we would also have to take on board inter-PBX internal enterprise traffic, which would be an explosion of the scope of MARTINI.

John

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 09 February 2010 21:42
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [martini] Explicit DID indication in REGISTER

On 2/9/10 13:42, Feb 9, Richard Shockey wrote:
In addition A. the IETF isn't very good at provisioning issues (I could say some things about CUA Config) . B. there are lots of proprietary solutions out there that vendors use. Though the goal is laudable I just haven't seen the SSP-PBX vendors agree that the pain point are sufficient to try and standardize the solution for a comprehensive plug and play solution.

We're certainly in agreement that this mechanism isn't the way to provisioning.

But this issue is about much more than provisioning. I agree that some unrelated provisioning action is required to let each side know what extensions are associated with a customer.

On one end, this is about intermediary behavior. On the other, it is about terminal mobility between PBXes.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Feb 2010 16:02:53 -0500

I've been ignoring this thread because it was going too fast for me to 
keep up. I think it has finally died down and I just read all the posts.

I think terminal mobility is an interesting problem/feature. But I agree 
with John that there is more to it than the registration problem. I've 
been through this with some proprietary implementations, and there are 
lots of approaches, governed by many things including a lot of 
non-technical ones.

Some cases that seem to beg for different sorts of solutions:

- temporary moves vs. permanent moves.
- "services" (like VM) shared between multiple pbxes
   vs. dedicated to specific pbx.
- pbxes in the same geography, where the numbers are "local"
   to both, vs. pbxes further removed from one another

So I'm inclined to punt this issue right now.

	Thanks,
	Paul

Elwell, John wrote:
> Adam,
>  
> I don't believe this is about terminal mobility between PBXs, as I have 
> detailed in another thread. Although inter-PBX mobility is an issue for 
> which we don't necessarily have all the answers at present, I don' think 
> dynamic changing of the set of AORs registered through MARTINI is a 
> necessary and sufficient solution. If we were to take on board inter-PBX 
> mobility, we would also have to take on board inter-PBX internal 
> enterprise traffic, which would be an explosion of the scope of MARTINI.
>  
> John
>  
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Adam Roach
>     *Sent:* 09 February 2010 21:42
>     *To:* Richard Shockey
>     *Cc:* [email-masked]
>     *Subject:* Re: [martini] Explicit DID indication in REGISTER
> 
>>     In addition A. the IETF isn’t very good at provisioning issues (I
>>     proprietary solutions out there that vendors use. Though the goal
>>     is laudable I just haven’t seen the SSP-PBX vendors agree that the
>>     pain point are sufficient to try and standardize the solution for
>>     a comprehensive plug and play solution.
>>
> 
>     But this issue is about much more than provisioning. I agree that
>     some unrelated provisioning action is required to let each side know
>     what extensions are associated with a customer.
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Feb 2010 13:42:15 -0600

Bernard and I talked this past weekend, and we both think that the question 
on mobility is the major open issue that we need to close before asking to 
adopt the next version of GIN as a working group draft.

Speaking as an individual, I'm inclined to punt on this topic as well, 
because I agree with Paul that this isn't a small anount of work, and 
MARTINI would be useful without it.

In conversations I've been involved with, over the past couple of years (I'm 
new here), I don't even think we have agreement on which end of the protocol 
"knows" the information it will be passing to the other end using MARTINI 
signaling.

I've been in conversations with service providers who say "we have to know 
about the phone numbers, because we have to be able to route them anyway, so 
we can configure a blank-slate SIP-PBX that someone bought at Walmart".

I've been in conversations with SIP-PBX providers who say "we have to 
configure all the AoRs because we have to define what services are 
available, etc. so we can configure what we want the SPs to route to us".

It does not seem that we're close to consensus on this topic. It might be 
possible to say "here's what I think you have for me"/"here's what I 
actually have for you", and define possible ways to recover if those two 
lists don't agree, but I'm not sure what more we could do.

Other points of view, before Bernard and I declare consensus? Please speak 
quickly...

Thanks,

Spencer

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Elwell, John" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 12, 2010 3:02 PM
Subject: Re: [martini] Explicit DID indication in REGISTER

Thanks,
Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 15 Feb 2010 21:30:08 +0100

I agree the mobility question is outside the scope of MARTINI.

John 

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 15 February 2010 19:42
> To: Paul Kyzivat; Elwell, John
> Cc: [email-masked]
> >>     is laudable I just haven't seen the SSP-PBX vendors 
> agree that the

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 15 Feb 2010 15:37:59 -0500

+1 .. out of scope

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Monday, February 15, 2010 3:30 PM
To: Spencer Dawkins; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [martini] Explicit DID indication in REGISTER

John

---

From: "Brian Lindsay" <[email-masked]>
Date: Mon, 15 Feb 2010 18:09:36 -0500

Hi,

   Agree with mobility out of scope, and ranges not being included in
register transaction.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Shockey
Sent: Monday, February 15, 2010 3:38 PM
To: 'Elwell, John'; 'Spencer Dawkins'; 'Paul Kyzivat'
Cc: [email-masked]
Subject: Re: [martini] Explicit DID indication in REGISTER

+1 .. out of scope

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: Monday, February 15, 2010 3:30 PM
To: Spencer Dawkins; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [martini] Explicit DID indication in REGISTER

John 

> Bernard and I talked this past weekend, and we both think that the 
> question on mobility is the major open issue that we need to close 
> before asking to adopt the next version of GIN as a working group 
> draft.
> 

> In conversations I've been involved with, over the past couple of 
> years (I'm new here), I don't even think we have agreement on which 
> end of the protocol "knows" the information it will be passing to the 
> other end using MARTINI signaling.
> 
> I've been in conversations with service providers who say "we have to 
> know about the phone numbers, because we have to be able to route them

> anyway, so we can configure a blank-slate SIP-PBX that someone bought 
> at Walmart".
> 
> actually have for you", and define possible ways to recover if those 
> two lists don't agree, but I'm not sure what more we could do.
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 15 Feb 2010 15:43:22 -0800

+1. 

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Monday, February 15, 2010 12:38 PM
To: 'Elwell, John'; 'Spencer Dawkins'; 'Paul Kyzivat'
Cc: [email-masked]
Subject: Re: [martini] Explicit DID indication in REGISTER

+1 .. out of scope

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

John

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Feb 2010 18:00:20 -0600

> before asking to adopt the next version of GIN as a working group  

I disagree. I think explicit indication of the numbers being  
registered is the open-question for MARTINI.

Explicit registration is required but not sufficient for the mobility  
scenarios. Doing MARTINI registration without explicit indication will  
preclude using this mechanism. However, doing the followup work is  
probably outside of MARTINI's immediate scope.

Further, we know from our history that "implicit" is AWLAYS a mistake.  
We never realize the implications at the time -- it always comes back  
to bite us later. Perhaps we should learn from this and stop doing  
implicit stuff.

So, I think we should continue with an explicit registration mechanism  
that is adequate to meet our current needs ASAP, without sawing our  
legs off for the future.

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Feb 2010 18:36:57 -0600

Hi, Dean,

>> before asking to adopt the next version of GIN as a working group  draft.
>
> I disagree. I think explicit indication of the numbers being  registered 
> is the open-question for MARTINI.
>

My post morphed pretty quickly into a discussion of explicit indication 
while considering mobility, so one side of my brain apparently agreed with 
you about the close relationship, and I don't disagree with your assertion 
that explicit indication may be the longest pole in the tent.

Thanks,

Spencer

---

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

Hi,

I think that mobility and explicit response indication are two different things - or we simply think about different things when we talk about mobility :)

In my opinion, MOBILITY is about when a PBX user goes from one PBX contact to another, and how the SSP knows behind which contact the user is located. The solution for that would most likely have impact on the communication in the PBX-to-SSP direction (no matter whether based on registration or some other mechanism).

Explicit indication in the response simply who is registered, in the SSP-to-PBX direction, and that might be a requirement to solve even if mobility (as defined above) is left out.

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: 16. helmikuuta 2010 2:37
> To: Dean Willis
> Cc: [email-masked]
> My post morphed pretty quickly into a discussion of explicit 
> indication while considering mobility, so one side of my 
> brain apparently agreed with you about the close 
> relationship, and I don't disagree with your assertion that 
> explicit indication may be the longest pole in the tent.
> 
> Thanks,
> 
> Spencer 
>

---

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

Hi, Christer,

I believe that your opinion matches Dean's opinion, if I understand both...

Thanks,

Spencer

----- Original Message ----- 
From: "Christer Holmberg" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Dean Willis" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 16, 2010 12:45 AM
Subject: RE: [martini] Explicit DID indication in REGISTER

Hi,

I think that mobility and explicit response indication are two different 
things - or we simply think about different things when we talk about 
mobility :)

In my opinion, MOBILITY is about when a PBX user goes from one PBX contact 
to another, and how the SSP knows behind which contact the user is located. 
The solution for that would most likely have impact on the communication in 
the PBX-to-SSP direction (no matter whether based on registration or some 
other mechanism).

Explicit indication in the response simply who is registered, in the 
SSP-to-PBX direction, and that might be a requirement to solve even if 
mobility (as defined above) is left out.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 16 Feb 2010 08:17:24 +0100

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 16 February 2010 00:00
> To: Spencer Dawkins
> Cc: Paul Kyzivat; Elwell, John; [email-masked]
> scenarios.
[JRE] In my opinion it is not proven that explicit registration is required in order to achieve mobility. During the earlier discussion I thought there were one or two proposals for mobility that did not depend on explicit registration.

John

> Doing MARTINI registration without explicit 
> indication will

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Feb 2010 03:48:57 -0600

Hi, John,

Just so Bernard and I can keep up with the cats being herded, you're 
referring to proposals for serial forking that were made onlist, right?

Thanks,

Spencer

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>

> Explicit registration is required but not sufficient for the
[JRE] In my opinion it is not proven that explicit registration is required 
in order to achieve mobility. During the earlier discussion I thought there 
were one or two proposals for mobility that did not depend on explicit 
registration.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 16 Feb 2010 10:54:26 +0100

Spencer,

That's one case, another case is where the PBX user always uses a registrar at the same PBX, even when roaming to other PBXs.

John 

> Sent: 16 February 2010 09:49
> To: Elwell, John; Dean Willis
> Cc: Paul Kyzivat; [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Feb 2010 08:27:27 -0600

> I believe that your opinion matches Dean's opinion, if I understand  

Not quite. Christer seems to think that a PBX has only one Contact,  
independent of however many AORs it might have.  This requires the PBX  
to be a UA or SBC/B2BUA, and precludes upstream registration-based  
routing (And forking) to the AORs of the PBX.

I, in general, presume that there is at least one Contact per AOR  
currently "live". This allows the PBX to be a proxy if it wants to,  
and allows for upstream routing logic to use the set of Contacts.

For example, consider an AO that is bound to two PBX instances and  
also to my PC. If all three instances REGISTER to my "service  
provider" proxy, then said proxy can do things like fork incoming  
INVITES to all three instances, without requiring any special tricky  
logic to know reachability-state for the PBXes. It treats the PBX  
Contacts no differently than the PC's Contact -- they're all just  
ordinary contacts once they're in the location service.

AS I understand it, Christer's model requires the proxy using the  
location service to know that PBXes are somehow special, then go do a  
Reg-Event on them, in order to find out what their current "real  
Contact" set is and perform routing logic. This seems highly baroque,  
probably even "broken".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Feb 2010 08:30:29 -0600

On Feb 16, 2010, at 3:54 AM, Elwell, John wrote:

> Spencer,
>
> That's one case, another case is where the PBX user always uses a  
> registrar at the same PBX, even when roaming to other PBXs.

But what about when an upstream proxy is trying to fork to multiple  
PBXes as well as non-PBX SIP UAs? How does it "know" which AORs are  
"active" on a given PBX right now? If you don't have a fully populated  
location service with all the AORs and all the Contacts corresponding  
to those AORs, you need a whole new type of routing logic.

--
Dean

---

From: "Brian Lindsay" <[email-masked]>
Date: Tue, 16 Feb 2010 10:00:06 -0500

Hi,

   I believe the model we have here is that the enterprise has a
registrar/proxy responsible for the AoRs. The end clients need to
register with the enterprise registrar/proxy. There technically wouldn't
be a "non-PBX SIP UA" since it would also register with the same
enterprise entity.

   The intent is that the Service Provider is simply routing requests to
a set of E.164 numbers to the enterprise entity (aka SIP PBX). The
registration transaction from the enterprise to the SSP provides the
reachability information (this transaction uses an AoR that represents
the enterprise entity) in lieu of any static addressing information.

  But otherwise this should at a high level work the same way (and
support the same types of capabilities) as if the Service Provider had a
static IP address for the enterprise, and there was no registration
transaction between the enterprise and the Service Provider.

  Regards
     Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Tuesday, February 16, 2010 9:30 AM
To: Elwell, John
Cc: MARTINI
Subject: Re: [martini] Explicit DID indication in REGISTER

But what about when an upstream proxy is trying to fork to multiple
PBXes as well as non-PBX SIP UAs? How does it "know" which AORs are
"active" on a given PBX right now? If you don't have a fully populated
location service with all the AORs and all the Contacts corresponding to
those AORs, you need a whole new type of routing logic.

---

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

Exactly

John 

> From: Brian Lindsay [mailto:[email-masked]] 
> Sent: 16 February 2010 15:00
> To: Dean Willis; Elwell, John
> Cc: MARTINI

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Feb 2010 10:04:07 -0600

Hi, John,

Thank you for resynchronizing me.

Thanks,

Spencer

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Dean Willis" 
<[email-masked]>
Cc: "Paul Kyzivat" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 16, 2010 3:54 AM
Subject: RE: [martini] Explicit DID indication in REGISTER

Spencer,

That's one case, another case is where the PBX user always uses a registrar 
at the same PBX, even when roaming to other PBXs.

John

> =

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Feb 2010 11:03:01 -0600

Hi, Dean,

> independent of however many AORs it might have.  This requires the PBX  to 
> be a UA or SBC/B2BUA, and precludes upstream registration-based  routing 
> (And forking) to the AORs of the PBX.

My apologies for not including a scoping identifier on "your opinion matches 
Dean's opinion" - what I meant to say was that both of you were calling out 
explicit lists and mobility as seperate, but related, topics that the 
working group needs to close on (quickly).

Thank you for your helpful post in followup, though. It captures several 
points that I've heard referred to in passing, but have not seen previous 
discussed on our mailing list.

Spencer

---

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

And mine, for that matter. Explicit DID lists in the REGISTER have a 
number of applications. Terminal mobility is just one of them. And it's 
not (IMHO) even the most important one.

/a

On 2/16/10 00:52, Feb 16, Spencer Dawkins wrote:
> ----- Original Message ----- From: "Christer Holmberg" 
> <[email-masked]>
> I think that mobility and explicit response indication are two 
> different things - or we simply think about different things when we 
> talk about mobility :)
>
> In my opinion, MOBILITY is about when a PBX user goes from one PBX 
> contact to another, and how the SSP knows behind which contact the 
> user is located. The solution for that would most likely have impact 
> on the communication in the PBX-to-SSP direction (no matter whether 
> based on registration or some other mechanism).
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Feb 2010 22:18:10 +0100

Hi,

>to be a UA or SBC/B2BUA,

If you put the contact (which points to the PBX) in a Route header, and the called PBX number in the R-URI, I believe the PBX can act as a proxy.

For the rest of your e-mail, we would probably need to draw some pictures, to make sure we have a common understanding of "proxies", "real contacts" etc :)

Regards,

Christer

>and precludes upstream registration-based routing (And forking) to the AORs of the PBX.
>

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Feb 2010 17:07:34 -0500

Christer,

> If you put the contact (which points to the PBX) in a Route header, and the called PBX number in the R-URI, I believe the PBX can act as a proxy.

I'm getting deja vu (and not for the first time).
You are looping back through the cases that have been discussed ad nauseum.

That approach works well with "stirred", but problems were found with 
stirred, so we dropped it. There have been issues raised using it with 
"shaken" as well.

AFAIK we were *closest* to a consensus when we were talking about the 
registration actually (at least virtually) creates a registered contact 
for each AOR.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Feb 2010 10:48:59 +0100

Hi Paul,

I was simply replying to Dean, showing a mechanism where the PBX would not need to be a B2BUA.

My intention was not to re-open old discussions, so I appologize for that.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 17. helmikuuta 2010 0:08
To: Christer Holmberg
Cc: Dean Willis; Spencer Dawkins; [email-masked]
Subject: Re: [martini] Explicit DID indication in REGISTER

Christer,

Christer Holmberg wrote:
>> independent of however many AORs it might have.  This requires the 
>> PBX to be a UA or SBC/B2BUA,
> 

That approach works well with "stirred", but problems were found with stirred, so we dropped it. There have been issues raised using it with "shaken" as well.

AFAIK we were *closest* to a consensus when we were talking about the registration actually (at least virtually) creates a registered contact for each AOR.

	Thanks,
	Paul

> For the rest of your e-mail, we would probably need to draw some 
> pictures, to make sure we have a common understanding of "proxies", 
> "real contacts" etc :)
> 
> Regards,
> 
> Christer
> 
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Feb 2010 07:53:18 -0600

> transaction between the enterprise and the Service Provider.

Then what you're wanting just isn't REGISTER. It doesn't specify an AOR
to be registered. It produces no AOR->Contact bindings. It doesn't
result in contact-routing at the proxy/registrar. It doesn't return a
set of Contacts in a 200 OK response. It doesn't result in a AAA check
for the AORs being requested.

As Adams might say, what you seem to want is almost but not quite
entirely different from REGISTER.

And you've pushed back on every approach we've suggested to make a
solution that actually works like REGISTER.

So why do you want to call your solution REGISTER? Are you just trying
to make SIP even more confusing than it already is?

--
Dean