Subject: [martini] The much maligned Request-URI

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

Howdy,
The topic of what to do with that pesky Req-uri seems to be going round and round.

There are 3 camps afaict:
1) Leave it alone - completely alone.
2) Contact-route it: replace it with the Registered contact, where "Registered contact" may be a URI indicated in a body list per AoR, or regex-style formula.
3) Change the host portion only, based on the contact-uri host or a provisioned domain name, leave the rest alone (user and params).

I don't think Option-1 is a real option.  As far as I know, in virtually all cases of IP-PBX trunking I've been involved with, by the time the request gets to the IP-PBX, the req-uri's domain/host portion identifies the IP-PBX's domain or host/IP.  It may not be the routing proxy-registrar which does it, but a middlebox instead... but it will get changed if it wasn't already right.  

That's consistent with what *should* happen, because if the request was sip:[email-masked] and was routed to pbx.com, then it got *retargeted*.  Luckily (or not) retargeting rules are basically completely open in 3261.  We can do whatever magic we want to.

There have been some threads that changing "sip:[email-masked]" to "sip:[email-masked]" *blindly* is broken for anything but E.164 because foobar may be someone different for pbx.com.  I think that's a red herring argument.  In what way, shape or form could the SSP have possibly *blindly* retargeted [email-masked] to [email-masked]??  Clearly the SSP must have had some retargeting entry for "[email-masked]" - the whole thing, not just the host.  The same is true of E.164's - the SSP can't/won't send all E.164's to pbx.com, just the list of ones for the pbx.

So ISTM what we're really talking about is whether the PBX should be able to provision the retargeting rules themselves in the SSP through the registration mechanism (ie, a body list or regex formula), or whether we should leave it as just pre-provisioned and simply document that a retargeting MUST occur to the PBX's domain/host.

Personally I vote for leave it pre-provisioned, because I don't want to troubleshoot weird PBX implementations putting crap in a body list.  I know the SSP side can screw up too, but it's easier to manage. (but then of course I'd say that)

-hadriel

---

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

> That's consistent with what *should* happen, because if the request was sip:[email-masked] and was routed to pbx.com, then it got *retargeted*.  Luckily (or not) retargeting rules are basically com…

That's only true for a proxy that is responsible for the R-URI. Everyone 
else is pretty tightly constrained in what they can do -- basically, 
they can add Route headers, but they are forbidden from retargeting. RFC 
3261 has at least two normative statements on the topic:

"A proxy MUST NOT add additional targets to the target set if the 
Request-URI of the original request does not indicate a resource this 
proxy is responsible for."

"If the domain of the Request-URI indicates a domain this element is not 
responsible for, the Request-URI MUST be placed into the target set as 
the only target, and the element MUST proceed to the task of Request 
Forwarding"

> There have been some threads that changing "sip:[email-masked]" to "sip:[email-masked]" *blindly* is broken for anything but E.164 because foobar may be someone different for pbx.com.  I think that's a red herring argument.  In what way, shape or form could the SSP have possibly *blindly* retargeted [email-masked] to [email-masked]??  Clearly the SSP must have had some retargeting entry for "[email-masked]" - the whole thing, not just the host.

I agree. The prospect of ignoring the domain and treating the user as a 
unique key is highly problematic.

> So ISTM what we're really talking about is whether the PBX should be able to provision the retargeting rules themselves in the SSP

The SSP can't retarget unless is responsible for the domain.

But if the SSP is responsible for the domain, then the PBX can't 
retarget the requests once they arrive, which means they can't send them 
to the proper terminal.

Which is why we need to nail down domain responsibility.

/a

---

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

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Hadriel Kaplan
> Envoyé : mardi 26 janvier 2010 16:33
> À : [email-masked]
> Objet : [martini] The much maligned Request-URI
> 
> Howdy,
> 2) Contact-route it: replace it with the Registered contact, 
> where "Registered contact" may be a URI indicated in a body 
> list per AoR, or regex-style formula.
> 3) Change the host portion only, based on the contact-uri 
> host or a provisioned domain name, leave the rest alone (user 
> and params).
> 
> I don't think Option-1 is a real option.  As far as I know, 
> in virtually all cases of IP-PBX trunking I've been involved 
> with, by the time the request gets to the IP-PBX, the 
> req-uri's domain/host portion identifies the IP-PBX's domain 
> or host/IP.  It may not be the routing proxy-registrar which 
> does it, but a middlebox instead... but it will get changed 
> if it wasn't already right.  
> 

