Subject: [martini] DID Number Mobility and MARTINI

From: Dean Willis <[email-masked]>
Date: Tue, 9 Feb 2010 09:50:51 -0600

One of my understanding of goals for corporate VoIP systems was the  
ability to move a user from one PBX to another PBX without having to  
pay a service provider MACD (move, add, change, delete) fee.

In fact, it was my demonstrating this very capability to MCI's chief  
engineering officer back in  1999 that got the first SIP project there  
funded.

Let's talk through a use case:

Assume Alice is working today in our building at #901 I-street, which  
has a PBX. Her DID number is routed to that PBX. Over lunch, her  
office gets moved down the street to the lab at #400 I-Street.

Three cases might apply:

1) Alice moves her phone and plugs it in and it "just works", because  
the phone dynamically registers with the new PBX, which then  
dynamically registers with the SSP proxy for that DID number,  
effectively moving the binding from #901's PBX to #400's PBX.

2) Alice moves her phone to #400, waits until after lunch, then calls  
the phone support people, who manually reprovision her onto the #400  
PBX. This PBX then re-registers with SSP, and her number starts  
working again.

3) Alice moves her pone to #400, and waits until after lunch to talk  
to the phone support people, who reprovision her on the PBXes and then  
call the SSP support people to move her DID number from #901's "trunk"  
to 400's "trunk". Sometime, tomorrow, her phone line starts working  
AND we get a $50 bill for the "change fee" from the SSP.

Our original design goal favored #1, we might have accepted #2, and #3  
was what we were most aggressively trying to avoid.

Yet my understanding of the consensus of MARTINI is that #3 is the  
desired outcome. This is the difference, if I understand it, between  
draft-gin's "()" proposal for implicit registration and the "XXXX"  
proposal for explicit registration I made on-list.

Why are we pushing ourselves ten years backwards in operational  
advances?

And what happens when Alice has a WiFi phone and moves back and forth  
from #901 to #400 several times a day? Does she just go without a  
phone, or do we pay a $50 change fee each time?

--
Dean

---

From: "Tyler Parkin" <[email-masked]>
Date: Tue, 9 Feb 2010 13:24:49 -0500

The other issue with this is that when Alice unplugs her phone at #901 the 
PBX at that loc needs to be able to de-register her number.  I'm pretty sure 
de-registering a single number that was previously registered with a 
bulk-register request was shot down.

----- Original Message ----- 
From: "Dean Willis" <[email-masked]>
To: "MARTINI" <[email-masked]>
Sent: Tuesday, February 09, 2010 10:50 AM
Subject: [martini] DID Number Mobility and MARTINI

> ability to move a user from one PBX to another PBX without having to  pay 
> a service provider MACD (move, add, change, delete) fee.
>
> Assume Alice is working today in our building at #901 I-street, which  has 
> a PBX. Her DID number is routed to that PBX. Over lunch, her  office gets 
> moved down the street to the lab at #400 I-Street.
>
> Three cases might apply:
>
> 1) Alice moves her phone and plugs it in and it "just works", because  the 
> phone dynamically registers with the new PBX, which then  dynamically 
> registers with the SSP proxy for that DID number,  effectively moving the 
> binding from #901's PBX to #400's PBX.
>
> 2) Alice moves her phone to #400, waits until after lunch, then calls  the 
> phone support people, who manually reprovision her onto the #400  PBX. 
> This PBX then re-registers with SSP, and her number starts  working again.
>
> 3) Alice moves her pone to #400, and waits until after lunch to talk  to 
> the phone support people, who reprovision her on the PBXes and then  call 
> the SSP support people to move her DID number from #901's "trunk"  to 
> 400's "trunk". Sometime, tomorrow, her phone line starts working  AND we 
> get a $50 bill for the "change fee" from the SSP.
>
>
> Why are we pushing ourselves ten years backwards in operational  advances?
>
> from #901 to #400 several times a day? Does she just go without a  phone, 
> or do we pay a $50 change fee each time?
>
>
>
> --
> Dean
>
>
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

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

On 2/9/10 12:24, Feb 9, Tyler Parkin wrote:
> The other issue with this is that when Alice unplugs her phone at #901 
> the PBX at that loc needs to be able to de-register her number.  I'm 
> pretty sure de-registering a single number that was previously 
> registered with a bulk-register request was shot down.

But that's not the same as omitting a number from the a subsequent 
registation, which will have the same net effect.

So, for example, if you have a PBX servicing +12145550100 through 
+12145550120, and Alice (DID +12145550115) moves her phone, then the 
next PBX registration could be for the two ranges +12145550100 through 
+12145550114, and +12145550116 through +12145550120.

This does get a bit into Richard's fragmentation issue, though. After a 
small number of phone number moves, you end up with a set of ranges that 
devolves almost into a complete enumeration of extensions.

/a

---

From: "Jack Burton" <[email-masked]>
Date: Tue, 09 Feb 2010 13:32:25 -0500

Tyler,
 
The PBX would indeed de-register the phone when it is unplugged.  That is not the issue here.  Registrations between phones and the PBX are out of scope.
 
To describe further:
 
When the phone is unplugged, after some period the PBX de-registers the phone and knows it is offline.  If a call comes in destined for the phone, the PBX would apply appropriate forwarding treatment for an unavailable extension.  The SSP considers the number implicitly registered, and would continue to deliver calls to the PBX for that number.  It is up to the PBX to treat those calls appropriately.
 
If another phone on the PBX wished to make a call using the outbound number of the failed extension, such as in a multiple line appearance situation, the SSP would process those calls as if nothing happened.  To the SSP, nothing did happen.
 
The only time the SSP would change its treatment of calls to the extension in question is if the PBX parent de-registered.  Then, the SSP would provide appropriate "endpoint not available" treatment to ALL associated DIDs.
 
-Jack

>>> "Tyler Parkin" <[email-masked]> 2/9/2010 11:24 >>>

-------------------------------------------------------- 
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. 
--------------------------------------------------------

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Feb 2010 13:11:16 -0600

On Feb 9, 2010, at 12:29 PM, Adam Roach wrote:

> This does get a bit into Richard's fragmentation issue, though.  
> After a small number of phone number moves, you end up with a set of  
> ranges that devolves almost into a complete enumeration of extensions.

Almost, but not quite. Ranging vs. enumeration is a just an  
abbreviation technique.  If there are even two consecutive numbers in  
the set ranging reduces the specification size relative to enumeration.

However, there is no assurance that there will be even two consecutive  
numbers. Therefore whatever technique we use MUST work with a fully- 
enumerated request (the most degenerate case of Shockey fragmentation)  
if it allows explicit registration.

This means that any solution that requires regurgitating a large  
Contact set in the response is probably a non-starter in UDP land. The  
reg-event model is certainly cleaner for finding out "what is  
currently registered?".

However, allowing a registration to succeed even when that  
registration produces no AOR-to-contact (but was expected to) also  
makes no sense to me. It violates the principle of minimal surprise.  
It also requires a lot of other provisioning triggerwork for  
associating Contacts with AORs that we've traditionally handled with  
REGISTER.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Feb 2010 13:14:56 -0600

On Feb 9, 2010, at 12:32 PM, Jack Burton wrote:

> Tyler,
>
> The PBX would indeed de-register the phone when it is unplugged.   
> That is not the issue here.  Registrations between phones and the  
> PBX are out of scope.
>
> To describe further:
>
> When the phone is unplugged, after some period the PBX de-registers  
> the phone and knows it is offline.  If a call comes in destined for  
> the phone, the PBX would apply appropriate forwarding treatment for  
> an unavailable extension.  The SSP considers the number implicitly  
> registered, and would continue to deliver calls to the PBX for that  
> number.  It is up to the PBX to treat those calls appropriately.
>
> If another phone on the PBX wished to make a call using the outbound  
> number of the failed extension, such as in a multiple line  
> appearance situation, the SSP would process those calls as if  
> nothing happened.  To the SSP, nothing did happen.
>
> The only time the SSP would change its treatment of calls to the  
> extension in question is if the PBX parent de-registered.  Then, the  
> SSP would provide appropriate "endpoint not available" treatment to  
> ALL associated DIDs.
>

But what if the phone and/or DID moves from one PBX to another within  
the customer organization?

A lot of our thinking here has relied on the unstated assumption that  
the customer only has a single PBX and that AORs (phone numbers)  do  
not dynamically migrate between PBXes. If that's a part of our model,  
we need to clearly state that as an underlying assumption. I find this  
to be an overly-simplistic and not particularly interesting case.

--
Dean

---

From: "Tyler Parkin" <[email-masked]>
Date: Tue, 9 Feb 2010 14:24:28 -0500

I was speaking of the registration between the PBX and the SSP, not the phone and the PBX.  

If the intention is to let a SSP's customer move phones between two PBX's without incurring a MACD fee, then there has to be a way for the old PBX to declare that it's no longer resposible for a number and the new PBX to declare that it is so that calls route to the "correct" PBX for (and avoid treatment on a PBX that was last used 6 weeks ago).

I didn't really dive too far into what would happen when the old PBX refreshes it's reg, or how it would split the range, etc.  I'm pretty the whole concept of roaming between PBX's is contrary to implicit reg.  

I wasn't necessarily advocating it, as a SSP it makes me sick. =)  More for technical reasons than MACD fees.

Tyler  

----- Original Message ----- 
  From: Jack Burton 
  To: MARTINI 
  Sent: Tuesday, February 09, 2010 1:32 PM
  Subject: Re: [martini] DID Number Mobility and MARTINI

  Tyler,

  To describe further:

  -Jack

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

---

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

You might think is overly simplistic but it is the vast majority of the
market. 

http://www.census.gov/epcd/www/smallbus.html

Look at the percentage of firms with under 99 employees

RS> that is not our problem

RS> IMHO it is the underlying assumption. Think about your dentist's office.
I've said this before the business case assumption here are typically the
sub 24 concurrent session market.
--
Dean
_______________________________________________
martini mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/martini

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Feb 2010 15:04:11 -0600

> I was speaking of the registration between the PBX and the SSP, not  

Me too.

>
> If the intention is to let a SSP's customer move phones between two  
> PBX's without incurring a MACD fee, then there has to be a way for  
> the old PBX to declare that it's no longer resposible for a number  
> and the new PBX to declare that it is so that calls route to the  
> "correct" PBX for (and avoid treatment on a PBX that was last used 6  
> weeks ago).
>

Right; that's the question I'm asking. Is this in-scope or out of scope?

> I didn't really dive too far into what would happen when the old PBX  
> refreshes it's reg, or how it would split the range, etc.

That's the subject of Adam's last two drafts.

> I'm pretty the whole concept of roaming between PBX's is contrary to  
> implicit reg.

Indeed it is, which is exactly my point. If we need to allow roaming  
between PBXes, then we require a solution for explicit registration.  
If however we rely entirely on back-end provisioning systems (and all  
their inherent latencies and costs) then an implicit registration  
system may suffice.

>
> I wasn't necessarily advocating it, as a SSP it makes me sick. =)   
> More for technical reasons than MACD fees.
>

Can you elaborate on those technical reasons?

Most of what we've heard so far from the old-school service providers  
is:  We map a DID to a fixed trunk, and a trunk to a fixed PBX, and  
all we want is for VoIP to work just like we do it now except  
dynamically discover the IP address and port number of the fixed PBX.  
We still want to have a fixed DID<->trunk relationship even though the  
trunks are entirely virtual and happen over the Internet (and we're  
having to make up a bunch of stuff to make it look like a trunk,  
because that's all we know how to model). Really, all we are doing is  
replacing an ISDN line with a dynamically changing IP peering.

That's not a technical reason for an architecture -- it's an excuse  
for not having one.

What technical reasons (and neither inertia nor apathy qualify) are  
driving that decision?

--
Dean

---

From: "Tyler Parkin" <[email-masked]>
Date: Tue, 9 Feb 2010 16:24:45 -0500

Numbers lie =)

If you look at the numbers, sure, <99 makes up a huge percentage of firms 
and locations.  However, looking at the bigger picture, most companies over 
subscribe users to concurrent sessions, so a customer with 24 concurrent 
calls could actually have 50-75 users.  A single PRI with 100 DID's is not 
uncommon.

Second, looking at the numbers in the link below:

1-4 employees
    SOHO, probably not going to have a PBX
5-9 employees
    approaching the point where they might need a PBX, but the lower half 
will probably stick w/ their key system
10-99
    Probably have a PBX and might even have or be interested in an IP PBX
    The numbers for this group indicate it's basically one location per firm
100-499
    Probably have a PBX, probably looking for advanced features and probably 
interested in an IP PBX
    The numbers for this group indicate ~4 locations per firm

Of total locations for firms with 10-499 employees, the multilocation firms 
(100-499 emps) make up ~20% of all locs

20% is a big number of an SMB target market, and reflects why L3VPN is our 
second best selling product.  The % grows as you weed out the bottom half of 
firms near 10 users.

----- Original Message ----- 
From: "Richard Shockey" <[email-masked]>
To: "'Dean Willis'" <[email-masked]>; "'Jack Burton'" 
<[email-masked]>
Cc: "'MARTINI'" <[email-masked]>
Sent: Tuesday, February 09, 2010 2:48 PM
Subject: Re: [martini] DID Number Mobility and MARTINI

---

From: "Jack Burton" <[email-masked]>
Date: Tue, 09 Feb 2010 16:43:54 -0500

OK, now we're talking about the problem of multiple PBXs within a single customer.
 
In my opinion...
 
1)  Few organizations have multiple PBXs that share DID ranges.
 
2)  Multiple PBXs have their own number ranges typically.  They would be treated as different locations by the SSP.  It is unusual for a firm to move extensions around multiple PBXs without changing DIDs when they do it.  (DIDs usually stay with the PBX)
 
3)  If a customer must move their DID to a different PBX, the SSP can make this change within the limits of the GIN proposal.  Why does this rare operation have to be touch-free by the SSP?  I think that it is very reasonable for the SSP to know when a customer moves a DID to a new PBX location - - if for nothing else but E911 reasons. 
 
4)  Think of how this is done today, with PRI or Analog trunks to each PBX.  In every case, moving a DID from one PBX to another requires SP action.  
 
It seems to me that the efforts to avoid MAC charges for this very rare operation may be excessive.
 
-Jack

>>> "Tyler Parkin" <[email-masked]> 2/9/2010 14:24 >>>
Numbers lie =)

1-4 employees

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Feb 2010 18:18:34 -0600

On Feb 9, 2010, at 3:43 PM, Jack Burton wrote:
>
>
> 4)  Think of how this is done today, with PRI or Analog trunks to  
> each PBX.  In every case, moving a DID from one PBX to another  
> requires SP action.
>

Yeah, and that's why we came up with SIP.

A few years back, one in ten people died young of Polio. That's why  
Salk invented a vaccine.

SIP might not be quite that important, but "we've ALWAYS made it hard  
for the customer" is a really bad reason to perpetuate a design's  
physical limitations even after those physical limitations have ceased  
to be relevant,.

--
dean

---

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

Dean,

It is certainly the case that Alice should be able to move location and have things "just work" without having to contact the service desk. Let's assume Alice's device normally registers with the PBX at site A, and that the PBX registers with the SSP to receive calls to Alice's E.164 number. Alice moves to site B, but Alice's device (the same one or a different one) still registers with the PBX at site A. If there are issues with being able to register with a PBX on site A from a LAN on site B, that is outside the scope of MARTINI work.

Of course, calls from the SSP to Alice, on arrival at PBX-A, if the preferred device at that time is on site B, need to be routed to that device on site B. How this is achieved might also be an issue, put presumably would be based on a path established at registration time. I think this is also outside the scope of MARTINI.

What Dean proposes is that we support the nomadic user by moving the registrar for Alice's AOR from PBX-A to PBX-B. This would be a much bigger problem that just telling the SSP that Alice's E.164 number is now served by PBX-B instead of PBX-A. You also need to arrange for calls from UAs within the PBXs concerned to go to PBX-B instead of PBX-A for handling. Also all Alice's preferences known to the registrar at PBX-A need to be moved to PBX-B (e.g., conditions for calls to be redirected to voicemail). Also, what if Alice still has other devices that stay on site A? How does it help by moving the registrar to PBX-B.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 09 February 2010 15:51
> To: MARTINI

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Feb 2010 12:26:38 -0600

On Feb 10, 2010, at 2:32 AM, Elwell, John wrote:

> Dean,
>
> It is certainly the case that Alice should be able to move location  
> and have things "just work" without having to contact the service  
> desk. Let's assume Alice's device normally registers with the PBX at  
> site A, and that the PBX registers with the SSP to receive calls to  
> Alice's E.164 number. Alice moves to site B, but Alice's device (the  
> same one or a different one) still registers with the PBX at site A.  
> If there are issues with being able to register with a PBX on site A  
> from a LAN on site B, that is outside the scope of MARTINI work.

Since Site A and Site B each have their own firewall/NATs between them  
and the Internet, it's not going to work; we'd end up with inside-out  
Outbound.

However, they do share an authentication database.

>
> Of course, calls from the SSP to Alice, on arrival at PBX-A, if the  
> preferred device at that time is on site B, need to be routed to  
> that device on site B. How this is achieved might also be an issue,  
> put presumably would be based on a path established at registration  
> time. I think this is also outside the scope of MARTINI.
>

That'sa lot of triggerwork, when she could have just registered to the  
B PBX.

> What Dean proposes is that we support the nomadic user by moving the  
> registrar for Alice's AOR from PBX-A to PBX-B. This would be a much  
> bigger problem that just telling the SSP that Alice's E.164 number  
> is now served by PBX-B instead of PBX-A. You also need to arrange  
> for calls from UAs within the PBXs concerned to go to PBX-B instead  
> of PBX-A for handling. Also all Alice's preferences known to the  
> registrar at PBX-A need to be moved to PBX-B (e.g., conditions for  
> calls to be redirected to voicemail). Also, what if Alice still has  
> other devices that stay on site A? How does it help by moving the  
> registrar to PBX-B.

A and B need a dynamic routing table between themselves. That's  
definitely outside the scope of MARTINI, although I've been pondering  
an event-packaged based framework for dynamic routing in SIP.  
Alternatively, B could "MARTINI" to A, or vice-versa, as needed to  
handle inter-PBX routing.

It might be entirely reasonable for Alice's phone number to be  
registered simultaneously at A and B. We have this thing called  
"forking" that I've always wanted to get rid of, but can't seem to  
shake.

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 10 Feb 2010 12:40:27 -0600

Speaking as a participant - and if it wasn't clear that I was speaking as a 
participant I talked about this on the call this week, I apologize...

> Almost, but not quite. Ranging vs. enumeration is a just an  abbreviation 
> technique.  If there are even two consecutive numbers in  the set ranging 
> reduces the specification size relative to enumeration.
>
> enumerated request (the most degenerate case of Shockey fragmentation)  if 
> it allows explicit registration.
>
> This means that any solution that requires regurgitating a large  Contact 
> set in the response is probably a non-starter in UDP land. The  reg-event 
> model is certainly cleaner for finding out "what is  currently 
> registered?".

This is exactly why I am where I am, on this question.

It does make sense to me to send a list of numbers between the SP and the 
SIP-PBX so that mismatches can be identified at REGISTER time. In 
discussions at the SIP Forum, I encouraged that.

*BUT* my understanding from discussions at the IETF is that we would need to

- accommodate fragmented number ranges, with full enumeration as the 
degenerate case,

- while not exceeding the SIP UDP request/response size limit, which isn't 
large.

So, I think we would be limited in practice to something like 20-30 number 
ranges (using an encoding like Adam has proposed), which might translate 
into 20-30 numbers, in the degenerate case, for MARTINI. I don't see that as 
desireable, because it significantly low-balls the size of SIP-PBX we could 
expect to support (based on the requirements draft that John has put 
together).

I'm happy to participate in discussion about this topic, but at the onset of 
that discussion I'd like to make sure whether we really have the constraints 
I've identified in this note. Without a common understanding of the 
constraints, we're just wasting valuable time.

Thanks,

Spencer

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Feb 2010 13:09:41 -0600

On Feb 10, 2010, at 12:40 PM, Spencer Dawkins wrote:

> Speaking as a participant - and if it wasn't clear that I was  
> speaking as a participant I talked about this on the call this week,  
> I apologize...
>
>>> After a small number of phone number moves, you end up with a set  
>>> of  ranges that devolves almost into a complete enumeration of  
>>> extensions.
>>
>> abbreviation technique.  If there are even two consecutive numbers  
>> in  the set ranging reduces the specification size relative to  
>> enumeration.
>>
>> However, there is no assurance that there will be even two  
>> consecutive numbers. Therefore whatever technique we use MUST work  
>> with a fully- enumerated request (the most degenerate case of  
>> Shockey fragmentation)  if it allows explicit registration.
>>
>> Contact set in the response is probably a non-starter in UDP land.  
>> The  reg-event model is certainly cleaner for finding out "what is   
>> currently registered?".
>
> It does make sense to me to send a list of numbers between the SP  
> and the SIP-PBX so that mismatches can be identified at REGISTER  
> time. In discussions at the SIP Forum, I encouraged that.
>
> - while not exceeding the SIP UDP request/response size limit, which  
> isn't large.
>
> So, I think we would be limited in practice to something like 20-30  
> number ranges (using an encoding like Adam has proposed), which  
> might translate into 20-30 numbers, in the degenerate case, for  
> MARTINI. I don't see that as desireable, because it significantly  
> low-balls the size of SIP-PBX we could expect to support (based on  
> the requirements draft that John has put together).
>
> I'm happy to participate in discussion about this topic, but at the  
> onset of that discussion I'd like to make sure whether we really  
> have the constraints I've identified in this note. Without a common  
> understanding of the constraints, we're just wasting valuable time.
>

Too-large requests can be rejected by intermediaries. We have no way  
of rejecting responses, however. So the important thing is to keep the  
RESPONSES from becoming too big.

So, while we could conceivably send a fairly large request (and in  
fact the requester has the option of using TCP), what we have to do   
prevent is an overly-large response.

I do think it is important for SSP to be able to say "I'm sorry, you  
are not authorized to use one (or more) of the telephone-number- 
expressions you have just requested" in a response to a REGISTER. I  
think it might be reasonable to limit the volume of that response, by  
perhaps including only the  first "failed" telephone-number-expression  
in the response.

