Subject: [martini] Requirements - rev1

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Jan 2010 18:46:29 +0100

Revised following the feedback since yesterday. Please continue the feedback.

- The mechanism MUST allow the PBX to be responsible for its AORs and to handle requests to those AORs according to its rules.
- The mechanism MUST allow the PBX to receive requests to its AORs that originate off-PBX and arrive via the SSP, so that the PBX can handle those requests according to its rules.
- The mechanism MUST provide a means whereby the PBX knows which of its AORs an inbound request is targeted at.
- The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not.
- The mechanism MUST observe SIP backwards compatibility principles.
- The mechanism MUST work in the presence of intermediate "proxies" between the PBX and the SSP's domain proxy, where those intermediate "proxies" need to be on the path of inbound requests to the PBX.
- The mechanism MUST work when the PBX obtains its IP address dynamically.
- The mechanism MUST work without requiring the PBX to publish reachability information through the DNS.

Also some desiderata:
- The mechanism SHOULD allow SSPs to exploit its mechanisms for providing SIP service to ordinary subscribers in order to provide a SIP trunking service to PBXs.
- The mechanism SHOULD scale to PBXs of several thousand AORs.
- The mechanism SHOULD require relatively modest changes to a substantial population of existing SSP and PBX implementations, in order to encourage a fast market adoption of the standardized mechanism.

John

---

From: <[email-masked]>
Date: Fri, 8 Jan 2010 18:59:17 +0100

You have included a requirement that the mechanism MUST work in the presence of intermediate "proxies" between the PBX and the SSP's. Don't we need as well a requirement about the presence of intermediate enterprise proxies between the PBX and the SIP terminals, especially when considering inbound requests?

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Elwell, John
> Envoyé : vendredi 8 janvier 2010 18:46
> À : [email-masked]
> Objet : [martini] Requirements - rev1
> 
> - The mechanism MUST allow the PBX to be responsible for its 
> AORs and to handle requests to those AORs according to its rules.
> - The mechanism MUST allow the PBX to receive requests to its 
> AORs that originate off-PBX and arrive via the SSP, so that 
> the PBX can handle those requests according to its rules.
> - The mechanism MUST provide a means whereby the PBX knows 
> which of its AORs an inbound request is targeted at.
> - The mechanism MUST provide a means of avoiding problems due 
> to one side using the mechanism and the other side not.
> - The mechanism MUST work in the presence of intermediate 
> "proxies" between the PBX and the SSP's domain proxy, where 
> those intermediate "proxies" need to be on the path of 
> inbound requests to the PBX.
> - The mechanism MUST work without requiring the PBX to 
> publish reachability information through the DNS.
> 
> Also some desiderata:
> - The mechanism SHOULD allow SSPs to exploit its mechanisms 
> for providing SIP service to ordinary subscribers in order to 
> provide a SIP trunking service to PBXs.
> - The mechanism SHOULD require relatively modest changes to a 
> substantial population of existing SSP and PBX 
> implementations, in order to encourage a fast market adoption 
> of the standardized mechanism.
> 
> John
> 
> 
> 
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
> 

*********************************
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: Fri, 8 Jan 2010 19:04:01 +0100

Bruno,

Thanks. That is true, but during the SIPconnect work we have always considered the interface between the enterprise edge device and the SSP, and that the enterprise edge device would register and supply the contact URIs. So it hasn't really been an issue.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 08 January 2010 17:59
> To: Elwell, John
> Cc: [email-masked]
> Subject: RE: [martini] Requirements - rev1
> 
> You have included a requirement that the mechanism MUST work 
> in the presence of intermediate "proxies" between the PBX and 
> the SSP's. Don't we need as well a requirement about the 
> presence of intermediate enterprise proxies between the PBX 
> and the SIP terminals, especially when considering inbound requests?
> 
> 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: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 9 Jan 2010 00:38:44 +0100

I would like to see a SHOULD on something like:

The mechansism should allow handling of inbound requests and outbound requests between SSP and PBX to be as common as possible as for a normal peering arrangement (e.g. RFC 3263 based), as far as the PBX is concerned. The handing of requests at the incoming / outgoing gateway in the edge PBX should be common once the mechanism has been applied.

Essentially this means that the Request-URI should not be replaced by the SSP on requests sent to the PBX.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Friday, January 08, 2010 5:46 PM
> To: [email-masked]
> Subject: [martini] Requirements - rev1
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 9 Jan 2010 00:45:41 +0100

With regard to the intermediate proxies requirement, can we limit this to intermediate proxies in the SSP.

For the PBX side, I have always considered an such mechanism as local to the gateway provided by the PBX, and not extending any further into the enterprise. If this applies, then it excludes any proxies on the PBX side of the gateway.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, January 08, 2010 5:59 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [martini] Requirements - rev1
> 
> > [mailto:[email-masked]] De la part de Elwell, 
> John Envoyé : 
> > vendredi 8 janvier 2010 18:46 À : [email-masked] Objet : 
> [martini] 
> > Requirements - rev1
> > 
> > - The mechanism MUST allow the PBX to be responsible for 
> its AORs and 
> > to handle requests to those AORs according to its rules.
> > - The mechanism MUST allow the PBX to receive requests to its AORs 
> > that originate off-PBX and arrive via the SSP, so that the PBX can 
> > handle those requests according to its rules.
> > - The mechanism MUST provide a means whereby the PBX knows which of 
> > its AORs an inbound request is targeted at.
> > - The mechanism MUST provide a means of avoiding problems 
> due to one 
> > side using the mechanism and the other side not.
> > - The mechanism MUST work in the presence of intermediate "proxies" 
> > between the PBX and the SSP's domain proxy, where those 
> intermediate 
> > "proxies" need to be on the path of inbound requests to the PBX.
> > - The mechanism MUST work without requiring the PBX to publish 
> > reachability information through the DNS.
> > 
> > Also some desiderata:
> > - The mechanism SHOULD allow SSPs to exploit its mechanisms for 
> > providing SIP service to ordinary subscribers in order to provide a 
> > SIP trunking service to PBXs.
> > substantial population of existing SSP and PBX implementations, in 
> > order to encourage a fast market adoption of the standardized 
> > mechanism.
> > 
> > John
> > 
> > 
> > 
> >

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Jan 2010 17:48:19 -0600

> Essentially this means that the Request-URI should not be replaced by the SSP on requests sent to the PBX.

No, I don't think this is correct.

Fundamentally, this is a 3261 registrar relationship (regardless of 
whether we use NOTIFY or REGISTER), not a 3263 relationship. In 
particular, what you propose cannot co-exist with the requirement:

- The mechanism MUST provide a means of avoiding problems dueto one side using the mechanism and the other side not.

Because a failure to rewrite the URI means that the URI will still 
resolve to the SSP under 3263 rules (since that's how it got there in 
the first place). So, if it sends it to the PBX, and the PBX doesn't use 
the MARTINI mechanism, it will apply 3263, and route it back to the SSP. 
The SSP will then apply MARTINI rules and route it to the registered 
PBX. Who will route it to the SSP. Which will then route it to the PBX.

And so on.

In particular, I think what you're describing is a requirement, but it 
should be "MUST NOT", instead of SHOULD."

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 9 Jan 2010 00:54:25 +0100

And here is where we start having the difference in philosophy.

The correct mechanism for connecting two networks together is to peer them, i.e. requests-URIs are not normally rewritten.

That therefore should be the starting point of what PBXs have implemented.

What we are then looking for is something that makes the life of the SSPs easier in some circumstances regarding configuration, to support such an interface. To me, that means bolting "the mechanism" as an add on, across that gateway. Therefore we should leave the bits that are not the add-on as like normal DNS / ENUM operation as possible.

regards

Keith

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Friday, January 08, 2010 11:48 PM
> To: DRAGE, Keith (Keith)
> Cc: Elwell, John; [email-masked]
> > The mechansism should allow handling of inbound requests 
> and outbound requests between SSP and PBX to be as common as 
> possible as for a normal peering arrangement (e.g. RFC 3263 
> based), as far as the PBX is concerned. The handing of 
> requests at the incoming / outgoing gateway in the edge PBX 
> should be common once the mechanism has been applied.
> >
> > Essentially this means that the Request-URI should not be 
> replaced by the SSP on requests sent to the PBX.
> >    
> 
> Fundamentally, this is a 3261 registrar relationship 
> (regardless of whether we use NOTIFY or REGISTER), not a 3263 
> relationship. In particular, what you propose cannot co-exist 
> with the requirement:
> 
> dueto one side using the mechanism and the other side not.
> 
> 
> Because a failure to rewrite the URI means that the URI will 
> still resolve to the SSP under 3263 rules (since that's how 
> it got there in the first place). So, if it sends it to the 
> PBX, and the PBX doesn't use the MARTINI mechanism, it will 
> apply 3263, and route it back to the SSP. 
> The SSP will then apply MARTINI rules and route it to the 
> registered PBX. Who will route it to the SSP. Which will then 
> route it to the PBX.
> 
> And so on.
> 
> In particular, I think what you're describing is a 
> requirement, but it should be "MUST NOT", instead of SHOULD."
> 
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Jan 2010 18:18:21 -0600

> And here is where we start having the difference in philosophy.

I think we're more closely aligned in philosophy than you believe. We've 
just drawn different conclusions. For example: I agree, in as strong 

> The correct mechanism for connecting two networks together is to peer them, i.e. requests-URIs are not normally rewritten.

Yes! The correct way to do this is 3263 routing! I can't agree more!

> That therefore should be the starting point of what PBXs have implemented.

That would be great! It would also be a different reality, apparently.

MARTINI's very existence is predicated on the assertion that there are 
PBXes and/or SSPs out there that don't -- and for unstated reasons 
apparently won't ever -- properly implement peering using 3263 rules. 
Starting from the position that they should have done so is tilting at 
windmills.

> What we are then looking for is something that makes the life of the SSPs easier in some circumstances regarding configuration, to support such an interface. To me, that means bolting "the mechanis…

Ah, see here's what I'm talking about -- same philosophy, different 
conclusions. We both believe that the correct way to do this is with 
3263. But you conclude that the best thing to do is split the baby by 
making a Location Sever DB/3263 hybrid. I've concluded that the dynamic 
approach, despite it being the wrong tool, is more closely modeled by 
the dynamic location mechanisms we already have in SIP -- so, the 
associated routing procedures should most closely mimic that.

I can clearly describe what goes wrong, in a very real sense, with your 
proposal. We would need to solve the looping problem if we go down the 
path you're advocating. Which, even if it is a tractable problem to 
solve, is still one more problem you are choosing to introduce into the 
situation.

/a

---

From: "David Hancock" <[email-masked]>
Date: Fri, 8 Jan 2010 17:27:18 -0700

Adam,

Just to clarify, you're saying Flow-1 is bad, because it creates a
routing loop. (The following flows assume the IP-PBX has used implicit
registration to bind the enterprise AORs to a single IP-PBX contact
address.)

========================= Flow-1 ================================

Some network             SP Network                    IP-PBX
------------             ----------                    ------
[1]INVITE sip:[email-masked] -->

                            [2]INVITE sip:[email-masked] -->
                               Route: sip:<pbx contact>

                            [3]<-- INVITE sip:[email-masked]

================================================================

To avoid the routing loop, the SP network must retarget the Request-URI
of [2] so it contains the domain of the IP-PBX, as shown in Flow-2.

========================= Flow-2 ================================

Some network            SP Network                        IP-PBX
------------            ----------                        ------
[1]INVITE sip:[email-masked] -->

                            [2]INVITE sip:[email-masked] -->
                               Route: sip:<pbx contact>

================================================================

My understanding is that Keith's text "...the Request-URI should not be
replaced by the SSP on requests sent to the PBX" wasn't referring to
Flow-2, but to Flow-3, where the SP terminating home proxy retargets the
request to the registered contact address as shown in Flow-3. 

========================= Flow-3 ================================

Some network            SP Network                        IP-PBX
------------            ----------                        ------
[1]INVITE sip:[email-masked] -->

                            [2]INVITE sip:<pbx contact> -->

================================================================

My understanding is that Keith is saying that the message routing
procedure in Flow-2 should apply for both "subscription" and "peering"
modes (is that correct Keith?). 

I hope this clarifies and doesn't confuse the issue.

Thanks
David

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Adam Roach
> Sent: Friday, January 08, 2010 4:48 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> > The mechansism should allow handling of inbound requests and
outbound
> requests between SSP and PBX to be as common as possible as for a
normal
> peering arrangement (e.g. RFC 3263 based), as far as the PBX is
concerned.
> The handing of requests at the incoming / outgoing gateway in the edge
PBX
> > Essentially this means that the Request-URI should not be replaced
by
> the SSP on requests sent to the PBX.
> >
> 
> - The mechanism MUST provide a means of avoiding problems dueto one
side
> using the mechanism and the other side not.
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jan 2010 19:48:28 -0500

> For the PBX side, I have always considered an such mechanism as local to the gateway provided by the PBX, and not extending any further into the enterprise. If this applies, then it excludes any pr…