==>BC: This statement sounds strange to me as I have seen cases where the middlebox does the opposite: overrides the Request-URI with the contents of a P-Called-Party-Id header field so as to restore the initial value Request-URI.

> That's consistent with what *should* happen, because if the 
> request was sip:[email-masked] and was routed to pbx.com, 
> then it got *retargeted*.  Luckily (or not) retargeting rules 
> are basically completely open in 3261.  We can do whatever 
> magic we want to.
> 
> There have been some threads that changing 
> "sip:[email-masked]" to "sip:[email-masked]" *blindly* is 
> broken for anything but E.164 because foobar may be someone 
> different for pbx.com.  I think that's a red herring 
> argument.  In what way, shape or form could the SSP have 
> possibly *blindly* retargeted [email-masked] to 
> [email-masked]??  Clearly the SSP must have had some 
> retargeting entry for "[email-masked]" - the whole thing, not 
> just the host.  The same is true of E.164's - the SSP 
> can't/won't send all E.164's to pbx.com, just the list of 
> ones for the pbx.
> 
> So ISTM what we're really talking about is whether the PBX 
> should be able to provision the retargeting rules themselves 
> in the SSP through the registration mechanism (ie, a body 
> list or regex formula), or whether we should leave it as just 
> pre-provisioned and simply document that a retargeting MUST 
> occur to the PBX's domain/host.
> 
> Personally I vote for leave it pre-provisioned, because I 
> don't want to troubleshoot weird PBX implementations putting 
> crap in a body list.  I know the SSP side can screw up too, 
> but it's easier to manage. (but then of course I'd say that)
> 
> -hadriel
> 
> _______________________________________________
> 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: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jan 2010 10:44:56 -0500

Sorry I should have been explicit about the context.  The context was the SSP receives a request for "sip:[email-masked]".  The SSP is authoritative for ssp.com.  It retargets to pbx.com.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, January 26, 2010 10:39 AM
To: [email-masked]
Subject: Re: [martini] The much maligned Request-URI

That's consistent with what *should* happen, because if the request was sip:[email-masked]<mailto:sip:[email-masked]> and was routed to pbx.com, then it got *retargeted*.  Luckily (or not) retargeting rules are basically completely open in 3261.  We can do whatever magic we want to.

That's only true for a proxy that is responsible for the R-URI. Everyone else is pretty tightly constrained in what they can do -- basically, they can add Route headers, but they are forbidden from retargeting. RFC 3261 has at least two normative statements on the topic:

"A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for."

"If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding"

There have been some threads that changing "sip:[email-masked]"<mailto:sip:[email-masked]> to "sip:[email-masked]"<mailto:sip:[email-masked]> *blindly* is broken for anything but E.164 because foobar may be someone different for pbx.com.  I think that's a red herring argument.  In what way, shape or form could the SSP have possibly *blindly* retargeted [email-masked]<mailto:[email-masked]> to [email-masked]<mailto:[email-masked]>??  Clearly the SSP must have had some retargeting entry for "[email-masked]"<mailto:[email-masked]> - the whole thing, not just the host.

I agree. The prospect of ignoring the domain and treating the user as a unique key is highly problematic.

But if the SSP is responsible for the domain, then the PBX can't retarget the requests once they arrive, which means they can't send them to the proper terminal.

/a

---

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

So, in my previous examples, you're thinking that Braniff would want to 
be giving out r-uris of the form "sip:[email-masked]" instead of 
"sip:[email-masked]"?

/a