--
Dean

---

From: "Jack Burton" <[email-masked]>
Date: Wed, 10 Feb 2010 14:31:32 -0500

An excellent point.
 
The SSP could implicitly register the entire list of PBX-A and PBX-B phone numbers when EITHER of them registers.  Problem solved.  Well, the problem of PBX-B knowing what to do when a PBX-A phone hooks up remains out of scope.
 
Invites from either PBX involving any of the DIDs would be honored.
Outbound calls to any DID (assuming both PBXs are online and registered) would be forked to both.
 
This seems kind of silly, but if it will get us moving along, I'm OK with it.
-Jack

>>> Dean Willis [email-masked]> 2/10/2010 11:26 >> ( mailto:[email-masked]> )

--

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 10 Feb 2010 13:52:03 -0600

So, the obvious question (to me as co-chair) is, "does this just work like two UAs that register diffferent contacts for the same AOR, or would we need to say anything about it in MARTINI documents?"

Any thoughts?

Spencer, speaking as co-chair
  ----- Original Message ----- 
  From: Jack Burton 
  To: MARTINI 
  Sent: Wednesday, February 10, 2010 1:31 PM
  Subject: Re: [martini] DID Number Mobility and MARTINI

  An excellent point.

  >>> Dean Willis [email-masked]> 2/10/2010 11:26 >>

  --

---

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

I didn't say that keeping the registrar at PBX-A was without issues, but also being able to move the registrar from A to B has issues, and it is not clear that providing a means in MARTINI for dynamically varying the set of numbers registered from each PBX is a necessary part of the overall solution. Building extra complexity into the MARTINI solution just because it might form part of the solution to another problem seems wrong.

I think we just have to make do with the suggested forking solution. Or rely on inter-registrar communication between the two PBXs to ensure that if a call arrives at the wrong PBX, that PBX can retarget or redirect to the other PBX. Either way, MARTINI does not need to solve it.

John

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 10 February 2010 18:27
> To: Elwell, John
> Cc: MARTINI

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 10 Feb 2010 14:13:35 -0600

John,

So please tell me if I'm misunderstanding or not...

> I think we just have to make do with the suggested forking solution. Or 
> rely on inter-registrar communication between the two PBXs to ensure that 
> if a call arrives at the wrong PBX, that PBX can retarget or redirect to 
> the other PBX. Either way, MARTINI does not need to solve it.

Your answer is that forking "just works" for AORs that have two or more 
contacts, pointing to different PBXes, right? So no document impact?

Thanks,

Spencer

---

From: "Brian Lindsay" <[email-masked]>
Date: Wed, 10 Feb 2010 15:24:54 -0500

Hi,
 
   Hadriel's MARTINI-SHAKEN draft allowed for registration from multiple
SIP PBXs, but for serial forking purposes (presumeably for backup
cases).
 
   One comment on this topic: In the discussions within the SIP Forum
and in the work on the SIP Connect specification, the "registration"
mode of operation was one of two modes for supporting SIP PBXs, the
other being a "static" mode in which the SIP PBX did not register but
had a static IP address or the address is obtained from DNS (e.g. RFC
3263 approach). The only substantial difference was intended to be the
means by which the SSP obtained the reachability information to be able
to route the request to the SIP PBX (which birthed the effort to start
MARTINI for the non-"static" mode). We seem to be getting into areas,
such as mobility and exchange of numbering info, that are well beyond
the original intended scope, and are perhaps equally asked about the
non-registration based approach. If these are "common" topics to both
modes, perhaps they should be tabled as out of scope for this effort
(they may have common solutions).
 
  Thanks
      Brian

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: Wednesday, February 10, 2010 2:52 PM
To: MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

So, the obvious question (to me as co-chair) is, "does this just work
like two UAs that register diffferent contacts for the same AOR, or
would we need to say anything about it in MARTINI documents?"
 
Any thoughts?

	----- Original Message ----- 
	From: Jack Burton <mailto:[email-masked]>  
	To: MARTINI <mailto:[email-masked]>  
	Sent: Wednesday, February 10, 2010 1:31 PM
	Subject: Re: [martini] DID Number Mobility and MARTINI

	An excellent point.
	 
	The SSP could implicitly register the entire list of PBX-A and
PBX-B phone numbers when EITHER of them registers.  Problem solved.
Well, the problem of PBX-B knowing what to do when a PBX-A phone hooks
up remains out of scope.
	 
	Invites from either PBX involving any of the DIDs would be
honored.
	Outbound calls to any DID (assuming both PBXs are online and
registered) would be forked to both.
	 
	This seems kind of silly, but if it will get us moving along,
I'm OK with it.
	-Jack

	>>> Dean Willis [email-masked]> 2/10/2010 11:26 >>
<mailto:[email-masked]> 2/10/2010 11:26 >>> 

	"forking" that I've always wanted to get rid of, but can't seem
to  
	shake.
	
	--

	-------------------------------------------------------- 
	The information transmitted in this email and any of its
attachments is intended only for the person or entity to which it is
addressed and may contain Cablevision proprietary information, which is
privileged, confidential, or subject to copyright belonging to
Cablevision. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited and may be
unlawful. If you received this in error, please contact the sender
immediately and delete and destroy the communication and all of the
attachments you have received and all copies thereof. 
	-------------------------------------------------------- 

________________________________

---

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

I am saying we can make it work in two ways, without impacting MARTINI:

1. By both PBXs registering all the time with the SSP, as Dean and Jack have suggested.

2. By only one PBX registering at any one time, and relying on intra-registrar communication (between the registrar in PBX-A and the registrar in PBX-B) ensuring that each registrar is aware of all contacts for Alice, whichever registrar they are registered at. Then the PBX that has registered with the SSP will receive calls from the SSP and can retarget or redirect to the other PBX.

And of course, there is also:
3. There is only a single registrar (at PBX A), and if Alice goes to PBX B, her UA registers from there. This, as Dean points out, is subject to the firewall situation between the two PBXs.

None of these require MARTINI work.

John 

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 10 February 2010 20:14
> To: Elwell, John; Dean Willis
> Cc: MARTINI

---

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

Agreed.

John

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Lindsay
Sent: 10 February 2010 20:25
To: Spencer Dawkins; MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Hi,

   Hadriel's MARTINI-SHAKEN draft allowed for registration from multiple SIP PBXs, but for serial forking purposes (presumeably for backup cases).

   One comment on this topic: In the discussions within the SIP Forum and in the work on the SIP Connect specification, the "registration" mode of operation was one of two modes for supporting SIP PBXs, the other being a "static" mode in which the SIP PBX did not register but had a static IP address or the address is obtained from DNS (e.g. RFC 3263 approach). The only substantial difference was intended to be the means by which the SSP obtained the reachability information to be able to route the request to the SIP PBX (which birthed the effort to start MARTINI for the non-"static" mode). We seem to be getting into areas, such as mobility and exchange of numbering info, that are well beyond the original intended scope, and are perhaps equally asked about the non-registration based approach. If these are "common" topics to both modes, perhaps they should be tabled as out of scope for this effort (they may have common solutions).

  Thanks
      Brian

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Wednesday, February 10, 2010 2:52 PM
To: MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Any thoughts?

----- Original Message -----
From: Jack Burton<mailto:[email-masked]>
To: MARTINI<mailto:[email-masked]>
Sent: Wednesday, February 10, 2010 1:31 PM
Subject: Re: [martini] DID Number Mobility and MARTINI

An excellent point.

>>> Dean Willis [email-masked]> 2/10/2010 11:26 >><mailto:[email-masked]>%202/10/2010%2011:26%20>>>

--

---

From: "Jack Burton" <[email-masked]>
Date: Wed, 10 Feb 2010 15:47:46 -0500

I may have suggested (1), but I much prefer we rely upon (3) and keep away from forking things up.
-Jack

>>> "Elwell, John" <[email-masked]> 2/10/2010 13:27 >>>

John

---

From: Doug Sauder <[email-masked]>
Date: Thu, 11 Feb 2010 12:23:05 -0500

Dean,

There is another option that you didn't include:

4) Alice calls her administrator, who brings up a web page hosted by the 
SSP and changes the selection in a drop-down list from PBX-901 to PBX-400.

It really is that simple.  I think what Richard is trying to promote, 
and which I agree with, is that we're trying to solve the problem of 
SSPs who prefer a Walmart-like model: lots of customers and low prices.  
The SSPs who charge a fee for every provisioning change will not 
survive.  The SSPs that can provide self-service options for their 
customers will.

Having said that, I agree with others who have pointed out that the 
"mobility" issue is out of scope.

--
Doug

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Feb 2010 11:25:52 -0600

On 2/11/10 11:23 AM, Doug Sauder wrote:
> 4) Alice calls her administrator, who brings up a web page hosted by 
> the SSP and changes the selection in a drop-down list from PBX-901 to 
> PBX-400.

If we can do that, then the administrator can just as easily pull up a 
web page hosted by the SSP and enter their PBX's IP address.

Voilà! The whole MARTINI problem, solved by a web page!

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Feb 2010 12:28:17 -0500

> survive.  The SSPs that can provide self-service options for their 

Such providers exist???

They certainly haven't taken hold in the consumer space.

	Thanks,
	Paul

---

From: Doug Sauder <[email-masked]>
Date: Thu, 11 Feb 2010 12:51:42 -0500

Adam,

Dean wanted to argue that the PBX should register its DIDs because it is 
expensive to have the DID-to-PBX association changed by the SSP.  I 
meant to suggest that that is not a legitimate reason.

I'm sure you know that there is a difference between a registrar 
receiving a REGISTER request and a statically provisioned IP address.

--
Doug

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Feb 2010 12:27:03 -0600

Wait a second... the very existence of MARTINI as a working group is 
predicated on exactly one fact: we have accepted the assertion that it 
is impractical -- notably, too expensive -- for SSPs to provision PBX IP 
addresses into their system. Once we start asserting that these same 
SSPs allow customer self-provisioning, then the rationale for MARTINI 
evaporates.

In other words: I think we can safely assume that the SSPs that are 
clamoring for the MARTINI solution have a vanishingly small chance of 
deploying a self-provisioning system.

/a

On 2/11/10 11:51, Feb 11, Doug Sauder wrote:
> Adam,
>
> Dean wanted to argue that the PBX should register its DIDs because it 
> is expensive to have the DID-to-PBX association changed by the SSP.  I 
>>> the SSP and changes the selection in a drop-down list from PBX-901 
>>> to PBX-400.
>>
>> If we can do that, then the administrator can just as easily pull up 
>> a web page hosted by the SSP and enter their PBX's IP address.
>>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Feb 2010 13:38:36 -0500

Paul .. they are certainly starting to emerge in SMB oriented CLEC space and
certainly the Cable Co's are moving in that direction. Cox and Cbeyond for
years has had highly competitive products with some innovative self-serve
provisioning mechanisms. There are lots of examples of EC Cable Operators
drop shipping PBX systems directly to small business customers preconfigured
and given to the customer free of charge for a specified service contract.
Taking the mobile model to the SMB-PBX space.

This entire concept of "Plug n' Dial" has been the business case and
philosophy behind the SIP Forum SIP Connect initiative and the participants
( who are all here on this list ) who proposed the MARTINI WG in the first
place.

The largest constraints for the Plug and Dial SSP model are the lack of
standardization of the provisioning mechanism and the lack of real Local
Number Portability in the EC and ASIA-Pac. I cannot emphasize enough how
important this is to competitive markets for SIP services. Duh its about
phone numbers..business will not switch providers if they have to switch
their numbers.

The sooner we make these things work better..the sooner product fly's off
the shelf.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Thursday, February 11, 2010 12:28 PM
To: Doug Sauder
Cc: MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Such providers exist???

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Feb 2010 14:24:32 +0100

Hi,

I was thinking about the same as Dean, whether it could be seen as a normal forking case, where a single user (again, I think the PBX is seen as a single user from the SIP core perspectiv, but let's not go into that here and now) registers multiple contacts for the same AOR.

A major advantage would be that we would not trigger SIP registration updates towards the SSP every time a PBX user is "roaming".

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: 10. helmikuuta 2010 21:52
To: MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Any thoughts?

----- Original Message -----
From: Jack Burton<mailto:[email-masked]>
To: MARTINI<mailto:[email-masked]>
Sent: Wednesday, February 10, 2010 1:31 PM
Subject: Re: [martini] DID Number Mobility and MARTINI

An excellent point.

--

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Feb 2010 14:30:33 +0100

Hi,

Well, you could use a web based mechanism where the PBXs contact the SSP behind which contact a specific user is, and the SSP can use that to make forking decissions. The good thing with 3261 is that it doesn't say how forking decissions must be made :)

Another way is to simply paralell fork inbound request to every PBX contact, and all but one should return a "dude, the user is not here" response.

However, I don't think it solves the core MARTINI problem, because there may be many reasons why the PBXs want to use SIP registration to register the PBXs.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 11. helmikuuta 2010 19:26
To: Doug Sauder
Cc: MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

> the SSP and changes the selection in a drop-down list from PBX-901 to 

If we can do that, then the administrator can just as easily pull up a web page hosted by the SSP and enter their PBX's IP address.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Feb 2010 15:11:12 -0500

This seems like a straightforward approach. Some obviouls drawbacks to 
it are:
- sounds like many SSPs don't support forking like this.

- all calls will be delivered to all the related pbxes, increasing
   the amount of signaling that must be handled on both the SSP and
   pbx sides.

- unless their is coordination between the pbxes, it seems highly
   likely that in some cases one may answer with VM while another
   is alerting. (At least I would expect if my phone was off/ not
   connected to my PBX then the pbx ought to provide VM or an
   announcement.)

Bottom line - there are a lot of aspects to getting such a mobility 
feature to work right. The registration aspects are just one part of that.

	Thanks,
	Paul

Christer Holmberg wrote:
>  
> Hi,
>  
> I was thinking about the same as Dean, whether it could be seen as a 
> normal forking case, where a single user (again, I think the PBX is seen 
> as a single user from the SIP core perspectiv, but let's not go into 
> that here and now) registers multiple contacts for the same AOR.
>  
> A major advantage would be that we would not trigger SIP registration 
> updates towards the SSP every time a PBX user is "roaming".
>  
> Regards,
>  
> Christer
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Spencer Dawkins
> *Sent:* 10. helmikuuta 2010 21:52
> *To:* MARTINI
> *Subject:* Re: [martini] DID Number Mobility and MARTINI
> 
>     *From:* Jack Burton <mailto:[email-masked]>
>     *To:* MARTINI <mailto:[email-masked]>
>     *Sent:* Wednesday, February 10, 2010 1:31 PM
>     *Subject:* Re: [martini] DID Number Mobility and MARTINI
> 
>     An excellent point.
>      
>     The SSP could implicitly register the entire list of PBX-A and PBX-B
>     phone numbers when EITHER of them registers.  Problem solved.  Well,
>     the problem of PBX-B knowing what to do when a PBX-A phone hooks up
>     remains out of scope.
>      
>     The information transmitted in this email and any of its attachments
>     is intended only for the person or entity to which it is addressed
>     and may contain Cablevision proprietary information, which is
>     Cablevision. Any review, retransmission, dissemination or other use
>     of, or taking of any action in reliance upon, this information by
>     persons or entities other than the intended recipient is prohibited
>     and may be unlawful. If you received this in error, please contact
>     the sender immediately and delete and destroy the communication and
>     all of the attachments you have received and all copies thereof.
>     ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 14 Feb 2010 21:32:07 +0100

Hi,

>- sounds like many SSPs don't support forking like this.

True. But, the point was that the forking mechanism would not require any multiple PBX specific work, since it's part of basic SIP.

>   the amount of signaling that must be handled on both the SSP and

Not necessarily. The SSP could do serial forking, based on whatever priority logic (or, as I said in my reply to Adam, some non-registration PBX-SSP communication mechanism).

>   connected to my PBX then the pbx ought to provide VM or an

That could of course happen, yes.

>Bottom line - there are a lot of aspects to getting such a mobility feature to work right. The registration aspects are just one part of that.

Sure. The question is whether the non-registration aspects are within the scope of MARTINI.

Regards,

Christer

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 15 Feb 2010 14:44:23 -0800

Speaking as co-chair, the non-registration aspects of DID number mobility
are outside the scope of the current MARTINI WG charter. 

The question on the table (see
http://www.ietf.org/mail-archive/web/martini/current/msg00687.html ) is
whether the registration aspects represent a requirement or not.  Feel free
to respond and provide your opinion on that thread. 

-----Original Message-----
From: Christer Holmberg 
Sent: Sunday, February 14, 2010 12:11 PM
To: Paul Kyzivat
Cc: MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Hi,

>This seems like a straightforward approach. Some obvious drawbacks to
>it are:

True. But, the point was that the forking mechanism would not require any
multiple PBX specific work, since it's part of basic SIP.

>   the amount of signaling that must be handled on both the SSP and

Not necessarily. The SSP could do serial forking, based on whatever priority
logic (or, as I said in my reply to Adam, some non-registration PBX-SSP
communication mechanism).

>- unless there is coordination between the pbxes, it seems highly

>Bottom line - there are a lot of aspects to getting such a mobility feature
to work right. The registration aspects are just one part of that.

Sure. The question is whether the non-registration aspects are within the
scope of MARTINI.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Sunday, February 14, 2010 12:11 PM
To: Christer Holmberg
Cc: MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

This seems like a straightforward approach. Some obvious drawbacks to it
are:
- sounds like many SSPs don't support forking like this.

- unless there is coordination between the pbxes, it seems highly
   likely that in some cases one may answer with VM while another
   is alerting. (At least I would expect if my phone was off/ not
   connected to my PBX then the pbx ought to provide VM or an
   announcement.)

Bottom line - there are a lot of aspects to getting such a mobility feature
to work right. The registration aspects are just one part of that.

	Thanks,
	Paul

Christer Holmberg wrote:
> normal forking case, where a single user (again, I think the PBX is 
> seen as a single user from the SIP core perspectiv, but let's not go 
> into that here and now) registers multiple contacts for the same AOR.
>

---

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

> to respond and provide your opinion on that thread.

Explicit is its own reward.

Remember, the one thing that RFC 3261 REGISTER really does is bind an  
AOR to a Contact.  Both the AOR and the Contact involved are  
explicitly encoded in the request.

I'm OKAY with extending REGISTER to bind multiple AORs to multiple  
Contacts. This seems like a reasonable extension to simplify life  for  
a "multi user" SIP user agent. But I really think we should respect  
the history of REGISTERs explicit encoding of the AORs and Contacts  
involved.

 From a requirements perspective, I'd be happy with a requirement  
along the lines of  "must not preclude AOR mobility indicated by the  
registration." I agree that we can't justify a requirement to produce  
a mechanism at the time for the whole enchilada.

--
Dean

---

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

Hi, Dean,

> Remember, the one thing that RFC 3261 REGISTER really does is bind an  AOR 
> to a Contact.  Both the AOR and the Contact involved are  explicitly 
> encoded in the request.
>
> Contacts. This seems like a reasonable extension to simplify life  for  a 
> "multi user" SIP user agent. But I really think we should respect  the 
> history of REGISTERs explicit encoding of the AORs and Contacts  involved.
>
> From a requirements perspective, I'd be happy with a requirement  along 
> the lines of  "must not preclude AOR mobility indicated by the 
> registration." I agree that we can't justify a requirement to produce  a 
> mechanism at the time for the whole enchilada.

OK, I happen to like your proposed resolution here, but want to try to act 
like a responsible chair, and want to make sure that if we go this 
direction, we're not just declaring victory and sailing out of the harbor.

I was most concerned about the request/response size, based on MTU 
limitations. We've said that anyone who loses sleep over that is welcome to 
REGISTER TCP. Check.

I have been reminded by someone smarter than me that intermediate devices 
may puke on large requests/responses (where "large" is measured at the SIP 
level, not at the IP MTU level), and that they can reject large requests, 
but not large responses. So, I'm back to my previous concern, just higher in 
the stack, if including explicit lists of what's being registered can mean 
that the request (and, more so, the response) can be big enough to cause 
problems.

Several people have been saying "use regevents, because you want an ongoing 
understanding of what the other guy thinks anyway, not just a snapshot at 
REGISTER time", and I've been listening. So, I think my next question is, 
does using regevents make what's being registered explicit ENOUGH to satisfy 
the concern Dean is voicing here?

If the answer is "yes", I'm good with "must not preclude".

Thanks,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Feb 2010 20:07:05 -0500

Dean,

In principle I agree with you.
But this horse is already out of the barn with IMS implicit registration.

It was never explicitly brought to the ietf, though things linked to it 
like P-Asserted-ID and P-Associated-URI were. While we could say that is 
not our problem, I think we already implicitly approved it via benign 
neglect.

	Thanks,
	Paul

Dean Willis wrote:
> AOR to a Contact.  Both the AOR and the Contact involved are explicitly 
> encoded in the request.
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Feb 2010 19:27:23 -0600

On Feb 15, 2010, at 6:52 PM, Spencer Dawkins wrote:

> limitations. We've said that anyone who loses sleep over that is  
> welcome to REGISTER TCP. Check.
>
> I have been reminded by someone smarter than me that intermediate  
> devices may puke on large requests/responses (where "large" is  
> measured at the SIP level, not at the IP MTU level), and that they  
> can reject large requests, but not large responses. So, I'm back to  
> my previous concern, just higher in the stack, if including explicit  
> lists of what's being registered can mean that the request (and,  
> more so, the response) can be big enough to cause problems.
>

I believe I raised the request/response rejection dichotomy.

If your request fails because it is too large, you can break the  
request up into "pieces" and do each piece separately.  So for example  
if we find we can get 20 number ranges in a request, and you have 40  
to REGISTER, it MIGHT take two requests. But that's only if either 1)  
an intermediary kicks it back as "too large" or 2) you just KNOW it  
isn't going to work.

The problematic side is the response.

I argue that we don't really need to know about the ranges that  
succeeded. If we get back a 200 OK, that's enough to say that the  
ranges we sent worked.

The problem comes from RFC 3261, which I quote below:

> 10.2.3 Fetching Bindings
>  A success response to any REGISTER request contains the complete  
> list of existing bindings, regardless of whether the request  
> contained a Contact header field. If no Contact header field is  
> present in a REGISTER request, the list of bindings is left unchanged.

So, regardless of whether the REQUEST was explicit or implicit in  
declaring the scope of bindings, RFC 3261 requires that the register  
RESPONSE contain the full set. This is obviously problematic for very  
large registration sets, whether resulting from a single "mass  
registration" or many individual registration operations.

This might lead one to think of the AOR being registered as singular,  
with a singular Contact, and that the telephone-numbers involved are  
"aliases" for this AOR. One can certainly envision explicit or  
implicit alias registration, and even consider that explicit  
transmission could occur in either direction. IMS makes it explicit  
using the P-Associated-URI List which is passed in the registrar->UAC  
direction.

This of course raises the question we asked early on: How does a  
request coming in to the PBX, resulting from a contact-routing  
operation that maps the AOR to the Contact, indicate which alias the  
call is actually for? IMS doesn't really answer this for "aliases that  
are really different users", but does give is the RFC 3455 P-Called- 
Party-ID header that some people (Keith, I believe) keeps reminding us  
about. As we know, going down this path starts to get muddy very  
quickly.

The other alternative is for MARTINI to simply amend the RFC 3261  
behavior for REGISTER by mandating that responses to requests wherein  
the target is a "bnc" (or whatever other flag we use) do not contain  
the full set of registered contacts, but instead include some  
(presumably useful and size-limited) subset.

My proposal is that, for "bnc" contacts, a successful REGISTER  
response return not the "expansion" of the macro-registration, but the  
set of  unexpanded "To, Contact" vectors currently registered. Yes,  
this isn't a fully-explicit indication of registration state, but I  
think it's the best we can do in a REGISTER response over UDP.

This leaves the question of what to do in a response to a  failed  
REGISTER  request. If we incorporate PBX->SSP explicit indication in  
the request, I propose that the failed response (specifically a 403,  
in most cases) contain only the first range that failed.

Yes, if you have a really messed-up REGISTER request it could take a  
few tries before you get informed about all the failing range  
requests, but I don't see that as a huge problem. Ypu'll still know  
you have a failed registration, and that response will contain enough  
useful information for SOME sort of debugging. This is much better  
than the "implicit registration" case, where you might just THINK  
you'd had a successful registration, even though nothing is actually  
working.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Feb 2010 19:30:33 -0600

> But this horse is already out of the barn with IMS implicit  

Not really. IMS simply has a set of aliases for each registering AOR,  
and it explicitly reports those aliases back to the UAC in P- 
Associated-URI.

It doesn't really address the situation where each "alias" is actually  
supposed to ring a different handset. RFC 3455 comes close to  
providing a solution in P-Called-Party-ID, but that's really more for  
distinctive-ring than it is for sub-AOR call routing operations. We  
don't think of P-Called-Party-ID as a routing header.

---
Dean

---

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

Hi Dean,

>Not really. IMS simply has a set of aliases for each 
>registering AOR, and it explicitly reports those aliases back to the UAC in P- 
>Associated-URI.
> 
>It doesn't really address the situation where each "alias" is 
>actually supposed to ring a different handset. RFC 3455 comes close to  
>providing a solution in P-Called-Party-ID, but that's really 
>more for distinctive-ring than it is for sub-AOR call routing operations. We  

Have you looked into the 3GPP/TISPAN work on enterprises? The R-URI is forwarded unchanged, so you don't need to rely on P-CPI.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Feb 2010 08:20:15 +0100

One more thing on this. 

>This might lead one to think of the AOR being registered as 
>singular, with a singular Contact, and that the 
>telephone-numbers involved are "aliases" for this AOR. One 
>can certainly envision explicit or implicit alias 
>registration, and even consider that explicit transmission 
>could occur in either direction. IMS makes it explicit using 
>the P-Associated-URI List which is passed in the 
>registrar->UAC direction.
> 
>This of course raises the question we asked early on: How 
>does a request coming in to the PBX, resulting from a 
>contact-routing operation that maps the AOR to the Contact, 
>indicate which alias the call is actually for? IMS doesn't 
>really answer this for "aliases that are really different 
>users",

As said before, the whole idea is that it doesn't have to answer. The PBX is seen as a single user, and what happens within the PBX is outside the scope.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Feb 2010 08:31:11 +0100

Hi,

H.248 has (or, at least used to have) a mechanism where you could split a big message into multiple messages.

So, maybe would need something similar: a '188 (More stuff is coming dude)' provisional response for REGISTER, and you keep sending those until the full set has been delivered :)

Regards,

Christer

> Sent: 16. helmikuuta 2010 3:27
> To: Spencer Dawkins
> Cc: Bernard Aboba; 'MARTINI'
> > measured at the SIP level, not at the IP MTU level), and 
> that they can 
> > reject large requests, but not large responses. So, I'm back to my 
> > previous concern, just higher in the stack, if including explicit 
> > lists of what's being registered can mean that the request 
> (and, more 
> > so, the response) can be big enough to cause problems.
> >
> 
> 
> If your request fails because it is too large, you can break 
> the request up into "pieces" and do each piece separately.  
> So for example if we find we can get 20 number ranges in a 
> request, and you have 40 to REGISTER, it MIGHT take two 
> requests. But that's only if either 1) an intermediary kicks 
> it back as "too large" or 2) you just KNOW it isn't going to work.
> 
> I argue that we don't really need to know about the ranges 
> that succeeded. If we get back a 200 OK, that's enough to say 
> that the ranges we sent worked.
> 
> 
> >  A success response to any REGISTER request contains the 
> complete list 
> > of existing bindings, regardless of whether the request contained a 
> > Contact header field. If no Contact header field is present in a 
> > REGISTER request, the list of bindings is left unchanged.
> 
> So, regardless of whether the REQUEST was explicit or 
> implicit in declaring the scope of bindings, RFC 3261 
> requires that the register RESPONSE contain the full set. 
> This is obviously problematic for very large registration 
> sets, whether resulting from a single "mass registration" or 
> many individual registration operations.
> 
> users", but does give is the RFC 3455 P-Called- Party-ID 
> header that some people (Keith, I believe) keeps reminding us 
> about. As we know, going down this path starts to get muddy 
> very quickly.
> 
> 
> The other alternative is for MARTINI to simply amend the RFC 
> 3261 behavior for REGISTER by mandating that responses to 
> requests wherein the target is a "bnc" (or whatever other 
> flag we use) do not contain the full set of registered 
> contacts, but instead include some (presumably useful and 
> size-limited) subset.
> 
> My proposal is that, for "bnc" contacts, a successful 
> REGISTER response return not the "expansion" of the 
> macro-registration, but the set of  unexpanded "To, Contact" 
> vectors currently registered. Yes, this isn't a 
> fully-explicit indication of registration state, but I think 
> it's the best we can do in a REGISTER response over UDP.
> 
> This leaves the question of what to do in a response to a  
> failed REGISTER  request. If we incorporate PBX->SSP explicit 
> indication in the request, I propose that the failed response 
> (specifically a 403, in most cases) contain only the first 
> range that failed.
> 
> Yes, if you have a really messed-up REGISTER request it could 
> take a few tries before you get informed about all the 
> failing range requests, but I don't see that as a huge 
> problem. Ypu'll still know you have a failed registration, 
> and that response will contain enough useful information for 
> SOME sort of debugging. This is much better than the 
> "implicit registration" case, where you might just THINK 
> you'd had a successful registration, even though nothing is 
> actually working.
> 
> 
> --
> Dean
>

---

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

On 2/15/10 18:52, Feb 15, Spencer Dawkins wrote:
> measured at the SIP level, not at the IP MTU level), and that they can 
> lists of what's being registered can mean that the request (and, more 
> Several people have been saying "use regevents, because you want an 
> ongoing understanding of what the other guy thinks anyway, not just a 
> snapshot at REGISTER time", and I've been listening.

Wait, what?

The REGISTER will be too big if we include a list of extensions in it, 
but the NOTIFY won't? What kind of magic is this?

/a

---

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

So, here's what I don't understand: 3GPP at least defined a procedure -- 
through a questionable use of P-Associated-URI -- to indicate which URIs 
the registrar would be registering on behalf of the user. So even the 
original 3GPP implicit approach had an enumeration of the AORs 
associated with the registration process.

We're proposing to be even more sparse than that. Rather than just 
"implicit with a list of AORs," we're proposing "implicit with *no* list 
of AORs."

So, even if your assertion that our allowing the implicit mechanism to 
stand is somehow tacit approval, what's being proposed here is even one 
step more nebulous.

/a

On 2/15/10 19:07, Feb 15, Paul Kyzivat wrote:
> It was never explicitly brought to the ietf, though things linked to 
> it like P-Asserted-ID and P-Associated-URI were. While we could say 
> that is not our problem, I think we already implicitly approved it via 
> benign neglect.
>
>     Thanks,
>     Paul
>
> Dean Willis wrote:
>>
>> Contacts. This seems like a reasonable extension to simplify life  
>> for a "multi user" SIP user agent. But I really think we should 
>> respect the history of REGISTERs explicit encoding of the AORs and 
>> Contacts involved.
>>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Feb 2010 13:17:28 -0600

Hi, Adam,

>> may puke on large requests/responses (where "large" is measured at the 
>> SIP level, not at the IP MTU level), and that they can reject large 
>> requests, but not large responses. So, I'm back to my previous concern, 
>> just higher in the stack, if including explicit lists of what's being 
>> registered can mean that the request (and, more so, the response) can be 
>> big enough to cause problems.
>>
> The REGISTER will be too big if we include a list of extensions in it, but 
> the NOTIFY won't? What kind of magic is this?

I wasn't intending magic here... just saying that the REGISTER would no 
longer have the problem.

I was assuming (maybe this is a bad assumption) that we didn't have to send 
back the entire list in one NOTIFY, but that we would have to send the 
entire list in one REGISTER (whether in the request, the response, or both).

I didn't say that, of course, and if other people aren't thinking what I'm 
thinking, I could be confused.

Thanks,

Spencer

---

From: "Brian Lindsay" <[email-masked]>
Date: Tue, 16 Feb 2010 14:36:12 -0500

Hi,

   I think it's been stated many times in the threads that E.164 number
provisioning between the enterprise and service provider is out of scope
of MARTINI. So we're not using the register transaction to perform any
syncronization on these numbers betweeen the enterprise and service
provider. The registration is just being used to provide reachability
info, to allow requests to a set of E.164 numbers to be routed to the
SIP PBX. As such, I don't think the number ranges need to be part of the
registration transaction. It'll just add extra complexity to the
implementations.

   Regards
       Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
Sent: Tuesday, February 16, 2010 1:39 PM
To: Paul Kyzivat
Cc: Bernard Aboba; 'MARTINI'
Subject: Re: [martini] DID Number Mobility and MARTINI

/a

>>> Speaking as co-chair, the non-registration aspects of DID number 
>>> mobility are outside the scope of the current MARTINI WG charter.
>>>
>>> http://www.ietf.org/mail-archive/web/martini/current/msg00687.html )

>>> is whether the registration aspects represent a requirement or not.
>>> Feel free

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Feb 2010 21:57:59 +0100

Hi,

In IMS the P-Associated-URI header field is included in the REGISTER response.

I don't know if anyone is claiming otherwise, but just to be clear :)

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Spencer Dawkins [[email-masked]]
Sent: Tuesday, February 16, 2010 9:17 PM
To: Adam Roach
Cc: Bernard Aboba; 'MARTINI'
Subject: Re: [martini] DID Number Mobility and MARTINI

Hi, Adam,

Thanks,

Spencer

---

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

Hi, Brian,

Just trying to stay synchronized here.

Speaking as an individual, I think you're right about provisioning being out 
of scope, based on what I've been hearing on this list and in telechats, 
etc.

What I thought Adam was talking about isn't quite provisioning (ignoring the 
question direction - I've heard some people suggest each direction). It was 
more like "I expect these numbers to be registered" and/or "I registered 
these numbers on your behalf", with the question of how each end knows what 
numbers "should" be registered being out of scope - because "knowing" was 
provisioned.

At least, that's the context in which I was reading Adam's note below.

Thanks,

Spencer

---

From: "Brian Lindsay" <[email-masked]>
Date: Tue, 16 Feb 2010 16:51:39 -0500

Hi Spencer,

   So basically since the provisioning/sync of the E.164 numbers/ranges
is out of scope I don't see a strong argument for including them in the
registration transaction. The Service Provider has a set of E.164
numbers that, based on prior assignment/arrangement, it is responsible
to route to the SIP PBX. The SIP PBX is aware of these numbers already.
The registration process (using an AoR identifying the SIP PBX) is
intended to provide reachability information for the SIP PBX, in the
absence of static IP address configuration / DNS (hence the ranges are
not actually required in this transaction).

  Thanks
    Brian

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Tuesday, February 16, 2010 4:37 PM
To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat
Cc: Bernard Aboba; MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Hi, Brian,

Speaking as an individual, I think you're right about provisioning being
out of scope, based on what I've been hearing on this list and in
telechats, etc.

What I thought Adam was talking about isn't quite provisioning (ignoring
the question direction - I've heard some people suggest each direction).
It was more like "I expect these numbers to be registered" and/or "I
registered these numbers on your behalf", with the question of how each
end knows what numbers "should" be registered being out of scope -
because "knowing" was provisioned.

Thanks,

Spencer

> provisioning between the enterprise and service provider is out of 
> scope of MARTINI. So we're not using the register transaction to 
> perform any syncronization on these numbers betweeen the enterprise 
> and service provider. The registration is just being used to provide 
> reachability info, to allow requests to a set of E.164 numbers to be 
> routed to the SIP PBX. As such, I don't think the number ranges need 
> to be part of the registration transaction. It'll just add extra 
> complexity to the implementations.
>
>   Regards
>       Brian
>
> So, here's what I don't understand: 3GPP at least defined a procedure 
> -- through a questionable use of P-Associated-URI -- to indicate which

> URIs the registrar would be registering on behalf of the user. So even

> the original 3GPP implicit approach had an enumeration of the AORs 
> "implicit with a list of AORs," we're proposing "implicit with *no* 
> list of AORs."
>

> stand is somehow tacit approval, what's being proposed here is even 
> one step more nebulous.
>
> /a
>
>>> for

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Feb 2010 16:23:12 -0600

Hi, Brian,

Speaking carefully as chair, and Bernard can correct me if I am saying 
things I should not be saying as chair, at this point...

I happen to agree with your reasoning, re: REGISTER. What I'm trying to 
tease out is whether we can just say "we're not providing that information 
in the REGISTER exchange, BUT you can get that information using regevents", 
so that we can move on - I haven't heard anyone propose that MARTINI would 
say "MUST NOT use regevents" :-)

I would be comfortable if our specifications were silent on this point, and 
might be more comfortable if we pointer out somewhere that the REGISTER 
exchange does not provide this information, but people who want the 
information can use regevents or whatever other method seems appropriate to 
get the information that they want.

But (Bernard and) I don't get to decide what working group consensus is - we 
only get to recognize what consensus is, and when it exists. For that, we 
need to hear from other participants (including you, of course - and "thank 
you" to participants who care, and have expressed opinions about this, in 
the current thread.

I hope this is helpful.

Thanks,

Spencer

----- Original Message ----- 
From: "Brian Lindsay" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Adam Roach" 
<[email-masked]>; "Paul Kyzivat" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; "MARTINI" 
<[email-masked]>
Sent: Tuesday, February 16, 2010 3:51 PM
Subject: RE: [martini] DID Number Mobility and MARTINI

Hi Spencer,

  Thanks
    Brian

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Tuesday, February 16, 2010 4:37 PM
To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat
Cc: Bernard Aboba; MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Hi, Brian,

Thanks,

Spencer

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 16 Feb 2010 14:39:46 -0800

There are a number of related things that have been discussed in this (and
other) threads, and sometimes it's hard to tease the issues apart: 

a. Use of REGISTER vs. reg-events to find out what DIDs were registered. 
b. Use of REGISTER for provisioning vs. telling the SSP "what DIDs the PBX
thinks it has" (which the SSP is free to find fault with, as in a
conventional registration)
c. Error handling (e.g. what happens when the SSP/PBX are not in sync, and
how the PBX admin figures out what went wrong). 

I read Brian's message below as expressing an opinion on issue b), and
Spencer's message as relating to that as well as Issue a).  

In one of the threads, Dean brought up issue c).  

Ideally, the requirements document would touch on each of these issues with
enough clarity so that we can tell them apart.

Behind a number of these issues seems to be the general question of whether
a multiple AOR registration is in principle expected to produce very similar
results to many single AOR registrations (minus the additional traffic, of
course).    Registering multiple AORs w/multiple contacts, providing similar
error semantics, etc. seem to point in that direction, but I'm not sure that
this principle has been explicitly discussed (or even agreed to as a goal). 

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Tuesday, February 16, 2010 2:23 PM
To: Brian Lindsay; Adam Roach; Paul Kyzivat
Cc: Bernard Aboba; MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Hi, Brian,

I hope this is helpful.

Thanks,

Spencer

----- Original Message -----
From: "Brian Lindsay" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Adam Roach" 

Hi Spencer,

  Thanks
    Brian

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Tuesday, February 16, 2010 4:37 PM
To: Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat
Cc: Bernard Aboba; MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

Hi, Brian,

Thanks,

Spencer

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Feb 2010 16:43:09 -0600

> how the PBX admin figures out what went wrong).

I think you've omitted:

d. Use of REGISTER for *intermediaries* to find out what DIDs have been 
registered.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Feb 2010 17:03:13 -0600

On 2/16/10 14:57, Feb 16, Christer Holmberg wrote:
> I was assuming (maybe this is a bad assumption) that we didn't have to 
> send back the entire list in one NOTIFY...
The first time it's sent, yeah, you do. After that, there are things you 
can do to make it smaller, but there's no getting around the fact that 
the first NOTIFY ever sent will need to contain all the DID, and still 
fit in a single SIP message.

If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in 
fact, the format for reg event will be even more bulky than anything 
anyone has in mind for REGISTER, so it makes the problem worse, not better).

So, while message size might be a valid topic of conversation, moving 
the ranges of extensions from REGISTER to NOTIFY is simply reducing the 
entire issue to a previously unsolved problem.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 17 Feb 2010 01:29:26 +0100

But here the registration we are talking about is not the registration of the handset. It is the registration of the next step on the process of how to get to the handset / terminal. This it is using register to create part of a route, sothing already done by SIP in the path and service route extensions.

regards

Keith 

> Sent: Tuesday, February 16, 2010 1:31 AM
> To: Paul Kyzivat
> registering AOR,  
> actually  
> more for

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 17 Feb 2010 01:29:23 +0100

I would point out that all of the implicit registration stuff was brought to IETF, not as a standards track document, but there was an informational RFC in RFC 4083 where the general intro says:

  "This document is advisory in nature.  Its primary purpose is to help
   the IETF understand the IMS environment.  Given this better
   understanding, we expect that the IETF can more effectively evolve
   the SIP protocol.  The IETF will not respond to the requirements
   given in this document on a point-for-point basis.  Some requirements
   have been and/or will be met by extensions to the SIP protocol.
   Others may be addressed by effectively using existing capabilities in
   SIP or other protocols, and we expect that individual members of the
   SIP community will work with 3GPP to achieve a better understanding
   of these mechanisms.  Some of the requirements in this document may
   not be addressed at all by the IETF, although we believe that the act
   of documenting and discussing them is in itself helpful in achieving
   a better all-around understanding of the task at hand."

It then goes on to document the implicit registration in 4.10.2.2 of that document:

"4.10.2.2.  Registration of Public User IDs

   It must be possible to register globally (i.e., through one single UA
   request) a user that has more than one public identity that belongs
   to the same user profile, via a mechanism within the IMS.  In this
   case, the user will be registered with all the public identities
   associated to a user profile.

   We believe this requirement may be accomplished by external
   procedures.  For example, the user's profile may contain a list of
   alias identities that the registrar considers active if the primary
   identity is registered.  The user may get informed of the
   automatically registered public user IDs by subscribing to its own
   registration state."

I would point out that while is is not IETF sanction in saying this is the IETF way of doing things, this document was used to discuss the mechanism involved in IMS, and based on IETF response, a significant number of changes were made in the way IMS does things as a result of this. I would contend that at least the participants at that time argued out the harmful things, and what is left is at least not breaking the rules.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, February 16, 2010 1:07 AM
> To: Dean Willis
> It was never explicitly brought to the ietf, though things 
> linked to it like P-Asserted-ID and P-Associated-URI were. 
> While we could say that is not our problem, I think we 
> already implicitly approved it via benign neglect.
> 
> 	Thanks,
> 	Paul
> 
> Dean Willis wrote:
> > 
> >> Feel free to respond and provide your opinion on that thread.
> > 
> > the history of REGISTERs explicit encoding of the AORs and 
> Contacts involved.
> >

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 16 Feb 2010 16:59:20 -0800

Adam said: 

"If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in 
fact, the format for reg event will be even more bulky than anything 
anyone has in mind for REGISTER, so it makes the problem worse, not better).

So, while message size might be a valid topic of conversation, moving 
the ranges of extensions from REGISTER to NOTIFY is simply reducing the 
entire issue to a previously unsolved problem."

[BA] Let me ask a (perhaps naïve) question about the expected behavior
of reg-event with respect to MARTINI multiple AOR registrations. 

Within RFC 3680, the contents of the NOTIFY depends on which AOR is being
subscribed to.  
If you buy into the multiple AOR/multiple contact model, wouldn't a
SUBSCRIBE for the 
an AOR return only information relating to that specific AOR, not all the
AORs that
were registered? If so, doesn't that make the size issue for NOTIFY somewhat
more
tractable? 