Seems to me that argument also works (or actual also *doesn't* work) in 
reverse: the "proxies" on the SSP side could be considered as a local 
mechanism to the registrar provided by the SSP.

If you look at it from the SSP side then you want your side to have the 
special treatment but are willing to sweep the issues of the other side 
under the rug. Same goes the other way.

The fact is that its quite possible that the architecture is:

	pbx --- enterprise_sbc --- SP_sbc --- SP_other_stuff

And the enterprise_sbc may be sourced independently of the pbx.
(Though of course we would be happy to sell you both.)

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 9 Jan 2010 02:00:42 +0100

Yes, but in that case why doesn't the enterprise SBC support the PBX end of "the mechanism", rather than the PBX itself.

Remember that the PBX network as a whole does not need to know about "the mechanism". It is purely local to the interface.

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Saturday, January 09, 2010 12:48 AM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> > With regard to the intermediate proxies requirement, can we 
> limit this to intermediate proxies in the SSP.
> > 
> > For the PBX side, I have always considered an such 
> mechanism as local to the gateway provided by the PBX, and 
> not extending any further into the enterprise. If this 
> applies, then it excludes any proxies on the PBX side of the gateway.
> 
> reverse: the "proxies" on the SSP side could be considered as 
> a local mechanism to the registrar provided by the SSP.
> 
> If you look at it from the SSP side then you want your side 
> to have the special treatment but are willing to sweep the 
> issues of the other side under the rug. Same goes the other way.
> 
> >> You have included a requirement that the mechanism MUST 
> work in the 
> >> presence of intermediate "proxies" between the PBX and the SSP's. 
> >> Don't we need as well a requirement about the presence of 
> >> intermediate enterprise proxies between the PBX and the SIP 
> >> terminals, especially when considering inbound requests?
> >>
> >>> Revised following the feedback since yesterday. Please 
> continue the 
> >>> feedback.
> >>>
> "proxies" 
> implementations, in 
> >> 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: <[email-masked]>
Date: Mon, 11 Jan 2010 09:20:01 +0100

I was alluding to this requirement as one of the reasons why the R-URI should not be replaced by the contact address (at least if we want to keep the gateway function as simple as possible).

> De : DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Envoyé : samedi 9 janvier 2010 00:46
> À : CHATRAS Bruno RD-CORE-ISS; [email-masked]
> Cc : [email-masked]
> Objet : RE: [martini] Requirements - rev1
> 
> For the PBX side, I have always considered an such mechanism 
> as local to the gateway provided by the PBX, and not 
> extending any further into the enterprise. If this applies, 
> then it excludes any proxies on the PBX side of the gateway.
> 
> regards
> 
> Keith 
> 
> > You have included a requirement that the mechanism MUST work in the 
> > enterprise proxies between the PBX and the SIP terminals, 
> especially 
> > when considering inbound requests?
> > 
> > France Telecom Group shall not be liable for the message if 
> altered, 
> > changed or falsified.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 11 Jan 2010 10:13:43 +0100

> Sent: 08 January 2010 23:48
> To: DRAGE, Keith (Keith)
[JRE] I agree with Adam, in that the Request-URI received by the PBX must be an AOR as recognised by the PBX, to avoid looping. For example, if the original Request-URI (as received by the SSP from the UAC) is sip:[email-masked] or tel:+12345, then it should be replaced by something like sip:[email-masked]. The point is, the Request-URI still identifies the target AOR, and is not simply the single contact URI that was registered.

So although it would seem reasonable to add a requirement along the lines that Keith suggested, I would be inclined to suppress the bit "Essentially this means..." as going beyond requirements.

John

> requirement, but it

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jan 2010 09:43:42 -0500

> Remember that the PBX network as a whole does not need to know about "the mechanism". It is purely local to the interface.

IMO the discussion is about a UAC sending a REGISTER request and a UAS 
processing and responding to a REGISTER request.

Within that context, either intervening proxies are supported or not.
I think its generally agreed that it is indeed necessary to support 
intervening proxies.

It is true that you might have an SBC that does the REGISTER, and a 
"pbx" behind it that is oblivious to the register. And in that case I 
think we can say that the relationship between those two is out of scope.

But it is also possible to have a "pbx" that does the REGISTER, and a 
proxy or SBC between it and the registrar, managed by the enterprise 
rather than the SP.

I don't see how it can matter who is in charge of intermediates between 
the registering UA and the registrar. (Or how making such a distinction 
would help anything.)

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 11 Jan 2010 09:24:45 -0600

David:

I think you've represented my concerns accurately below. I still think 
that Keith is advocating Flow-1.

Keith: can you clarify your position?

/a

On 1/8/10 6:27 PM, David Hancock wrote:
>> the first place). So, if it sends it to the PBX, and the PBX doesn't
>>      
> use
>    
>> the MARTINI mechanism, it will apply 3263, and route it back to the
>>      
> SSP.
>    
>> PBX. Who will route it to the SSP. Which will then route it to the
>>      
> PBX.
>    
>> And so on.
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 14 Jan 2010 12:02:56 -0500

I think you guys are talking past each other, or maybe are actually in vehement agreement without realizing it.

Imagine we have SSP-A and SSP-B.

In a 3263 peering relationship, if SSP-A gets a request for sip:[email-masked], it won't change the request-uri, and there will NOT be a loop, because the RURI's domain is *SSP-B*.

IF SSP-A gets a request for sip:[email-masked], and it sends it to SSP-B, it must *retarget* the request, BEFORE applying 3263 procedures.  Thus it WILL replace the RURI, with at least SSP-B.com.

So in this Registration-based mechanism we ARE talking about doing the same thing as 3263 procedures.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of DRAGE, Keith (Keith)
> Sent: Friday, January 08, 2010 6:39 PM
> To: Elwell, John; [email-masked]
> The mechansism should allow handling of inbound requests and outbound
> requests between SSP and PBX to be as common as possible as for a normal
> peering arrangement (e.g. RFC 3263 based), as far as the PBX is concerned.
> The handing of requests at the incoming / outgoing gateway in the edge PBX

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Jan 2010 11:19:08 -0600

> In a 3263 peering relationship, if SSP-A gets a request for sip:[email-masked], it won't change the request-uri, and there will NOT be a loop, because the RURI's domain is *SSP-B*.

And, far more importantly, applying DNS to SSP-B returns an IP address 
belonging to one of SSP-B's servers. *That* is why it won't loop.

> So in this Registration-based mechanism we ARE talking about doing the same thing as 3263 procedures.

The problem is that Keith is using phrases like "the Request-URI should 
not be replaced by the SSP on requests sent to the PBX."

Let's step through the ramifications of that statement.

It had to arrive at the SSP somehow, right? How did it get there?

The only plausible answer is that the Request URI that arrived at the 
SSP contains a domain that, when fed into DNS, returns an IP address 
pointing to a server at the SSP.

Now, let's apply Keith's assertion that this URI "should not be replaced."

This means that the request will arrive at the PBX with a RURI that 
points back to a machine at the SSP. In your example, this would be 
equivalent to SSP-A getting a request for "sip:[email-masked]" and 
forwarding it to SSP-B *WITHOUT* *CHANGING* *THE* *REQUEST* *URI*.

You and I can see that this is a fantastically bad idea. In fact, it's 
so mind-numbingly obvious to you that you apparently can't bring 
yourself to believe that this is exactly what Keith and John are 
lobbying for.

But read their words carefully.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jan 2010 21:26:36 +0100

> Sent: 14 January 2010 17:19
> To: Hadriel Kaplan
> Cc: DRAGE, Keith (Keith); Elwell, John; [email-masked]
> > I think you guys are talking past each other, or maybe are 
> actually in vehement agreement without realizing it.
> >
> > In a 3263 peering relationship, if SSP-A gets a request for 
> sip:[email-masked], it won't change the request-uri, and 
> there will NOT be a loop, because the RURI's domain is *SSP-B*.
> >    
> 
> > IF SSP-A gets a request for sip:[email-masked], and it 
> sends it to SSP-B, it must *retarget* the request, BEFORE 
> applying 3263 procedures.  Thus it WILL replace the RURI, 
> with at least SSP-B.com.
> >
> > So in this Registration-based mechanism we ARE talking 
> about doing the same thing as 3263 procedures.
> >    
> 
[JRE] I am not lobbying for the case where a request to [email-masked] is passed on by ssp.com to pbx.com. In that case the Request-URI would have to be changed. However, if a request to [email-masked] arrives at ssp.com (because 3263 routing takes it there), in that case it should be passed on unchanged to [email-masked]. I can't speak for Keith, but I perhaps that was the case he was referring to.

John

> [mailto:[email-masked]] On Behalf
> >> Of DRAGE, Keith (Keith)
> and outbound

---

From: Adam Roach <[email-masked]>
Date: Sat, 16 Jan 2010 21:28:04 -0600

On 1/14/10 2:26 PM, Elwell, John wrote:
> However, if a request [email-masked]  arrives at ssp.com (because 3263 routing takes it there)...
>    

Let me finish that sentence for you.

"...then the domain pbx.com belongs to ssp.com."

And that's where the problem starts.

In your view, in this example, who is responsible for the domain "pbx.com"?

/a

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jan 2010 09:26:46 +0100

Adam,

In that example, the PBX is responsible for pbx.com. However, the SP has a role in routing calls there.

John

> Sent: 17 January 2010 03:28
> To: Elwell, John
> Cc: Hadriel Kaplan; DRAGE, Keith (Keith); [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jan 2010 09:22:26 -0500

> In that example, the PBX is responsible for pbx.com. However, the SP has a role in routing calls there.

You are saying that the DNS lookup for pbx.com resolves to the SSP, but 
that the pbx, not the SSP, is *responsible* for the domain?

This is either broken, or else it is a sort of relationship for which we 
currently have no definition. It either requires hairpinning through the 
ssp for calls between pbx devices, or else it requires something akin to 
a split DNS to avoid that.

If this is to be considered valid, then I think some careful 
specification will be needed to ensure that it will be used in a correct 
way.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 18 Jan 2010 12:46:12 -0600

> In your view, in this example, who is responsible for the domain  

Let's see if I can restate John's position:

The PBX has delegated RFC 3263 handling for "pbx.com" to the SSP.

 From a configuration perspective, the PBX "knows" it is authoritative  
for "pbx.com". The SSP knows it is a relay for "pbx.com".  External  
parties, relying on RFC 3263 resolution, find the relay at SSP instead  
of the PBX.

Incoming requests arrive at the  SSP with a target of "pbx.com", and  
the SSP routes those requests on to pbx.com unchanged (except for a  
recorded route). The pbx doesn't bother to do a 3263 lookup, because  
it is configured to use pbx.com as as local domain. This is a common  
model of operation for email systems dating to UUCP days. It would  
have worked on unmodified dynamicsoft proxies from 2003.

Where's the confusion?

Certainly there is a possibility of a misconfiguration. The SSP could  
think that the PBX is authoritative for "pbx.com" while the PBX  
doesn't, and this would cause a loop. It's an evident and obvious  
misconfiguration. If it hurts, don't do it!

 From the PBX's point of view, the SSP is just a relay proxy, what we  
would have called an "outbound proxy" ten years ago (before draft-ietf- 
sip-outbound changed that). No explicit signaling indicator of this  
relay behavior appears to be needed; it's just basic RFC 3261 on the  
wire, augmented by relay policy at SSP and an "outbound proxy" setting  
at PBX.

The real question is how PBX informs SSP of its current route and  
status. Is it static configuration, REGISTER, or something else?

--
Dean

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Jan 2010 21:07:10 +0000

Paul said: 

"You are saying that the DNS lookup for pbx.com resolves to the SSP, but 
that the pbx, not the SSP, is *responsible* for the domain?"

[BA] There are a number of DNS RRs we could be talking about here. 
For example, there are the A/AAAA RRs; and there are the SRV RRs. 

They don't necessarily have to point to the same place.  For example,
The A/AAAA RRs could point to the PBX while the SRV RRs could conceivably
point to *both* the PBX and the SP (to provide backup).  So I'm not
clear precisely what "DNS lookup" is referring to here. 

Paul said:

"If this is to be considered valid, then I think some careful 
specification will be needed to ensure that it will be used in a correct 
way."

[BA] The question in my mind is whether that "careful specification"
needs to occur in MARTINI or not. 

It seems like this issue also occurs in classic "static mode" deployments 
as well (where MARTINI mechanisms  would presumably not be used).  In
that case, why is this problem specific to MARTINI?

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jan 2010 22:47:45 +0100

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: 18 January 2010 21:07
> To: Elwell, John
> Cc: [email-masked]
[JRE] Yes, that has been bothering me. I don't see it as something specific to MARTINI.

John

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 18 Jan 2010 14:25:21 -0800

Paul said: 

[BA] There are a number of DNS RRs we could be talking about here.  For
example, there are the A/AAAA RRs; and there are the SRV RRs (and maybe
NAPTR RRs). 

They don't necessarily have to point to the same place.  For example, The
A/AAAA RRs could point to the PBX while the SRV/NAPTR RRs could conceivably
point to *both* the PBX and the SP (to provide backup).  So I'm not clear
precisely what "DNS lookup" is referring to here. 

Paul said:

"If this is to be considered valid, then I think some careful specification
will be needed to ensure that it will be used in a correct way."

[BA] The question in my mind is whether that "careful specification" needs
to occur in MARTINI or not. 

It seems like this issue also occurs in classic "static mode" deployments as
well (where MARTINI mechanisms  would presumably not be used).  In that
case, why is this problem specific to MARTINI?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jan 2010 17:44:51 -0500

> clear precisely what "DNS lookup" is referring to here. 

Its true that 3261 isn't especially clear about what it means for a 
server to be responsible for a domain. But to avoid hyjacking, their 
ought to be *some* relationship between the domain name in the sip URI, 
the DNS entries for that domain, and the server claiming responsibility.
Maybe it shouldn't be specified in Martini, but it ought to be defined 
*somewhere* in sufficient detail that this can work for Martini.

Perhaps we can first figure out what the relationship needs to be, and 
then decide where it ought to be defined.

ISTM that it must be something like:
- whoever is responsible for the content of the DNS SIP SRV entry for a
   domain may designate which servers may claim responsibility for
   sip requests addressed to URIs containing that domain.

I realize that is overly squishy, but I offer it as a starting point.

This would allow whoever has the rights to the DNS entries for pbx.com 
to designate that both the pbx and the appropriate ssp servers may claim 
responsibility for pbx.com. Beyond that, it seems that this martini 
approach may be dicing "responsibility" into sub-roles for that domain 
that are then assigned to the ssp and the pbx.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Jan 2010 18:57:16 +0100

Yes, Dean has stated my position better than I did!

John 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 18 January 2010 18:46
> To: Adam Roach
> Cc: Elwell, John; [email-masked]; Hadriel Kaplan

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Jan 2010 14:13:07 -0600

I've been looking at Dean's note (below), and wanted to say something out 
loud that I've been thinking to myself... speaking as an individual, of 
course.

We asked that MARTINI be chartered with a very short timeline for 
milestones, because we want to use the output of MARTINI in various places 
like SIPconnect 1.1, and we need that output really badly.

Speaking as an individual, I was hoping that we would nail down solution 
mechanisms in the charter, but we didn't do that, and I'm actually OK with 
the tone, pace and direction that I've been seeing in discussions about 
solution mechanisms so far ...

... but I'm very concerned about the idea that MARTINI would need to nail 
down the details that Dean is describing here, in order to produce a 
solution specification. I'm not saying that Dean thinks this is necessary, 
but I am hearing other people talking about whether it's necessary.

>From my perspective, we're talking about whether MARTINI is not chartered to 
solve a problem that isn't MARTINI-specific, has not been previously solved 
at the IETF (because we've never drawn a "SIP pentazoid" that looks like

    p --- SP
   /        \
  UA        PBX
              \
              UA

in a way that led the IETF SIP community to describe how the SP-PBX part of 
this diagram would actually work using RFC 3263), but must be solved so that 
we can describe
how this would actually work in MARTINI mode (which IS MARTINI-specific).

If I'm reading Dean's note correctly, he's saying that all this is 
business-as-usual for RFC 3263 DNS routing, RFC 3261 REGISTER-based routing, 
and (he didn't say this, but I'm extrapolating) whatever mechanism we end up 
selecting for MARTINI, so the problem isn't MARTINI-specific, and shouldn't 
be a MARTINI dependency.

Do people disagree with my understanding here? (Especially, but not limited 
to, Dean?)

Because if people disagree, we're tripping over new work that needs to be 
DISPATCHed, and we're already post-"tell the DISPATCH chairs/working group 
that a new proposal is coming" for IETF 77. :-(

Thanks,

Spencer

> From a configuration perspective, the PBX "knows" it is authoritative  for 
> "pbx.com". The SSP knows it is a relay for "pbx.com".  External  parties, 
> relying on RFC 3263 resolution, find the relay at SSP instead  of the PBX.
>
> Incoming requests arrive at the  SSP with a target of "pbx.com", and  the 
> SSP routes those requests on to pbx.com unchanged (except for a  recorded 
> route). The pbx doesn't bother to do a 3263 lookup, because  it is 
> configured to use pbx.com as as local domain. This is a common  model of 
> operation for email systems dating to UUCP days. It would  have worked on 
> unmodified dynamicsoft proxies from 2003.
>
> Where's the confusion?
>
> think that the PBX is authoritative for "pbx.com" while the PBX  doesn't, 
> and this would cause a loop. It's an evident and obvious 
> sip-outbound changed that). No explicit signaling indicator of this  relay 
> behavior appears to be needed; it's just basic RFC 3261 on the  wire, 
> augmented by relay policy at SSP and an "outbound proxy" setting  at PBX.
>
> The real question is how PBX informs SSP of its current route and  status. 
> Is it static configuration, REGISTER, or something else?
>
> --
> Dean
>

