Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements?

From: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jan 2010 10:36:05 +0100

Thanks to Bernard for highlighting the issues and to Adam for his initial response. My thoughts are interleaved below.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 28 December 2009 23:37
> To: [email-masked]
> Cc: Bernard Aboba
> Subject: Re: [martini] draft-kaplan-martini-mixing-problems: 
> solution requirements?
> 
> On 12/28/09 12:53 AM, Bernard Aboba wrote: 
> 
> 	Currently, these sections articulate the issues, but 
> don't make recommendations as to which of the issues a 
> potential solution needs to solve.  Some of the issues are 
> indicated as open in the solution proposals (e.g. open 
> question on PAU/Wildcard syntax in 
> draft-kaplan-martini-shaken-implicit-registrations) so this 
> is not just a rhetorical question. 
> 	
> 	Here's a list of the Issues described in Sections 4, 5 & 6. 
> 	
> 	4.1.  Explicit Indication of Multiple AOR Registration
> 	
> 
> 
> I think this is REQUIRED.
[JRE] Agreed.

> 
> 
> 
> 	4.2-4.4: Usage of P-Associated URI
> 	        a. Inclusion of PAU
> 	        b. Avoidance of SIP Response fragmentation
> 	           1. Non-wildcard mitigation
> 	           2. Support for Wildcard syntax
> 	           3. Compatibility of Wildcard syntax with TEL URI
> 	        c. Defined behavior of IP-PBX on PAU mismatch
> 	
> 
> 
> I don't think we want to rely on PAU behavior to make a 
> multiple registration solution work. The definition in 
> RFC3455 is pretty well constrained to an exhaustive 
> enumeration of identities, which is not appropriate for the 
> kind of use cases MARTINI is discussing. Even more 
> importantly, it was meant for something rather different than 
> MARTINI's problem space: multiple identities that 
> semantically mean *exactly* the same *user*. Not billing 
> entity, but actual *user*.
> 
> So, I think all the PAU issues are IRRELEVANT with regards to 
> PAU itself.
[JRE]I don't want to see a solution that relies on PAU.

> 
> However, I think we need to carefully consider the semantic 
> issues that are implied by these sections. Things like:
> 
> 
> *	Who designates which URIs the request is attempting to 
> register? For example, if a company has a single PBX and 
> decides to split its users between two different PBXes (say, 
> at different sites) -- does it need to get the SSP to 
> reprovision the URIs associated with its implicit 
> registrations? Or would it make more sense for the request to 
> indicate which URIs it was attempting to register? This would 
> allow the company to move URIs around between its own PBXes 
> without a provisioning action at the SSP.
[JRE] I don't think this is a problem we necessarily need to solve at this stage. It would involve issues such as what if two PBXs try to register overlapping sets of AORs, and what if one of the AORs in the request is one that the PBX is not entitled to use. Provisioning will in any case be needed at the SSP whenever a new AOR is added to (or removed from) the total pool, so requiring provisioning also for the case where an AOR moves PBX is not out of the question.