Note that RFC 3680 Section 4.3 refers to the inclusion of a body in the
SUBSCRIBE, to enable filtering of subscriptions:

   A SUBSCRIBE for registration events MAY contain a body.  This body
   would serve the purpose of filtering the subscription.  The
   definition of such a body is outside the scope of this specification.

   A SUBSCRIBE for the registration package MAY be sent without a body.
   This implies that the default registration filtering policy has been
   requested. The default policy is:

      o  Notifications are generated every time there is any change in
         the state of any of the registered contacts for the resource
         being subscribed to.  Those notifications only contain
         information on the contacts whose state has changed.

      o  Notifications triggered from a SUBSCRIBE contain full state
         (the list of all contacts bound to the address-of-record).

---

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

> were registered? If so, doesn't that make the size issue for NOTIFY somewhat

The GIN draft goes into how this works. The short version is: yes, if 
you subscribe to <sip:[email-masked]>, you'll get registration 
information from the PBX about that one AOR. If you subscribe to the 
PBX's AOR -- the one it uses to identify itself to the SSP (e.g. 
<sip:[email-masked]>), then you'll get registration information from the 
SSP for all of the AORs. This is consistent with the behavior described 
in 3680:

    Note that the document format explicitly allows for conveying
    information on multiple addresses-of-record.  This enables
    subscriptions to groups of registrations, where such a group is
    identified by some kind of URI.

>     definition of such a body is outside the scope of this specification.

Outside the scope and still undefined. We can't wave our hands at an 
unspecified solution and say that it somehow solves the issue. And I 
doubt MARTINI needs to get in the business of defining RFC 3680 filters.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Feb 2010 21:51:22 -0500

Interesting direction...

IMS has set the precedent that a subscribe to one AOR can result in 
notification about associated AORs. But I suppose it could also be 
specified to limit its behavior in that regard somehow.

And as Bernard hints, it would certainly be possible to define a (new) 
filter that explicitly constrains what is returned.

	Thanks,
	Paul

---

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

Hi, Adam,

OK, I agree with with you that we "can't handwave".

I believe Dean that we need to think about request/response sizes, especially response sizes, whether because we're running over UDP or because SIP intermediaries may enforce limits on request/response sizes, even using TCP.

I understand your assertion that what GIN is doing is consistent with RFC 3680, so I'm not suggesting that we change that (without a lot more discussion).

So I'm down to your assertion that we don't want to specify RFC 3680 filters in MARTINI. 

I'm not quite sure how we we limit request/response sizes without filtering, but people have been doing pretty well at suggesting alternatives I haven't thought of ... any clues on what I might be missing here?

Thanks,

Spencer
  ----- Original Message ----- 
  From: Adam Roach 
  To: Bernard Aboba 
  Cc: 'Christer Holmberg' ; 'Spencer Dawkins' ; 'MARTINI' 
  Sent: Tuesday, February 16, 2010 8:42 PM
  Subject: Re: [martini] DID Number Mobility and MARTINI

  Outside the scope and still undefined. We can't wave our hands at an unspecified solution and say that it somehow solves the issue. And I doubt MARTINI needs to get in the business of defining RFC 3680 filters.

  /a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Feb 2010 08:35:47 +0100

So in trying to tease out whether there needs to be, as part of the MARTINI mechanism (as opposed to provisioning) an explicit list of numbers and/or contacts (I won't try to tie down which at present), I think it is important to understand which direction this is needed in, because that will go some way towards determining the mechanism. Do people think:

a) there is good reason for providing this information in the direction SIP-PBX to SSP (in which case inclusion in a REGISTER request might be one solution); or

b) there is a good reason for providing this information in the direction SSP to SIP-PBX (in which case reg-events might be one solution); or

c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or

d) there is a good reason for doing both; or

e) there is no good reason to do either.

My personal opinion is e), but I would like to hear other opinions, with reasons.

John

> [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: 16 February 2010 22:23
> linked to

---

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

Hi, 

>The first time it's sent, yeah, you do. After that, there are things you can do to make it smaller, but there's no getting around the fact that the first NOTIFY ever sent will need to contain all the 
>DID, and still fit in a single SIP message.
>
>If size is an issue for REGISTER, it's an issue for NOTIFY. (And, in fact, the format for reg event will be even more bulky than anything anyone has in mind for REGISTER, so it makes the problem worse, 
>not better).
>
>So, while message size might be a valid topic of conversation, moving the ranges of extensions from REGISTER to NOTIFY is simply reducing the entire issue to a previously unsolved problem.

The text you commented was not written by me.

But, in any case, when we talk about the message size, we need to be clear about if we talk about requests and responses. As we know, creatomg a response which is larger than the associated request can cause fragmentation problems if UDP was used.

Sending a large request should not have that problem - you just use TCP to start with.

But, there may of course be other reasons why we want to avoid large messages.

Regards,

Christer

---

From: <[email-masked]>
Date: Wed, 17 Feb 2010 13:44:53 +0100

My view is that there is no strong need need for carrying this information accross the SIP-PBX - SSP interface. However this information needs to be provided by the SSP's Registrar to the SSP's edge proxy so as to enable the edge proxy to assert identities received from the PBX in a P-Preferred-Identity header field.

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Elwell, John
> Envoyé : mercredi 17 février 2010 08:36
> À : Spencer Dawkins; Brian Lindsay; Adam Roach; Paul Kyzivat
> Cc : Bernard Aboba; MARTINI
> Objet : Re: [martini] DID Number Mobility and MARTINI
> 
> So in trying to tease out whether there needs to be, as part 
> of the MARTINI mechanism (as opposed to provisioning) an 
> explicit list of numbers and/or contacts (I won't try to tie 
> down which at present), I think it is important to understand 
> which direction this is needed in, because that will go some 
> way towards determining the mechanism. Do people think:
> 
> a) there is good reason for providing this information in the 
> direction SIP-PBX to SSP (in which case inclusion in a 
> REGISTER request might be one solution); or
> 
> b) there is a good reason for providing this information in 
> the direction SSP to SIP-PBX (in which case reg-events might 
> be one solution); or
> 
> c) it doesn't matter which direction - either direction would 
> be good enough so that at least one side is able to detect a 
> discrepancy; or
> 
> > I happen to agree with your reasoning, re: REGISTER. What 
> I'm trying 
> > to tease out is whether we can just say "we're not providing that 
> > information in the REGISTER exchange, BUT you can get that 
> information 
> > using regevents", so that we can move on - I haven't heard anyone 
> > propose that MARTINI would say "MUST NOT use regevents" :-)
> > 
> > I would be comfortable if our specifications were silent on this 
> > point, and might be more comfortable if we pointer out 
> somewhere that 
> > the REGISTER exchange does not provide this information, but people 
> > who want the information can use regevents or whatever other method 
> > seems appropriate to get the information that they want.
> > 
> > But (Bernard and) I don't get to decide what working group 
> consensus 
> > is - we only get to recognize what consensus is, and when it exists.
> > For that, we
> > need to hear from other participants (including you, of 
> course - and 
> > "thank you" to participants who care, and have expressed opinions 
> > about this, in the current thread.
> > 
> > I hope this is helpful.
> > 
> > Thanks,
> > 
> > Spencer
> > 
> >    So basically since the provisioning/sync of the E.164 
> > numbers/ranges is out of scope I don't see a strong argument for 
> > including them in the registration transaction. The Service 
> Provider 
> > has a set of E.164 numbers that, based on prior 
> > assignment/arrangement, it is responsible to route to the 
> SIP PBX. The 
> > SIP PBX is aware of these numbers already.
> > Speaking as an individual, I think you're right about provisioning 
> > being out of scope, based on what I've been hearing on this 
> list and 
> > in telechats, etc.
> > 
> > What I thought Adam was talking about isn't quite provisioning 
> > (ignoring the question direction - I've heard some people 
> suggest each 
> > direction).
> > registered these numbers on your behalf", with the question of how 
> > each end knows what numbers "should" be registered being 
> out of scope 
> > - because "knowing" was provisioned.
> > 
> [mailto:[email-masked]] On 
> > > Behalf Of Adam Roach
> > >> that is not our problem, I think we already implicitly 
> approved it 
> > >> via
> > >
> > >> benign neglect.
> > >>
> > >>     Thanks,
> > >>     Paul
> > >>
> > >> Dean Willis wrote:
> > >>>
> > >>> Remember, the one thing that RFC 3261 REGISTER really 
> does is bind 
> > >>> an
> > >

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Feb 2010 14:37:12 +0100

Bruno,

Thanks. However, this particular reason for a proxy needing this information is because of an architecture where the proxy is assigned responsibility for asserting an identity for the source of a request. If the domain proxy takes on this responsibility instead, problem solved. So it is a question of whether this particular architecture is common enough that we need a solution that conveys registered identities to the edge proxy. IMS solves this using PAU (ignoring issues of response size), so the question for others is whether there are other architectures in practice where this is important. I guess for this particular usage it doesn't matter whether the information is in the REGISTER request or the REGISTER response.

John

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 17 February 2010 12:45
> To: Elwell, John; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> My view is that there is no strong need need for carrying 
> this information accross the SIP-PBX - SSP interface. However 
> this information needs to be provided by the SSP's Registrar 
> to the SSP's edge proxy so as to enable the edge proxy to 
> assert identities received from the PBX in a 
> P-Preferred-Identity header field.
> 
> This message and any attachments (the "message") are 
> confidential and intended solely for the addressees. 
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Feb 2010 14:47:36 +0100

Hi,

I don't really see what the problem is. Can't we simply say that P-AU is optional, and people can use it if required?

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 17. helmikuuta 2010 15:37
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] DID Number Mobility and MARTINI

Bruno,

John

> To: Elwell, John; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> My view is that there is no strong need need for carrying this 
> information accross the SIP-PBX - SSP interface. However this 
> information needs to be provided by the SSP's Registrar to the SSP's 
> edge proxy so as to enable the edge proxy to assert identities 
> received from the PBX in a P-Preferred-Identity header field.
> 
> > [mailto:[email-masked]] De la part de Elwell, John Envoyé 
> > : mercredi 17 février 2010 08:36 À : Spencer Dawkins; Brian Lindsay; 
> > Adam Roach; Paul Kyzivat Cc : Bernard Aboba; MARTINI Objet : Re: 
> > [martini] DID Number Mobility and MARTINI
> > 
> > So in trying to tease out whether there needs to be, as part of the 
> > MARTINI mechanism (as opposed to provisioning) an explicit list of 
> > numbers and/or contacts (I won't try to tie down which at present), 
> > I think it is important to understand which direction this is needed 
> > in, because that will go some way towards determining the mechanism. 
> > Do people think:
> > 
> > direction SIP-PBX to SSP (in which case inclusion in a REGISTER 
> > request might be one solution); or
> > 
> > b) there is a good reason for providing this information in the 
> > direction SSP to SIP-PBX (in which case reg-events might be one 
> > solution); or
> > 
> > c) it doesn't matter which direction - either direction would be 
> > good enough so that at least one side is able to detect a 
> > discrepancy; or
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Feb 2010 14:54:40 +0100

Christer,

Yes, that was what I was intending to imply. However, if MARTINI decides that there are compelling reasons why this information needs somehow to be conveyed (other than for IMS, which claims already to have a solution), I am not sure that sending the information in a response would be acceptable, given the issue of the response size, and assuming we retain the requirement for operation over UDP.

John

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: 17 February 2010 13:48
> To: Elwell, John; [email-masked];
> [email-masked]; [email-masked];
> I don't really see what the problem is. Can't we simply say
> that P-AU is optional, and people can use it if required?
>
> Regards,
>
> Christer
>
> [mailto:[email-masked]] On Behalf Of Elwell, John
> To: [email-masked];
> [email-masked]; [email-masked];
> Thanks. However, this particular reason for a proxy needing
> this information is because of an architecture where the
> proxy is assigned responsibility for asserting an identity
> for the source of a request. If the domain proxy takes on
> this responsibility instead, problem solved. So it is a
> question of whether this particular architecture is common
> enough that we need a solution that conveys registered
> identities to the edge proxy. IMS solves this using PAU
> (ignoring issues of response size), so the question for
> others is whether there are other architectures in practice
> where this is important. I guess for this particular usage it
> doesn't matter whether the information is in the REGISTER
> request or the REGISTER response.
>
> John
>
>
> > > My personal opinion is e), but I would like to hear other
> opinions,
> > > with reasons.
> > >
> > > John
> > >
> > >
> > > > >>> registration." I agree that we can't justify a
> requirement to
> > > > >>> produce
> > > > >
> > France Telecom Group shall not be liable for the message if
> altered,
> > changed or falsified.
> > If you are not the intended addressee of this message,
> please cancel
> > it immediately and inform the sender.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Feb 2010 15:08:44 +0100

Hi,

People who use P-AU have to take the message size issue into consideration.

I am pretty sure this is not the only SIP scenario where you can get a response that is larger than the associated request... In addition, unless I've missed it, we don't even know how the REGISTER request will look like yet :)

Regards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: 17. helmikuuta 2010 15:55
To: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [martini] DID Number Mobility and MARTINI

Christer,

John

> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> I don't really see what the problem is. Can't we simply say that P-AU
> is optional, and people can use it if required?
>
> Regards,
>
> Christer
>
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Thanks. However, this particular reason for a proxy needing this
> information is because of an architecture where the proxy is assigned
> responsibility for asserting an identity for the source of a request.
> If the domain proxy takes on this responsibility instead, problem
> solved. So it is a question of whether this particular architecture is
> common enough that we need a solution that conveys registered
> identities to the edge proxy. IMS solves this using PAU (ignoring
> issues of response size), so the question for others is whether there
> are other architectures in practice where this is important. I guess
> for this particular usage it doesn't matter whether the information is
> in the REGISTER request or the REGISTER response.
>
> John
>
>

---

From: <[email-masked]>
Date: Wed, 17 Feb 2010 15:26:57 +0100

Use of wildcarded identities in P-AU provides a solution to shorten the message. Does this discussion means that the MARTINI group has already discarded this solution? I remember someone stating that the use of wildcards was not permitted by RFC3455. If this is confirmed, a revision of RFC3455 might be more appropriate than just discarding the solution.

> De : Christer Holmberg [mailto:[email-masked]] 
> Envoyé : mercredi 17 février 2010 15:09
> À : 'Elwell, John'; CHATRAS Bruno RD-CORE-ISS; 
> Cc : [email-masked]; [email-masked]
> Objet : RE: [martini] DID Number Mobility and MARTINI
> 
> 
> Hi,
> 
> I am pretty sure this is not the only SIP scenario where you 
> can get a response that is larger than the associated 
> request... In addition, unless I've missed it, we don't even 
> know how the REGISTER request will look like yet :)
> 
> Regards,
> 
> Christer
> 
> To: Christer Holmberg; [email-masked]; 
> Yes, that was what I was intending to imply. However, if 
> MARTINI decides that there are compelling reasons why this 
> information needs somehow to be conveyed (other than for IMS, 
> which claims already to have a solution), I am not sure that 
> sending the information in a response would be acceptable, 
> given the issue of the response size, and assuming we retain 
> the requirement for operation over UDP.
> 
> John
> 
> that P-AU

---

From: "Brian Lindsay" <[email-masked]>
Date: Wed, 17 Feb 2010 09:34:26 -0500

Hi,

   I would suggest keeping P-AU out of the draft(s). If there is a service provider architecture, like IMS, that wants to use it, that's fine, but it doesn't need to be included in the mechanism described by the draft.

   Regards
      Brian

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Wednesday, February 17, 2010 8:48 AM
To: 'Elwell, John'; [email-masked]; [email-masked]; Lindsay, Brian (CAR:AR00); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [martini] DID Number Mobility and MARTINI

Hi,

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 17. helmikuuta 2010 15:37
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] DID Number Mobility and MARTINI

Bruno,

John

---

From: "Brian Lindsay" <[email-masked]>
Date: Wed, 17 Feb 2010 09:38:51 -0500

Hi John,

   Per my previous posts, I agree with you on e).

   Thanks

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, February 17, 2010 2:36 AM
To: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Adam Roach; Paul Kyzivat
Cc: Bernard Aboba; MARTINI
Subject: RE: [martini] DID Number Mobility and MARTINI

So in trying to tease out whether there needs to be, as part of the
MARTINI mechanism (as opposed to provisioning) an explicit list of
numbers and/or contacts (I won't try to tie down which at present), I
think it is important to understand which direction this is needed in,
because that will go some way towards determining the mechanism. Do
people think:

a) there is good reason for providing this information in the direction
SIP-PBX to SSP (in which case inclusion in a REGISTER request might be
one solution); or

c) it doesn't matter which direction - either direction would be good
enough so that at least one side is able to detect a discrepancy; or

My personal opinion is e), but I would like to hear other opinions, with
reasons.

John

> I happen to agree with your reasoning, re: REGISTER. What I'm trying 
> information in the REGISTER exchange, BUT you can get that information

> point, and might be more comfortable if we pointer out somewhere that 
> But (Bernard and) I don't get to decide what working group consensus 
> need to hear from other participants (including you, of course - and 
> including them in the registration transaction. The Service Provider 
> assignment/arrangement, it is responsible to route to the SIP PBX. The

> being out of scope, based on what I've been hearing on this list and 
> in telechats, etc.
> 
> (ignoring the question direction - I've heard some people suggest each

> each end knows what numbers "should" be registered being out of scope 

> >>> Remember, the one thing that RFC 3261 REGISTER really does is bind

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Feb 2010 15:42:04 +0100

Hi,

I guess it's ok to leave it out, as long as we don't forbid the usage of it.

However, *IF* we will end up with a solution/requirement where the registered AoRs for whatever other ("non-IMS") reason need to be sent from the SSP to the PBX, I see no reason why P-AU can't be listed as an option...

Regards,

Christer

-----Original Message-----
From: Brian Lindsay [mailto:[email-masked]]
Sent: 17. helmikuuta 2010 16:34
To: Christer Holmberg; Elwell, John; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [martini] DID Number Mobility and MARTINI

Hi,

   Regards
      Brian

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Wednesday, February 17, 2010 8:48 AM
To: 'Elwell, John'; [email-masked]; [email-masked]; Lindsay, Brian (CAR:AR00); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [martini] DID Number Mobility and MARTINI

Hi,

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 17. helmikuuta 2010 15:37
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] DID Number Mobility and MARTINI

Bruno,

John

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 17 Feb 2010 06:57:21 -0800

A comment --

One might answer the question differently, depending on whether we're
referring to:

a. The common case (a successful REGISTER request/response)
b. An error condition

One might have a different answer depending on whether we're talking about
REGISTER or reg-event. 

For example:

For the REGISTER common case (where we'd like to optimize), my personal
preference would be e).  

In the case of REGISTER response indicating an error, it would be useful to
get some indication of what went wrong.  In this situation, the information
that is most useful is the list of numbers that were found to be in error
(which might be a smaller set).  Since those numbers might not be
registerable even in single AOR registration, they can't enter the ACTIVE
state and thus won't generate a reg-event. 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, February 16, 2010 11:36 PM
To: Spencer Dawkins; Brian Lindsay; Adam Roach; Paul Kyzivat
Cc: Bernard Aboba; MARTINI
Subject: RE: [martini] DID Number Mobility and MARTINI

So in trying to tease out whether there needs to be, as part of the MARTINI
mechanism (as opposed to provisioning) an explicit list of numbers and/or
contacts (I won't try to tie down which at present), I think it is important
to understand which direction this is needed in, because that will go some
way towards determining the mechanism. Do people think:

a) there is good reason for providing this information in the direction
SIP-PBX to SSP (in which case inclusion in a REGISTER request might be one
solution); or

b) there is a good reason for providing this information in the direction
SSP to SIP-PBX (in which case reg-events might be one solution); or

c) it doesn't matter which direction - either direction would be good enough
so that at least one side is able to detect a discrepancy; or

John

> consensus is - we 
> course - and "thank 
> numbers/ranges

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Feb 2010 10:07:11 -0500

John,

I'm still not entirely decided on this. My inclination is (c), but I 
don't find the need to be compelling. I just share Dean and Adam's 
concern that implicit behavior is likely to come back and bite us.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Feb 2010 16:29:19 +0100

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: 17 February 2010 14:57
> To: Elwell, John; 'Adam Roach'
> Cc: 'MARTINI'
> (which might be a smaller set). 
[JRE] That pre-supposes an explicit list in the request, some numbers in the list being found to be in error. If the list is implicit, it seems likely that the whole registration would either succeed or fail. I don't see why an SSP, having been provisioned with a set of numbers assigned to the PBX, would successfully register some and not others when the request has simply asked for implicit registration of the whole lot.

So my intention, when asking the question, was for an explicit list in the successful case. Depending on what we agree on for that, we might then wish to consider unsuccessful cases.

John

>  Since those numbers might not be
> of the MARTINI
> direction
> the direction
> be good enough
> opinions, with

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Feb 2010 16:34:47 +0100

Paul,

And if the need is not compelling, my concern is that we might introduce into the specification unnecessarily complications and unnecessary differences from the types of implementation already existing today, thereby imposing greater costs on vendors and service providers considering upgrading their equipment to be MARTINI (and SIPconnect 1.1) compliant. As you know, I view things from the PBX side, and there (depending of course on the exact solution adopted), the increment in implementation effort might not be so great. Therefore I am somewhat neutral, but concerned to have something that can easily be adopted by service providers.

John

> Sent: 17 February 2010 15:07
> To: Elwell, John
> Cc: Spencer Dawkins; Brian Lindsay; Adam Roach; Bernard Aboba; MARTINI
> > So in trying to tease out whether there needs to be, as 
> part of the MARTINI mechanism (as opposed to provisioning) an 
> > a) there is good reason for providing this information in 
> the direction SIP-PBX to SSP (in which case inclusion in a 
> > c) it doesn't matter which direction - either direction 
> would be good enough so that at least one side is able to 
> detect a discrepancy; or
> > 
> opinions, with reasons.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Feb 2010 17:25:41 +0100

Hi John,

When you say "explicit", do you exclude wildcarded values? Because, one may think that we don't need explicit, but still wildcarded, or one may think that we need neither.

I really appretiate your questionairy, but to me it seems that we are discussing protocol details when we aren't (at least I'm not) clear on the registration structure itself :)

For example, I think the answer one gives depends on whether one will use implicit registrations or not. It may also depend on whether a PBX will be one contact or many.