---

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

Spencer,

I agree with you.

John 

> [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: 19 January 2010 20:13
> To: Dean Willis; Adam Roach
> Cc: [email-masked]; Hadriel Kaplan
> >>> However, if a request [email-masked]  arrives at ssp.com 
> (because  3263 
> >>> routing takes it there)...
> >>>
> >>

---

From: David Hancock <[email-masked]>
Date: Tue, 19 Jan 2010 17:22:13 -0700

Spencer,

I agree with your overall summary below.

Furthermore, not only does this routing issue exist for the IP-PBX case you identified...

    p --- SP
   /        \
  UA        PBX
              \
              UA

... I think it exists more generally, say to the transit network case. 

    SP(a) --- SP(transit) --- SP(b)
    /                          \
   /                            \
  UA1                           UA2
 
I'm sure this transit case happens today. How is it being done?

It seems this is either... 

a) a non-issue because it's being handled today in a standards-complaint manner, or

b) a real issue (because it's being done in a non-standard way) but is outside the scope of MARTINI (SPEERMINT, perhaps?).

Thanks
David

> Of Spencer Dawkins
> Sent: Tuesday, January 19, 2010 1:13 PM
> >>> However, if a request [email-masked]  arrives at ssp.com (because
> 3263
> for
> the
> doesn't,
> relay
> status.

---

From: David Hancock <[email-masked]>
Date: Wed, 20 Jan 2010 10:25:21 -0700

The list includes a requirement that mechanism should scale to many AORs on a single PBX. Do we also need a requirement for the case where there are many PBXs on a single network? 

Something like ... 
"The mechanism must be scale to support several thousand IP-PBXs on a single service provider network."

Thanks
David

> Of Elwell, John
> Sent: Friday, January 08, 2010 10:46 AM
> To: [email-masked]
> - The mechanism MUST allow the PBX to be responsible for its AORs and to
> handle requests to those AORs according to its rules.
> - The mechanism MUST allow the PBX to receive requests to its AORs that
> originate off-PBX and arrive via the SSP, so that the PBX can handle those
> requests according to its rules.
> - The mechanism MUST provide a means of avoiding problems due to one side
> between the PBX and the SSP's domain proxy, where those intermediate
> - The mechanism SHOULD allow SSPs to exploit its mechanisms for providing
> SIP service to ordinary subscribers in order to provide a SIP trunking
> service to PBXs.
> - The mechanism SHOULD require relatively modest changes to a substantial
> population of existing SSP and PBX implementations, in order to encourage
> a fast market adoption of the standardized mechanism.
> 
> John
> 
> 
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Jan 2010 22:02:44 +0100

Yes, of course. I will try to put out a revised reqs list when I have chance, but in the meantime please keep the suggestions coming in.

John 

> From: David Hancock [mailto:[email-masked]] 
> Sent: 20 January 2010 17:25
> The list includes a requirement that mechanism should scale 
> to many AORs on a single PBX. Do we also need a requirement 
> for the case where there are many PBXs on a single network? 
> 
> Something like ... 
> "The mechanism must be scale to support several thousand 
> IP-PBXs on a single service provider network."
> 
> Thanks
> David
> 
> its AORs and to
> due to one side
> for providing

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 20 Jan 2010 13:16:41 -0800

WARNING: contains banned part

Subject: RE: [martini] Requirements - rev1
From: "Bernard Aboba" <[email-masked]>
To: "'Spencer Dawkins'" <[email-masked]>, "'Dean Willis'" <[email-masked]>, "'Adam Roach'" <[email-masked]>
Cc: <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>
Date: Wed, 20 Jan 2010 13:16:41 -0800

I assume you're referring to this message:
http://www.ietf.org/mail-archive/web/martini/current/msg00210.html

In it, Dean makes a number of points, including:

1.  That the domain pointed to by a NAPTR/SRV/MX RR may not necessarily be
authoritative for the domain (it could just be a relay).  
2.  That while misconfiguration can occur, this is not inherently caused by
pointing the NAPTR/SRV/MX RRs to one entity vs. the other, but rather by
mismatches in the configuration of the entities.

Dean notes:

"This is a common model of operation for email systems dating to UUCP days.
It would have worked on unmodified dynamicsoft proxies from 2003...."

So one question that comes to mind is whether points 1 and 2 can be accepted
as points of reference for SIP and whether there is agreement with Dean's
statement that: 

"The real question is how PBX informs SSP of its current route and status.
Is it static configuration, REGISTER, or something else?" 

If there is disagreement on points 1 & 2, the next question is whether
MARTINI is the right place to resolve that disagreement.  Since these issues
relate to configuration of SRV/MX/NAPTR RRs, they arise both in the static
case (where static A/AAAA RRs are configured) as well as in the dynamic case
(where the A/AAAA RRs may be dynamically updated).   Given that, the
question is whether this is a problem that is unique to MARTINI scenarios.

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Jan 2010 21:50:43 -0600

On Jan 19, 2010, at 2:13 PM, Spencer Dawkins wrote:

> ...
> business-as-usual for RFC 3263 DNS routing, RFC 3261 REGISTER-based  
> routing, and (he didn't say this, but I'm extrapolating) whatever  
> mechanism we end up selecting for MARTINI, so the problem isn't  
> MARTINI-specific, and shouldn't be a MARTINI dependency.

> status. Is it static configuration, REGISTER, or something else?

We have a standing practice of using static configuration, and know  
that this has severe limitations in a DHCP world, so what we're trying  
to do is standardize a dynamic binding mechanism between PBX and SSP  
that overcomes those limitations.

And I think THIS is the "MARTINI" question. Hadriel's draft proposes  
overloading REGISTER to inform the SSP. Adam's draft proposes an event  
package which is PUBLISHed to SSP to inform it. MARTINI picks one (r  
invents yet another solution) and standardizes it.

Maybe if there is a great deal of confusion over what SSP does with  
the information (which AFAIK is use it to add a Route: header field  
value, or possibly a vector of values) then we need to document it  
just to clear up the uncertainty, but to my mind there is no  
uncertainty here; there's only one thing that is reasonable to do, and  
the other things people have proposed that SSP might do are pretty  
clear unhinged.

Personally, I think it would be very useful to advertise a routing  
vector rather than a single hop, and REGISTER semantics really only  
allow for a single hop. I believe that this is a design flaw in  
REGISTER, which is responsible for a great deal of the complexity in  
Outbound, Service-Route, and Path, all of which should have been more  
properly resolved just by fixing REGISTER so that it records a route- 
vector (list of routes) rather than a Contact. And  I wish that  
solving this weakness in REGISTER was the goal of MARTINI, because  
that would be very very cool.

--
dean

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Jan 2010 08:43:57 +0100

> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 21 January 2010 03:51
> To: Spencer Dawkins
[JRE] But the problems have been solved for REGISTER using Outbound, Service-Route and Path, so it is a simple matter to reuse those.

John

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Jan 2010 01:24:48 -0600

On Jan 21, 2010, at 1:43 AM, Elwell, John wrote:
>>
> [JRE] But the problems have been solved for REGISTER using Outbound,  
> Service-Route and Path, so it is a simple matter to reuse those.

Not really. Adam has effectively pointed out several of the the rather  
large number of issues related to trying to extend the REGISTER  
metaphor to cover advertisement of routes for domains and phone number  
ranges. Although it looks good at first glance, once you really dig  
into what it means to "register a contact for an AOR" versus  
"registering a route for a domain", things start to get messy.  
Consider for example the debate we're currently having about whether  
the SSP does "contact routing" and replaces the r-URI with a  
registered contact, or does "domain routing" and just pushes the  
registered route onto the route stack (really, it MUST do the latter,  
but REGISTER implies the former, which makes it something of a hack).  
Seriously, go back and look at Adam's arguments very carefully. He  
might wear excessively colorful trousers from time to time, but I  
think most of his arguments are spot-on. Please everybody: go read  
draft-roach-martini-up-00 and pay very careful attention to Section 9.

You claim that the use of REGISTER is justified because the trifecta  
of Outbound, Service-Route, and Path solves the multi-hop route  
advertisement problem.

Let's consider Outbound, for example. Outbound works for a single  
contact of an AOR because it allows binding the credentials of that  
single AOR to the persistent connection established to the contact.  
Once the "contact" represents a large number of AORs, the security  
assumptions around Outbound are completely broken. This, by the way,  
is also the "connection reuse" problem. We really need to extend our  
AAA model to consider domains and phone-number ranges.  Further,  
Outbound really provides for connection use at only a single relay  
(the "outbound proxy"), and a general solution needs to allow  
persistent multi-hop routes (multiple "outbound proxies" in sequence).  
I might, for example, be behind a NAT router at my house, which is in  
itself VPNed to a concentrator at my office, which is also NATed back  
to the Internet, and the "ssp" and "pbx" proxy nodes could be anywhere  
up or down that hierarchy. There might even be multiple layers of  
"ssp" proxy involved, and it would be very nice to establish the  
required routing dynamically rather than having all that static  
configuration.

As the editor of Service-Route and Path, I can tell you that they're  
pretty conclusively broken in the general model. Sure, they work for  
the single-point scenarios of IMS that inspired them, but a fully  
symmetric general route solution would have been a much cleaner  
solution to the problem.

A maxim to consider: an authenticated single-hop route towards a user  
is NOT the same as an authenticated connection to the user. The same  
is true of any multi-hop route that is not authenticated all the way  
to the user.  Consequently, an authenticated route to a domain is much  
different than a route between an authoritative proxy and a contact  
registered to an AOR homed at that proxy.

Outbound, Route, and Service-Route are all based on the idea that we  
have a unique vector through a singular "sticky point" (the outbound  
proxy) to a single end user. That, however, is NOT the scenario in  
domain/range routing, and the assumptions of the security model  
require careful re-examination.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Jan 2010 09:11:39 -0500

Dean,

I don't think the points you make about security assumptions have been 
raised before, and they are important.

OTOH, I surmise many of those that are requesting this work may have 
more limited expectations. Specifically, the argument that "the PBX *is* 
the user" may indeed apply in the case where the PBX is itself a B2BUA 
and does all the identity management for all the numbers it is 
responsible for. So perhaps the registration model would be applicable 
in that limited (but large) scope of applicability.

	Thanks,
	Paul

Dean Willis wrote:
> large number of issues related to trying to extend the REGISTER metaphor 
> to cover advertisement of routes for domains and phone number ranges. 
> Although it looks good at first glance, once you really dig into what it 
> means to "register a contact for an AOR" versus "registering a route for 
> a domain", things start to get messy. Consider for example the debate 
> we're currently having about whether the SSP does "contact routing" and 
> replaces the r-URI with a registered contact, or does "domain routing" 
> and just pushes the registered route onto the route stack (really, it 
> MUST do the latter, but REGISTER implies the former, which makes it 
> something of a hack). Seriously, go back and look at Adam's arguments 
> very carefully. He might wear excessively colorful trousers from time to 
> time, but I think most of his arguments are spot-on. Please everybody: 
> go read draft-roach-martini-up-00 and pay very careful attention to 
> Section 9.
> 
> You claim that the use of REGISTER is justified because the trifecta of 
> Outbound, Service-Route, and Path solves the multi-hop route 
> advertisement problem.
> 
> single AOR to the persistent connection established to the contact. Once 
> the "contact" represents a large number of AORs, the security 
> assumptions around Outbound are completely broken. This, by the way, is 
> also the "connection reuse" problem. We really need to extend our AAA 
> model to consider domains and phone-number ranges.  Further, Outbound 
> really provides for connection use at only a single relay (the "outbound 
> proxy"), and a general solution needs to allow persistent multi-hop 
> routes (multiple "outbound proxies" in sequence). I might, for example, 
> be behind a NAT router at my house, which is in itself VPNed to a 
> concentrator at my office, which is also NATed back to the Internet, and 
> the "ssp" and "pbx" proxy nodes could be anywhere up or down that 
> hierarchy. There might even be multiple layers of "ssp" proxy involved, 
> and it would be very nice to establish the required routing dynamically 
> rather than having all that static configuration.
> 
> pretty conclusively broken in the general model. Sure, they work for the 
> single-point scenarios of IMS that inspired them, but a fully symmetric 
> general route solution would have been a much cleaner solution to the 
> problem.
> 
> A maxim to consider: an authenticated single-hop route towards a user is 
> NOT the same as an authenticated connection to the user. The same is 
> true of any multi-hop route that is not authenticated all the way to the 
> user.  Consequently, an authenticated route to a domain is much 
> domain/range routing, and the assumptions of the security model require 
> careful re-examination.
> 
> -- 
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Jan 2010 11:14:20 -0600

On Jan 22, 2010, at 8:11 AM, Paul Kyzivat wrote:

> Dean,
>
> I don't think the points you make about security assumptions have  
> been raised before, and they are important.
>

Thanks! I try to say at least one relevant thing for every three crazy  
ones.

> more limited expectations. Specifically, the argument that "the PBX  
> *is* the user" may indeed apply in the case where the PBX is itself  
> a B2BUA and does all the identity management for all the numbers it  
> is responsible for. So perhaps the registration model would be  
> applicable in that limited (but large) scope of applicability.

You have an excellent point.

If the SSP were a traditional proxy/registrar that is authoritative  
for the domain and the PBX were a multi-user telephone adapter with  
credentials for each user in the domain, such that the PBX could send  
a unique REGISTER for each user, then we might well be having a  
different conversation. This conversation would be about ways to  
reduce the number of REGISTER messages required to effect registration  
of the PBX as a contact for each user. So we might be talking about  
"multiple authentication", perhaps extending the digest-authentication  
model to allow a separate authentication header for each AOR being  
registered. This would preserve the property that the proxy/registrar  
has established an authenticated relationship between each AOR and its  
Contact, a property that is fundamental to REGISTER within RFC 3261  
and its current kin. Such an approach would clearly work reasonably  
well within our current security assumptions, although it should be  
noted that it does not prevent "identity substitution" attacks in the  
PBX. For example, if the PBX chose to claim that a call is from Bob  
when in fact the originating user is Alice, the SSP has no way to  
determine that this substitution has been made. This is a fundamental  
property of a shared connection in SIP (or indeed, in multi-user  
systems in general; how do you know this email came from me and not my  
sysadmin?) and there's not a lot we can do about it short of requiring  
users to provide single-use keys for each transaction (the equivalent  
of me signing this message using PGP).

If we scoped the applicability to such an environment, then I'd be  
willing to accept that REGISTER can be used for a domain, at least to  
the extent I think it works for an individual user (I think REGISTER  
is deeply wounded and we've had to put a lot of ugly bandaids on it to  
keep it from bleeding out). MARTINI could quite reasonably define an  
extension to REGISTER that works within this scope.

However, our discussion recently has centered on models where SSP is  
NOT authoritative for the domain in-question; rather it is just one of  
many possible relays that might be used to reach the domain- 
authoritative "PBX". This model potentially allows SSP to make  
different security assertions. For example, SSP could assert 1) that  
SSP is transitively authorized as a route for reaching the domain of  
pbx.com, and that 2) a request exiting through SSP comes from some  
user in the domain of PBX. Note that this second assertion is not the  
same as SSP being able to assert that a specific user in the domain is  
involved. In this model, only PBX (or perhaps the user itself) can  
make assertions about specific user identities.

The fundamental security question: How does SSP prove to others that  
it is authorized to route requests to/from the domain of PBX? We don't  
have a security framework for this in SIP. This leads to the "alt  
root" problem we recently discussed. What keeps a rogue node from  
claiming to be authoritative as a route toward a domain? For that  
matter, what keeps a node from claiming to be authoritative for a  
domain itself, rather than just as a route toward that domain?

Let's start with this second question and work backwards. Our  
fundamental security model (when we have any security at all) assumes  
that the node that is authoritative for a domain has in its possession  
booth the public and private keys needed to cryptographically assert  
that domain. This understanding comes from the basic references of TLS  
in RFC 3261, and is echoed in our various documents (draft-ietf-sip- 
certs, draft-ietf-sip-domain-certs, etc.). So if we make a TLS  
connection to a node, and that TLS connection uses at the other end a  
trusted cert for the domain in question, then we assume that the other  
end is trusted to assert identities within that domain. RFC 3274  
provides a transitive mechanism for assertion of identity in the  
context of a SIP request message that is also based on this model of  
certification.

So what we need is something like RFC 3274 for route certification.  
This has to allow for route redistribution and aggregation, since  
there might be more than one relay proxy between the source and  
destination of a SIP request. Adam's draft-roach-martini-up-00 defines  
a possible syntax for a "route" (using XML), as well as a means for  
advertising a route (PUBLISH). One can readily envision adding a  
signature to this syntax. It's straightforward then to go from a  
single-hop route to a routing vector, where each hop in the vector is  
signed by the next hop, providing a fully certificated transit chain  
to the destination.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Jan 2010 11:15:43 -0600

> but REGISTER implies the former, which makes it something of a hack).