> 	
> 	
> *	How does the UAC know which URIs have just been 
> registered? If they don't match what it expects, how does it 
> react? Note that this problem goes away if we allow the user 
> to designate which URIs they're attempting to register in the 
> request. Granted, it pushes the responsibility of verifying 
> the URIs onto the SSP equipment, but at least it can send an 
> error response if the requestor is not authorized to use the 
> specified URIs.
> 	
> 	
> *	Response size is a real concern, since there's no way 
> to switch from UDP to TCP at the UAS side when responses are 
> too large for the MTU. On the other hand, the requestor can 
> always elect to use TCP if the request is too large. This, 
> again, points to having the requestor indicate the URIs to be 
> used instead of the responder. 
> 
> Which is to say: I think the implicit model currently under 
> discussion in the problems and implicit-registration drafts 
> is going about the issue backwards. I believe that there are 
> a number of reasons it makes much more sense to have an 
> explicit model in which the PBX tells the SSP which URIs it 
> is attempting to register, and the SSP accepts or denies the 
> request based on authorization policy.
> 
> 
> 
> 	5.1   Retaining Target Info
> 	5.2   Contact-URI handling
> 	        a.  Request-URI
> 	        b.  Route Header
> 	
> 
> 
> I think retaining all the information that the PBX used to 
> indicate itself -- the "Contact" header field in Hadriel's 
> drafts -- is REQUIRED. Clearly, we also need the ability to 
> tell which extension is being addressed (i.e., this is 
> REQUIRED as well).
> 
> I'm less concerned about the mechanisms used to convey this 
> information. Ideally, it would be as consistent with normal 
> handling as is possible -- meaning that the Request URI is 
> semantically the information the PBX used to indicate itself 
> (again, the "Contact" header field in Hadriel's proposals).
[JRE] It depends what you mean by "normal handling". From the PBX's point of view, it would be more normal for the target AOR to appear in the Request-URI - that is where it would appear if the request had come from another source, e.g., a local UA, another PBX in the enterprise network, or another domain with which the PBX peers.

> 
> When you think about how currently-deployed multiline SIP 
> phones handle this situation, they'll usually use the user 
> portion of the Contact header field to keep track of which of 
> its several identities a request is associated with. For 
> example, a phone may register the AOR "sip:[email-masked]" 
> <sip:[email-masked]>  with a Contact of 
> "sip:[email-masked]" <sip:[email-masked]> , and 
> register "sip:[email-masked]" 
> <sip:[email-masked]>  with a Contact of 
> "sip:[email-masked]" <sip:[email-masked]> . That's 
> kind of nice, because it lets the end device correlate 
> information according to its own local scheme.
[JRE] Is the use of example.com for the first line and example.net for the second line deliberate? Are either or both of these intended to be the domain of the SSP or the domain of the PBX?

> 
> If we go with a scheme that allows the requestor to indicate 
> which URIs it is requesting for, we might also include some 
> kind of transform to go with each of the URIs. For example, 
> we could define a syntax whereby a MARTINI request ends up 
> associating a range-of-URI indicator like 
> "sip:214329{wildcard pattern meaning 4 
> [email-masked]" 
> <sip:[email-masked]>  
> with "sip:pbx-110-{pattern meaning put those 4 digits 
> [email-masked]" 
> <sip:[email-masked]> .
[JRE] How would all this work when the PBX mints a temporary GRUU (based on the PBX's domain name), and subsequently an inbound request to that GRUU needs to be routed to the PBX? The PBX cannot predict all possible GRUU values and include them in the REGISTER request.

> 
> 
> 
> 	5.3   Routing for explicit/implicitly registered AOR
> 	
> 
> 
> I think we need to be able to do this without middleboxes, 
> and without violating SIP's rules about being authoritative 
> for the requests that a proxy retargets. The strawman 
> proposal I describe above does not exhibit the problem 
> described in 5.3. Of course, neither does any well-designed 
> solution. I think the stuff in the field that includes the 
> SSP's domain in the R-URI bound for the PBX is simply poorly 
> designed and insufficiently thought out.
[JRE] Yes, but this depends on whether the AOR in the Request-URI uses the PBX's domain or the SSP's domain. Consider the different scenario where a local UA on the PBX issues a request to one of the PBX's AORs. The Request-URI in that case must contain the domain of the PBX (which could be a sub-domain of the SSP, assigned to the PBX) - otherwise, according to normal SIP rules, the PBX would route it to the SSP, which would be wrong (the request is targeting a destination on the PBX). So likewise requests from the SSP targeting an AOR on the PBX must have the PBX's domain in the Request-URI. I guess in your example the PBX's IP address is a substitute for the PBX's domain name, and that would satisfy this. However, I think I still have a preference for the AOR (e.g., sip:[email-masked]) rather than contact (e.g., sip:[email-masked]) being in the Request-URI, so that the PBX can handle the request just as if it had come from another source (e.g., a local UA).

> 
> In other words, the issue in 5.3 is one of poorly-engineered 
> implementations, and therefore IRRELEVANT.
> 
> 
> 
> 	6.1   Avoidance of authorization policy mismatch
> 	
> 
> 
> IRRELEVANT. I don't think we need to codify the type of 
> authorization described in this section, as such policies 
> necessarily limit the flexibility of SIP PBX implementations. 
> It is quite useful to include state information in the 
> Contact header field that can be extracted in future 
> requests. if the SSP policy doesn't allow this kind of valid 
> use of Contact URIs, then we've lost a rather elegant mechanism.
[JRE] Yes, an outbound request could contain a temporary GRUU, for example, in the contact header field, and the From/PAI could contain a URI from outside the PBX's domain (where the PBX is forwarding a request from another domain). Authorisation of the request should be based on authentication of the PBX from which it is received (e.g., based on delivery over an authenticated TLS transport) rather than on From/PAI/Contact header field contents in that request.

> 
> 
> 
> 	6.2.  Avoidance of PAU mismatch
> 	
> 
> 
> IRRELEVANT, for the reasons I enumerate under 4.2-4.4, above.
> 
> 
> 
> 	6.3.  Trust domain clarification
> 	
> 
> 
> I think this isn't just IRRELEVANT -- I think it's out of 
> scope for the working group.
[JRE] I tend to agree.

John

---

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Tue, 5 Jan 2010 08:39:38 -0600

I agree with Adam's designations of REQUIRED/IRRELEVANT however I
support John in not allowing the IP-PBX to change the identities it
wishes to implicitly register.  See [DM] below for more on this as well
as another comment.

David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Elwell, John
Sent: Tuesday, January 05, 2010 4:36 AM
To: Adam Roach; [email-masked]
Cc: Bernard Aboba
Subject: Re: [martini]draft-kaplan-martini-mixing-problems: solution
requirements?

Thanks to Bernard for highlighting the issues and to Adam for his
initial response. My thoughts are interleaved below.

[JRE] Agreed.

> without a provisioning action at the SSP.
[JRE] I don't think this is a problem we necessarily need to solve at
this stage. It would involve issues such as what if two PBXs try to
register overlapping sets of AORs, and what if one of the AORs in the
request is one that the PBX is not entitled to use. Provisioning will in
any case be needed at the SSP whenever a new AOR is added to (or removed
from) the total pool, so requiring provisioning also for the case where
an AOR moves PBX is not out of the question.
[DM] This is a nice goal but it would be dependent on multiple PBXs
being hosted by the same SSP Registrar short of developing additional
interfaces between systems.  I agree with John that it should be out of
scope of this working group.
> (again, the "Contact" header field in Hadriel's proposals).
[JRE] It depends what you mean by "normal handling". From the PBX's
point of view, it would be more normal for the target AOR to appear in
the Request-URI - that is where it would appear if the request had come
from another source, e.g., a local UA, another PBX in the enterprise
network, or another domain with which the PBX peers.

> information according to its own local scheme.
[JRE] Is the use of example.com for the first line and example.net for
the second line deliberate? Are either or both of these intended to be
the domain of the SSP or the domain of the PBX?

> <sip:[email-masked]> .
[JRE] How would all this work when the PBX mints a temporary GRUU (based
on the PBX's domain name), and subsequently an inbound request to that
GRUU needs to be routed to the PBX? The PBX cannot predict all possible
GRUU values and include them in the REGISTER request.

> designed and insufficiently thought out.
[JRE] Yes, but this depends on whether the AOR in the Request-URI uses
the PBX's domain or the SSP's domain. Consider the different scenario
where a local UA on the PBX issues a request to one of the PBX's AORs.
The Request-URI in that case must contain the domain of the PBX (which
could be a sub-domain of the SSP, assigned to the PBX) - otherwise,
according to normal SIP rules, the PBX would route it to the SSP, which
would be wrong (the request is targeting a destination on the PBX). So
likewise requests from the SSP targeting an AOR on the PBX must have the
PBX's domain in the Request-URI. I guess in your example the PBX's IP
address is a substitute for the PBX's domain name, and that would
satisfy this. However, I think I still have a preference for the AOR
(e.g., sip:[email-masked]) rather than contact (e.g.,
sip:[email-masked]) being in the Request-URI, so that the
PBX can handle the request just as if it had come from another source
(e.g., a local
  UA).

> use of Contact URIs, then we've lost a rather elegant mechanism.
[JRE] Yes, an outbound request could contain a temporary GRUU, for
example, in the contact header field, and the From/PAI could contain a
URI from outside the PBX's domain (where the PBX is forwarding a request
from another domain). Authorisation of the request should be based on
authentication of the PBX from which it is received (e.g., based on
delivery over an authenticated TLS transport) rather than on
From/PAI/Contact header field contents in that request.
[DM]  While authorization policy mismatch is a valid concern, it is
IRRELEVANT to providing reachability information.  SSP problems handling
changing contact headers can happen irrespective of multiple users (e.g.
IP-PBX).
[JRE] I tend to agree.

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jan 2010 08:41:37 -0600

I'm breaking out this issue into its own thread, since I think it's 
fundamental to getting the solution correct.

On 1/5/10 03:36, Jan 5, Elwell, John wrote:
> [JRE] I don't think this is a problem we necessarily need to solve at this stage.

Quite to the contrary -- I think the assumption that the SSP makes the 
determination is a fundamental fallacy in the current suite of 
documents. Fixing this problem will require different procedures than 
are proposed at the moment.

We need to get the semantics correct before we start jumping into 
protocol and syntax. At this point, we seem to have taken as a given 
that "the way to do it" should be modeled off the hacked-together ad hoc 
solutions that people have thrown together in the field. Duct tape and 
bailing wire may keep you going for a while in a pinch, but you don't 
explicitly call for them on blueprints when you sit down to design a system.

>   It would involve issues such as what if two PBXs try to register overlapping sets of AORs

Oddly enough, SIP handles multiple registrations for a single AOR just 
fine now. In fact, even Hadriel's current set of proposals talks about 
multiple registrations for an AOR. It's just a basic, key part of SIP's 
rendezvous model.

I fear that this highlights one of the problems MARTINI must overcome: 
people are thinking of this problem space too much in terms of "how can 
we make this work like 1960s PBX systems?," not "how do we adapt SIP to 
perform multiple AOR registrations in a single transaction?" If you are 
considering the first question, overlapping AORs would be a real 
problem, since that's not how the PSTN works. If you are considering the 
second question, the very concept of "overlapping AORs" is nonsense, 
since multiple registrations for a single AOR are so very, very 
fundamental to the core functioning of SIP.

> and what if one of the AORs in the request is one that the PBX is not entitled to use.

Which is the mirror problem to "what if one of the AORs in the response 
is one that PBX is not prepared to handle?" We need to fix it either way.

At least with the "PBX requestor" model, the problem is discovered 
mid-transaction, and can be addressed with proper error handling. With 
the mechanisms in Hadiel's document, the error is only discovered after 
the binding is established. Even worse, there is no clear recovery path, 
and no flexibility in handling the situation.

> Provisioning will in any case be needed at the SSP whenever a new AOR is added to (or removed from) the total pool, so requiring provisioning also for the case where an AOR moves PBX is not out of the question.
>    

I don't want to invoke a provisioning action because one of my employees 
is traveling from the Dallas office to the Kansas office for two days. 
Based on the SSPs I've worked with, by the time the ticket is closed, 
he'll be back in Dallas anyway.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jan 2010 09:03:11 -0600

On 1/5/10 03:36, Jan 5, Elwell, John wrote:
> [JRE] It depends what you mean by "normal handling".

I mean registrar processing as described in RFC 3261.

>    From the PBX's point of view, it would be more normal for the target AOR to appear in the Request-URI - that is where it would appear if the request had come from another source, e.g., a local UA, another PBX in the enterprise network, or another domain with which the PBX peers.
>    

You're confusing RFC3263 routing with registrar routing. They're very 
different things. And since we're talking about PBXes that have 
effectively removed themselves from the 3263 routing model, "normal" 
behavior is registrar behavior.

>> "sip:[email-masked]"<sip:[email-masked]>  , and
>> "sip:[email-masked]"<sip:[email-masked]>  . That's

The answer to your first question is "it's irrelevant." the second 
question is nonsense -- I was giving an example of a SIP terminal in a 
generic SIP network, without anything that one would reasonably consider 
a PBX or an SSP. Example.com and example.net are both registrars. Which 
is not to say they are PBXes. They're registrars. Read nothing more into 
that.

> [JRE] How would all this work when the PBX mints a temporary GRUU (based on the PBX's domain name), and subsequently an inbound request to that GRUU needs to be routed to the PBX? The PBX cannot pr…

Yep, we'll have to define special procedures for GRUUs. This problem 
arises regardless of whether the SSP or the PBX selects the AORs. I'm 
comfortable that we can solve it for both cases, and have some ideas in 
this space. But I don't want to rathole on that issue right now, so I'm 
not describing them at the moment.

> [JRE] Yes, but this depends on whether the AOR in the Request-URI uses the PBX's domain or the SSP's domain. Consider the different scenario where a local UA on the PBX issues a request to one of t…

I don't think that works the way you think it does. In your example, 
what do you get when you run "pbx.example.com" through 3263 resolution 
rules? Does it point to the SSP or the PBX? If it points to the PBX, 
then the justification described by 
draft-kaplan-martini-shaken-implicit-registrations goes away. That 
particular PBX is not a candidate for MARTINI procedures.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jan 2010 16:48:38 +0100

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 05 January 2010 14:42
> To: Elwell, John
> Cc: [email-masked]; Bernard Aboba
> Subject: Who designates AORs? (was Re: [martini] 
> draft-kaplan-martini-mixing-problems: solution requirements?)
> 
> > Provisioning will in any case be needed at the SSP whenever 
> a new AOR is added to (or removed from) the total pool, so 
> requiring provisioning also for the case where an AOR moves 
> PBX is not out of the question.
> >    
> 
[JRE] I guess there are two ways to do this temporary move type scenario from PBX1 to PBX2. One is as you suggest, you register the fact with the SSP so that SSP forwards all incoming requests to PBX2 instead of PBX1, until such time as PBX2 de-registers that AOR and PBX1 re-registers it. The other way is for all incoming requests to continue to arrive at PBX1 and for PBX1 to route onwards (within the enterprise infrastructure) to PBX2. This is the way it would work if the source of the request were a local UA on PBX1 - PBX 1 would just route it to PBX2. So given that PBX1 has this capability, why can't it use this for requests arriving from the SSP?

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jan 2010 17:09:18 +0100

> Sent: 05 January 2010 15:03
> To: Elwell, John
> >    From the PBX's point of view, it would be more normal 
> for the target AOR to appear in the Request-URI - that is 
> where it would appear if the request had come from another 
> source, e.g., a local UA, another PBX in the enterprise 
[JRE] I don't understand your reasoning. For both registrar routing and 3263 routing, you start with what is in the Request-URI (assuming there is no Route header) and resolve that. Whether it is resolved by DNS look-up or by other means is irrelevant - the Request-URI is the starting point. With what you propose, the PBX would have first to manipulate the Request-URI to get it back to an AOR, in order then to carry out whatever form or routing it would normally do.

> > [JRE] Is the use of example.com for the first line and 
> example.net for the second line deliberate? Are either or 
> both of these intended to be the domain of the SSP or the 
> domain of the PBX?
> >    
> 
> 
> > [JRE] How would all this work when the PBX mints a 
> temporary GRUU (based on the PBX's domain name), and 
> subsequently an inbound request to that GRUU needs to be 
> routed to the PBX? The PBX cannot predict all possible GRUU 
> values and include them in the REGISTER request.
> >    
> 
> 
> > [JRE] Yes, but this depends on whether the AOR in the 
> Request-URI uses the PBX's domain or the SSP's domain. 
> Consider the different scenario where a local UA on the PBX 
> issues a request to one of the PBX's AORs. The Request-URI in 
> that case must contain the domain of the PBX (which could be 
> a sub-domain of the SSP, assigned to the PBX) - otherwise, 
> according to normal SIP rules, the PBX would route it to the 
> SSP, which would be wrong (the request is targeting a 
> destination on the PBX). So likewise requests from the SSP 
> targeting an AOR on the PBX must have the PBX's domain in the 
> Request-URI. I guess in your example the PBX's IP address is 
> a substitute for the PBX's domain name, and that would 
> satisfy this. However, I think I still have a preference for 
> the AOR (e.g., sip:[email-masked]) rather than contact 
> (e.g., sip:[email-masked]) being in the 
> Request-URI, so that the PBX can handle the request just as 
> if it had come from another source (e.g., a local UA).
> >    
> 
[JRE] Internally the PBX would be able to route on pbx.example.com (it would treat it as its own domain, as it would if its own IP address were in the domain part). This does not necessarily mean that pbx.example.com is published to the whole world so that they can get there without using MARTINI procedures. For most purposes today, E.164 numbers are used, so a request could start off as addressed to sip:[email-masked] (or tel:+12345679, which would get resolved to sip:[email-masked]). The SSP (ssp.example.net) would use MARTINI procedures to get it to the PBX. For delivery to the PBX you need something different in the domain part (e.g., IP address or pbx.example.com) so that, on receipt, the PBX doesn't simply route it back to the SSP.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jan 2010 11:13:06 -0500

I agree with a lot of what Adam says here.

But, is it reasonable to expect a sip request to convey
several hundred AORs? (And what if it becomes several thousand?)
This is out of the scope of what sip requests were designed to handle.

If that path is taken, then next people will be asking to encode those 
more tightly, such as by specifying ranges of numbers. But of course 
that won't work for non-numeric addresses. It starts to look very ugly.

Regarding the "overlapping registrations", I agree with Adam that 
allowing multiple PBXs to "own" the same number is a feature.
In Adam's example of employee going from Dallas to Kansas City for a few 
days it is equally likely that the employee's desk phone is still 
registered in Dallas, along side the temporary (or soft) phone that 
person is using in KC, so that they will both ring. That's ok.

	Thanks,
	Paul

Adam Roach wrote:
>> this stage.
>> Provisioning will in any case be needed at the SSP whenever a new AOR 
>> is added to (or removed from) the total pool, so requiring 
>> provisioning also for the case where an AOR moves PBX is not out of 
>> the question.
>>    
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jan 2010 17:25:52 +0100

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 05 January 2010 16:13
> To: Adam Roach
> Cc: Elwell, John; Bernard Aboba; [email-masked]
> Subject: Re: [martini] Who designates AORs? (was Re: 
[JRE] But there are other ways of making them both ring, i.e., deliver the request to the Dallas PBX and let that do the parallel forking to the Dallas UA and to the KC UA. Just as it would if the source of the request were a local UA in Dallas.

John

---

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jan 2010 10:31:47 -0600

> that won't work for non-numeric addresses. It starts to look very ugly.

Yes, this is one of the most difficult problems that MARTINI must solve. 
And it's a problem regardless of whether the PBX suggests the AORs to 
register or the SSP tells the PBX which AORs it has just registered. 
Some message somewhere is going to have to indicate the AORs involved.

We clearly don't do ranges of numbers. But we can do a lot with 
patterns, which would include ranges of numbers.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jan 2010 11:36:19 -0500

> [JRE] Internally the PBX would be able to route on pbx.example.com (it would treat it as its own domain, as it would if its own IP address were in the domain part). This does not necessarily mean t…

I don't buy that logic.

If you want requests to pbx.example.com to go through the martini 
processes, then responsibility for that domain needs to reside with the 
SSP.

What you describe amounts to having a split-DNS, where the resolution of 
that domain name gets a different answer inside the enterprise than it 
does outside. I don't find that an appealing direction to go.

If you want the pbx to have its own domain name, then it needs to be a 
different one from the one used to reach its numbers at the SSP.

When routing on numbers in the SSP world the domain names are constantly 
changing in any case. It seems plausible to me that 1-408-555-1234 is 
initially addressed to sip:[email-masked], gets routed by 
ssp1.net to ssp2.net and in the process gets rewritten as 
sip:[email-masked], then mapped by ssp2 to 
sip:[email-masked] and then to 
sip:[email-masked] before being delivered to the pbx.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jan 2010 11:40:21 -0500

> [JRE] I guess there are two ways to do this temporary move type scenario from PBX1 to PBX2. One is as you suggest, you register the fact with the SSP so that SSP forwards all incoming requests to P…

The latter assumes the enterprise infrastructure is up to the task of 
carrying the phone calls between sites. Some enterprises are set up for 
that, and some are not.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jan 2010 10:43:09 -0600

On 1/5/10 10:40, Jan 5, Paul Kyzivat wrote:
>
>
> Elwell, John wrote:
>
>>> I don't want to invoke a provisioning action because one of my 
>>> employees is traveling from the Dallas office to the Kansas office 
>>> for two days. Based on the SSPs I've worked with, by the time the 
>>> ticket is closed, he'll be back in Dallas anyway.
>> [JRE] I guess there are two ways to do this temporary move type 
>> scenario from PBX1 to PBX2. One is as you suggest, you register the 
>> fact with the SSP so that SSP forwards all incoming requests to PBX2 
>> instead of PBX1, until such time as PBX2 de-registers that AOR and 
>> PBX1 re-registers it. The other way is for all incoming requests to 
>> continue to arrive at PBX1 and for PBX1 to route onwards (within the 
>> enterprise infrastructure) to PBX2. This is the way it would work if 
>> the source of the request were a local UA on PBX1 - PBX 1 would just 
>> route it to PBX2. So given that PBX1 has this capability, why can't 
>> it use this for requests arriving from the SSP?
>
> carrying the phone calls between sites. Some enterprises are set up 
> for that, and some are not.

Very true. I certainly wouldn't want to tie up 180 kbps of bandwidth on 
my T1 hairpinning a call out to another site. That's over 10% of the 
total link capacity...

/a

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Jan 2010 09:02:03 -0800

> that won't work for non-numeric addresses. It starts to look very ugly.

These are two of the issues that Hadriel raises in the draft.   

Setting aside the precise details of how to go about it,  I'm wondering
whether we can come to any conclusions as to whether solutions
to these issues are REQUIRED, RECOMMENDED or OPTIONAL.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jan 2010 19:03:56 +0100

> Sent: 05 January 2010 16:36
> To: Elwell, John
> Cc: Adam Roach; Bernard Aboba; [email-masked]
> > [JRE] Internally the PBX would be able to route on 
> pbx.example.com (it would treat it as its own domain, as it 
> would if its own IP address were in the domain part). This 
> does not necessarily mean that pbx.example.com is published 
> to the whole world so that they can get there without using 
> MARTINI procedures. For most purposes today, E.164 numbers 
> are used, so a request could start off as addressed to 
> sip:[email-masked] (or tel:+12345679, which would 
> get resolved to sip:[email-masked]). The SSP 
> (ssp.example.net) would use MARTINI procedures to get it to 
> the PBX. For delivery to the PBX you need something different 
> in the domain part (e.g., IP address or pbx.example.com) so 
> that, on receipt, the PBX doesn't simply route it back to the SSP.
> 
> I don't buy that logic.
> 
[JRE] Yes, and that is what I show in my example above.

> sip:[email-masked] before being delivered to the pbx.
[JRE] I agree. And if a local UA on the PBX issues a request to sip:[email-masked] the PBX would resolve it locally.

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jan 2010 19:07:06 +0100

> Sent: 05 January 2010 16:43
> To: Paul Kyzivat
[JRE] Of course not, but if you can reach the other site only via the SSP, then redirection might be another possibility.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jan 2010 13:17:54 -0500

at end...

> [JRE] I agree. And if a local UA on the PBX issues a request to sip:[email-masked] the PBX would resolve it locally.

So then the question remains: if someone outside the enterprise, and 
outside the SSP, sends a sip request to 
sip:[email-masked], what happens?

I presume that in that case the ssp would not be involved.
Then one of two things will happen:
- there is no global DNS mapping for this address, so the
   request fails
- there is a global DNS mapping for this address, to the
   pbx, so the request succeeds. In this case there was no
   need to use the registration mechanism.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jan 2010 21:17:09 +0100

> Sent: 05 January 2010 18:18
> To: Elwell, John
> > [JRE] I agree. And if a local UA on the PBX issues a 
> request to sip:[email-masked] the PBX would 
> resolve it locally.
> 
[JRE] Yes, it would fail - you would need to use one of the other forms above, so that is what you would need to publish publicly (e.g., on your business card). The alternatives are to use one of the above forms (e.g., sip:[email-masked]) all the time, even internally within the PBX, but then we would have a  split responsibility for that domain.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jan 2010 15:33:57 -0500

I agree that the approach below can work.

IIRC, somebody (was it Cullen) had an aversion to using "DNS" names that 
have no registered address.

	Thanks,
	Paul

---

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Wed, 6 Jan 2010 09:50:07 -0600

If/when the capability to standardize the sort of portability Adam
mentioned is done, it should also consider the case of a teleworker
using a client that registers directly with the SSP.   This aspect helps
make a case for addressing this form of portability separately as
opposed to encumbering the basic reachability solution.

For clarification, the teleworker case that I am referring to is where
the teleworker is also a PBX user.  Requests would be forked to both the
PBX and the teleworker if both are registered.  This could be
implemented without knowing if the teleworker has a client active behind
the PBX but if we head down the path of the SSP knowing the identities
behind the PBX, the call should only be forked when the user is
available.

This very much complicates the feature handling at the IP PBX since the
call may not be offered to it.  The user could have IP PBX-hosted voice
mail or other features like call forwarding that would not be invoked if
the call is not routed through the IP PBX.

To be clear, my position on this is that it should be considered
out-of-scope of the MARTINI WG.

David

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Jan 2010 18:24:10 +0100

I do not believe this is a forking problem.

It needs to be implemented by some form of application server which is the addressed endpoint of the original request-URI (on behalf of the real owner of that URI) which then generates two call requests to the user (one to his UA hosted on the PBX and one to his UA hosted on the SSP). This is essentially no different to the shared appearance stuff documented in draft-ietf-bliss-shared-appearances

Note also that the teleworker will in any case need to be registered on the PBX, as there will be users on the PBX who wish to call the teleworker, at the address which belongs to the PBX operator. Do it any other way and you essentially turn the PBX into an access gateway to a Centrex implementation on the SSP (valid, but it is no longer a PBX providing services to its own end users).

And no, I don't propose to handle this in MARTINI - I think the solution exists already.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Middleton, 
> David (NSN - US/Boca Raton)
> Sent: Wednesday, January 06, 2010 3:50 PM
> To: [email-masked]
> If/when the capability to standardize the sort of portability 
> Adam mentioned is done, it should also consider the case of a 
> teleworker
> make a case for addressing this form of portability 
> separately as opposed to encumbering the basic reachability solution.
> 
> For clarification, the teleworker case that I am referring to 
> is where the teleworker is also a PBX user.  Requests would 
> be forked to both the PBX and the teleworker if both are 
> registered.  This could be implemented without knowing if the 
> teleworker has a client active behind the PBX but if we head 
> down the path of the SSP knowing the identities behind the 
> PBX, the call should only be forked when the user is available.
> 
> This very much complicates the feature handling at the IP PBX 
> since the call may not be offered to it.  The user could have 
> IP PBX-hosted voice mail or other features like call 
> forwarding that would not be invoked if the call is not 
> routed through the IP PBX.
> 
> To be clear, my position on this is that it should be 
> considered out-of-scope of the MARTINI WG.
> 
> David
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Jan 2010 18:49:00 +0100

For information, the IMS mechanism of supporting this is using a wildcarded URI defined as follows:

"consists of a delimited regular expression located either in the userinfo portion of the SIP URI or in the telephone-subscriber portion of the Tel URI. The regular expression in the wildcarded PSI shall take the form of Extended Regular Expressions (ERE) as defined in chapter 9 in IEEE 1003.1-2004 Part 1 [60]. The delimiter shall be the exclamation mark character ("!"). If more than two exclamation mark characters are present in the userinfo portion or telephone-subscriber portion of a wildcarded PSI then the outside pair of exclamation mark characters is regarded as the pair of delimiters (i.e. no exclamation mark characters are allowed to be present in the fixed parts of the userinfo portion or telephone-subscriber portion)."

where the reference is:

[60]	IEEE 1003.1-2004, Part 1: Base Definitions

Extract from 3GPP TS 23.003.

Note that an attached device to IMS would only see these in the P-Associated-URI and in the reg event package. Otherwise their use is internal to the IMS. As such the attached device would not necessarily need to understand them.

regards

Keith 

> Sent: Tuesday, January 05, 2010 4:32 PM
> To: Paul Kyzivat
> Cc: Bernard Aboba; [email-masked]
> > But, is it reasonable to expect a sip request to convey several 
> > hundred AORs? (And what if it becomes several thousand?) 
> This is out 
> > of the scope of what sip requests were designed to handle.
> >
> And it's a problem regardless of whether the PBX suggests the 
> AORs to register or the SSP tells the PBX which AORs it has 
> just registered. 
> We clearly don't do ranges of numbers. But we can do a lot 
> with patterns, which would include ranges of numbers.
> 
> /a