I think we need to be clear on those issues first. Or, am I completely out of line? :)

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 17. helmikuuta 2010 9:36
To: Spencer Dawkins; Brian Lindsay; Adam Roach; Paul Kyzivat
Cc: Bernard Aboba; MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

John

---

From: <[email-masked]>
Date: Wed, 17 Feb 2010 15:29:08 +0100

A good solution should work irrespective of which proxy is responsibile for asserting identities, including the case where this is the edge proxy.

> De : Elwell, John [mailto:[email-masked]] 
> Envoyé : mercredi 17 février 2010 14:37
> À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; 
> part of the

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Feb 2010 10:28:19 -0600

> c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or

I think you overspecified this option. I'm happy with the assertion that 
"it doesn't matter which direction," but the additional text implies 
that this is only being done for discrepancy detection.

Which tells me that you aren't following the entire conversation. But 
you're clearly not the only one.

There are at least three /very different/ reasons people have raised 
(and a fourth, completely fallacious red herring that the opposition has 
been using as a strawman to tear apart) for including this information:

   1. Specification, by the PBX, of the (sub)set of E.164 numbers it
      wants this registration to apply to,
   2. Indication to the intermediaries of which E.164 numbers the
      registration applies to, and
   3. Detection of mismatched provisioning between the PBX and the SSP.

The fourth thing, which no one has proposed, but which many detractors 
have set up as a wholly bogus strawman, is using this information to 
provision the PBX. No one wants that. No one has proposed that. We can 
stop arguing against it because no one is defending it. We all agree 
that this is not done in SIP.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Feb 2010 18:04:56 +0100

> Sent: 17 February 2010 16:26
> To: Elwell, John; Spencer Dawkins; Brian Lindsay; Adam Roach; 
> Paul Kyzivat
> When you say "explicit", do you exclude wildcarded values? 
> Because, one may think that we don't need explicit, but still 
> wildcarded, or one may think that we need neither.
[JRE] Wildcarded is still explicit - just a different syntax. This assumes of course that the intention is to register EVERY number in a wildcarded range (not just an implicit subset that the SSP is expected to know in advance).

> 
> I really appretiate your questionairy, but to me it seems 
> that we are discussing protocol details when we aren't (at 
> least I'm not) clear on the registration structure itself :)
> 
> For example, I think the answer one gives depends on whether 
> one will use implicit registrations or not. It may also 
> depend on whether a PBX will be one contact or many.
> 
[JRE] My attempt was to try to bring us back to requirements before discussion of protocol details, so the questions are pretty much agnostic to which messages are used (e.g., whether REGISTER, NOTIFY or PUBLISH, or whether request or response). Instead I am trying to focus on direction, i.e., is there a compelling reason why the PBX needs to receive an explicit list, is there a compelling reason why the SSP needs to receive an explicit list, is there a compelling reason why an intermediary (edge proxy) needs to receive an explicit list?

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Feb 2010 18:05:20 +0100

Bruno,

This depends whether we have a requirement for an edge proxy to be able to base identity assertions for outbound (non-REGISTER) requests on whether the identity concerned has been registered. We don't have such a requirement at present, so if you think we need such a requirement, please propose text for the requirements document.

John

> Sent: 17 February 2010 14:29
> A good solution should work irrespective of which proxy is
> responsibile for asserting identities, including the case
> where this is the edge proxy.
>
> would be
> altered, changed or falsified.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Feb 2010 18:14:05 +0100

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 17 February 2010 16:28
> To: Elwell, John
> Cc: Spencer Dawkins; Brian Lindsay; Paul Kyzivat; Bernard 
> Aboba; MARTINI
> I think you overspecified this option. I'm happy with the 
> assertion that "it doesn't matter which direction," but the 
> additional text implies that this is only being done for 
> discrepancy detection.
[JRE] I agree.

> 
> Which tells me that you aren't following the entire 
> conversation. But you're clearly not the only one.
[JRE] It was a mistake to add that to c).

> 
> There are at least three very different reasons people have 
> raised (and a fourth, completely fallacious red herring that 
> the opposition has been using as a strawman to tear apart) 
> for including this information:
> 
> 
> 
> 1.	Specification, by the PBX, of the (sub)set of E.164 
> numbers it wants this registration to apply to, 
> 2.	Indication to the intermediaries of which E.164 numbers 
> the registration applies to, and
> 	
[JRE] Some people are saying they are just uncomfortable with "implicit", so I am trying to determine in what direction they are trying to be "explicit". So true, I guess I was focusing on 3, and whether such mismatches need to be detected at the SIP-PBX or at the SSP. Clearly 1 would lead people to answer that they need the explicit indication  in the direction PBX to SSP, whereas 2 would work with an explicit indication in either direction. Maybe my way of trying to tease out requirements wasn't the best, and thanks for re-iterating the issues discussed.

John

> 
> The fourth thing, which no one has proposed, but which many 
> detractors have set up as a wholly bogus strawman, is using 
> this information to provision the PBX. No one wants that. No 
> one has proposed that. We can stop arguing against it because 
> no one is defending it. We all agree that this is not done in SIP.
> 
> /a
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 18 Feb 2010 03:08:38 +0100

Correction: IMS solves this using a combination of P-Associated-URI and reg event. This is because registered values can be deregistered by the SSP due to internal causes, and therefore when there is not a response to send to a REGISTER request.

But I do agree that the only interesting part of the problem is if it needs to go outside the SSP domain.

regards

Keith

> Sent: Wednesday, February 17, 2010 1:37 PM

---

From: "Brian Lindsay" <[email-masked]>
Date: Wed, 17 Feb 2010 21:35:16 -0500

Hi,
 
    Regarding the 3 reasons outlined below, I'm wondering if we can take
a couple of these off the table: 
 
    Regarding #1, one of the suggested drivers for this (that spawned
this and another thread) appeared to be mobility. There was at least
some set of people suggesting there were alternate mechanisms to support
mobility and that the mobility topic should be out of scope. Are we at
the point where mobility has been determined to be out of scope, and can
this reason then be removed?
 
    Regarding #3, detection of provisioning mismatches using the MARTINI
mechanism would seem to be out of scope since the provisioning mechanism
itself is out of scope. (why would we need the MARTINI mechanism to
detect mismatches associated with an out of scope capability?)
 
     Thanks
          Brian

From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, February 17, 2010 11:28 AM
To: Elwell, John
Cc: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Paul Kyzivat; Bernard
Aboba; MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

	c) it doesn't matter which direction - either direction would be
good enough so that at least one side is able to detect a discrepancy;
or

There are at least three very different reasons people have raised (and
a fourth, completely fallacious red herring that the opposition has been
using as a strawman to tear apart) for including this information:

3.	Detection of mismatched provisioning between the PBX and the
SSP. 

/a

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 17 Feb 2010 21:19:37 -0800

Brian Lindsay said:

"Regarding #3, detection of provisioning mismatches using the MARTINI
mechanism would seem to be out of scope since the provisioning mechanism
itself is out of scope. (why would we need the MARTINI mechanism to detect
mismatches associated with an out of scope capability?)"

[BA] In thinking of how we can consistently answer this and other questions
about what should be in/out of scope for multiple AOR registration it might
help to have some general principles to hang our hat on.   We've got a bunch
of these questions to plow through between now and (ideally) yesterday, and
we have had to put considerable effort into answering them one at a time.  

One principle that might help us in answering a bunch of them at once is to
ask whether a multiple AOR registration should provide similar functionality
to many single AOR registrations.   The arguments for contact routing and
support for many AOR/many contact explicit registration follow from this
principle. 

If we believe this (not sure that we do, but work with me)  then we can use
it to answer questions about whether certain functionality should be in or
out of scope.  

For example, to answer the question "is detection of provisioning mismatches
using multiple AOR registration out of scope?" we can ask the question "can
many single AOR registrations provide for detection of provisioning
mismatches?"   If you attempt to register an AOR with a conventional
REGISTER that the SSP doesn't know about, you would get an error for that
AOR, but not for other AORs that were registered successfully.  So that
level of functionality is provided by REGISTER as defined in RFC 3261, and I
believe that Dean has made a similar argument with respect to multiple AOR
functionality. 

  _____  

From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, February 17, 2010 11:28 AM
To: Elwell, John
Cc: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Paul Kyzivat; Bernard Aboba;
MARTINI
Subject: Re: [martini] DID Number Mobility and MARTINI

I think you overspecified this option. I'm happy with the assertion that "it
doesn't matter which direction," but the additional text implies that this
is only being done for discrepancy detection.

Which tells me that you aren't following the entire conversation. But you're
clearly not the only one.

There are at least three very different reasons people have raised (and a
fourth, completely fallacious red herring that the opposition has been using
as a strawman to tear apart) for including this information:

1.	Specification, by the PBX, of the (sub)set of E.164 numbers it wants
this registration to apply to, 
2.	Indication to the intermediaries of which E.164 numbers the
registration applies to, and 
3.	Detection of mismatched provisioning between the PBX and the SSP. 

The fourth thing, which no one has proposed, but which many detractors have
set up as a wholly bogus strawman, is using this information to provision
the PBX. No one wants that. No one has proposed that. We can stop arguing
against it because no one is defending it. We all agree that this is not
done in SIP.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2010 07:05:15 +0100

Hi, 

>[JRE] Wildcarded is still explicit - just a different syntax. 
>This assumes of course that the intention is to register 
>EVERY number in a wildcarded range (not just an implicit 
>subset that the SSP is expected to know in advance).

And, it applies to both AORs and contact? For example, do you consider the "bnc" mechanism in the gin draft as wildcarding?

Regards,

Christer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 18 Feb 2010 00:28:52 -0600

Speaking STRICTLY as a participant...

I think Bernard's suggestion is helpful in looking at (3) on Adam's list.

On (1) and (2) - 

- (1) doesn't actually make sense to me, because I'm reading it as saying "an SP AND a SIP-PBX might both be provisioned with one or more AoRs that COULD be registered successfully, but the SIP-PBX might choose not to register these AoRs". Is that what we're saying here? If so - why would the SIP-PBX need to do that?

- (2) if we're saying that provisioning AoRs at the SP AND at the SIP-PBX is required (and is out of scope for MARTINI - right?), I'm not sure why the additional effort to provision middleboxes with these AoRs justifies explicit signaling.

Please don't read either of these as a strong position against either justification - I don't understand why people are saying these things, and might just need educating...

Thanks,

Spencer
  ----- Original Message ----- 
  From: Bernard Aboba 
  To: 'Brian Lindsay' ; 'Adam Roach' ; 'Elwell, John' 
  Cc: 'Spencer Dawkins' ; 'Paul Kyzivat' ; 'MARTINI' 
  Sent: Wednesday, February 17, 2010 11:19 PM
  Subject: RE: [martini] DID Number Mobility and MARTINI

  Brian Lindsay said:

  "Regarding #3, detection of provisioning mismatches using the MARTINI mechanism would seem to be out of scope since the provisioning mechanism itself is out of scope. (why would we need the MARTINI mechanism to detect mismatches associated with an out of scope capability?)"

  [BA] In thinking of how we can consistently answer this and other questions about what should be in/out of scope for multiple AOR registration it might help to have some general principles to hang our hat on.   We've got a bunch of these questions to plow through between now and (ideally) yesterday, and we have had to put considerable effort into answering them one at a time.  

  One principle that might help us in answering a bunch of them at once is to ask whether a multiple AOR registration should provide similar functionality to many single AOR registrations.   The arguments for contact routing and support for many AOR/many contact explicit registration follow from this principle. 

  If we believe this (not sure that we do, but work with me)  then we can use it to answer questions about whether certain functionality should be in or out of scope.  

  For example, to answer the question "is detection of provisioning mismatches using multiple AOR registration out of scope?" we can ask the question "can many single AOR registrations provide for detection of provisioning mismatches?"   If you attempt to register an AOR with a conventional REGISTER that the SSP doesn't know about, you would get an error for that AOR, but not for other AORs that were registered successfully.  So that level of functionality is provided by REGISTER as defined in RFC 3261, and I believe that Dean has made a similar argument with respect to multiple AOR functionality. 

  From: Adam Roach [mailto:[email-masked]] 
  Sent: Wednesday, February 17, 2010 11:28 AM
  To: Elwell, John
  Cc: Spencer Dawkins; Lindsay, Brian (CAR:AR00); Paul Kyzivat; Bernard Aboba; MARTINI
  Subject: Re: [martini] DID Number Mobility and MARTINI

c) it doesn't matter which direction - either direction would be good enough so that at least one side is able to detect a discrepancy; or  
  I think you overspecified this option. I'm happy with the assertion that "it doesn't matter which direction," but the additional text implies that this is only being done for discrepancy detection.

  Which tells me that you aren't following the entire conversation. But you're clearly not the only one.

  There are at least three very different reasons people have raised (and a fourth, completely fallacious red herring that the opposition has been using as a strawman to tear apart) for including this information:

    1.. Specification, by the PBX, of the (sub)set of E.164 numbers it wants this registration to apply to, 
    2.. Indication to the intermediaries of which E.164 numbers the registration applies to, and 
    3.. Detection of mismatched provisioning between the PBX and the SSP. 
  The fourth thing, which no one has proposed, but which many detractors have set up as a wholly bogus strawman, is using this information to provision the PBX. No one wants that. No one has proposed that. We can stop arguing against it because no one is defending it. We all agree that this is not done in SIP.

  /a

---

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

> but the NOTIFY won't? What kind of magic is this?

The power of magical thinking and willful logic avoidance?

The underlying but unstated assumption behind the REGISTER-based
solution is that there is only one AOR (the identity of the PBX) and
only one Contact. The phone numbers are just provisioned aliases for the
PBX. Given this approach, one might as well adopt IMS in its entirety,
as they've already gotten this thought out. Except perhaps for some of
the subtleties of GRUU and Outbound, which AFAIK don't actually work in
this environment.

--
Dean

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2010 15:04:55 +0100

Hi, 

>>The REGISTER will be too big if we include a list of 
>>extensions in it, but the NOTIFY won't? What kind of magic is this?
>>
> 
>The underlying but unstated assumption behind the 
>REGISTER-based solution is that there is only one AOR (the 
>identity of the PBX) and only one Contact. The phone numbers 
>are just provisioned aliases for the PBX. Given this 
>approach, one might as well adopt IMS in its entirety, as 
>they've already gotten this thought out. Except perhaps for 
>some of the subtleties of GRUU and Outbound, which AFAIK 
>don't actually work in this environment.

Why don't you think Outbound will work?

Regards,

Christer

---

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

> But here the registration we are talking about is not the registration of the handset. It is the registration of the next step on the process of how to get to the handset / terminal. This it is usi…

Yes, BUT:

The registration using path and service-route still results in a "real
registration" wherein an AOR is bound to a Contact, and where a proxy
uses that binding for contact-routing of requests sent to the AOR. There
are a number of other AORs that are essentially aliases for the
registered AOR that are separately provisioned, but the core operation
of REGISTER is still being used.

Using REGISTER exclusively to insert a routing intermediate is something
entirely different. It's going to have all sorts of unfortunate
side-effects unless EVERYBODY (and I mean that literally) involved has a
clear understanding of the difference. And even then, it's going to
confuse a lot of people whi are trying to learn this already obfuscated
protocol.

--
dean

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Feb 2010 08:16:04 -0600

> My personal opinion is e), but I would like to hear other opinions, with reasons.

If the phone number is used in the R-URI of a request headed to the PBX,
and we have SBC-style intermediaries that block incoming requests for
unknown R-URIs, and we expect those intermediaries to learn about the
R-URIs during the REGISTER transaction, then we MUST include the full
list of possible R-URIs in at least one direction of the REGISTER
transaction.

That statement allows for several alternatives that could eliminate the
requirement. We could, for example, not have such SBCs (but people have
said we MUST support them). We could not use the phone number in the
R-URI (but we haven't agreed on a extension to the SIP routing model to
make this work). We could find some other mechanism than REGISTER for
informing the intermediaries (for example, force them to use reg-info,
which has even more severe size limitations).

But for now, we have what are in effect absolutely contradictory
requirements.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Feb 2010 08:23:02 -0600

> Sending a large request should not have that problem - you just use TCP to start with.

Intermediary proxies can switch between TCP and UDP at will. The only
mechanism we have that requires TLS all the way through is sips: (and
even that potentially breaks down depending on what you believe about
DTLS and sips:).

So, unless we have a Proxy-Require for this extension, and this
extension also forces uses of TCP, then we don't have a solution here.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Feb 2010 08:28:27 -0600

> When you say "explicit", do you exclude wildcarded values? Because, one may think that we don't need explicit, but still wildcarded, or one may think that we need neither.
Wildcards in the request/response are explicit. They're just a different
syntax that conveys the same literal meaning.

However, in what I've been calling "Shockey fragmentation" (since he
always brings it up), sufficiently complex number ranges receive little
or no benefit from wildcarding.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2010 15:31:15 +0100

Hi, 

>>But, in any case, when we talk about the message size, we 
>>need to be clear about if we talk about requests and 
>>responses. As we know, creatomg a response which is larger 
>>than the associated request can cause fragmentation problems 
>>if UDP was used.
>>
>Intermediary proxies can switch between TCP and UDP at will. 

Sure, but that is a generic SIP problem. There are other cases where you can get a response which is bigger than the request.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Feb 2010 09:31:52 -0500

Dean,

I don't follow you on this comment.

While intermediaries can indeed switch frm TCP to UDP, they can only do 
so if the request they are forwarding can be sent using UDP. If the 
intermediary receives a request over TCP that is too big to send via 
UDP, then it has no (conforming) choice but to forward it on via TCP.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Feb 2010 08:36:24 -0600

> Why don't you think Outbound will work?
It was not part of the repertoire at the time that 3GPP chose their
particular aliasing and registration model. It MIGHT work, but as far as
I know, hasn't been thought completely through, and given our track
record, I am not inclined to assume something like this is just going to
work.

Remember the "multiple simultaneous registrations with divergent paths"
part of Outbound?

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2010 15:38:31 +0100

Hi, 

>Wildcards in the request/response are explicit. They're just 
>a different syntax that conveys the same literal meaning.
> 
>However, in what I've been calling "Shockey fragmentation" 
>(since he always brings it up), sufficiently complex number 
>ranges receive little or no benefit from wildcarding.

Could someone give some input of what kind of complex number ranges we would expect? Are there cases where we would not be able to use wildcarding at all?

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Feb 2010 08:41:27 -0600

> Sure, but that is a generic SIP problem. There are other cases where you can get a response which is bigger than the request.

Right. And size is also a problem on requests. For oversized requests,
we have a mechanism for failing gracefully (BUT THE REQUEST STILL
FAILS!). For oversized responses, we can't even fail gracefully; about
all we can do is hope that the Overload provisions kick in and prevent a
cascading overload failure.

The response size flaw in SIP is something like having a chest wound
with lung penetration. As long as we keep a finger stuck in the wound,
the lung is unlikely to collapse. But it still hurts and is likely to
result in bleeding out. And we're starting to run out of fingers, so
perhaps we should stop shooting ourselves in the chest?

--
dean

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2010 15:42:00 +0100

Hi,

3GPP has adopted Outbound for their multiple registration mechanism.

Regards,

Christer 

> Sent: 18. helmikuuta 2010 16:36
> To: Christer Holmberg
> Cc: Adam Roach; Bernard Aboba; 'MARTINI'
> It was not part of the repertoire at the time that 3GPP chose 
> their particular aliasing and registration model. It MIGHT 
> work, but as far as I know, hasn't been thought completely 
> through, and given our track record, I am not inclined to 
> assume something like this is just going to work.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2010 15:46:12 +0100

>>Sure, but that is a generic SIP problem. There are other 
>>cases where you can get a response which is bigger than the request.
>>
>>   
> 
>Right. And size is also a problem on requests. For oversized 
>requests, we have a mechanism for failing gracefully (BUT THE 
>REQUEST STILL FAILS!). For oversized responses, we can't even 
>fail gracefully; about all we can do is hope that the 
>Overload provisions kick in and prevent a cascading overload failure.
> 
>The response size flaw in SIP is something like having a 
>chest wound with lung penetration. As long as we keep a 
>finger stuck in the wound, the lung is unlikely to collapse. 
>But it still hurts and is likely to result in bleeding out. 
>And we're starting to run out of fingers, so perhaps we 
>should stop shooting ourselves in the chest?

...or, we can just hope that people will configure their proxies so that things work :)

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Feb 2010 08:48:15 -0600

Paul Kyzivat wrote:
> While intermediaries can indeed switch frm TCP to UDP, they can only
> do so if the request they are forwarding can be sent using UDP. If the
The size-conforming node can also reject the oversized request. We have
a response code for that (413?). If  this happens, the request fails.
It's a "graceful fail" in that the sender is informed of the problem,
but it still fails.