I'm not sure it must do the latter. I think there are some people here 
whose use cases will work if you do it that way, but I think a careful 
examination of everyone's position will show that it simply won't work 
for others'.

On the other hand, the "contact routing" approach, as far as I can tell, 
will work for all the use cases described so far, as long as we have the 
ability to define a mapping from AOR to contact URI in some sensible 
fashion. The martini-up draft gives an existence proof of such a 
mechanism -- and the mechanism is hardly NOTIFY-specific. It could be 
used just as sensibly with REGISTER.

So, let's take a quick look at the "contact routing" approach versus the 
"domain routing" approach. I hope you'll excuse that I'm stepping 
slightly outside IETF norms to convey these concepts clearly: to save 
the confusion among "example.com," "example.org," and "example.net," I'm 
going to use dead companies in my example; I'm also going to use inline 
images for my diagrams.

Ignoring how the information gets there in the first place, the "domain 
routing" approach looks sensible at first blush for this kind of 
application. Here is an SSP and two of its customers. Through some 
non-DNS mechanism, the SSP knows to route the domain "pan-am.com" to the 
Pan Am PBX, and to route the domain "braniff.com" to the Braniff PBX:

Great. Aside from the somewhat nonstandard determination of the next-hop 
server at the SSP, this is pretty normal handling.

That said, MARTINI has a special relationship with phone numbers. 
They're in our charter: " The solution will support AoRs with E.164
addresses at a minimum, although support for other classes of AoRs may 
be included." So, let's explore what that ends up meaning.

As long as we expect some external party (not the SSP) to determine what 
domain each E.164 number belongs to, then everything works the same as 
my previous example:

And, if that's good enough, then great. But I'm willing to bet that at 
least one person working in this space looks at that diagram and says, 
"No! That's not what I meant! I want the SSP to handle the number mapping."

Now, if we stick with the "the SSP does not rewrite the URI" approach 
that Keith and John are rather adamant about, the only thing we can 
really do in terms of "these numbers go here, those numbers go there" 
looks something like this:

I suspect most people can tell that's wrong by simple inspection. What 
I'm willing to bet people are expecting is something more like this:

But that's most certainly not the "domain routing" model Dean is talking 
about. In fact, it's pretty much the "contact routing" model straight 
up, with an AOR to Contact mapping of "sip:[email-masked] 
=> sip:[email-masked]" (and a similar one for +15005550200).

Okay, great. So the "contact routing" approach works fine for the later 
cases. But what about the people who want to register entire domains? 
That's the neat thing about the "contact routing" approach -- if done 
correctly, it works just fine for those cases, too. Going back to the 
first example; if we perform normal "contact routing" -- URI rewriting 
and all -- and have the PBXes register their IP addresses as the mapped 
contacts, everything works fine:

This is great! Now we're using REGISTER to put an AOR to Contact mapping 
in place (like it always has) instead of using it to install rules to 
override normal RFC3263 handling. Best of all, we're not saying "ignore 
DNS and use this alternate mechanism for turning names into addresses" 
like we have to with the "domain routing" approach.

So, Dean: can you explain what breaks if we use "contact routing" for 
all the use cases described so far?

/a

---

From: "Brian Lindsay" <[email-masked]>
Date: Fri, 22 Jan 2010 14:31:18 -0500

Hi Adam,
 
   Regarding the case below, you could use a "domain routing" approach
for this as well.
 
   For example, the SSP could perform an intermediate step (e.g. using a
local "Look-Up Function" to borrow from SPEERMINT terminology) that
effectively provides the mapping from the E.164 number to the pbx domain
and does the conversion from sip:[email-masked]
<sip:[email-masked]>  => sip:[email-masked]
<sip:[email-masked]> . After that the routing mechanism kicks
in.

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
Sent: Friday, January 22, 2010 12:16 PM
To: Dean Willis
Cc: Hadriel Kaplan; [email-masked]
Subject: Re: [martini] Requirements - rev1

[... text deleted ....]

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Jan 2010 17:22:02 -0600

> case, why is this problem specific to MARTINI?

Yes, there will be similar and congruent problems that arise in general 
purpose peering with third-party intermediaries. And I assume that 
SPEERMINT and/or DRINKS will come up with solutions to those issues. 
However, if we rely on those solutions in MARTINI while simultaneously 
punting on working out what those solutions are, then we are effectively 
adding requirements to SPEERMINT and/or DRINKS to analyze their 
solutions in the context of dynamic domain registration.

Or we can sidestep the issue altogether by using REGISTER like 3261 uses 
it: to bind AORs to contacts.

Assuming both approaches work for the MARTINI problem, which one seems 
safer?

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Jan 2010 17:30:07 -0600

Brian:

Yes, you could. But with that approach, you're needing to define two 
different mechanisms:

    * One that informs the "domain routing function" of the SSP where to
      route the domain pan-am.com, and

    * Another that informs the "look-up function" of the SSP how to
      convert "sip:[email-masked]" to
      "sip:[email-masked]"

While we certainly could go down the path of defining yet more 
mechanisms, I would suggest that we don't.

/a

On 1/22/10 1:31 PM, Brian Lindsay wrote:
>    For example, the SSP could perform an intermediate step (e.g. using 
> a local "Look-Up Function" to borrow from SPEERMINT terminology) that 
> effectively provides the mapping from the E.164 number to the pbx 
> domain and does the conversion from sip:[email-masked] 
> => sip:[email-masked]. After that the routing mechanism kicks in.
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Adam Roach
> *Sent:* Friday, January 22, 2010 12:16 PM
> *To:* Dean Willis
> *Cc:* Hadriel Kaplan; [email-masked]
> *Subject:* Re: [martini] Requirements - rev1
>
> [... text deleted ....]
> But that's most certainly not the "domain routing" model Dean is 
> talking about. In fact, it's pretty much the "contact routing" model 
> straight up, with an AOR to Contact mapping of 
> "sip:[email-masked] => sip:[email-masked]" 
> (and a similar one for +15005550200).
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Jan 2010 18:51:40 -0500

Dean Willis wrote:
>> *is* the user" may indeed apply in the case where the PBX is itself a 
>> B2BUA and does all the identity management for all the numbers it is 
> If the SSP were a traditional proxy/registrar that is authoritative for 
> the domain and the PBX were a multi-user telephone adapter with 
> credentials for each user in the domain, such that the PBX could send a 
> unique REGISTER for each user, then we might well be having a different 
> conversation. This conversation would be about ways to reduce the number 
> of REGISTER messages required to effect registration of the PBX as a 
> contact for each user. So we might be talking about "multiple 
> authentication", perhaps extending the digest-authentication model to 
> allow a separate authentication header for each AOR being registered. 
> This would preserve the property that the proxy/registrar has 
> established an authenticated relationship between each AOR and its 
> Contact, a property that is fundamental to REGISTER within RFC 3261 and 
> its current kin. Such an approach would clearly work reasonably well 
> within our current security assumptions, although it should be noted 
> that it does not prevent "identity substitution" attacks in the PBX. For 
> example, if the PBX chose to claim that a call is from Bob when in fact 
> the originating user is Alice, the SSP has no way to determine that this 
> substitution has been made. This is a fundamental property of a shared 
> connection in SIP (or indeed, in multi-user systems in general; how do 
> you know this email came from me and not my sysadmin?) and there's not a 
> lot we can do about it short of requiring users to provide single-use 
> keys for each transaction (the equivalent of me signing this message 
> using PGP).
> 
> the extent I think it works for an individual user (I think REGISTER is 
> deeply wounded and we've had to put a lot of ugly bandaids on it to keep 
> it from bleeding out). MARTINI could quite reasonably define an 
> However, our discussion recently has centered on models where SSP is NOT 
> authoritative for the domain in-question; rather it is just one of many 
> possible relays that might be used to reach the domain-authoritative 
> "PBX". This model potentially allows SSP to make different security 
> assertions. For example, SSP could assert 1) that SSP is transitively 
> authorized as a route for reaching the domain of pbx.com, and that 2) a 
> request exiting through SSP comes from some user in the domain of PBX. 
> Note that this second assertion is not the same as SSP being able to 
> assert that a specific user in the domain is involved. In this model, 
> only PBX (or perhaps the user itself) can make assertions about specific 
> user identities.

Yeah, more or less. For "names" what you say seems right.

For "numbers" the situation may be somewhat different.
In that case the SSP actually owns the numbers, and is retargeting 
incoming calls from sip:[email-masked] to sip:[email-masked].

When requests originate from the PBX, the SSP should be verifying that 
the claimed originating number is one that it believes to be assigned to 
that PBX. Of course it still can't tell that this is coming from the 
precise person assigned to that number - but that is because it has no 
notion that there *is* a precise person assigned to that number. As far 
as it is concerned they are all assigned to the pbx, and if it can 
verify the request is coming from the pbx, then that is enough.

There is another part to that however - once it has satisfied itself 
that an originated request is valid, it needs to re-identify the source 
as sip:[email-masked]. Depending on how it does that, it may need to be 
a B2BUA to do it.

	Thanks,
	Paul

> The fundamental security question: How does SSP prove to others that it 
> is authorized to route requests to/from the domain of PBX? We don't have 
> a security framework for this in SIP. This leads to the "alt root" 
> problem we recently discussed. What keeps a rogue node from claiming to 
> be authoritative as a route toward a domain? For that matter, what keeps 
> a node from claiming to be authoritative for a domain itself, rather 
> than just as a route toward that domain?

> in RFC 3261, and is echoed in our various documents 
> (draft-ietf-sip-certs, draft-ietf-sip-domain-certs, etc.). So if we make 
> a TLS connection to a node, and that TLS connection uses at the other 
> end a trusted cert for the domain in question, then we assume that the 
> other end is trusted to assert identities within that domain. RFC 3274 
> provides a transitive mechanism for assertion of identity in the context 
> of a SIP request message that is also based on this model of certification.
> 
> So what we need is something like RFC 3274 for route certification. This 

> has to allow for route redistribution and aggregation, since there might 
> be more than one relay proxy between the source and destination of a SIP 
> request. Adam's draft-roach-martini-up-00 defines a possible syntax for 
> a "route" (using XML), as well as a means for advertising a route 
> (PUBLISH). One can readily envision adding a signature to this syntax. 
> It's straightforward then to go from a single-hop route to a routing 
> vector, where each hop in the vector is signed by the next hop, 
> providing a fully certificated transit chain to the destination.
> 
> -- 
> Dean
> 
> 
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Jan 2010 23:58:35 -0600

On Jan 22, 2010, at 11:15 AM, Adam Roach wrote:

> "
> Now, if we stick with the "the SSP does not rewrite the URI"  
> approach that Keith and John are rather adamant about, the only  
> thing we can really do in terms of "these numbers go here, those  
> numbers go there" looks something like this:
>

I don't understand. Why is the INVITE showing up at ssp with a  
telephone number embedded in the user-part of a SIP URI in some  
abstract domain not associated with the target domain? That's not the  
use case that was put forward for MARTINI; the assumption is that  
requests are are either user@domain where the domain part is owned by  
the PBX, or are telephone numbers. And properly encoded telephone  
numbers are tel: URLs; they don't have domain-parts, so the domain- 
part doesn't have to be re-written on forwarding (but contact-routing  
ALWAYS rewrites it, as the AOR-target resulting from contact routing  
is always a SIP URI).

>
>
> I suspect most people can tell that's wrong by simple inspection.  
> What I'm willing to bet people are expecting is something more like  
> this:
>
>
> straight up, with an AOR to Contact mapping of "sip:[email-masked] 

No, it's neither: it's table-driven retargeting. You're transforming a  
request for one domain into a request for another domain, based  
strictly on the "user part" of the original request. This is ignoring  
the domain-part of the registered AOR. So it's not contact routing;  
remember, contact-routing takes as its input an AOR. It looks this AOR  
up in a table populated by storing AORs (including user and domain  
parts) received in REGISTER requests, returns the Contact matching the  
AOR, and replaces the request URI with the Contact before proxying the  
request on. By matching only on the 	user-part of the AOR, you;re  
doings something that isn't quite contact routing.

What happens when "+15005550100" is a valid user-part on both the pan- 
am.com and braniff.com domains?

>
> Okay, great. So the "contact routing" approach works fine for the  
> later cases. But what about the people who want to register entire  
> domains? That's the neat thing about the "contact routing" approach  
> -- if done correctly, it works just fine for those cases, too. Going  
> back to the first example; if we perform normal "contact routing" --  
> URI rewriting and all -- and have the PBXes register their IP  
> addresses as the mapped contacts, everything works fine:
>
>
> This is great! Now we're using REGISTER to put an AOR to Contact  
> mapping in place (like it always has) instead of using it to install  
> rules to override normal RFC3263 handling. Best of all, we're not  
> saying "ignore DNS and use this alternate mechanism for turning  
> names into addresses" like we have to with the "domain routing"  
> approach.