On 1/26/10 09:44, Jan 26, Hadriel Kaplan wrote:
>
> Sorry I should have been explicit about the context.  The context was 
> the SSP receives a request for "sip:[email-masked]".  The SSP is 
> authoritative for ssp.com.  It retargets to pbx.com.
>
> -hadriel
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Adam Roach
> *Sent:* Tuesday, January 26, 2010 10:39 AM
> *To:* [email-masked]
> *Subject:* Re: [martini] The much maligned Request-URI
>
> That's consistent with what *should* happen, because if the request wassip:[email-masked]  <mailto:sip:[email-masked]>  and was routed to pbx.com, then it got *retargeted*.  Luckily (or not) retargeting rules are basically completely open in 3261.  We can do whatever magic we want to.
>    
>
>
> That's only true for a proxy that is responsible for the R-URI. 
> Everyone else is pretty tightly constrained in what they can do -- 
> basically, they can add Route headers, but they are forbidden from 
> retargeting. RFC 3261 has at least two normative statements on the topic:
>
> "If the domain of the Request-URI indicates a domain this element is 
> not responsible for, the Request-URI MUST be placed into the target 
> set as the only target, and the element MUST proceed to the task of 
> Request Forwarding"
>
>
>
>   
> There have been some threads that changing"sip:[email-masked]"  <mailto:sip:[email-masked]>  to"sip:[email-masked]"  <mailto:sip:[email-masked]>  *blindly* is broken for anything but E.164 because foobar may be someone different for pbx.com.  I think that's a red herring argument.  In what way, shape or form could the SSP have possibly *blindly* [email-masked]  <mailto:[email-masked]>  [email-masked]  <mailto:[email-masked]>??  Clearly the SSP must have had some retargeting entry for"[email-masked]"  <mailto:[email-masked]>  - the whole thing, not just the host.
>
>
> retarget the requests once they arrive, which means they can't send 
> them to the proper terminal.
>

---

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

> -----Original Message-----
> From: [email-masked] [mailto:bruno.chatras@orange-
> ftgroup.com]
> Sent: Tuesday, January 26, 2010 10:40 AM
> 
> ==>BC: This statement sounds strange to me as I have seen cases where the
> middlebox does the opposite: overrides the Request-URI with the contents
> of a P-Called-Party-Id header field so as to restore the initial value
> Request-URI.

Huh.  I've seen us do that - but for the user portion only. (because the original req-uri was replaced by the registrar-proxy to be the registered contact-uri and lost the actual target info)

For the cases you've seen where the req-uri ended up being the SSP's domain again when it reached the IP-PBX, was the IP-PBX actually provisioned to be in the SSP's domain?  I have seen that - the IP-PBX was configured to literally be in ssp.com, with a default route for unknown users to the "real" SSP proxies.

-hadriel

---

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

> De : Hadriel Kaplan [mailto:[email-masked]] 
> Envoyé : mardi 26 janvier 2010 16:52
> À : CHATRAS Bruno RD-CORE-ISS; [email-masked]
> Objet : RE: [martini] The much maligned Request-URI
> 
> 
> 
> > > Envoyé : mardi 26 janvier 2010 16:33 I don't think Option-1 is a 
> > > real option.  As far as I know, in virtually all cases of IP-PBX 
> > > trunking I've been involved with, by the time the request gets to 
> > > the IP-PBX, the req-uri's domain/host portion identifies the 
> > > IP-PBX's domain or host/IP.  It may not be the routing 
> > > proxy-registrar which does it, but a middlebox instead... but it 
> > > will get changed if it wasn't already right.
> > >
> > 
> > ==>BC: This statement sounds strange to me as I have seen 
> cases where 
> > the middlebox does the opposite: overrides the Request-URI with the 
> > contents of a P-Called-Party-Id header field so as to restore the 
> > initial value Request-URI.
> 
> Huh.  I've seen us do that - but for the user portion only. 
> (because the original req-uri was replaced by the 
> registrar-proxy to be the registered contact-uri and lost the 
> actual target info)
> 
> For the cases you've seen where the req-uri ended up being 
> the SSP's domain again when it reached the IP-PBX, was the 
> IP-PBX actually provisioned to be in the SSP's domain?  I 
> have seen that - the IP-PBX was configured to literally be in 
> ssp.com, with a default route for unknown users to the "real" 
> SSP proxies.

==>BC: I have to double check but from memory the edge proxy was replacing the R-URI with the contents of the P-Called-Pary-Id,irrespective of the domain name.

---

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

Not at all - I have no idea what Braniff would want to do (probably use [email-masked]<mailto:[email-masked]>, since Verizon now owns Braniff's former headquarters building :)).
But seriously, how a request to [email-masked]<mailto:[email-masked]> happened to get to centricvoice's proxies does not matter, and is not in scope.  All we're doing is figuring out how a request to [email-masked]<mailto:[email-masked]> gets from centricvoice to braniff.
hadriel

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: Tuesday, January 26, 2010 10:49 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] The much maligned Request-URI