>From a practical perspective, we cannot currently anticipate that TCP
will actually be available on every hop. Yes, the proxies have to
support it, but that doesn't mean it works with the current network
topology. We could certainly define an extension to require
bidirectional TCP (and discussed doing so back during the "diagnostic
response" discussion).

--
Dean

---

From: <[email-masked]>
Date: Thu, 18 Feb 2010 16:59:55 +0100

Hi John,

You almost wrote the text for such a requirement.

"An edge proxy shall be able to base identity assertions for outbound (non-REGISTER) requests received from a PBX on whether the identity concerned has been registered." 

Are you looking for a more formal comment on the requirements document?

Bruno

> Envoyé : mercredi 17 février 2010 18:05
> This depends whether we have a requirement for an edge proxy 
> to be able to base identity assertions for outbound 
> (non-REGISTER) requests on whether the identity concerned has 
> been registered. We don't have such a requirement at present, 
> so if you think we need such a requirement, please propose 
> text for the requirements document.
> 
> John
> 
> 
> > > Envoyé : mercredi 17 février 2010 14:37 À : CHATRAS Bruno 
> > > RD-CORE-ISS; [email-masked]; [email-masked]; 
> > > [email-masked]; [email-masked] Cc : 
> [email-masked]; 
> > > [email-masked] Objet : RE: [martini] DID Number Mobility and 
> > > MARTINI
> > >
> > > Bruno,
> > >
> > > information is because of an architecture where the proxy is 
> > > assigned responsibility for asserting an identity for the 
> source of 
> > > a request. If the domain proxy takes on this 
> responsibility instead, 
> > > problem solved. So it is a question of whether this particular 
> > > architecture is common enough that we need a solution 
> that conveys 
> > > registered identities to the edge proxy. IMS solves this 
> using PAU 
> > > (ignoring issues of response size), so the question for others is 
> > > whether there are other architectures in practice where this is 
> > > important. I guess for this particular usage it doesn't matter 
> > > whether the information is in the REGISTER request or the 
> REGISTER 
> > > response.
> > >
> > > John
> > >
> > >
> > > > > > > So, here's what I don't understand: 3GPP at least 
> defined a
> > > > > > procedure
> > > > > > >> But this horse is already out of the barn with 
> IMS implicit
> > > > > > > registration.
> > > > > > >>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 18 Feb 2010 10:19:14 -0600

Speaking as chair,

>> But, in any case, when we talk about the message size, we need to be 
>> clear about if we talk about requests and responses. As we know, creatomg 
>> a response which is larger than the associated request can cause 
>> fragmentation problems if UDP was used.
>>

I believe that I have seen general acceptance of Proxy-Require to support 
whatever MARTINI ends up with, if that's necessary, and I haven't seen 
anyone saying on-list that Proxy-Require is unacceptable.

Unless Bernard wants to drag me into a corner for a chair-to-chair meeting 
of the minds, I think we can declare that question closed, assume that we 
will have Proxy-Require for this extension if it is necessary, and move on 
to the next technical issue.

Thanks,

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 18 Feb 2010 10:44:05 -0600

Hi, Dean,

> list of possible R-URIs in at least one direction of the REGISTER

I sent a note last night to the list 
(http://www.ietf.org/mail-archive/web/martini/current/msg00765.html) that 
you might not have seen when you sent your note, and it included this text:

"- (2) if we're saying that provisioning AoRs at the SP AND at the SIP-PBX 
is required (and is out of scope for MARTINI - right?), I'm not sure why the 
additional effort to provision middleboxes with these AoRs justifies 
explicit signaling."

I sent that note as an individual, but I think it's now appropriate for me 
to ask, as co-chair, that someone explain why

- the SIP-PBX can't use MARTINI to provision the SP, AND

- the SP can't use MARTINI to provision the SIP-PBX, AND

- we have to explicitly include the list of AoRs in signaling because there 
are middleboxes that neither end can provision

Please note the "AND"s - I'm not asking for reasons why any one of these 
statements are true, I'm asking for reasons why all three statements are 
true.

... (brief pause to change hats)

Speaking as an individual (in the same e-mail as I have been speaking as 
co-chair - and that's always dangerous), I don't LIKE the idea that we have 
to provision each end of the REGISTER relationship independently, but I'm 
not seeing any danger that we can come to consensus on which end of the 
REGISTER relationship should always be provisioning the other end, so I 
think that's where we are - with two independent provisioning actions.

Given that we have two independent provisioning actions in the process now, 
I'm clueless as to why we can't include middlebox provisioning as part of 
the provisioning action on whichever end is in the same administrative 
domain as the middlebox, and (still speaking as an individual), I haven't 
seen anyone arguing that there will be middleboxes in a MARTINI SP/SIP-PBX 
REGISTER path that aren't controlled by the same administrative entity that 
controls at least one end of the path.

The chairs are in the process of declaring that we have consensus on using 
Proxy-Require if we need it, so saying that we expect people to stick an 
independent administrative domain in the middle of the path would change the 
dynamics of that discussion pretty drastically.

Speaking as an individual, I think this is a great time for anyone who is 
planning to make that argument, to make it.

Thanks,

Spencer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 18 Feb 2010 17:53:23 +0100

Bruno,

Yes, I thought that was what you were asking for. Let's see whether the WG agrees with that requirement. Comments?

John

> Sent: 18 February 2010 16:00
> "An edge proxy shall be able to base identity assertions for
> outbound (non-REGISTER) requests received from a PBX on
> whether the identity concerned has been registered."
>
> others is
> > > > > > > absence of static IP address configuration / DNS
> (hence the
> > > > > > ranges are
> > > > > > > >   I think it's been stated many times in the
> threads that
> > > > > > > E.164 number
> > > > > > >
> > > > > > > > and service provider. The registration is just
> being used
> > > > > > to provide
> > > > > > > > the original 3GPP implicit approach had an
> enumeration of
> > > > > > the AORs
> > > > > > > > "implicit with a list of AORs," we're proposing
> "implicit
> > > > > > with *no*
> > > > > > > > list of AORs."
> > > > > > > >
> > > > > > > > So, even if your assertion that our allowing
> the implicit
> > > > > > > mechanism to
> > > > > > >

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 18 Feb 2010 09:15:14 -0800

Spencer said:

" I sent that note as an individual, but I think it's now appropriate for me

true."

[BA] And while we're asking for that explanation, I'd also like to
understand
what assumptions we are making about the middleboxes in question.  For
example:

a. Is there an assumption that the middlebox wouldn't be updated to support
MARTINI?
b. If it could be updated, is there an assumption about what kinds of
information the middle box can understand/parse?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2010 18:55:09 +0100

Hi,

>as they've already gotten this thought out.

Yes, one might. There is nothing wrong with adopting an existing solution.

People have been talking about the "bad history of implicit". I may have missed something, but I am not really sure what that "bad history" is...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Feb 2010 19:05:53 +0100

Hi,

I think that is a good requirement.

It doesn't necessarily mean that the functionality needs be enabled at all time, in all deployments (as someone said, the assertion can also be done by the registrar, or by some other entity), but I think it would be very good if the solution would provide such functionality.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Elwell, John [[email-masked]]
Sent: Thursday, February 18, 2010 6:53 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] DID Number Mobility and MARTINI

Bruno,

John

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Thu, 18 Feb 2010 13:12:42 -0500

+1, agree with the requirement

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, February 18, 2010 11:53 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] DID Number Mobility and MARTINI

Bruno,

John

---

From: "Brian Lindsay" <[email-masked]>
Date: Thu, 18 Feb 2010 14:08:15 -0500

Hi Bruno,

  I'm just curious about this works for cases where SIP PBXs don't actually register (e.g. have a static IP address, DNS is used, etc).

  Thanks
     Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 18, 2010 11:00 AM
To: [email-masked]; [email-masked]; Lindsay, Brian (CAR:AR00); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [martini] DID Number Mobility and MARTINI

Hi John,

Bruno

> Envoyé : mercredi 17 février 2010 18:05 À : CHATRAS Bruno RD-CORE-ISS; 
> [email-masked] Cc : [email-masked]; [email-masked] 
> This depends whether we have a requirement for an edge proxy to be 
> able to base identity assertions for outbound
> (non-REGISTER) requests on whether the identity concerned has been 
> registered. We don't have such a requirement at present, so if you 
> think we need such a requirement, please propose text for the 
> requirements document.
> 
> John
> 
> 
> > > > ********************************* This message and any 
> > > > attachments (the "message") are
> > > confidential and

---

From: <[email-masked]>
Date: Thu, 18 Feb 2010 20:17:17 +0100

In this case you need a work-around of course... One option consists in inserting an adaptor between the PBX and  the edge proxy. The adaptor sneds the REGISTER request on behalf of the PBX. Another option consists in sending an O&M command to the edge proxy that triggers the sending a REGISTER request with appropriate parameters to the registrar...

> De : Brian Lindsay [mailto:[email-masked]] 
> Envoyé : jeudi 18 février 2010 20:08
> À : CHATRAS Bruno RD-CORE-ISS; 
> [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
>   I'm just curious about this works for cases where SIP PBXs 
> don't actually register (e.g. have a static IP address, DNS 
> is used, etc).
> 
>   Thanks
>      Brian
> 
> To: [email-masked]; 
> [email-masked]; Lindsay, Brian (CAR:AR00);

---

From: "Brian Lindsay" <[email-masked]>
Date: Thu, 18 Feb 2010 15:16:41 -0500

Hi Bruno,

   Thanks. So there are cases where edge proxies perform a surrogate registration.

   I was wondering about cases where the "core" network itself isn't using a registration-based approach for a SIP PBX, but just uses a static IP or dns for routing towards the SIP PBX. 

   How do edge proxies operate in that context? Would they still manage identify assertion and would they they typically be provisioned with address info to do so? Just wondering what the existing baseline solutions are for this.

   Thanks
     Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 18, 2010 2:17 PM
To: Lindsay, Brian (CAR:AR00); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [martini] DID Number Mobility and MARTINI

> De : Brian Lindsay [mailto:[email-masked]] Envoyé : jeudi 18 
> février 2010 20:08 À : CHATRAS Bruno RD-CORE-ISS; 
> [email-masked]; [email-masked]; [email-masked] Cc : 
> [email-masked]; [email-masked] Objet : RE: [martini] DID 
> Number Mobility and MARTINI
> 
> Hi Bruno,
> 
>   I'm just curious about this works for cases where SIP PBXs don't 
> actually register (e.g. have a static IP address, DNS is used, etc).
> 
>   Thanks
>      Brian
> 
> "An edge proxy shall be able to base identity assertions for outbound 
> (non-REGISTER) requests received from a PBX on whether the identity 
> concerned has been registered."
>

---

From: <[email-masked]>
Date: Thu, 18 Feb 2010 21:27:15 +0100

This sounds like you are referring to what ETSI calls the "peering-based" approach. In this case the edge proxy does not assert identities. It receives a P-Asserted-Identity header field from the PBX rather than a P-Preferred-Identity. The SSP has to trust the enterprise network.

> Envoyé : jeudi 18 février 2010 21:17
>    I was wondering about cases where the "core" network 
> itself isn't using a registration-based approach for a SIP 
> PBX, but just uses a static IP or dns for routing towards the 
> SIP PBX. 
> 
>    How do edge proxies operate in that context? Would they 
> still manage identify assertion and would they they typically 
> be provisioned with address info to do so? Just wondering 
> what the existing baseline solutions are for this.
> 
>    Thanks
>      Brian
> 
> To: Lindsay, Brian (CAR:AR00); 
> In this case you need a work-around of course... One option 
> consists in inserting an adaptor between the PBX and  the 
> edge proxy. The adaptor sneds the REGISTER request on behalf 
> of the PBX. Another option consists in sending an O&M command 
> to the edge proxy that triggers the sending a REGISTER 
> request with appropriate parameters to the registrar...
> 
> > > > > > > > Speaking carefully as chair, and Bernard can 
> correct me if
> > > > > > > I am saying
> > > > > > > > is - we only get to recognize what consensus 
> is, and when
> > > > > > it exists.
> > > > > > > > For that, we
> > > > > > > > It was more like "I expect these numbers to be 
> registered"
> > > > > > > and/or "I
> > > > > > > > At least, that's the context in which I was 
> reading Adam's
> > > > > > > note below.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Spencer
> > > > > > > >
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > provisioning between the enterprise and 
> service provider
> > > > > > > is out of
> > > > > > > > > perform any syncronization on these numbers 
> betweeen the
> > > > > > > enterprise
> > > > > > > > > routed to the SIP PBX. As such, I don't think 
> the number
> > > > > > > ranges need
> > > > > > > > > -- through a questionable use of 
> P-Associated-URI -- to
> > > > > > > > indicate which
> > > > > > > >
> > > > > > > > > URIs the registrar would be registering on 
> behalf of the
> > > > > > > > user. So even
> > > > > > > >
> > > > > > > > > We're proposing to be even more sparse than 
> that. Rather
> > > > > > > than just
> > > > > > > > >> it like P-Asserted-ID and P-Associated-URI 
> were. While
> > > > > > > we could say
> > > > > > > > >>>> Speaking as co-chair, the non-registration 
> aspects of
> > > > > > > DID number
> > > > > > > > >>>> mobility are outside the scope of the 
> current MARTINI
> > > > > > > WG charter.
> > > > > > > > >>>>
> > > > > > > > >>> I'm OKAY with extending REGISTER to bind 
> multiple AORs
> > > > > > > to multiple
> > > > > > > > >>> the history of REGISTERs explicit encoding 
> of the AORs
> > > > > > > > and Contacts
> > > > > > > > >>> involved.
> > > > > > > > >>>
> > > > > > > > >>>  From a requirements perspective, I'd be 
> happy with a
> > > > > > > requirement

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Feb 2010 16:11:06 -0500

Why would using DNS rather than registration have anything to do with 
trust, or lack of trust, in the PBX? Registration is not the only form 
of authentication.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 18 Feb 2010 16:01:36 -0600

On 2/18/10 10:44, Feb 18, Spencer Dawkins wrote:
> I sent that note as an individual, but I think it's now appropriate 
> for me to ask, as co-chair, that someone explain why
>

I can't even begin to get a grip on your questions. MARTINI isn't about 
provisioning.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 18 Feb 2010 17:35:19 -0600

On 2/18/10 00:28, Feb 18, Spencer Dawkins wrote:
> - (2) if we're saying that provisioning AoRs at the SP AND at the 
> SIP-PBX is required (and is out of scope for MARTINI - right?), I'm 
> not sure why the additional effort to provision middleboxes with these 
> AoRs justifies explicit signaling.
>

Registration state and provisioning are very different things. Many 
middleboxes do track registration state.

And middleboxes that track registration state need to track registration 
state to function properly. I'm sure they wouldn't be doing it 
otherwise, since it's not a particularly cheap operation.

And part of normal registration state includes the AOR involved in the 
registration.

Once you're registering multiple AORs in a single registration, it's 
pretty clear that the registration state includes all of those AORs.

So the middleboxes will want to know about them.

We can certainly engage in a discussion around whether it makes more 
sense to provision all the extensions into the middleboxes, but that 
seems exceedingly operationally expensive. And if we were willing to 
absorb the cost of additional operational expenses due to provisioning, 
the answer would be "provision the PBX IP address into the SSP and be 
done with it" instead of doing all this MARTINI work.

/a

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 18 Feb 2010 15:47:03 -0800

Adam Roach said: 

"Once you're registering multiple AORs in a single registration, it's pretty
clear that the registration state includes all of those AORs.

So the middleboxes will want to know about them."

[BA] I'm curious to understand exactly what the middleboxes need to know and
in what situations.  After all, there are SSPs out there doing RFC 3263
domain routing without MARTINI, and presumably the middleboxes aren't a
problem in that scenario.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 18 Feb 2010 18:22:10 -0600

Hi, Adam,

>> I sent that note as an individual, but I think it's now appropriate for 
>> me to ask, as co-chair, that someone explain why
>>

I may not have been clear enough - my point was that MARTINI isn't about 
provisioning either end, so that's happening some other way on both ends, so 
why would we suddenly we need explicit lists so that the middlebox can 
figure out what's going on - that's what I wasn't understanding.

Thanks,

Spencer

---

From: Dean Willis <[email-masked]>
Date: Fri, 19 Feb 2010 00:03:18 -0600

Spencer Dawkins wrote:
> ...

> "- (2) if we're saying that provisioning AoRs at the SP AND at the
> AoRs justifies explicit signaling."
>
> - we have to explicitly include the list of AoRs in signaling because
> there are middleboxes that neither end can provision
>

Because "provision", in bellheadspeak, is either an arcane swearword or
a description of the most complex, highly-regulated, and frequently
audited process of the entire operations world, and is supported by the
most expensive single software system in a service provider environment.
It is generally easier to obtain revisions to the great holy books of
any major religion than it is to change a provisioning system.

If Social Security is the third rail of American politics (referring to
that part of an electric train track that will electrocute you if
touched), the provisioning is the third rail of service provider
politics. Congratulations, you've just been electrocuted.

Dynamic binding and "gate unlocking" are therefore NOT provisioning.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 19 Feb 2010 00:12:44 -0600

> trust, or lack of trust, in the PBX? Registration is not the only form
Registration is the only authenticated exchange in classic IMS. This
"mistake" (as I railed against it muchly at the time) has consequences
like only being able to trust-anchor in a REGISTER transaction, or have
to rely on entirely contractual trust anchoring. Oddly enough, the
problem was derived from the method name REGISTER, which sounded  too
much like "registration" in a GSM system and was consequently forced to
function the same way. If we had called the method SETCONTACT to start
with, everything would be different today.

This also gets back to Christer's question about the negativity of our
experience with implicit invocations.  Other things that might be
pointed out are implicit subscriptions on REFER (giving us norefersub as
a needed extension), implicit terminations (requiring regevent in IMS),
the nightmare of implicit bandwidth gating in the early PacketCable
work, and many more that I'm just too tired of to keep in my head.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 19 Feb 2010 00:18:47 -0600

Bernard Aboba wrote:
>
> *Adam Roach said: *
>
>
> “Once you're registering multiple AORs in a single registration, it's
> So the middleboxes will want to know about them.”
>
> *[BA] I’m curious to understand exactly what the middleboxes need to
> know and in what situations. After all, there are SSPs out there doing
> RFC 3263 domain routing without MARTINI, and presumably the
> middleboxes aren’t a problem in that scenario. ***
>
The middleboxes will block any request message sent towards the PBX that
contains a Request-URI which does not match a Contact seen in a current
registration by that middlebox. In other words, if the middlebox hasn't
seen a REGISTER for that URI, it blocks all requests being sent to that URI.

Envision, if you will, a spam control mechanism that only allows your
email server to receive SMTP messages for a given email address if, in
the preceding few seconds, your email server had POPed messages that
were to that same email address.

It's an absolutely barbaric thing for a middlebox to do, but some people
would rather do stuff like this than use real identity mechanisms. Go
figure.

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Feb 2010 00:49:08 -0600

I should probably stop posting (as an individual) in this thread, but ...

> Dynamic binding and "gate unlocking" are therefore NOT provisioning.

I'm trying to tug at the reaons that people have suggested sending lists of 
AoRs explicitly in signaling, and "indication of what AoRs were being 
registered to intermediate devices" was on the list of reasons that Adam 
thoughtfully provided in 
http://www.ietf.org/mail-archive/web/martini/current/msg00757.html.

What I'm trying to ask, perhaps not using helpful terminology, is why 
middleboxes that I believe are under the same administrative control as 
either the SP or the SIP-PBX, need to be treated differently than we're 
treating the SP and the SIP-PBX in MARTINI.

I tried to be clear that MARTINI wasn't provisioning in my post at 
http://www.ietf.org/mail-archive/web/martini/current/msg00783.html, but you 
may be correct that the word "provisioning" is so poisonous that I can't use 
it in a sentence that people can parse. If that's true, I apologise for 
using the word.

But ... my understanding is that, by some process that is out of scope for 
MARTINI, the SP and the SIP-PBX both automagically know, without either 
telling the other, what AoRs would be registered, and I'm asking, if the 
middlebox is either in the same administrative domain as the SP, or in the 
same administrative domain name as the SIP-PBX, why we can't/shouldn't make 
the same assumption for middleboxes that we're already making for the SP and 
for the SIP-PBX - that they will automagically know what AoRs are being 
MARTINI-REGISTERed as well.

Does that sound like a different question, that might be useful for people 
to respond to?

Thanks,

Spencer

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Feb 2010 08:48:13 +0100

During the flurry of messages late yesterday I detected a lack of synch between some participants. I think Adam made it clear that what we should be discussing is whether middleboxes need to know the registration state (not provisioning) of AORs, so we should focus on this need. 

I would like to try to understand why these middleboxes need knowledge of the registration state of individual AORs, if at all. I think there have been arguments that they need some state in order to route inbound requests to the PBX. There have also been arguments that they need state in order to assert identities for outbound requests. Are there any other reasons for middleboxes needing knowledge of the registration state of individual AORs? (Forgive me if I have forgotten something already posted.)

The GIN draft does indeed provide a mechanism whereby the middlebox gains this state knowledge. If there is consensus this is needed, or might be needed in some reasonable circumstances, we should probably go along with something similar to what is in the GIN draft. On the other hand, I am hearing some people opposed to putting in functionality that they believe to be unnecessary, so those arguing for having this functionality need to argue more convincingly.

John

> Sent: 19 February 2010 06:49
> To: Dean Willis
> Cc: Elwell, John; Brian Lindsay; Adam Roach; Paul Kyzivat; 
> Bernard Aboba; MARTINI

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Feb 2010 09:05:17 +0100

I think one of the arguments I have heard (although I may have misunderstood) for middleboxes needing to know registration state of individual AORs registered by a PBX is to enable the routing of inbound requests to the PBX.

It can be argued that, certainly when sip-outbound is used, the middlebox needs to maintain state in order to route inbound requests to the PBX, although it can achieve this by means of a cookie sent to the domain proxy/registrar. This needs to identify the 'flow', so that the inbound request can be delivered over that same TCP connection or UDP path. However, even though multiple AORs are  registered by the same REGISTER request, the same 'flow' will apply to all registrations, so I don't believe the middlebox needs knowledge of individual registrations. The rest of the information needed is in the inbound request.

When outbound is not used, the middlebox should just be able to route on what is in the Request-URI or Route header field (depending on the particular solution we adopt). I don't see why it needs knowledge of individual registrations.

So what are the particular reasons, if any, that knowledge of individual registrations is needed in order for a middlebox to route inbound requests to a PBX?

John

---

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

(Subject changed)
The answer is to use P-Asserted-Identity also for the MARTINI case. I don't think we should bring the subject of Trust Domains and PAI versus PPI into the MARTINI discussions - these are orthogonal issues.

John

> Sent: 18 February 2010 20:27
> To: [email-masked]; Elwell, John;
> This sounds like you are referring to what ETSI calls the
> "peering-based" approach. In this case the edge proxy does
> not assert identities. It receives a P-Asserted-Identity
> header field from the PBX rather than a P-Preferred-Identity.
> The SSP has to trust the enterprise network.
>
> [email-masked];
> > > > > > De : Elwell, John
> [mailto:[email-masked]]
> > > > > > > > numbers and/or contacts (I won't try to tie
> down which at
> > > > > > present),
> > > > > > > > in, because that will go some way towards
> determining the
> > > > > > mechanism.
> > > > > > > > Do people think:
> > > > > > > >
> > > > > > > > > the REGISTER exchange does not provide this
> information,
> > > > > > > but people
> > > > > > > > > intended to provide reachability information
> for the SIP
> > > > > > > > PBX, in the
> > > > > > > > > > reachability info, to allow requests to a
> set of E.164
> > > > > > > > numbers to be
> > > > > > > > > > to be part of the registration transaction.
> It'll just
> > > > > > > add extra
> > > > > > > > > > stand is somehow tacit approval, what's
> being proposed
> > > > > > > > here is even
> > > > > > > > > > one step more nebulous.
> > > > > > > > > >
> > > > > > > > > > /a
> > > > > > > > > >
> > > > > > > > > >>> Contacts. This seems like a reasonable
> extension to
> > > > > > > > simplify life
> > > > > > > > > >>> for
> > > > > > > > > >
> > > > > > > > > >>> a "multi user" SIP user agent. But I
> really think we
> > > > > > > > > should respect
> > > > > > > > > >>> along the lines of  "must not preclude
> AOR mobility
> > > > > > > > > indicated by the
> > > > > > > > >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Feb 2010 09:24:13 +0100

(Subject changed)
Dean, you are arguing that some middleboxes need to know registration state so that they can match a Request-URI in an inbound request with a known registered contact URI and block requests where there is no match.

I would argue that an SSP would not use such a middlebox if it wanted to offer a MARTINI interface to PBXs. As you say, it is broken. I would argue that we should not try to accommodate such broken middleboxes.

However, if the WG feels there is a need, we would need to introduce a new requirement along the lines of "An edge proxy MUST be able to filter inbound requests to a PBX on the basis of whether or not they are addressed to currently registered contact URIs".

John

> Sent: 19 February 2010 06:19
> To: Bernard Aboba
> Cc: 'MARTINI'
> > "Once you're registering multiple AORs in a single 
> registration, it's
> > *[BA] I'm curious to understand exactly what the middleboxes need to
> > middleboxes aren't a problem in that scenario. ***
> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Feb 2010 11:03:31 +0100

>It is generally easier to obtain revisions to the great holy 
>books of any major religion than it is to change a 
>provisioning system.

Do you include RFC 3261 in that list of holy books? ;)

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Feb 2010 11:09:43 +0100

Hi, 

>>trust, or lack of trust, in the PBX? Registration is not 
>>the only form of authentication.
>>
>Registration is the only authenticated exchange in classic 
>IMS. This "mistake" (as I railed against it muchly at the 
>time) has consequences like only being able to trust-anchor 
>in a REGISTER transaction, or have to rely on entirely 
>contractual trust anchoring. Oddly enough, the problem was 
>derived from the method name REGISTER, which sounded  too 
>much like "registration" in a GSM system and was consequently 
>forced to function the same way. If we had called the method 
>SETCONTACT to start with, everything would be different today.
> 
>This also gets back to Christer's question about the 
>negativity of our experience with implicit invocations.  
>Other things that might be pointed out are implicit 
>subscriptions on REFER (giving us norefersub as a needed 
>extension), implicit terminations (requiring regevent in 
>IMS), the nightmare of implicit bandwidth gating in the early 
>PacketCable work, and many more that I'm just too tired of to 
>keep in my head.

I am not familiar with all the things listed above, but to me they sound a little different than implicit registrations.

When implicit registrations occur, you get a list of what has been registered implicitly. You don't need to "assume" something has happended in the network, and there are no additional "embedded" SIP actions (subscriptions etc) taking place.

Regarding REFER, I don't think implicit subscriptions as such is the problem. The problem is that we didn't include norefersub from the beginning.

Regards,

Christer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Feb 2010 08:11:03 -0600

Hi, John,

Speaking as co-chair, thanks for framing the question in this manner. This 
was helpful.

Spencer

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Dean Willis" 
<[email-masked]>
Cc: "Brian Lindsay" <[email-masked]>; "Adam Roach" <[email-masked]>; 
"Paul Kyzivat" <[email-masked]>; "Bernard Aboba" 
<[email-masked]>; "MARTINI" <[email-masked]>
Sent: Friday, February 19, 2010 1:48 AM
Subject: Middlebox needs (was RE: [martini] DID Number Mobility and MARTINI)

During the flurry of messages late yesterday I detected a lack of synch 
between some participants. I think Adam made it clear that what we should be 
discussing is whether middleboxes need to know the registration state (not 
provisioning) of AORs, so we should focus on this need.

I would like to try to understand why these middleboxes need knowledge of 
the registration state of individual AORs, if at all. I think there have 
been arguments that they need some state in order to route inbound requests 
to the PBX. There have also been arguments that they need state in order to 
assert identities for outbound requests. Are there any other reasons for 
middleboxes needing knowledge of the registration state of individual AORs? 
(Forgive me if I have forgotten something already posted.)

The GIN draft does indeed provide a mechanism whereby the middlebox gains 
this state knowledge. If there is consensus this is needed, or might be 
needed in some reasonable circumstances, we should probably go along with 
something similar to what is in the GIN draft. On the other hand, I am 
hearing some people opposed to putting in functionality that they believe to 
be unnecessary, so those arguing for having this functionality need to argue 
more convincingly.

John

> =

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Feb 2010 08:19:47 -0600

Hi, John,

Again, I think your posting below was helpful.

If I am understanding correctly, I saw some discussion asking "how would a 
middlebox do this for a SIP-PBX that was using RFC 3263 routing to/from the 
SP, so that the middlebox would not be aware of registration state for the 
AORs that UAs inside the enterprise REGISTER with the SIP-PBX?"

If I am understanding correctly, I'd like to include this as part of John's 
request for feedback that started this thread.

Thank you,

Spencer

>I think one of the arguments I have heard (although I may have 
>misunderstood) for middleboxes needing to know registration state of 
>individual AORs registered by a PBX is to enable the routing of inbound 
>requests to the PBX.
>
> It can be argued that, certainly when sip-outbound is used, the middlebox 
> needs to maintain state in order to route inbound requests to the PBX, 
> although it can achieve this by means of a cookie sent to the domain 
> proxy/registrar. This needs to identify the 'flow', so that the inbound 
> request can be delivered over that same TCP connection or UDP path. 
> However, even though multiple AORs are  registered by the same REGISTER 
> request, the same 'flow' will apply to all registrations, so I don't 
> believe the middlebox needs knowledge of individual registrations. The 
> rest of the information needed is in the inbound request.
>
> When outbound is not used, the middlebox should just be able to route on 
> what is in the Request-URI or Route header field (depending on the 
> particular solution we adopt). I don't see why it needs knowledge of 
> individual registrations.
>
> So what are the particular reasons, if any, that knowledge of individual 
> registrations is needed in order for a middlebox to route inbound requests 
> to a PBX?
>
> John

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Feb 2010 08:20:41 -0600

Hi, Adam,

Speaking as co-chair, this was a helpful clarification. Thank you for the post.

Spencer
  ----- Original Message ----- 
  From: Adam Roach 
  To: Spencer Dawkins 
  Cc: Bernard Aboba ; 'Brian Lindsay' ; 'Elwell, John' ; 'Paul Kyzivat' ; 'MARTINI' 
  Sent: Thursday, February 18, 2010 5:35 PM
  Subject: Re: [martini] DID Number Mobility and MARTINI

  Registration state and provisioning are very different things. Many middleboxes do track registration state.

  And middleboxes that track registration state need to track registration state to function properly. I'm sure they wouldn't be doing it otherwise, since it's not a particularly cheap operation.

  And part of normal registration state includes the AOR involved in the registration.

  Once you're registering multiple AORs in a single registration, it's pretty clear that the registration state includes all of those AORs.

  We can certainly engage in a discussion around whether it makes more sense to provision all the extensions into the middleboxes, but that seems exceedingly operationally expensive. And if we were willing to absorb the cost of additional operational expenses due to provisioning, the answer would be "provision the PBX IP address into the SSP and be done with it" instead of doing all this MARTINI work.

  /a

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Feb 2010 16:01:31 +0100

Spencer,

I thought that question arose in the context of a middlebox asserting identity for outbound requests, not in the context of inbound requests, but I may have missed something.

John 

> Sent: 19 February 2010 14:20
> To: Elwell, John; MARTINI
> Subject: Re: [martini] Middlebox needs - routing inbound requests
> 
> Hi, John,
>

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 19 Feb 2010 10:10:50 -0500

Dean is absolutely correct here. Which is why we can't go there.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Feb 2010 09:18:47 -0600

Speaking as individual,

As always, I apologize for mischaracterizing the discussion.

I am still curious about the question on middlebox filtering based on 
awareness of registration state that I raised - perhaps the previous 
discussion just got me thinking about another topic ...

Are we saying that middleboxes do this filtering for you if you REGISTER, 
but stop doing it if you get your own domain and start using RFC 3263?

Thanks,

Spencer

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "MARTINI" 
<[email-masked]>
Sent: Friday, February 19, 2010 9:01 AM
Subject: RE: [martini] Middlebox needs - routing inbound requests

Spencer,

I thought that question arose in the context of a middlebox asserting 
identity for outbound requests, not in the context of inbound requests, but 
I may have missed something.

John

---

From: "Jack Burton" <[email-masked]>
Date: Fri, 19 Feb 2010 11:22:21 -0500

No, the way our middle-boxes work does not require knowledge of implicitly registered entities behind the PBX.
 
While the PBX is registered, any methods originating from it's IP address are considered registered.
 
It is up to the SP's elements to decide whether a DID number presented on an outbound call is within the customer's authorized ranges, and could:
1) complete the call, passing information as-is
2) complete the call, changing information to the customer's main number
3) reject the call
 