Nope. What happens when the PBX supports two domains, and there might  
be user-name overlaps between the domains? If both [email-masked] 
  and [email-masked] are contact-routed by the SSP into [email-masked] 
, we have something of a mess.  This requires sending the  
untransformed r-URI to the PBX.

Also, what happens to security assumptions around the AOR-contact  
mapping as assumed in draft-ietf-sip-outbound? We end up with traffic  
for multiple users occurring over one flow, and that leads to the  
attack-model we panned the early connection-reuse drafts for allowing.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jan 2010 10:25:12 +0100

Adam,

Thanks for going to the trouble of explaining things in this clear way. See below.

> Sent: 22 January 2010 17:16
> To: Dean Willis
> 	Consider for example the debate we're currently having 
> about whether the SSP does "contact routing" and replaces the 
> r-URI with a registered contact, or does "domain routing" and 
> just pushes the registered route onto the route stack 
> (really, it MUST do the latter, but REGISTER implies the 
> former, which makes it something of a hack).
> 	
> 
> 
> I'm not sure it must do the latter. I think there are some 
> people here whose use cases will work if you do it that way, 
> but I think a careful examination of everyone's position will 
> show that it simply won't work for others'.
> 
> On the other hand, the "contact routing" approach, as far as 
> I can tell, will work for all the use cases described so far, 
> as long as we have the ability to define a mapping from AOR 
> to contact URI in some sensible fashion. The martini-up draft 
> gives an existence proof of such a mechanism -- and the 
> mechanism is hardly NOTIFY-specific. It could be used just as 
> sensibly with REGISTER.
> 
> So, let's take a quick look at the "contact routing" approach 
> versus the "domain routing" approach. I hope you'll excuse 
> that I'm stepping slightly outside IETF norms to convey these 
> concepts clearly: to save the confusion among "example.com," 
> "example.org," and "example.net," I'm going to use dead 
> companies in my example; I'm also going to use inline images 
> for my diagrams.
> 
> Ignoring how the information gets there in the first place, 
> the "domain routing" approach looks sensible at first blush 
> for this kind of application. Here is an SSP and two of its 
> customers. Through some non-DNS mechanism, the SSP knows to 
> route the domain "pan-am.com" to the Pan Am PBX, and to route 
> the domain "braniff.com" to the Braniff PBX:
> 
> 
> 
> Great. Aside from the somewhat nonstandard determination of 
> the next-hop server at the SSP, this is pretty normal handling.
> 
> That said, MARTINI has a special relationship with phone 
> numbers. They're in our charter: " The solution will support 
> AoRs with E.164
> addresses at a minimum, although support for other classes of 
> AoRs may be included." So, let's explore what that ends up meaning.
> 
> As long as we expect some external party (not the SSP) to 
> determine what domain each E.164 number belongs to, then 
> everything works the same as my previous example:
> 
> 
> 
> And, if that's good enough, then great. But I'm willing to 
> bet that at least one person working in this space looks at 
> that diagram and says, "No! That's not what I meant! I want 
> the SSP to handle the number mapping."
> 
> approach that Keith and John are rather adamant about, the 
> only thing we can really do in terms of "these numbers go 
> here, those numbers go there" looks something like this:
[JRE] Although I may not have made myself clear, what I really am adamant about is preserving the identity of the target user in the Request-URI. So if the domain part is changed, but the user-info part is retained, that would be satisfactory.

> 
> 
> 
> 
> I suspect most people can tell that's wrong by simple 
> inspection. What I'm willing to bet people are expecting is 
> something more like this:
> 
> 
> 
> But that's most certainly not the "domain routing" model Dean 
> is talking about. In fact, it's pretty much the "contact 
> routing" model straight up, with an AOR to Contact mapping of 
> "sip:[email-masked] => 
> sip:[email-masked]" (and a similar one for +15005550200).
> 
> Okay, great. So the "contact routing" approach works fine for 
> the later cases. But what about the people who want to 
> register entire domains? That's the neat thing about the 
> "contact routing" approach -- if done correctly, it works 
> just fine for those cases, too. Going back to the first 
> example; if we perform normal "contact routing" -- URI 
> rewriting and all -- and have the PBXes register their IP 
> This is great! Now we're using REGISTER to put an AOR to 
> Contact mapping in place (like it always has) instead of 
> using it to install rules to override normal RFC3263 
> handling. Best of all, we're not saying "ignore DNS and use 
> this alternate mechanism for turning names into addresses" 
[JRE] This would seem reasonable. The point is, if the PBX registers as its contact address [email-masked], then inbound INVITE requests would not contain that same value in the Request-URI, but would contain something like [email-masked]. The identity of the target is retained. So I think we are in agreement.

John

> 
> So, Dean: can you explain what breaks if we use "contact 
> routing" for all the use cases described so far?
> 
> /a
> 
>

---

From: "Brian Lindsay" <[email-masked]>
Date: Mon, 25 Jan 2010 09:37:44 -0500

Hi Adam,
 
   Regarding the 2nd mechanism - I don't think there's really anything
new here. Performing such a re-targetting operation is probably typical
for transit / indirect peering functions and this isn't specific to
MARTINI. There's examples in the SPEERMINT VoIP SIP Peering Use Cases
draft of this kind of operation for the indirect peering use cases.
 
   Regards
      Brian

From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, January 22, 2010 6:30 PM
To: Lindsay, Brian (CAR:AR00)
Cc: Dean Willis; Hadriel Kaplan; [email-masked]
Subject: Re: [martini] Requirements - rev1

Brian:

*	One that informs the "domain routing function" of the SSP where
to route the domain pan-am.com, and

*	Another that informs the "look-up function" of the SSP how to
convert "sip:[email-masked]"
<sip:[email-masked]>  to "sip:[email-masked]"
<sip:[email-masked]>  

/a

	Hi Adam,
	 
	   Regarding the case below, you could use a "domain routing"
approach for this as well.
	 
	   For example, the SSP could perform an intermediate step (e.g.
using a local "Look-Up Function" to borrow from SPEERMINT terminology)
that effectively provides the mapping from the E.164 number to the pbx
domain and does the conversion from sip:[email-masked]
<sip:[email-masked]>  => sip:[email-masked]
<sip:[email-masked]> . After that the routing mechanism kicks
in.

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Adam Roach
	Sent: Friday, January 22, 2010 12:16 PM
	To: Dean Willis
	Cc: Hadriel Kaplan; [email-masked]
	Subject: Re: [martini] Requirements - rev1

	[... text deleted ....] 
	I suspect most people can tell that's wrong by simple
inspection. What I'm willing to bet people are expecting is something
more like this:

	But that's most certainly not the "domain routing" model Dean is
talking about. In fact, it's pretty much the "contact routing" model
straight up, with an AOR to Contact mapping of "
sip:[email-masked] => sip:[email-masked]" (and a
similar one for +15005550200).

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2010 09:40:50 -0500

inline...

> [JRE] Although I may not have made myself clear, what I really am adamant about is preserving the identity of the target user in the Request-URI. So if the domain part is changed, but the user-info…

How have you preserved the identity of the target if you have retained 
the user-part but replaced the domain part?

That may work for e.164 numbers, but only them.

john.elwell is unique in siemens-enterprise.com, but its quite likely 
that verizon.net or comcast.net has a john.elwell that is not you.