So, in my previous examples, you're thinking that Braniff would want to be giving out r-uris of the form "sip:[email-masked]"<mailto:sip:[email-masked]> instead of "sip:[email-masked]"<mailto:sip:[email-masked]>?

/a

On 1/26/10 09:44, Jan 26, Hadriel Kaplan wrote:
Sorry I should have been explicit about the context.  The context was the SSP receives a request for "sip:[email-masked]<mailto:sip:[email-masked]>".  The SSP is authoritative for ssp.com.  It retargets to pbx.com.

-hadriel

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, January 26, 2010 10:39 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [martini] The much maligned Request-URI

/a

---

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

On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote:
>
> Not at all -- I have no idea what Braniff would want to do (probably 
> use [email-masked] <mailto:[email-masked]>, since Verizon now owns 
> Braniff's former headquarters building J).
>
> But seriously, how a request to [email-masked] 
> <mailto:[email-masked]> happened to get to centricvoice's proxies 
> does not matter...
>

It kind of does. If you're proposing a solution that is predicated on 
ignoring DNS wholesale, then you've just amplified the alt-root problem 
by several orders of magnitude.

The answer to that question must be "it works AT LEAST for the cases in 
which RFC 3263 routing procedures took it to the SSP". If you want to 
make it work for other scenarios, that's fine. But if you're designing a 
solution that cannot work on the Internet at large, then it really won't 
fly.

/a

---

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

I'm not proposing a solution that ignores DNS wholesale.  I'm proposing a mechanism for routing a request from domain-A (e.g., an SSP) to domain-B (e.g. a IP-PBX), for cases where DNS cannot be used for reaching domain-B from domain-A.  How a request gets to domain-A is not a problem for Martini.  If someone chooses to provision DNS such that domain-B has an entry which points to domain-A, that's their issue and I'm neither condoning it nor mentioning it.  I can't stop people from having host files or local policy overrides either.

-hadriel

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: Tuesday, January 26, 2010 11:05 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] The much maligned Request-URI

On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote:
Not at all - I have no idea what Braniff would want to do (probably use [email-masked]<mailto:[email-masked]>, since Verizon now owns Braniff's former headquarters building :)).
But seriously, how a request to [email-masked]<mailto:[email-masked]> happened to get to centricvoice's proxies does not matter...

It kind of does. If you're proposing a solution that is predicated on ignoring DNS wholesale, then you've just amplified the alt-root problem by several orders of magnitude.

The answer to that question must be "it works AT LEAST for the cases in which RFC 3263 routing procedures took it to the SSP". If you want to make it work for other scenarios, that's fine. But if you're designing a solution that cannot work on the Internet at large, then it really won't fly.

/a

---

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

Okay, so we're in agreement that it must work at least for the cases in 
which RFC 3263 resolution procedures on the PBX's domain resolve to an 
IP address belonging to one of the SSP's servers. Right?

/a

On 1/26/10 10:33, Jan 26, Hadriel Kaplan wrote:
>
> I'm not proposing a solution that ignores DNS wholesale.  I'm 
> proposing a mechanism for routing a request from domain-A (e.g., an 
> SSP) to domain-B (e.g. a IP-PBX), for cases where DNS cannot be used 
> for reaching domain-B from domain-A.  How a request gets to domain-A 
> is not a problem for Martini.  If someone chooses to provision DNS 
> such that domain-B has an entry which points to domain-A, that's their 
> issue and I'm neither condoning it nor mentioning it.  I can't stop 
> people from having host files or local policy overrides either.
>
> -hadriel
>
> *From:* Adam Roach [mailto:[email-masked]]
> *Sent:* Tuesday, January 26, 2010 11:05 AM
> *To:* Hadriel Kaplan
> *Cc:* [email-masked]
> ignoring DNS wholesale, then you've just amplified the alt-root 
> problem by several orders of magnitude.
>
> The answer to that question must be "it works AT LEAST for the cases 
> in which RFC 3263 routing procedures took it to the SSP". If you want 
> to make it work for other scenarios, that's fine. But if you're 
> designing a solution that cannot work on the Internet at large, then 
> it really won't fly.
>
> /a
>

---

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

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

>
> I don't think Option-1 is a real option.  As far as I know, in  
> virtually all cases of IP-PBX trunking I've been involved with, by  
> the time the request gets to the IP-PBX, the req-uri's domain/host  
> portion identifies the IP-PBX's domain or host/IP.  It may not be  
> the routing proxy-registrar which does it, but a middlebox  
> instead... but it will get changed if it wasn't already right.

But if the request had originally encoded "a domain belonging to the  
PBX", why does it get changed? You're starting with the assumption  
that the request originally targeted some other domain.

>
> That's consistent with what *should* happen, because if the request  
> was sip:[email-masked] and was routed to pbx.com, then it got  
> *retargeted*.  Luckily (or not) retargeting rules are basically  
> completely open in 3261.  We can do whatever magic we want to.

Hold on a sec. The idea behind MARTINI is that the request was NOT  
routed to the service provider, but was route to a domain "owned" by  
the customer (OBX), and for which the SSP is providing a relay service.

So what's our problem space again?

--
Dean

---

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

Sure I guess, but why is that a requirement for Martini?  I'm not trying to be belligerent, but I just don't see why those details matter for the problem at hand.  For all I care, the DNS can point to the PBX, which can send a 302 redirect to all requests not from its SSP, redirecting to its SSP.
-hadriel

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: Tuesday, January 26, 2010 11:36 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] The much maligned Request-URI