All of this would seem to be out-of-scope to me.  Implicit registration should (and does) work fine through our SBCs.
 
-Jack

>>> "Spencer Dawkins" <[email-masked]> 2/19/2010 10:18 >>>
Speaking as individual,

Thanks,

Spencer

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "MARTINI" 
<[email-masked]>

Spencer,

John

-------------------------------------------------------- 
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright.   Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful.  If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.
--------------------------------------------------------

---

From: Dean Willis <[email-masked]>
Date: Sat, 20 Feb 2010 01:11:25 -0600

Spencer Dawkins wrote:
> middleboxes that I believe are under the same administrative control
> as either the SP or the SIP-PBX, need to be treated differently than
> we're treating the SP and the SIP-PBX in MARTINI.
Here's the argument everybody is thinking but unwilling to say out loud.
I'm not sure I believe it, but there may be more truth to it than Senior
Management believes.

The middleboxes are only nominally under the same administrative control
as either SSP or OBX. In practice, they're run by either the service
provider or the corporate security department according to "industry
best practices". This means that the telecom people have almost no
influence on how they get operated. Neither the corporate nor service
provider provisioning systems are tied into them, change control
requires bribing, suborning, or outmanuevering somebody who thinks that
their alleged security expertise puts them above practical
considerations like "making the system work right", and in actuality
nobody understands how the damned middlebox works or what its supposed
to do. It just squats there doing its thing blindly, like a cross
between the zodiacal Libra and a turnpike tollbooth.

Think how much control the average homeowner has over their NAT-router,
and that's about how much control is exercised over the middleboxes.
Once the basic setup is done, usually by a vendor sales engineer, the
middlebox basically has to learn everything it needs to work by watching
the signaling go by because nobody knows how to tell it how to do
anything more useful.

> http://www.ietf.org/mail-archive/web/martini/current/msg00783.html,
> but you may be correct that the word "provisioning" is so poisonous
> that I can't use it in a sentence that people can parse. If that's
> true, I apologise for using the word.

accepted!
>
> But ... my understanding is that, by some process that is out of scope
> for MARTINI, the SP and the SIP-PBX both automagically know, without
> either telling the other, what AoRs would be registered, and I'm
> asking, if the middlebox is either in the same administrative domain
> as the SP, or in the same administrative domain name as the SIP-PBX,
> why we can't/shouldn't make the same assumption for middleboxes that
> we're already making for the SP and for the SIP-PBX - that they will
> automagically know what AoRs are being MARTINI-REGISTERed as well.
>
The argument basically says that the SSP and the PBX automagically know
because either a telecom guy at PBX or one at SSP (depending on which
order fulfillment model you believe in) is feeding stuff into the System
That Controls Everything Except The Middleboxes. However, the
middleboxes, like mushrooms, are kept totally in the dark, and subsist
only on the effluent passing by them in the currents of signaling.
Imagine the coral reefs that divide the lagoon from the open ocean, and
the only way through the reef is to be consumed and digested by the
coral, then excreted on the other side.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 20 Feb 2010 01:16:40 -0600

> Dean, you are arguing that some middleboxes need to know registration state so that they can match a Request-URI in an inbound request with a known registered contact URI and block requests where t…

Yep. They may also perform the same blocking on outbound requests; it
depends on whether the middlebox is protecting the service provider or
the enterprise (or very rarely, both).

> I would argue that an SSP would not use such a middlebox if it wanted to offer a MARTINI interface to PBXs. As you say, it is broken. I would argue that we should not try to accommodate such broken…

I'd think so too, but apparently people keep deploying the things.
> However, if the WG feels there is a need, we would need to introduce a new requirement along the lines of "An edge proxy MUST be able to filter inbound requests to a PBX on the basis of whether or…

That is exactly the correct question, if you strike the words "inbound"
and "to a PBX", and add "or from currently registered contact URIs, or
AORs to which a sending Contact is currently registered".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 20 Feb 2010 01:17:49 -0600

> Do you include RFC 3261 in that list of holy books? ;)

Of course! I've been trying to change it for years, but the priesthood
keeps blocking!

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 20 Feb 2010 01:27:30 -0600

Spencer Dawkins wrote:
>
> Are we saying that middleboxes do this filtering for you if you
> REGISTER, but stop doing it if you get your own domain and start using
> RFC 3263?

Getting your own domain and using RFC 3263 is hard because it requires
you to stop using those expensive middleboxes that somebody sold your
security department, and the middlebox vendor's sales team is in tight
with your CFO. AFAIK, the sipconnect work therefore assumes that most
PBXes will have to REGISTER with their SSP.

Seriously, people use the middleboxes in large part because they take
away the responsibility of running your VoIP system the "right way". 
Running a system is fairly hard, people are lazy, and it's easier to
punt and assume the middlebox knows what it's doing. Since the middlebox
isn't tied into anybody's provisioning system (because that would be
even harder!), the middlebox has to learn everything by watching
signaling go past.

I believe this in large part explains the lack of real sips: deployments
-- the people running the middleboxes can't handle the key management
needed to allow the middlebox to do its job by back-dooring the security
infrastructure.

--
Dean

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 20 Feb 2010 08:32:18 -0600

Just a small clarification here...

> PBXes will have to REGISTER with their SSP.

(speaking as SIPconnect 1.1 editor)

The current draft of SIPconnect 1.1 has two modes of operation - one using 
RFC 3263 for call routing, and one currently stalled waiting on MARTINI 
registration for call routing. Only the latter mode of operation makes that 
assumption - but it does make that assumption.

Thanks,

Spencer

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 20 Feb 2010 10:14:43 -0500

Dean ...like DUH here! Does this actually surprise you? As I think we have
understood 99.967 percent of SIP PBX installations use phone numbers. Your
vets office, hair salon and auto body shop really doesn't care about key
management, middle boxes and probably will never use a SIP URI on the side
of their trucks.

The ultimate customer here wants nice simple dial tone with no hassles. Some
nice CLEC or MSO came to the business owner with a offer.. new phones, HD TV
for the waiting room, Internet WIFI etal and probably real customer support
for a price that was probably lower than his PRI voice only service. "Press
hard you are making three copies..the installation team will be there
Thursday." 

Sure there are some business case assumptions in why MARTINI is scoped the
way it is but it is a feature not a bug. As for the reasons for the lack of
SIPS deployments, there is a simpler answer. No one cares other than the
govt. In the vast majority of SIP trunking installations SSP also is
controlling the Layer 1 circuit which is why I hear the "Why do I need TLS?"
question all the time. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean Willis
Sent: Saturday, February 20, 2010 2:28 AM
To: Spencer Dawkins
Cc: MARTINI
Subject: Re: [martini] Middlebox needs - routing inbound requests

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Feb 2010 10:16:22 -0500

Dean Willis wrote:

> However, the

Dean,

I don't know how you keep coming up with such apt imagery, but you do.
This is some of the best in awhile!

I think somebody should publish a supplement to Bartlett's Familiar 
Quotations dedicated to you.

	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 06:21:54 +0100

The coral reefs are disapearing because of all the crap in the oceans.
The middleboxes are deployed because of all the crap on the internet.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 20. helmikuuta 2010 17:16
To: Dean Willis
Cc: MARTINI; Bernard Aboba
Subject: Re: [martini] DID Number Mobility and MARTINI

> Imagine the coral reefs that divide the lagoon from the open ocean, 
> and the only way through the reef is to be consumed and digested by 
> the coral, then excreted on the other side.

Dean,

I think somebody should publish a supplement to Bartlett's Familiar Quotations dedicated to you.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Feb 2010 10:26:51 +0100

Dean,

I don't agree with a requirement for supporting the admission of outbound requests based on whether the caller has registered. This would prevent, for example, a call from A to B being forwarded to C via the SSP, where A is not one of the registered AORs at this particular PBX (unless you do horrible things that I don't think we want to condone, like pretending the caller is B, who is registered).

If you want to pursue the question of being able to support admitting both inbound requests and outbound requests on the basis of the current registration state of the AOR, I think we should consider these as separate issues. Do you want to raise issues on the tracker for one or both of these?

John

> Sent: 20 February 2010 07:17
> To: Elwell, John
> Subject: Re: Middlebox needs - admitting inbound requests
> 
> Elwell, John wrote:
> > (Subject changed)
> > Dean, you are arguing that some middleboxes need to know 
> registration state so that they can match a Request-URI in an 
> inbound request with a known registered contact URI and block 
> requests where there is no match.
> >   
> 
> > I would argue that an SSP would not use such a middlebox if 
> it wanted to offer a MARTINI interface to PBXs. As you say, 
> it is broken. I would argue that we should not try to 
> accommodate such broken middleboxes.
> >   
> 
> > However, if the WG feels there is a need, we would need to 
> introduce a new requirement along the lines of "An edge proxy 
> MUST be able to filter inbound requests to a PBX on the basis 
> of whether or not they are addressed to currently registered 
> contact URIs".
> >   
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 Feb 2010 13:59:45 -0600

On Feb 22, 2010, at 3:26 AM, Elwell, John wrote:

> Dean,
>
> I don't agree with a requirement for supporting the admission of  
> outbound requests based on whether the caller has registered. This  
> would prevent, for example, a call from A to B being forwarded to C  
> via the SSP, where A is not one of the registered AORs at this  
> particular PBX (unless you do horrible things that I don't think we  
> want to condone, like pretending the caller is B, who is registered).

Well, considering the call needs to be paid for by B, given that A has  
no billing relationship with the SSP, that's not completely off the  
wall.

>
> If you want to pursue the question of being able to support  
> admitting both inbound requests and outbound requests on the basis  
> of the current registration state of the AOR, I think we should  
> consider these as separate issues. Do you want to raise issues on  
> the tracker for one or both of these?

Well heck, I don't agree with the requirement either. I think it's a  
royally stupid idea in either direction. However, people have been  
claiming that it's necessary in one direction or the other for their  
deployments. I was just translating the rather vaguely worded  
requirements I was hearing so that we'd all know what the argument was  
about.

Will the middlebox vendors and their victims please step forward and  
tell us whether they really need to be able to do this?

--
Dean

---

From: "Brian Lindsay" <[email-masked]>
Date: Mon, 22 Feb 2010 15:06:02 -0500

Hi,

   I thought this email was pretty clear, from an operators perspective,
on the topic:

http://www.ietf.org/mail-archive/web/martini/current/msg00814.html 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Monday, February 22, 2010 3:00 PM
To: Elwell, John
Cc: Bernard Aboba; 'MARTINI'
Subject: Re: [martini] Middlebox needs - admitting inbound requests

>
> If you want to pursue the question of being able to support admitting 
> both inbound requests and outbound requests on the basis of the 
> current registration state of the AOR, I think we should consider 
> these as separate issues. Do you want to raise issues on the tracker 
> for one or both of these?

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 22 Feb 2010 14:12:56 -0600

Posting as co-chair,

Groovy. So, my next question is, how much, if anything, would we need to say 
about this in a MARTINI specification? I'm not saying that we would require 
that all SPs have this as their policy, I'm asking whether we need to say 
anything about the practice.

Thanks,

Spencer

----- Original Message ----- 
From: "Brian Lindsay" <[email-masked]>
To: "Dean Willis" <[email-masked]>; "Elwell, John" 
<[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; "MARTINI" 
<[email-masked]>
Sent: Monday, February 22, 2010 2:06 PM
Subject: Re: [martini] Middlebox needs - admitting inbound requests

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Feb 2010 22:09:55 +0100

> Sent: 22 February 2010 20:00
> To: Elwell, John
[JRE] The SSP can only bill somebody on the basis of what has been authenticated. Neither From (without SIP Identity) nor PAI has any means of authentication. The SSP instead has to bill the PBX on the basis of whatever authentication it provides.

John

---

From: "Tyler Parkin" <[email-masked]>
Date: Thu, 25 Feb 2010 16:01:07 -0500

I'll throw my $.02 in just for fun.

I'm not sure I'm clear on what you mean, John, but it sounds like you're 
saying you think most people who cut CDR's do it based on the authentication 
credentials.  You're right and wrong.  As an SSP we can only bill based on 
what's authenticated (to verify that's the person actually making the call). 
However, most softswitch vendors use From/PAI to find the correct account 
and generate billing records, not the authentication credentials.  As such, 
we can (and do) bill off of from and PAI when the situation dictates, like 
the example below.  There are various implimentations to ensure that the 
credentials provided match From/PAI, which conceivably would have already 
registered.  If you base it only on credentials then it means any 
deployments where the registrar isn't also the device that cuts billing 
records couldn't bill their customers.

As far as the middle box ~ there are reasons to deploy them that actually do 
support "running your voip system 'the right way'," which is why they're so 
prevalent.  One of the obvious ones is to mask core network components from 
untrusted sources.  Today, our UA's (internal and external) send a register 
request and the SBC caches the URI and IP address (presumably the same most 
of the time), manipulates the headers, and forwards the requests to the 
registrar using the internal/trusted IP address of the SBC.  When a request 
comes into the registrar destined for a UA, the registrar sends the request 
to the SBC using the internal IP (because that's what it received the 
request from), and the SBC maps it from the internal IP to the 
original/external IP and sends it to the UA.  Again, the registrar doesn't 
see different originating IP addresses, it only sees the single internal 
address of the SBC.