(I can't use my own name for examples like this.)

It works for e.164 numbers because they are globally unique in their own 
right, and by convention when used with domain names.

> [JRE] This would seem reasonable. The point is, if the PBX registers as its contact address [email-masked], then inbound INVITE requests would not contain that same value in the Request-URI, but wo…

This could probably be made to work.

But it requires new conventions about the form of contact URIs,
conventions we have never had before.

The rule has always been that the registering device can use whatever 
contact URI it wishes, as long as it routes to itself, and in particular 
it can use the user-info portion of that URI to encode arbitrary 
information that may be helpful to itself.

If an special convention is required for this new mechanism, then we 
need to be very explicit about it.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 09:07:26 -0600

On 1/25/10 8:40 AM, Paul Kyzivat wrote:
>>> From: Adam Roach [mailto:[email-masked]] Sent: 22 January 2010 17:16
>>>
>> [JRE] This would seem reasonable. The point is, if the PBX registers 
>> as its contact address [email-masked], then inbound INVITE requests 
>> would not contain that same value in the Request-URI, but would 
>> contain something like [email-masked]. The identity of the target 
>> is retained. So I think we are in agreement.
>
> contact URI it wishes, as long as it routes to itself, and in 
> particular it can use the user-info portion of that URI to encode 
> arbitrary information that may be helpful to itself.
>

I'd like to be explicit about it at a protocol level.

I'll reiterate that the AOR to Contact mapping model I propose in 
draft-roach-martini-up is *not* specific to the use of PUBLISH. Using a 
similar mechanism in REGISTER -- whether in the header or in the body -- 
would achieve the same goals. More importantly, it would address Dean's 
concern:

> What happens when the PBX supports two domains, and there might be 
> user-name overlaps between the domains? If both 
> [email-masked] and [email-masked] are contact-routed 
> by the SSP into [email-masked], we have something of a mess.

Because, in this case, the registration could look something like this 
(using the syntax from martini-up):

    1 full
    /sip:(.*)@eng.pan-am.com/sip:\[email-masked]/
    /sip:(.*)@mktg.pan-am.com/sip:\[email-masked]/

That's very explicit. It's not even a convention; it's a protocol.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Jan 2010 09:18:51 -0600

Thanks to Adam for his post, from me as well. One question inline...

Spencer

>> [JRE] Although I may not have made myself clear, what I really am adamant 
>> about is preserving the identity of the target user in the Request-URI. 
>> So if the domain part is changed, but the user-info part is retained, 
>> that would be satisfactory.
>
> How have you preserved the identity of the target if you have retained the 
> user-part but replaced the domain part?
>
> john.elwell is unique in siemens-enterprise.com, but its quite likely that 
> verizon.net or comcast.net has a john.elwell that is not you.
>

What I've been hearing consistently for a year is that, for the people who 
want this mass registration mechanism, "telephone numbers" (and I'm willing 
to stipulate "E.164 numbers") are what they are currently dealing with, and 
what they expect to be dealing with for a while.

I don't think any of the people I've been hearing would object to an 
E.164-only mechanism, which I'm understanding Paul to be saying, would work.

How would we know that the user part is an E.164 number, unambiguously, so 
that we don't have to reopen the discussion about interpreting user parts 
(which doesn't sound like a short conversation)?

Restrict to "tel:" URI? "user=phone" (and how would the caller know to do 
this)? is there a good answer? If there is, great. If there's not, can we 
decide that quickly?

Thanks,

Spencer

---

From: <[email-masked]>
Date: Mon, 25 Jan 2010 16:38:57 +0100

If my memory is correct a solution where only the user part was preserved was proposed to ETSI and 3GPP two years ago and rejected.  One of the reason why this solution was rejected is that it did not allow for the case where one PBX is associated to two domain names (e.g. one domain name representing a company and another one representing a brand owned by this company) and UserX@DomainA is different from UserX@DomainB. 
BC

> [mailto:[email-masked]] De la part de Paul Kyzivat
> Envoyé : lundi 25 janvier 2010 15:41
> À : Elwell, John
> Cc : [email-masked]; Hadriel Kaplan
> Objet : Re: [martini] Requirements - rev1
> 
> inline...
> 
> Elwell, John wrote:
> > Adam,
> > 
> about whether 
> >> I'm not sure it must do the latter. I think there are some people 
> >> here whose use cases will work if you do it that way, but 
> I think a 
> >> careful examination of everyone's position will show that 
> it simply 
> >> won't work for others'.
> >>
> >> On the other hand, the "contact routing" approach, as far as I can 
> >> tell, will work for all the use cases described so far, as 
> long as we 
> >> have the ability to define a mapping from AOR to contact 
> URI in some 
> >> sensible fashion. The martini-up draft gives an existence proof of 
> >> such a mechanism -- and the mechanism is hardly 
> NOTIFY-specific. It 
> >> could be used just as sensibly with REGISTER.
> >>
> >> So, let's take a quick look at the "contact routing" 
> approach versus 
> >> the "domain routing" approach. I hope you'll excuse that 
> I'm stepping 
> >> the confusion among "example.com,"
> companies in 
> >> my example; I'm also going to use inline images for my diagrams.
> >>
> >> Ignoring how the information gets there in the first place, the 
> >> "domain routing" approach looks sensible at first blush 
> for this kind 
> >> of application. Here is an SSP and two of its customers. 
> Through some 
> >> non-DNS mechanism, the SSP knows to route the domain 
> "pan-am.com" to 
> >> the Pan Am PBX, and to route the domain "braniff.com" to 
> the Braniff 
> >> PBX:
> >>
> >>
> >>
> >> Great. Aside from the somewhat nonstandard determination of the 
> >> next-hop server at the SSP, this is pretty normal handling.
> >>
> >> addresses at a minimum, although support for other classes of AoRs 
> >> may be included." So, let's explore what that ends up meaning.
> >>
> determine 
> >> what domain each E.164 number belongs to, then everything 
> works the 
> >> same as my previous example:
> >>
> >>
> >>
> bet that 
> >> at least one person working in this space looks at that 
> diagram and 
> >> says, "No! That's not what I meant! I want the SSP to handle the 
> >> number mapping."
> >>
> only thing 
> >> we can really do in terms of "these numbers go here, those 
> numbers go 
> > [JRE] Although I may not have made myself clear, what I 
> really am adamant about is preserving the identity of the 
> target user in the Request-URI. So if the domain part is 
> changed, but the user-info part is retained, that would be 
> satisfactory.
> 
> How have you preserved the identity of the target if you have 
> retained the user-part but replaced the domain part?
> 
> john.elwell is unique in siemens-enterprise.com, but its 
> quite likely that verizon.net or comcast.net has a 
> john.elwell that is not you.
> 
> It works for e.164 numbers because they are globally unique 
> in their own right, and by convention when used with domain names.
> 
> >> saying "ignore DNS and use this alternate mechanism for 
> turning names 
> >> into addresses"
> > [JRE] This would seem reasonable. The point is, if the PBX 
> registers as its contact address [email-masked], then 
> inbound INVITE requests would not contain that same value in 
> the Request-URI, but would contain something like 
> [email-masked]. The identity of the target is retained. So 
> I think we are in agreement.
> 
> particular

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 10:11:20 -0600

On 1/22/10 11:58 PM, Dean Willis wrote:
> the domain-part of the registered AOR.

No, that's not what I'm trying to show here. The user portion certainly 
could stay the same, but that would be local policy, not built-in 
mechanism. My example would be the same thing if the user portion were 
remapped via some transformation. For example, the diagram I included 
originally would be the result of a transformation like this:

/sip:(+150055501..)@centricvoice.com/sip:\[email-masked]/

But the Pan Am PBX could just as easily have requested a transformation 
like this:

/sip:+1500555(01..)@centricvoice.com/sip:extension-\[email-masked]/

And it would all work just fine:

> So it's not contact routing; remember, contact-routing takes as its 
> input an AOR. It looks this AOR up in a table populated by storing 
> AORs (including user and domain parts) received in REGISTER requests, 
> returns the Contact matching the AOR, and replaces the request URI 
> with the Contact before proxying the request on.

I don't know where you got the impression that I was proposing to ignore 
the domain portion. If the "CentricVoice (SSP)" entity wanted to treat 
incoming requests with different domain names as different, it certainly 
should be able to.

> By matching only on the     user-part of the AOR, you;re doings 
> something that isn't quite contact routing.

I never proposed that you should be doing this.

----------------------------------------------------------------------
*WARNING* *WARNING* *WARNING*!!! If you are not Dean, the following 
example and my response may be very confusing. Dean is discussing some 
valid but highly esoteric and unlikely scenarios. In particular, he is 
using user names that look exactly like E.164 numbers, but which 
actually are *NOT* taken from the E.164 numbering space.

> What happens when "+15005550100" is a valid user-part on both the 
> pan-am.com and braniff.com domains?

Then you're going to have to use a different AOR on the CentricVoice 
service. Both pan-am.com and braniff.com could define their own 
remapping rules that, when applied, transform incoming requests at 
centricvoice.com into "sip:[email-masked]" and 
"sip:[email-masked]" respectively. The Pan Am PBX could, for 
example, register for:

/sip:pan-am-(....)@centricvoice.com/sip:+1500555\[email-masked]/

While the Braniff PBX might register for:

/sip:braniff-(....)@centricvoice.com/sip:+1500555\[email-masked]/

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

>> saying "ignore DNS and use this alternate mechanism for turning names 
>> into addresses" like we have to with the "domain routing" approach.
>
>
> be user-name overlaps between the domains? If both 
> by the SSP into [email-masked], we have something of a mess.  This 
> requires sending the untransformed r-URI to the PBX.

No, it requires having a mapping that allows the PBX to properly 
correlate the r-URI with the user. You propose that this must be a unity 
mapping. But we have a clear existence proof that this works with 
arbitrary mapping, because THAT'S HOW REGISTER WORKS TODAY. The UA 
installs an arbitrary mapping from AOR to Contact address. And many, if 
not most, modern UAs can handle multiple registrations and figure out 
(based on the r-URI) which user an incoming INVITE belongs to.

You can get rid of most of the problems we've identified by allowing a 
programmatic mapping from AOR to Contact value. Your example, for 
instance, can be solved by having different mappings for each of those 
users.  I already showed this in an earlier message, but I'd like to 
reiterate it here, with some alternatives. You can trivially address the 
"@mktg..." versus "@eng..." issue with mappings like this:

1 full
/sip:(.*)@eng\.pan-am\.com/sip:\[email-masked]/
/sip:(.*)@mktg\.pan-am\.com/sip:\[email-masked]/

Alternately (since you raised UUCP and email), you could use a syntax 
like this:

1 full
/sip:(.*)@(eng\.pan-am\.com)/sip:\1%40\[email-masked]/
/sip:(.*)@(mktg\.pan-am\.com)/sip:\1%40\[email-masked]/

> attack-model we panned the early connection-reuse drafts for allowing.

Ah, now you're getting into the arguments that REGISTER is the wrong 
tool (or that REGISTER needs to have a Proxy-Require) for this 
application. And we're in complete agreement there. Any use of REGISTER 
for multiple AORs that correspond to multiple humans[*] is going to be 
broken from a security perspective. I raised this issue at the 
microphone in Hiroshima, and I jumped up and down on it a lot on the 
mailing list in early January (e.g., "You are changing a fundamental 
property of a core SIP construct -- the operation no longer applies to 
just the user indicated in the 'To' header field; it applies to myriad 
disparate users. Intermediaries assuming it means what RFC 3261 says it 
means will be mislead, and make potentially incorrect policy decisions 
as a consequence"). Believe me, this issue is near and dear to me. If 
you see me proposing something that you think means I don't care about 
this, then you're reading it wrong.

/a

[*] I'm avoiding the use of the word "user," since that word has been 
hijacked to mean something bizarre in this conversation.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jan 2010 17:13:27 +0100

> Sent: 22 January 2010 07:25
> To: Elwell, John
> Cc: Spencer Dawkins; [email-masked]; Hadriel Kaplan
[JRE] I just read it again, and to be honest most of what it claims could also apply to a well-chosen REGISTER-based mechanism. I will answer specific points in a separate thread.

> assumptions around Outbound are completely broken.
[JRE] I don't think so - the PBX registers on behalf of a bunch of AORs, and we get similar security properties between the PBX and the SP for that bunch of AORs to what we would get if we were registering a single AOR.

> This, by the way,  
[JRE] I would contend that if outbound is broken for MARTINI, it is also broken for a normal user registration where there are multiple entities on the path. Isn't that what IMS has in the case of roaming users?

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jan 2010 18:18:53 +0100

For the two domain case, using a REGISTER-based approach, I would expect the PBX to behave as two PBXs and register twice. 

John

> Sent: 25 January 2010 15:07
> To: Paul Kyzivat
> Cc: Elwell, John; Dean Willis; Hadriel Kaplan; [email-masked]
> 			From: Adam Roach 
> [mailto:[email-masked]] Sent: 22 January 2010 17:16 
> 			
> 
> 
> 			This is great! Now we're using REGISTER 
> to put an AOR to Contact mapping in place (like it always 
> has) instead of using it to install rules to override normal 
> RFC3263 handling. Best of all, we're not saying "ignore DNS 
> and use this alternate mechanism for turning names into 
> addresses" like we have to with the "domain routing" approach. 
> 			
> 
> 		[JRE] This would seem reasonable. The point is, 
> if the PBX registers as its contact address [email-masked], 
> then inbound INVITE requests would not contain that same 
> value in the Request-URI, but would contain something like 
> 	The rule has always been that the registering device 
> can use whatever contact URI it wishes, as long as it routes 
> to itself, and in particular it can use the user-info portion 
> of that URI to encode arbitrary information that may be 
> helpful to itself. 
> 	
> 	If an special convention is required for this new 
> mechanism, then we need to be very explicit about it. 
> 	
> 
> 
> I'll reiterate that the AOR to Contact mapping model I 
> propose in draft-roach-martini-up is *not* specific to the 
> use of PUBLISH. Using a similar mechanism in REGISTER -- 
> whether in the header or in the body -- would achieve the 
> same goals. More importantly, it would address Dean's concern:
> 
> 
> 
> 	What happens when the PBX supports two domains, and 
> there might be user-name overlaps between the domains? If 
> both [email-masked] and [email-masked] are 
> contact-routed by the SSP into [email-masked], we have 
> something of a mess.
> 
> 
> Because, in this case, the registration could look something 
> like this (using the syntax from martini-up):
> 
> 
> 
> 	1 full

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 12:42:39 -0600

On 1/25/10 10:13 AM, Elwell, John wrote:
> [JRE] I just read it again, and to be honest most of what it claims could also apply to a well-chosen REGISTER-based mechanism.
>    

I agree, with emphasis on the terms "most" and "well-chosen."

I would not be entirely opposed to exploring what would constitute 
"well-chosen," and then figuring out how to solve the problems that fall 
outside the envelope covered by your term "most."

Based on your analysis post, your definition of "well-chosen" inherently 
includes some programmatic mapping from AORs to Contacts ("one contact 
URI per AOR," implying contact routing, not domain routing). I think 
that's a good place to start working from.

Don't get hung up on martini-up's proposal to use PUBLISH. While it does 
solve a very real class of problems, that one relatively minor aspect of 
the draft is not the most mechanism it proposes. The majority of the 
problems it solves involve the explicit signaling of AORs in the 
request, the definition of a mechanism that enables "one contact URI per 
AOR," and the congruence with previous uses of REGISTER by employing 
"contact routing" instead of "domain routing."

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 13:14:11 -0600

...
> [JRE] This would seem reasonable. The point is, if the PBX registers as its contact address [email-masked], then inbound INVITE requests would not contain that same value in the Request-URI, but wo…

I think you're right. It would appear that our positions are not as far 
apart as they originally seemed.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 14:13:40 -0600

On 1/25/10 9:18 AM, Spencer Dawkins wrote:
> How would we know that the user part is an E.164 number, 
> unambiguously, so that we don't have to reopen the discussion about 
> interpreting user parts (which doesn't sound like a short conversation)?

I sure would be cool if we didn't have to worry about that, wouldn't it? 
Perhaps we should solve the general case instead of arguing about how to 
determine when the special case can be applied.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Jan 2010 14:35:06 -0600

Hi, Adam,

>> How would we know that the user part is an E.164 number, unambiguously, 
>> so that we don't have to reopen the discussion about interpreting user 
>> parts (which doesn't sound like a short conversation)?
>

Hi, Adam,

My understanding here is that we are trying to figure out how the service 
provider would automagically retarget [email-masked] (which is directed 
to the service provider) to [email-masked] (which is directed to the 
PBX), where +12145551212 is an E.164 number that we can know is an E.164 
number, and not some SIP administrator's idea of a cruel joke played on an 
unpleasant co-worker/customer). If I got this wrong, please disabuse me.

The limited approach, if we could make it work, would take advantage of the 
global uniqueness of +12145551212 as an E.164 number, so that the service 
provider would know it could safely retarget to [email-masked].

If we can't take advantage of the global uniqueness of +12145551212, then 
there's no difference between retargeting [email-masked] and 
retargeting [email-masked], so we have to solve the general case to do 
anything.

Am I understanding your point of view correctly?

Assuming so - I know that "if wishes were horses, then beggars would ride". 
I have observed that sometimes, people do ride horses. I'm trying to figure 
out if we could be riding horses, or if we're just wishing for a pony...

Thanks,

Spencer - who probably should be speaking as co-chair on this, since we're 
talking about making a decision that significantly affects the work that 
MARTINI will do, but is trying to speak as an individual and not speak in 
favor of one approach as chair. If I'm not succeeding, my apologies for 
that. Bernard, please feel free to chime in if I'm doing it wrong.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2010 16:02:21 -0500

Spencer,

I think the question you are asking is in some sense a non-issue, as it 
is entirely in control of the SSP. These all start out as user-info in 
URIs addressed to a domain the SSP is responsible for. It must overtly 
know that these are intended to be delegated to a customer. And part of 
knowing that can be knowing that they are phone numbers.

The SSP could, if it wishes, also have another class of its own AORs 
that are *not* phone numbers, but that are also delegated to a customer. 
It might need a different rule for mapping these.

A strong argument for the kind of mapping Adam is proposing is that the 
SSP might *not* represent phone numbers internally as E.164 numbers. And 
different SSPs might represent them differently. (I hate that, but 
gather it is the case.) And the PBX would perhaps like phone numbers all 
represented in some consistent way independent of SSP.

	Thanks,
	Paul

Spencer Dawkins wrote:
>> I sure would be cool if we didn't have to worry about that, wouldn't 
>> it? Perhaps we should solve the general case instead of arguing about 
>> how to determine when the special case can be applied.
> 
> Hi, Adam,
> 
> My understanding here is that we are trying to figure out how the 
> service provider would automagically retarget [email-masked] (which 
> is directed to the service provider) to [email-masked] (which is 
> directed to the PBX), where +12145551212 is an E.164 number that we can 
> know is an E.164 number, and not some SIP administrator's idea of a 
> cruel joke played on an unpleasant co-worker/customer). If I got this 
> wrong, please disabuse me.
> 
> The limited approach, if we could make it work, would take advantage of 
> the global uniqueness of +12145551212 as an E.164 number, so that the 
> service provider would know it could safely retarget to 
> [email-masked].
> 
> If we can't take advantage of the global uniqueness of +12145551212, 
> then there's no difference between retargeting [email-masked] and 
> Assuming so - I know that "if wishes were horses, then beggars would 
> ride". I have observed that sometimes, people do ride horses. I'm trying 
> to figure out if we could be riding horses, or if we're just wishing for 
> a pony...
> 
> Thanks,
> 
> Spencer - who probably should be speaking as co-chair on this, since 
> we're talking about making a decision that significantly affects the 
> work that MARTINI will do, but is trying to speak as an individual and 
> not speak in favor of one approach as chair. If I'm not succeeding, my 
> apologies for that. Bernard, please feel free to chime in if I'm doing 
> it wrong.
>

---

From: "Brian Lindsay" <[email-masked]>
Date: Mon, 25 Jan 2010 16:23:54 -0500

Hi,

    Note this isn't specific to MARTINI cases. Even if a pure "RFC3263"
approach is being used for peering to a SIP PBX, the SSP would need to
be able to re-target the request in the same fashion prior to routing
the request (e.g. modify a request uri such as
sip:[email-masked];user=phone to
sip:[email-masked];user=phone). 

    Regards
       Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Monday, January 25, 2010 4:02 PM
To: Spencer Dawkins
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [martini] Requirements - rev1

Spencer,

	Thanks,
	Paul

> service provider would automagically retarget [email-masked] 
> (which is directed to the service provider) to [email-masked] 
> (which is directed to the PBX), where +12145551212 is an E.164 number 
> that we can know is an E.164 number, and not some SIP administrator's 
> idea of a cruel joke played on an unpleasant co-worker/customer). If I

> got this wrong, please disabuse me.
> 
> The limited approach, if we could make it work, would take advantage 
> of the global uniqueness of +12145551212 as an E.164 number, so that 
> the service provider would know it could safely retarget to
> [email-masked].
> 

> ride". I have observed that sometimes, people do ride horses. I'm 
> trying to figure out if we could be riding horses, or if we're just 
> wishing for a pony...
> 
> Thanks,
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jan 2010 09:16:01 +0100

Changing the thread name to focus on another issue.

We seem to have converged on what Adam calls contact routing, which basically says that the domain part of the Request-URI in an inbound request should contain the domain part of the registered contact URI, leaving the user part to identify the particular AOR. I think this does indeed correspond to one of the practices seen in the wild at present.

This then leaves the question of whether we need to enumerate the different user parts (and hence the AORs and their respective contacts), either in the request (PBX to SP) or in the response (SP to PBX). My question is whether we need this at all - the question whether it should be in the request or the response can be addressed after we have determined whether it is needed at all.

The argument for exchanging this information is to ensure that the two sides are aligned, or at least to detect if there is misalignment. It is probably not a mechanism for making changes to the set of user parts - my opinion is that that is a provisioning issue and outside the scope of MARTINI.

John

> Sent: 25 January 2010 18:43
> To: Elwell, John
> Cc: Dean Willis; [email-masked]; Hadriel Kaplan
> > [JRE] I just read it again, and to be honest most of what 
> it claims could also apply to a well-chosen REGISTER-based mechanism.
> >    
>

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 09:29:13 +0100

It sounds like a trick rather than a solid solution...

> Envoyé : lundi 25 janvier 2010 18:19
> À : Adam Roach; Paul Kyzivat
> For the two domain case, using a REGISTER-based approach, I 
> would expect the PBX to behave as two PBXs and register twice. 
> 
> John
> 
> > RFC3263 handling. Best of all, we're not saying "ignore DNS and use 
> > this alternate mechanism for turning names into addresses" like we 
> > have to with the "domain routing" approach.
> > 			
> >

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 09:29:23 +0100

> Envoyé : mardi 26 janvier 2010 09:16
> À : Adam Roach
> Cc : [email-masked]
> Objet : [martini] Enumerating AORs/contacts
> 
> We seem to have converged on what Adam calls contact routing, 
> which basically says that the domain part of the Request-URI 
> in an inbound request should contain the domain part of the 
> registered contact URI, leaving the user part to identify the 
> particular AOR. I think this does indeed correspond to one of 
> the practices seen in the wild at present.
==>BC: Hum, I still think that both the user part and the domain part should be left unmodified. What are the concrete benefits for the PBX if only the user part is left unchanged? 
> 
> This then leaves the question of whether we need to enumerate 
> the different user parts (and hence the AORs and their 
> respective contacts), either in the request (PBX to SP) or in 
> the response (SP to PBX). My question is whether we need this 
> at all - the question whether it should be in the request or 
> the response can be addressed after we have determined 
> whether it is needed at all.
==>BC: I have no strong feeling as to whether we need it on the interface between the pBX and the SSP's edge proxy but I believe we do need it in the response from the Registrar to the SSP's edge proxy.

> 
> The argument for exchanging this information is to ensure 
> that the two sides are aligned, or at least to detect if 
> there is misalignment. It is probably not a mechanism for 
> making changes to the set of user parts - my opinion is that 
> that is a provisioning issue and outside the scope of MARTINI.
> 
> John
> 
> 
> > "well-chosen," and then figuring out how to solve the problems that 
> > fall outside the envelope covered by your term "most."
> > 
> > solve a very real class of problems, that one relatively 
> minor aspect 
> > of the draft is not the most mechanism it proposes. The majority of 
> > the problems it solves involve the explicit signaling of 
> AORs in the 
> > request, the definition of a mechanism that enables "one 
> contact URI 
> > per AOR," and the congruence with previous uses of REGISTER by 
> > employing "contact routing" instead of "domain routing."
> > 
> > /a
> >

---

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

> Sent: 26 January 2010 08:29
> To: Elwell, John; [email-masked]
> Cc: [email-masked]
> Subject: RE: [martini] Enumerating AORs/contacts
> 
>  
> 
> ==>BC: Hum, I still think that both the user part and the 
> domain part should be left unmodified. What are the concrete 
> benefits for the PBX if only the user part is left unchanged? 
[JRE] For reasons that Adam has given - sending a request to sip:[email-masked] to pbx.com will result in looping back to sp.com, since pbx.com is not responsible for that domain.

> ==>BC: I have no strong feeling as to whether we need it on 
> the interface between the pBX and the SSP's edge proxy but I 
> believe we do need it in the response from the Registrar to 
> the SSP's edge proxy.
[JRE] Can we somehow capture a requirement on this? Just saying it needs to be conveyed to the edge proxy is not sufficient. We need to identify a problem and capture a requirement that avoids that problem.

John

> altered, changed or falsified.

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 10:50:03 +0100

> De : Elwell, John [mailto:[email-masked]] 
> Envoyé : mardi 26 janvier 2010 10:20
> À : CHATRAS Bruno RD-CORE-ISS; [email-masked]
> Cc : [email-masked]
> Objet : RE: [martini] Enumerating AORs/contacts
> 
>  
> 
> John Envoyé 
> > > : mardi 26 janvier 2010 09:16 À : Adam Roach Cc : 
> [email-masked] 
> > > We seem to have converged on what Adam calls contact 
> routing, which 
> > > basically says that the domain part of the Request-URI in 
> an inbound 
> > > request should contain the domain part of the registered contact 
> > > URI, leaving the user part to identify the particular 
> AOR. I think 
> > > this does indeed correspond to one of the practices seen 
> in the wild 
> > > at present.
> domain part 
> > should be left unmodified. What are the concrete benefits 
> for the PBX 
> > if only the user part is left unchanged?
> [JRE] For reasons that Adam has given - sending a request to 
> sip:[email-masked] to pbx.com will result in looping back to 
> sp.com, since pbx.com is not responsible for that domain.

==>BC: I was referring to a URI of the form [email-masked], not [email-masked]

> [JRE] Can we somehow capture a requirement on this? Just 
> saying it needs to be conveyed to the edge proxy is not 
> sufficient. We need to identify a problem and capture a 
> requirement that avoids that problem.

==>BC: The mechanism shall ensure that an SSP's edge proxy that is responsible for asserting identities as per RFC 3325 is made aware of the list of identities implictly registered in the registrar.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 26 Jan 2010 07:46:39 -0600

Hi, Bruno,

The problem with [email-masked] is that requests from outside the 
service provider to this AOR would go straight to the SIP-PBX without 
traversing any service provider proxy - unless we dork with two-faced DNS, 
etc.

Or am I misunderstanding?

Thanks,

Spencer (as individual)

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 26, 2010 3:50 AM
Subject: Re: [martini] Enumerating AORs/contacts

> sp.com, since pbx.com is not responsible for that domain.

==>BC: I was referring to a URI of the form [email-masked], not 
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jan 2010 09:00:14 -0500

> The argument for exchanging this information is to ensure that the two sides are aligned, or at least to detect if there is misalignment. It is probably not a mechanism for making changes to the se…

AFAIK it has generally been the case that "I am the master of my URIs": 
that the URIs addressed specifically to my device are those that I have 
minted - that the whole URI, including the user part is my business. (If 
you want to talk to me, send a request to a URI that I provide, rather 
than making up something.)

The registration model certainly has preserved that property, until now.

This is important, because I may have only one domain/port combination 
under my control, and I may need to multiplex it using the user part. If 
you start "making up" URIs with my domain and port, there are no 
guarantees that you won't infringe on values I am using for something else.

If we are going to change this model, it must be done very deliberately, 
and with clear bounds, so that I still have predictable sub-ranges I can 
control within the user part.

This could be achieved by contract - my service agreement with the SSP 
specifies what values it might put into my contact URI.

Or this could be achieved by my providing an algorithm to the SSP to use 
in mapping other addresses into my contact URI space. That is what Adam 
has proposed with his regular expression mechanism.

Another way would be to leave the user part of the contact unchanged, 
and add a URI parameter.

	Thanks,
	Paul

>> minor aspect of 
>> contact URI per

---

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

On 1/26/10 02:16, Jan 26, Elwell, John wrote:
> We seem to have converged on what Adam calls contact routing, which basically says that the domain part of the Request-URI in an inbound request should contain the domain part of the registered contact URI, leaving the user part to identify the particular AOR.

So, that's not *quite* right. The right-hand-side corresponds to the 
PBX. In the dynamic-IP scenario, it ends up being the PBX's IP address, 
not a domain it claims responsibility for.

/a

---

From: "Brian Lindsay" <[email-masked]>
Date: Tue, 26 Jan 2010 09:41:23 -0500

Hi John,

  I am not sure we have converged on this. There seemed to be a large
measure of agreement in earlier threads that the domain portion reflect
the domain name associated with the pbx. Which means that a
re-targetting may need to occur, but not necessarily that a "contact
routing" approach was being used.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: Tuesday, January 26, 2010 3:16 AM
To: Adam Roach
Cc: [email-masked]
Subject: [martini] Enumerating AORs/contacts

We seem to have converged on what Adam calls contact routing, which
basically says that the domain part of the Request-URI in an inbound
request should contain the domain part of the registered contact URI,
leaving the user part to identify the particular AOR. I think this does
indeed correspond to one of the practices seen in the wild at present.

This then leaves the question of whether we need to enumerate the
different user parts (and hence the AORs and their respective contacts),
either in the request (PBX to SP) or in the response (SP to PBX). My
question is whether we need this at all - the question whether it should
be in the request or the response can be addressed after we have
determined whether it is needed at all.

The argument for exchanging this information is to ensure that the two
sides are aligned, or at least to detect if there is misalignment. It is
probably not a mechanism for making changes to the set of user parts -
my opinion is that that is a provisioning issue and outside the scope of
MARTINI.

John

> solve a very real class of problems, that one relatively minor aspect 
> the problems it solves involve the explicit signaling of AORs in the 
> request, the definition of a mechanism that enables "one contact URI

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 09:23:04 -0600

On Jan 25, 2010, at 1:14 PM, Adam Roach wrote:

>> [JRE] Although I may not have made myself clear, what I really am  
>> adamant about is preserving the identity of the target user in the  
>> Request-URI. So if the domain part is changed, but the user-info  
>> part is retained, that would be satisfactory.
>>
> ...
>> registers as its contact address [email-masked], then inbound  
>> INVITE requests would not contain that same value in the Request- 
>> URI, but would contain something like [email-masked]. The  
>> identity of the target is retained. So I think we are in agreement.
>>

Hold on here. If the SSP is doing contact routing, which is what I  
think Adam is proposing, then the inbound INVITE request might be  
transformed from sip:[email-masked] to sip:[email-masked].

If however the SSP is doing "something that is not contact routing",  
aka "just plain loose routing", then it would transform neither the  
user nor domain parts of the request, which would then arrive at PBX  
with a R-URI of "[email-masked]".

But what I think you're proposing is yet another programmatic  
transformation, where the user-part of the r-URI is held constant but  
the domain-part of the r-URI is transformed to match the domain-part  
of the To: URI from the REGISTER.

As has been pointed out, this requires that the PBX use a different  
contact URI for each domain being registered. But the restriction is  
really even tighter: the PBX MUST use a different domain part for the  
Contact registered for each domain, as lack of preservation of the  
registered user-part means it has to differentiate between local  
domains based only on the domain part of the registered contacts.

So this means that if the PBX supports multiple domains, then it  
cannot register using an IP address as a domain part unless it also  
has a separate IP address for each domain. Of course, it could use a  
different DNS name, but we sort of have the assumption that the PBX  
doesn't really have a useable domain name; if it did, then we'd just  
use RFC 3263 procedures combined with dynamic DNS. And presumably if  
PBX doesn't have a single useable DNS name, then it doesn't have a  
different one for each local domain.

--
Dean

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 26 Jan 2010 07:39:10 -0800

Spencer said:

"The problem with [email-masked] is that requests from outside the 
service provider to this AOR would go straight to the SIP-PBX without 
traversing any service provider proxy - unless we dork with two-faced DNS, 
etc."

[BA] Doesn't this depend on whether the DNS SRV RRs for "enterprise.com"
point to the service provider?  If so, then shouldn't requests go to the SP,
even if the A/AAAA RRs are dynamically updated to point to the SIP-PBX?

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 16:40:47 +0100

Yes. I was about to provide the same reply.

> De : Bernard Aboba [mailto:[email-masked]] 
> Envoyé : mardi 26 janvier 2010 16:39
> À : 'Spencer Dawkins'; CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]
> "The problem with [email-masked] is that requests from 
> outside the service provider to this AOR would go straight to 
> the SIP-PBX without traversing any service provider proxy - 
> unless we dork with two-faced DNS, etc."
> 
> point to the service provider?  If so, then shouldn't 
> requests go to the SP, even if the A/AAAA RRs are dynamically 
> updated to point to the SIP-PBX?
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jan 2010 10:42:44 -0500

> Sent: Tuesday, January 26, 2010 8:47 AM
> 

*We* (martini) won't be dorking with anything.  How a request got to the SSP is effectively out of scope for this WG, right?  For all I know, the request originated in the SSP.  The question isn't how it got to the SSP - the question is what the SSP should do about it once it gets it.  :)

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jan 2010 16:46:51 +0100

> From: Brian Lindsay [mailto:[email-masked]] 
> Sent: 26 January 2010 14:41
> To: Elwell, John; Adam Roach
> Cc: [email-masked]
[JRE] I didn't particular like the term contact routing, but I guess you could call it that, if the domain part of the contact URI (which would presumably match the domain part of the AORs being registered) is substituted for the domain part of the Request-URI that arrives at the SP from the UAC, leaving the user part unchanged.

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jan 2010 16:47:07 +0100

> Sent: 26 January 2010 09:50
[JRE] See Spencer's reply.

> ==>BC: The mechanism shall ensure that an SSP's edge proxy 
> that is responsible for asserting identities as per RFC 3325 
> is made aware of the list of identities implictly registered 
> in the registrar.
[JRE] I need advice how to include this - whether that interface is within scope of MARTINI.

John

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 09:52:07 -0600

On Jan 26, 2010, at 2:16 AM, Elwell, John wrote:

> URI, leaving the user part to identify the particular AOR. I think  
> this does indeed correspond to one of the practices seen in the wild  
> at present.
>

That's not contact-routing, and I don't THINK it's what Adam means. I  
think Adam means that there MUST be a unique contact URI for each AOR,  
One possible way for making this happen is to have at least one unique  
registered contact per AOR (that's traditional contact-routing on  
registrations, as done in RFC 3261)

Another is to have one registered contact "domain part" per AOR  
"domain part", and preserve user-parts across the transformation. I  
believe this is what Adam is proposing.

> different user parts (and hence the AORs and their respective  
> contacts), either in the request (PBX to SP) or in the response (SP  
> to PBX). My question is whether we need this at all - the question  
> whether it should be in the request or the response can be addressed  
> after we have determined whether it is needed at all.
>
> The argument for exchanging this information is to ensure that the  
> two sides are aligned, or at least to detect if there is  
> misalignment. It is probably not a mechanism for making changes to  
> the set of user parts - my opinion is that that is a provisioning  
> issue and outside the scope of MARTINI.

I believe the intent is that, using Adam's proposal, the SSP requires  
no prior knowledge of the set of user-parts,.  As PBX adds users,  
there is no "provisioning change" to the SSP. Possibly new  
registration messages, but no hard-state changes.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 09:55:09 -0600

On Jan 26, 2010, at 8:10 AM, Adam Roach wrote:

>> basically says that the domain part of the Request-URI in an  
>> inbound request should contain the domain part of the registered  
>> contact URI, leaving the user part to identify the particular AOR.
>
> PBX. In the dynamic-IP scenario, it ends up being the PBX's IP  
> address, not a domain it claims responsibility for.

And in that scenario, if the PBX supports two domains, and those  
domains have  separate user-name spaces, then the PBX needs to have  
two dynamic addresses. Or three addresses for three domains, etc.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jan 2010 09:57:34 -0600

On 1/26/10 09:55, Jan 26, Dean Willis wrote:
>>> URI, leaving the user part to identify the particular AOR.
>>

Or rules to rewrite each AOR into a unique contact address, each of 
which has that same IP address as the right-hand-side. I've given 
examples of how this works several times.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Jan 2010 09:03:54 -0700

> - The mechanism MUST allow the PBX to be responsible for its AORs and to handle requests to those AORs according to its rules.

Is it OK for the SSP to send the call to voicemail? I'm not arguing one way or the other here, I'm just trying to figure out if the SSP or PBX is responsible for the AOR?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 26 Jan 2010 10:12:37 -0600

Hi, Hadriel,

Sorry for being imprecise. "unless the service provider dorks with two-faced 
DNS" - that's the "we" I meant.

And I'm not suggesting that service providers dork with two-faced DNS - just 
that it's one of the alternatives I can imagine someone implementing quickly 
as a shortcut.

Thanks,

Spencer

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

> traversing any service provider proxy - unless we dork with two-faced DNS,

*We* (martini) won't be dorking with anything.  How a request got to the SSP 
is effectively out of scope for this WG, right?  For all I know, the request 
originated in the SSP.  The question isn't how it got to the SSP - the 
question is what the SSP should do about it once it gets it.  :)