Okay, so we're in agreement that it must work at least for the cases in which RFC 3263 resolution procedures on the PBX's domain resolve to an IP address belonging to one of the SSP's servers. Right?

/a

-hadriel

Cc: [email-masked]<mailto:[email-masked]>

/a

---

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

> the customer (OBX), and for which the SSP is providing a relay  

I mean "but was routed to a domain "owned" by the customer (PBX)".  
Keys are too close together on this keyboard! But apparently you folks  
knew what I meant anyhow.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jan 2010 11:00:00 -0600

It matters because it helps nail down the use cases we're talking about. 
We need to come to some consensus about who is "responsible" -- in the 
RFC 3261 sense of that word (that is, as RFC 3261 uses it in normative 
statements) -- for the domain in the request URI.

/a

On 1/26/10 10:51, Jan 26, Hadriel Kaplan wrote:
>
> Sure I guess, but why is that a requirement for Martini?  I'm not 
> trying to be belligerent, but I just don't see why those details 
> matter for the problem at hand.  For all I care, the DNS can point to 
> the PBX, which can send a 302 redirect to all requests not from its 
> SSP, redirecting to its SSP.
>
> -hadriel
>
> *Sent:* Tuesday, January 26, 2010 11:36 AM
> *To:* Hadriel Kaplan
> *Cc:* [email-masked]
> Okay, so we're in agreement that it must work at least for the cases 
> in which RFC 3263 resolution procedures on the PBX's domain resolve to 
> an IP address belonging to one of the SSP's servers. Right?
>
> /a
>
> *Cc:* [email-masked] <mailto:[email-masked]>

---

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

I think Hadriel makes an excellent point here. The SSP somehow has a request for pbx.com, and needs to know how to route it there, in the absence of being able to use RFC 3263. How the SSP gets that request can be considered out of scope.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 26 January 2010 16:34
> To: Adam Roach
> Cc: [email-masked]
> proposing a mechanism for routing a request from domain-A 
> (e.g., an SSP) to domain-B (e.g. a IP-PBX), for cases where 
> DNS cannot be used for reaching domain-B from domain-A.  How 
> a request gets to domain-A is not a problem for Martini.  If 
> someone chooses to provision DNS such that domain-B has an 
> entry which points to domain-A, that's their issue and I'm 
> neither condoning it nor mentioning it.  I can't stop people 
> from having host files or local policy overrides either. 
> 
>  
> 
> -hadriel
> 
>  
> 
> Not at all - I have no idea what Braniff would want to do 
> (probably use [email-masked], since Verizon now owns 
> But seriously, how a request to [email-masked] happened to 
> get to centricvoice's proxies does not matter...
> 
> 
> It kind of does. If you're proposing a solution that is 
> predicated on ignoring DNS wholesale, then you've just 
> amplified the alt-root problem by several orders of magnitude.
> 
> The answer to that question must be "it works AT LEAST for 
> the cases in which RFC 3263 routing procedures took it to the 
> SSP". If you want to make it work for other scenarios, that's 
> fine. But if you're designing a solution that cannot work on 
> the Internet at large, then it really won't fly.
> 
> /a
> 
>