My concern here is that the UA is expected to register using an AOR that 
apparently won't be used in subsequent messaging for associated/child 
addresses.  When a call comes into the registrar for a child address, it's 
going to send it to the SBC for delivery and the SBC won't have the child 
address mapping required to send it to the UA.  This is issue has come up 
with other implimentations for bulk reg, and each vendor has their own 
solution outside RFC spec.  One of those was to put the AOR in the request 
URI and the child address in the To field, and have the SBC substitute when 
it sends it to the UA.

Regards,

Tyler Parkin
[email-masked]

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; "'MARTINI'" 
<[email-masked]>
Sent: Monday, February 22, 2010 4:09 PM
Subject: Re: [martini] Middlebox needs - admitting inbound requests

> [JRE] The SSP can only bill somebody on the basis of what has been 
> authenticated. Neither From (without SIP Identity) nor PAI has any means 
> of authentication. The SSP instead has to bill the PBX on the basis of 
> whatever authentication it provides.
>
> John
>
>>
>> >

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Feb 2010 15:06:57 -0600

And, of course, if we indicate the list of extensions at registration time,
then the SBC can extract the necessary information from the REGISTER
messages (just like they do now).

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 25 Feb 2010 16:20:25 -0600

Hi, Adam,

> messages (just like they do now).

Just making sure I understand - do you mean "just like they do now with 
one-line-at-a-time REGISTERs", or something else?

Thanks,

Spencer

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Feb 2010 16:23:49 -0600

On 2/25/10 4:20 PM, Spencer Dawkins wrote:
> Just making sure I understand - do you mean "just like they do now 
> with one-line-at-a-time REGISTERs", or something else?

Yes. I mean they can know which AORs correspond to which registrations 
by examining the REGISTER messages. Which is what they do with 
one-AOR-at-a-time REGISTER messages currently.

/a

---

From: "Tyler Parkin" <[email-masked]>
Date: Thu, 25 Feb 2010 17:45:31 -0500

For what it's worth, SBC utilization isn't expected to decline, whether you 
like them or not.  Most carriers use them, and a lot of end customers are 
deploying products like Edgewater/Ingate in front of their PBX's as well. 
Chances are, there will be one or more "middleboxes" in any deployment 
excluding (possibly) peer to peer.  Whether inbound or oubound, if they're 
not explicitly made aware of the extensions or AOR as described earlier, 
they're going to have issues unless the behavior is accounted for in the 
standard.

http://sip-trunking.tmcnet.com/topics/security/articles/58263-new-enterprise-sbc-report-projects-48-percent-annual.htm

Tyler

----- Original Message ----- 
From: "Adam Roach" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "Tyler Parkin" <[email-masked]>; "Elwell, John" 
<[email-masked]>; "Dean Willis" 
<[email-masked]>; "Bernard Aboba" <[email-masked]>; 
"'MARTINI'" <[email-masked]>
Sent: Thursday, February 25, 2010 5:23 PM
Subject: Re: [martini] Middlebox needs - admitting inbound requests

> Yes. I mean they can know which AORs correspond to which registrations by 
> examining the REGISTER messages. Which is what they do with

---

From: "Brian Lindsay" <[email-masked]>
Date: Thu, 25 Feb 2010 18:26:51 -0500

Hi,

  There was a carrier who posted on this topic last week, who indicated
their middleboxes have no issues in an implicit registration
environment:
http://www.ietf.org/mail-archive/web/martini/current/msg00814.html

  Why would basic routing should be a problem? I would assume most SBC
B2BUA's might simply maintain some binding between the southbound
contact/routing info and northbound contact/routing info, or use some
other technique. 

  Regards
     Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tyler Parkin
Sent: Thursday, February 25, 2010 5:46 PM
To: Adam Roach; Spencer Dawkins
Cc: Bernard Aboba; 'MARTINI'
Subject: Re: [martini] Middlebox needs - admitting inbound requests

For what it's worth, SBC utilization isn't expected to decline, whether
you like them or not.  Most carriers use them, and a lot of end
customers are deploying products like Edgewater/Ingate in front of their
PBX's as well. 
Chances are, there will be one or more "middleboxes" in any deployment
excluding (possibly) peer to peer.  Whether inbound or oubound, if
they're not explicitly made aware of the extensions or AOR as described
earlier, they're going to have issues unless the behavior is accounted
for in the standard.

http://sip-trunking.tmcnet.com/topics/security/articles/58263-new-enterp
rise-sbc-report-projects-48-percent-annual.htm

Tyler

----- Original Message -----
From: "Adam Roach" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "Tyler Parkin" <[email-masked]>; "Elwell, John" 
<[email-masked]>; "Dean Willis" 
<[email-masked]>; "Bernard Aboba"
<[email-masked]>; "'MARTINI'" <[email-masked]>
Sent: Thursday, February 25, 2010 5:23 PM
Subject: Re: [martini] Middlebox needs - admitting inbound requests

>>> And, of course, if we indicate the list of extensions at 
>>> registration time, then the SBC can extract the necessary 
>>> information from the REGISTER messages (just like they do now).
>>>
>>> /a
>>

---

From: "Tyler Parkin" <[email-masked]>
Date: Thu, 25 Feb 2010 19:27:36 -0500

There were two discussions in that link, and I think the one Jack addressed 
was inbound (from the PBX).  He's correct, it's usually up to the SP to 
permit/deny calls from unregistered endpoints and they can do various things 
to them.  The comment "While the PBX is registered, any methods originating 
from it's IP address are considered registered." -- this is also 
configurable in most cases, user@host or just host.  Defaults and what can 
be configured depends on the middlebox vendor and not all behave the same 
way.

My concern is outbound from the SP to the PBX.  The middlebox needs a way to 
map the child/extension address to the implicit reg it initially received. 
IMO that method or identifier should be part of the standard, whether it's a 
list of extensions or a cookie as proposed in the link provided, or 
something else.

As an operator, I spend a lot of my time telling vendors that they aren't 
following RFC spec and therefore they're not working correctly with another 
vendor.  It's particularily frustrating when the RFC leaves something vague 
or just plain omits it.

Acknowledging that middleboxes exist, and that implict reg could (will) 
cause an issue for them, and then not specifying something in the standard 
for them to use basically ensures no two vendors use the standard the same 
way.  A middlebox could support a cookie, a registrar might include the 
original AOR or GRUU, etc.  Leaving it undetermined isn't enough in my 
opinion. 3261 defines the behavior for B2BUA's, so specifying behavior in 
this regard isn't out of the question.  *How* they do it might be out of 
spec, but what they use shouldn't be.  But then, discussions like this are 
new to me, so I might be crazy. =)

Respectfully,

Tyler

----- Original Message ----- 
From: "Brian Lindsay" <[email-masked]>
To: "Tyler Parkin" <[email-masked]>; "Adam Roach" <[email-masked]>; 
"Spencer Dawkins" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; "MARTINI" 
<[email-masked]>
Sent: Thursday, February 25, 2010 6:26 PM
Subject: RE: [martini] Middlebox needs - admitting inbound requests

Hi,

  Regards
     Brian

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

Tyler

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 26 Feb 2010 11:34:44 +0100

Tyler,

I found this thread a little mixed up between outbound requests from the PBX and inbound requests  to the PBX, so I am not sure I understood everything.

As far as inbound request are concerned, I think with gin-01 the problems you raise should be solvable, but it perhaps requires use of Proxy-Require, as already discussed. The middlebox does not need to know exactly which E.164s are implicitly registered, but when it gets a request to the PBX's IP address (presumably with Route indicating the IP address of the middlebox) it should assume the E.164 in the user part is indeed a registered AOR.

Now concerning outbound requests (this was what my earlier message was about, although somewhere further back that got brought across to this thread rather than the thread concerning outbound requests, so the thread title was wrong). Assuming an entity has knowledge of registered E.164 numbers, it is not clear to me how it would deal with a request where the From/PAI in the request from the PBX is not one of the implicitly registered ones. This can arise, for example, if the request originates elsewhere in the enterprise and "breaks out" to the SSP via this particular PBX. Or if the call originated elsewhere and was forwarded by the PBX to the SSP. I appreciate that there may be some arrangements between PBX and SSP where this is forbidden by policy, but in the general case I would expect it to work, so that the callee has a correct AOR to which it can make a return call.

John

> [mailto:[email-masked]] On Behalf Of Tyler Parkin
> Sent: 26 February 2010 00:28
> To: Brian Lindsay; Adam Roach; Spencer Dawkins

---

From: "Tyler Parkin" <[email-masked]>
Date: Fri, 26 Feb 2010 10:08:42 -0500

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Tyler Parkin" <[email-masked]>; "Brian Lindsay" 
<[email-masked]>; "Adam Roach" <[email-masked]>; "Spencer Dawkins" 
<[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>; "MARTINI" 
<[email-masked]>
Sent: Friday, February 26, 2010 5:34 AM
Subject: RE: [martini] Middlebox needs - admitting inbound requests

Tyler,

I found this thread a little mixed up between outbound requests from the PBX 
and inbound requests  to the PBX, so I am not sure I understood everything.
[tyler] sorry for the confusion, I think we're looking at it in different 
directions... inbound to me is inbound to the SSP, where to you inbound is 
to the PBX.  I guess we'll stick w/ inbound = to the PBX

As far as inbound request are concerned, I think with gin-01 the problems 
you raise should be solvable, but it perhaps requires use of Proxy-Require, 
as already discussed. The middlebox does not need to know exactly which 
E.164s are implicitly registered, but when it gets a request to the PBX's IP 
address (presumably with Route indicating the IP address of the middlebox) 
it should assume the E.164 in the user part is indeed a registered AOR.
[tyler] my point is that the middlebox doesn't get a request to the PBX's IP 
address.  The softswitch/registrar generating the call doesn't know the 
PBX's IP because it was masked during the initial registration.  Any 
requests from from the registrar/softswitch to the middlebox (destined for 
the PBX) will only have user@middlebox, perhaps w/ a cookie.  The middelbox 
needs to map user@middlebox to whatever IP/host originally registered. 
Today, the middlebox keeps a cache where the initial (individual) 
registration might be [email-masked], and the registration forwarded to the 
registrar is [email-masked].  That way when the registrar sends a request to 
the middlebox for [email-masked] it maps it to [email-masked] and all is good. 
If the middelbox doesn't have knowledge of the user (because of implicit), 
it can't make the mapping unless it has something else to associate to the 
original implicit reg (like a cookie, or knowledge of the extensions).

Now concerning outbound requests (this was what my earlier message was 
about, although somewhere further back that got brought across to this 
thread rather than the thread concerning outbound requests, so the thread 
title was wrong). Assuming an entity has knowledge of registered E.164 
numbers, it is not clear to me how it would deal with a request where the 
From/PAI in the request from the PBX is not one of the implicitly registered 
ones. This can arise, for example, if the request originates elsewhere in 
the enterprise and "breaks out" to the SSP via this particular PBX. Or if 
the call originated elsewhere and was forwarded by the PBX to the SSP. I 
appreciate that there may be some arrangements between PBX and SSP where 
this is forbidden by policy, but in the general case I would expect it to 
work, so that the callee has a correct AOR to which it can make a return 
call.
[tyler] methods dealing with this situation today (A calls B, B forwards the 
call to C) would use from=A and PAI=B, where B is a registered endpoint (and 
billable by the SSP).  Not sure if that's what you're asking?

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 26 Feb 2010 18:33:39 +0100

> From: Tyler Parkin [mailto:[email-masked]] 
> Sent: 26 February 2010 15:09
> To: Elwell, John; Brian Lindsay; Adam Roach; Spencer Dawkins
> address.  
[JRE] Why not? If the Contact URI contains the IP address (as in gin-01), this will be registered at the registrar and will be returned as the target of an inbound request to the PBX.

> The softswitch/registrar generating the call 
> doesn't know the 
> PBX's IP because it was masked during the initial registration.  
[JRE] Why would it be masked? I understand that the registrar would not see the IP address at the transport level from which the REGISTER request arrived at the middlebox, but it would see the IP address in the Contact URI.

> Any 
[JRE] Are you suggesting that each user behind the PBX would register with a different IP address, so you need to know whether it is user1 or user2 in order to send requests to 11.11.11.11 or 22.22.22.22? If so, that is not the scenario that MARTINI is addressing. MARTINI is addressing the case where requests to user1, user2 etc. on a given PBX all need to be routed to the PBX's IP address. So as long as the middlebox knows the request needs to go to the PBX, it doesn't need to know that particular user.
 
> billable by the SSP).  Not sure if that's what you're asking?
[JRE] Yes, that was what I was asking, and I know that it sometimes works the way you describe, but this is bad because PAI=B is wrong - it is not compliant with RFC 3325, since it is not the source of the request. If the callee used that to make a return call, the return call would arrive at the wrong place. For example, if a customer calls me on my office number and the PBX forwards it to my home via the SSP, if my phone stores the PAI as the caller's number and I try to make a return call, the return call goes to my office phone, not to my customer.

John

---

From: "Tyler Parkin" <[email-masked]>
Date: Fri, 26 Feb 2010 13:03:50 -0500

> [tyler] my point is that the middlebox doesn't get a request
[JRE] Why not? If the Contact URI contains the IP address (as in gin-01), 
this will be registered at the registrar and will be returned as the target 
of an inbound request to the PBX.

> PBX's IP because it was masked during the initial registration.
[JRE] Why would it be masked? I understand that the registrar would not see 
the IP address at the transport level from which the REGISTER request 
arrived at the middlebox, but it would see the IP address in the Contact 
URI.
[Tyler] In most scenarios where a middlebox (aka SBC) exists, the SBC 
performs two-way NAT functions, and NAT's the headers/URI's for inbound and 
outbound messaging.  Therefore, a request received on the public side from 
user@PBXIP is sent to the registrar as user@SBCPRIVATEIP.  The oposite 
direction (SSP -> PBX) is received by the SBC as user@SSPIP and NAT'd to 
user@SBCPUBLICIP.

> If the middelbox doesn't have knowledge of the user (because
[JRE] Are you suggesting that each user behind the PBX would register with a 
different IP address, so you need to know whether it is user1 or user2 in 
order to send requests to 11.11.11.11 or 22.22.22.22? If so, that is not the 
scenario that MARTINI is addressing. MARTINI is addressing the case where 
requests to user1, user2 etc. on a given PBX all need to be routed to the 
PBX's IP address. So as long as the middlebox knows the request needs to go 
to the PBX, it doesn't need to know that particular user.
[Tyler] Agreed, I shouldn't have used the term user.  The middlebox in this 
scenario wouldn't care about individual users, it's point of contact is the 
PBX.  All PBX's send register requests to the middlebox from different 
IP's/domains, granted.  After NAT, however, all the requests from the SBC to 
the registrar appear to come from the same IP.  We NAT in both directions, 
which is pretty standard, so we don't expose core equipment to the public, 
and we don't expose end user IP's to peers.  Plus it allows virtual route 
tables internally and resolves any issues with overlapping address space.

> billable by the SSP).  Not sure if that's what you're asking?
[JRE] Yes, that was what I was asking, and I know that it sometimes works 
the way you describe, but this is bad because PAI=B is wrong - it is not 
compliant with RFC 3325, since it is not the source of the request. If the 
callee used that to make a return call, the return call would arrive at the 
wrong place. For example, if a customer calls me on my office number and the 
PBX forwards it to my home via the SSP, if my phone stores the PAI as the 
caller's number and I try to make a return call, the return call goes to my 
office phone, not to my customer.
[Tyler] The source of the forward leg of the call is B, not A.  Calling area 
requirements and n11 need to be based on B.  Why would the callee use PAI to 
return a call?  That would be in violation of 3325 as well since it would 
obviate any callerid blocking/suppression requirements.  I guess whether the 
PBX should strip PAI before sending it to your phone is arguable.  Agreed, 
using PAI to assert a different ID than From (where from isn't private) 
might not strictly adhere to 3325, but I think alternate ID's vs suppressed 
ID's is splitting hairs a little.

John

---

From: "Brian Lindsay" <[email-masked]>
Date: Sun, 28 Feb 2010 15:51:31 -0500

Hi Tyler,

  I believe some SBCs that "NAT" as you describe would (or could) use a
unique port on the northbound side per registered entity. So the SBC
would be able to maintain a mapping from the client-side contact/routing
info to a unique northbound address/port that it would receive requests
on (for requests towards the SIP PBX). In this case, there shouldn't be
any problems routing the request.

  Also, I think the MARTINI-Shaken approach wouldn't have a problem in
this case either, since the domain portion of the request uri (from the
"SSP") contains a domain name representing the enterprise/PBX, rather
than an IP address derived from the contact.

  Thanks
     Brian

-----Original Message-----
From: Tyler Parkin [mailto:[email-masked]] 
Sent: Friday, February 26, 2010 1:04 PM
To: Elwell, John; Lindsay, Brian (CAR:AR00); Adam Roach; Spencer Dawkins
Cc: Bernard Aboba; MARTINI
Subject: Re: [martini] Middlebox needs - admitting inbound requests

> I found this thread a little mixed up between outbound requests from 
> the PBX and inbound requests  to the PBX, so I am not sure I 
> understood everything.
> [tyler] sorry for the confusion, I think we're looking at it in 
> different directions... inbound to me is inbound to the SSP, where to 
> you inbound is to the PBX.  I guess we'll stick w/ inbound = to the 
> PBX
>
> As far as inbound request are concerned, I think with gin-01 the 
> problems you raise should be solvable, but it perhaps requires use of 
> Proxy-Require, as already discussed. The middlebox does not need to 
> know exactly which E.164s are implicitly registered, but when it gets 
> a request to the PBX's IP address (presumably with Route indicating 
> the IP address of the middlebox) it should assume the E.164 in the 
> user part is indeed a registered AOR.
> [tyler] my point is that the middlebox doesn't get a request to the 
> PBX's IP address.
[JRE] Why not? If the Contact URI contains the IP address (as in
gin-01), this will be registered at the registrar and will be returned
as the target of an inbound request to the PBX.

> The softswitch/registrar generating the call doesn't know the PBX's IP

> because it was masked during the initial registration.
[JRE] Why would it be masked? I understand that the registrar would not
see the IP address at the transport level from which the REGISTER
request arrived at the middlebox, but it would see the IP address in the
Contact URI.
[Tyler] In most scenarios where a middlebox (aka SBC) exists, the SBC
performs two-way NAT functions, and NAT's the headers/URI's for inbound
and outbound messaging.  Therefore, a request received on the public
side from user@PBXIP is sent to the registrar as user@SBCPRIVATEIP.  The
oposite direction (SSP -> PBX) is received by the SBC as user@SSPIP and
NAT'd to user@SBCPUBLICIP.

> Any
> requests from from the registrar/softswitch to the middlebox (destined

> for the PBX) will only have user@middlebox, perhaps w/ a cookie.
> The middelbox
> registration might be [email-masked], and the registration forwarded to 
> the registrar is [email-masked].  That way when the registrar sends a 
> request to the middlebox for [email-masked] it maps it to [email-masked] 
> and all is good.
[JRE] Are you suggesting that each user behind the PBX would register
with a different IP address, so you need to know whether it is user1 or
user2 in order to send requests to 11.11.11.11 or 22.22.22.22? If so,
that is not the scenario that MARTINI is addressing. MARTINI is
addressing the case where requests to user1, user2 etc. on a given PBX
all need to be routed to the PBX's IP address. So as long as the
middlebox knows the request needs to go to the PBX, it doesn't need to
know that particular user.
[Tyler] Agreed, I shouldn't have used the term user.  The middlebox in
this scenario wouldn't care about individual users, it's point of
contact is the PBX.  All PBX's send register requests to the middlebox
from different IP's/domains, granted.  After NAT, however, all the
requests from the SBC to the registrar appear to come from the same IP.
We NAT in both directions, which is pretty standard, so we don't expose
core equipment to the public, and we don't expose end user IP's to
peers.  Plus it allows virtual route tables internally and resolves any
issues with overlapping address space.

> it can't make the mapping unless it has something else to associate to

> the original implicit reg (like a cookie, or knowledge of the 
> extensions).
>

> thread rather than the thread concerning outbound requests, so the 
> thread title was wrong). Assuming an entity has knowledge of 
> registered E.164 numbers, it is not clear to me how it would deal with

> a request where the From/PAI in the request from the PBX is not one of

> the implicitly registered ones. This can arise, for example, if the 
> request originates elsewhere in the enterprise and "breaks out" to the

> SSP via this particular PBX. Or if the call originated elsewhere and 
> was forwarded by the PBX to the SSP. I appreciate that there may be 
> some arrangements between PBX and SSP where this is forbidden by 
> policy, but in the general case I would expect it to work, so that the

> callee has a correct AOR to which it can make a return call.
> [tyler] methods dealing with this situation today (A calls B, B 
> forwards the call to C) would use from=A and PAI=B, where B is a 
> registered endpoint (and billable by the SSP).  Not sure if that's 
> what you're asking?
[JRE] Yes, that was what I was asking, and I know that it sometimes
works the way you describe, but this is bad because PAI=B is wrong - it
is not compliant with RFC 3325, since it is not the source of the
request. If the callee used that to make a return call, the return call
would arrive at the wrong place. For example, if a customer calls me on
my office number and the PBX forwards it to my home via the SSP, if my
phone stores the PAI as the caller's number and I try to make a return
call, the return call goes to my office phone, not to my customer.
[Tyler] The source of the forward leg of the call is B, not A.  Calling
area requirements and n11 need to be based on B.  Why would the callee
use PAI to return a call?  That would be in violation of 3325 as well
since it would obviate any callerid blocking/suppression requirements.
I guess whether the PBX should strip PAI before sending it to your phone
is arguable.  Agreed, using PAI to assert a different ID than From
(where from isn't private) might not strictly adhere to 3325, but I
think alternate ID's vs suppressed ID's is splitting hairs a little.

John