-hadriel

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 26 Jan 2010 10:15:40 -0600

Hi, Bernard,

> even if the A/AAAA RRs are dynamically updated to point to the SIP-PBX?

Well, yes. I'm sorry I didn't say that more clearly, but your question 
points to the right answer.

So the next question is "now that the request has arrived at the service 
provider based on DNS entries for enterprise.com pointing to the service 
provider, how would the request be sent to the SIP-PBX and processed by the 
SIP-PBX instead of being looped back to the servicer provider, if the 
request URI still contains a domain name that resolves to the service 
provider?"

I'm sorry, I'm not following your mention about A/AAAA being dynamically 
updated to point to the SIP-PBX - when are you thinking this would happen? 
(during request handling? both before and after seem problematic. But maybe 
I'm missing something).

Thanks,

Spencer

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 17:26:44 +0100

> De : Spencer Dawkins [mailto:[email-masked]] 
> Envoyé : mardi 26 janvier 2010 17:16
> À : Bernard Aboba; CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]
> Objet : Re: [martini] Enumerating AORs/contacts
> 
> Hi, Bernard,
> 
> > Spencer said:
> >
> > "The problem with [email-masked] is that requests from outside 
> > the service provider to this AOR would go straight to the SIP-PBX 
> > without traversing any service provider proxy - unless we dork with 
> > two-faced DNS, etc."
> >
> requests go to 
> > the SP, even if the A/AAAA RRs are dynamically updated to 
> point to the 
> > SIP-PBX?
> 
> Well, yes. I'm sorry I didn't say that more clearly, but your 
> question points to the right answer.
> 
> So the next question is "now that the request has arrived at 
> the service provider based on DNS entries for enterprise.com 
> pointing to the service provider, how would the request be 
> sent to the SIP-PBX and processed by the SIP-PBX instead of 
> being looped back to the servicer provider, if the request 
> URI still contains a domain name that resolves to the service 
> provider?"

==>BC: The Location Service in the SSP will return a contact address representing the PBX in response to a query from a proxy in the SSP domain. This proxy will include the contact address in the route header field and leave the R-URI unchanged.

> 
> I'm sorry, I'm not following your mention about A/AAAA being 
> dynamically updated to point to the SIP-PBX - when are you 
> thinking this would happen? 
> (during request handling? both before and after seem 
> problematic. But maybe I'm missing something).
> 
> Thanks,
> 
> Spencer
> 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jan 2010 10:41:50 -0600

On 1/26/10 09:52, Jan 26, Dean Willis wrote:
>> leaving the user part to identify the particular AOR. I think this 
>> does indeed correspond to one of the practices seen in the wild at 
>> present.
>>
>
> think Adam means that there MUST be a unique contact URI for each AOR.

Right.

/a

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 10:43:23 -0600

On Jan 26, 2010, at 9:42 AM, Hadriel Kaplan wrote:

> *We* (martini) won't be dorking with anything.  How a request got to  
> the SSP is effectively out of scope for this WG, right?  For all I  
> know, the request originated in the SSP.  The question isn't how it  
> got to the SSP - the question is what the SSP should do about it  
> once it gets it.  :)

One possible assumption is that the request got to the SSP because RFC  
3263 procedures POINTED the request to the SSP. This means we can't  
use RFC 3263 procedures to get the request from the SSP to the PBX,  
unless the SP retargets the request somehow.

So yeah, it DOES put constraints on the solution space.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jan 2010 11:43:36 -0500

Well of course they can - and they can do it right now too.  So what?  As long as we don't advocate it or rely on it.  And we *don't* rely on it.  Who's to say the request can't go direct to the Enterprise?  It's a local policy decision if the Enterprise wants to accept it, of course, but as far as Martini is concerned it can.

The question is if a UA in SSP's domain sends a request to sip:[email-masked] through its SSP proxy-registrar, what should the SSP proxy-registrar do with the req-uri?
Option-1: leave it alone but insert the registered path/contact info as Route-header URIs
Option-2: replace it with some form of the registered contact-URI

I vote option-1.

The second problem is what if the SSP gets sip:[email-masked], and I propose that it retarget it, and also insert the Route list of the path/contact (because after retargeting it would then follow Option-1 above again).

The question is if the retargeting function details should be prescribed by a SIP-Forum document, or by an IETF document, or prescribed by the IP-PBX in its registration through some body list/regex-formula, or left to random implementations.

-hadriel

> Sent: Tuesday, January 26, 2010 11:13 AM
> To: Hadriel Kaplan; [email-masked]; john.elwell@siemens-
> enterprise.com; [email-masked]
> Cc: [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 10:46:57 -0600

On Jan 26, 2010, at 10:03 AM, Cullen Jennings wrote:

>> - The mechanism MUST allow the PBX to be responsible for its AORs  
>> and to handle requests to those AORs according to its rules.
>
> Is it OK for the SSP to send the call to voicemail? I'm not arguing  
> one way or the other here, I'm just trying to figure out if the SSP  
> or PBX is responsible for the AOR?

and in particular: Does the SSP use Service-Route to dispatch the call  
to application servers in order to "service" the call?

--
Dean

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 26 Jan 2010 17:47:52 +0100

I've just read my way through this entire thread again.

So going back to the start, what IMS does is mechanism 1), not 3).

If does this on the basis that we are trying to simulate as much as possible what a proxy doing an ordinary DNS look up would do. However it includes the extra Route header value because it needs to get through the rest of the IMS proxies to the gateway PBX.

As such any issues probably exist in the straight network peering solution as well. I would make the following points:

1)	Dean quite rightly stated that the enterprise operator is devolving some responsibility to the SSP. In TISPAN/3GPP, the view is essentially that the SSP is providing some form of virtual transit PBX, which the SSP rents to the enterprise provider.So the devolving of DNS responsibility is on the basis of that.

2)	The number routing problem is no different to that that exists between two SSPs. If you are a user with 123 @ ssp_example1 and I make a call to 123 @ ssp_example2, what does ssp_example2 do with this call. Either it ignores the domain name and processes it anyway - something that is not allowed by IETF but many operators do anyway, or it rejects the call. I don't expect anything different to happen in the business trunking. Thus the correct address for users on the PBX is [email-masked], not [email-masked]. How the SSP handles [email-masked] is not going to alter based on an IETF edict, but it will be the SSP breaking the rules.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Tuesday, January 26, 2010 4:04 PM
> To: Elwell, John
> Cc: [email-masked]
> its AORs and to handle requests to those AORs according to its rules.
> 
> Is it OK for the SSP to send the call to voicemail? I'm not 
> arguing one way or the other here, I'm just trying to figure 
> out if the SSP or PBX is responsible for the AOR?
> 
> 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jan 2010 10:50:20 -0600

> Option-2: replace it with some form of the registered contact-URI

And I could kind of see where this was coming from, if we were using 
something other than REGISTER to define this routing information. But 
the type of operation you describe in option-1 has never been associated 
with REGISTER. The thing you're describing in option-1 is effectively a 
site-local DNS override, not an AOR => Contact binding.

/a

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jan 2010 10:53:21 -0600

On Jan 26, 2010, at 10:41 AM, Adam Roach wrote:

>>> which basically says that the domain part of the Request-URI in an  
>>> I think this does indeed correspond to one of the practices seen  
>>> in the wild at present.
>>>
>>
>> That's not contact-routing, and I don't THINK it's what Adam means.  
>> I think Adam means that there MUST be a unique contact URI for each  
>> AOR.
>
> Right.
>

And, as you have pointed out, such uniqueness could be produced using  
several techniques, including 1) varying the domain-part or 2) varying  
the user-part or 3) varying both.

But SOMETHING has to be different so that the requests can be  
differentiated at the PBX!

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jan 2010 11:58:59 -0500

> Sent: Tuesday, January 26, 2010 11:50 AM
> To: Hadriel Kaplan
> Cc: Spencer Dawkins; [email-masked];
> > The question is if a UA in SSP's domain sends a request to
> sip:[email-masked] through its SSP proxy-registrar, what should the SSP
> proxy-registrar do with the req-uri?

That's why we're talking about a standards-track document and an options-tag rather than a BCP. :)

You make it sound like the "REGISTER" method is immutable as to the logic which a registrar-proxy performs and derives routing information from its entries.  What is so sacrosanct about a REGISTER that all derivative information cannot be used for new procedures?  Is it covered by GPL 3.0?

-hadriel

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 18:25:51 +0100

It's probably obvious from what I said before but I vote option-1 as well. 

> De : Hadriel Kaplan [mailto:[email-masked]] 
> Envoyé : mardi 26 janvier 2010 17:44
> À : Spencer Dawkins; CHATRAS Bruno RD-CORE-ISS; 
> [email-masked]; [email-masked]
> Cc : [email-masked]
> Well of course they can - and they can do it right now too.  
> So what?  As long as we don't advocate it or rely on it.  And 
> we *don't* rely on it.  Who's to say the request can't go 
> direct to the Enterprise?  It's a local policy decision if 
> the Enterprise wants to accept it, of course, but as far as 
> Martini is concerned it can.
> 
> sip:[email-masked] through its SSP proxy-registrar, what 
> should the SSP proxy-registrar do with the req-uri?
> The second problem is what if the SSP gets 
> sip:[email-masked], and I propose that it retarget it, and 
> also insert the Route list of the path/contact (because after 
> retargeting it would then follow Option-1 above again).
> 
> The question is if the retargeting function details should be 
> prescribed by a SIP-Forum document, or by an IETF document, 
> or prescribed by the IP-PBX in its registration through some 
> body list/regex-formula, or left to random implementations.
> 
> -hadriel
> 
> 
> > To: Hadriel Kaplan; [email-masked]; 
> > john.elwell@siemens- enterprise.com; [email-masked]
> > Cc: [email-masked]
> > Sorry for being imprecise. "unless the service provider dorks with 
> > two- faced DNS" - that's the "we" I meant.
> > 
> > And I'm not suggesting that service providers dork with 
> two-faced DNS 
> > - just that it's one of the alternatives I can imagine someone 
> > implementing quickly as a shortcut.
> > 
> > Thanks,
> > 
> > Spencer
> > 
> > ------------------------
> > 
> > > The problem with [email-masked] is that requests 
> from outside 
> > > two-faced
> > DNS,
> > got to the SSP - the question is what the SSP should do 
> about it once 
> > it gets it.  :)
> > 
> > -hadriel
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Jan 2010 20:46:36 -0700

> So going back to the start, what IMS does is mechanism 1), not 3).

I'm not really sure it makes much difference for deciding what to do here, but when I look at 3GPP R5, it looks to me very much that the SSP was responsible for the domain and not the terminal. Part of the point of IMS was the service provider, not the terminal, being able to create and control services. So I come to a very different conclusion about if it is 1 or 3. Now I'd be the first to say than Keith understands 3GPP better than I ever will but I'm just not understanding how you come to the conclusion that the service provider was not responsible, in the 3261 sense of responsible, for the AOR. 

> 2)	The number routing problem is no different to that that exists between two SSPs. If you are a user with 123 @ ssp_example1 and I make a call to 123 @ ssp_example2, what does ssp_example2 do with this call. Either it ignores the domain name and processes it anyway - something that is not allowed by IETF but many operators do anyway, or it rejects the call. I don't expect anything different to happen in the business trunking. Thus the correct address for users on the PBX is [email-masked], not [email-masked]. How the SSP [email-masked] is not going to alter based on an IETF edict, but it will be the SSP breaking the rules.
> 
> regards
> 
> Keith

Cullen <in my individual contributor role>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jan 2010 10:08:23 +0100

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 26 January 2010 16:59
> To: Adam Roach
> Elwell, John; [email-masked]
> > > Option-1: leave it alone but insert the registered 
> path/contact info as
> > Route-header URIs
> You make it sound like the "REGISTER" method is immutable as 
> to the logic which a registrar-proxy performs and derives 
> routing information from its entries.  What is so sacrosanct 
> about a REGISTER that all derivative information cannot be 
> used for new procedures?  Is it covered by GPL 3.0?
[JRE] Exactly. We would still be using REGISTER to register a contact and a path. The difference is just in how that registered information is used to route a subsequent inbound request.

John
f

---

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

I suspect it comes down to the definition you are using of responsible. Maybe you would like to elaborate on what that term means, rather than what happens when it is applied as a condition (which is all we get from RFC 3261).

3GPP does not actually specify how domain names are used in IMS. GSMA has some work, but the rest is left to deployment.  

In general we have considered it under the same assumptions as domain names are handled in email - I can ask someone else to host my domain name, etc.

regards

Keith

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Wednesday, January 27, 2010 3:47 AM
> To: DRAGE, Keith (Keith)
> I'm not really sure it makes much difference for deciding 
> what to do here, but when I look at 3GPP R5, it looks to me 
> very much that the SSP was responsible for the domain and not 
> the terminal. Part of the point of IMS was the service 
> provider, not the terminal, being able to create and control 
> services. So I come to a very different conclusion about if 
> it is 1 or 3. Now I'd be the first to say than Keith 
> understands 3GPP better than I ever will but I'm just not 
> understanding how you come to the conclusion that the service 
> provider was not responsible, in the 3261 sense of 
> responsible, for the AOR. 
> 
> 
> > 
> > If does this on the basis that we are trying to simulate as 
> much as possible what a proxy doing an ordinary DNS look up 
> would do. However it includes the extra Route header value 
> because it needs to get through the rest of the IMS proxies 
> to the gateway PBX.
> > 
> > As such any issues probably exist in the straight network 
> peering solution as well. I would make the following points:
> > 
> > 1)	Dean quite rightly stated that the enterprise operator 
> is devolving some responsibility to the SSP. In TISPAN/3GPP, 
> the view is essentially that the SSP is providing some form 
> of virtual transit PBX, which the SSP rents to the enterprise 
> provider.So the devolving of DNS responsibility is on the 
> basis of that.
> > 
> > 2)	The number routing problem is no different to that that 
> exists between two SSPs. If you are a user with 123 @ 
> ssp_example1 and I make a call to 123 @ ssp_example2, what 
> does ssp_example2 do with this call. Either it ignores the 
> domain name and processes it anyway - something that is not 
> allowed by IETF but many operators do anyway, or it rejects 
> the call. I don't expect anything different to happen in the 
> business trunking. Thus the correct address for users on the 
> PBX is [email-masked], not [email-masked]. How the SSP 
> [email-masked] is not going to alter based on an IETF 
> edict, but it will be the SSP breaking the rules.
> > 
> > regards
> > 
> > Keith
>