Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 18:07:06 -0400

I dont think its crazy dean. Its more or less what I'm planning on 
putting in the revision to route-construct.

-Jonathan R.

Dean Willis wrote:

> 
> On May 5, 2006, at 9:20 AM, Paul Kyzivat wrote:
> 
> 
>>
>> Section 4 says that the s-r is associated with each registered  
>> contact rather than the AOR. By that, I guess you mean that if the  
>> register contains contacts X and Y, and the register response  
>> contains contacts X,Y,Z then the s-r applies to X and Y. Then what  
>> about a polling register that contains no contacts? Either it  
>> contains a s-r that applies to nothing, or else it shouldn't  contain 
>> a s-r at all. I guess this is implied, but might be worth  pointing out.
>>
> 
> This is exactly why we made S-R and Path apply to the AOR and not the  
> contact originally.
> 
> I wanted to change things such that the registrar stores and returns  a 
> contact-route instead of just a contact, but folks thought I was  
> crazier than usual.
> 
> -- 
> Dean
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 18:05:55 -0400

Wow - its been like 5 months since you sent this. I am now revising 
route-construct again, since its a key part of this mid-dialog failover 
mechanism for SIP-outbound, in addition to being needed for other 
reasons. So, thanks for the comments, and some responses inline.

For anyone else interested in this stuff, the draft has actually 
expired. It can be picked up on my website:
http://www.jdrosen.net/papers/draft-rosenberg-sip-route-construct-01.txt

Paul Kyzivat wrote:

> Jonathan,
> 
> I think we need this badly. It is clearly a complex issue. A few 
> comments and questions about the new version:
> 
> Section 4 says that the s-r is associated with each registered contact 
> rather than the AOR. By that, I guess you mean that if the register 
> contains contacts X and Y, and the register response contains contacts 
> X,Y,Z then the s-r applies to X and Y.

Actually what I'd like to say is that this mechanism only works when 
REGISTER has one contact. Realistically speaking, we are moving more and 
more towards the model where your REGISTER message is registering where 
you came from (sip outbound). If you are doing a third party register 
(and there are almost always better ways to accomplish a goal than 
that), or you are doing a polling register (for which there is little 
need anymore) you just don't get this feature.

  Then what about a polling
> register that contains no contacts? Either it contains a s-r that 
> applies to nothing, or else it shouldn't contain a s-r at all. I guess 
> this is implied, but might be worth pointing out.

No S-R.

I'd also go so far as to argue that, even if there are multpple UA, with 
this service route extension, the registrar just returns YOUR contact. 
It avoids the pain of looking through the contacts to find your own, and 
you don't need them anyway. Again this is along the lines of where 
register is going with sip-outbound.

> 
> Regarding doing things with domains under the control of the proxy: it 
> turns out to be interesting that none of the IMS elements seem to know 
> which domains they control. All they really know is which URIs get 
> matched in the HSS. There is also implicit understanding in the sense 
> that any domains that get routed to one of the elements of the IMS 
> network via normal routing policies must somehow be controlled by it, 
> but it will only understand this via the HSS lookup. So any logic of the 
> form: "do XYZ to a URI if the domain of the URI is one you control" is 
> problematic for IMS.

Hmm, I added these words for IMS in fact. Somehow I recall that the 
S-CSCF could insert additional service-routes besides just the S-CSCF. 
If this is not true its even easier. I would much prefer the spec just 
basically say to invert Path and thats it.

> 
> I like the use of the lr parameter in a contact to decide whether to 
> rewrite the aor with the registered contact. clever.

Thanks. This is now fully expanded upon in:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt

and I will remove it from the next revision in service route.

> 
> Section 5.4 says that a client (proxy or not) receiving a 305 with 
> non-zero response-target should not recurse on it. So what should a UAC 
> do in this case? Seems like this is equivalent to a 500 response.

I suppose. I've reconsidered this whole mechanism further and think its 
WAY too complciated. I was thinking of features like having a home proxy 
tell a UA to register to a different home proxy using a 305 targeted at 
the UA. However, there is no real need for that. If you limit recursion 
to the previous hop, the whole mechanism becomes much simpler. Indeed, 
the alternative is discussed in the loose-route draft, which is more or 
less what Jeroen has posted on this old thread (to which I will reply 
shortly). Include a flag in the Via. Redirect if the topmost Via has the 
flag, and the recursion is always by that entity. Then, this issue you 
raise goes away.

> 
> The rules for 305 processing don't mention stateless proxies. It is 
> possible for a 305 to be targetted to a stateless proxy. But in that 
> case it won't have the state needed to do the recursion. And of course 
> it is unclear how the sender of the 305 can tell what element to target 
> and whether it is stateless or not. Seems like some guidance on how to 
> select a 305 target is needed. But it is far from clear to me what that 
> guidance would be.

I think the guidance would be that a stateless proxy cannot implement 
this mechanism. Per above, it would not insert this flag into the 
topmost Via.

> 
> What should be done about a 305 received during recursion of a prior 
> 305? The obvious thing would be to start the recursion over with the new 
> value(s). But there is a potential for looping here. And I don't think 
> that is covered by 3261. So maybe some new loop prevention logic is 
> needed here.

I think it would recurse again. You are right there could be a loop. 
Text needs to be added (presumably in loose route since that is where I 
have put this) that says that you don't recurse toa  URI you already 
recursed to. There would probably also need to be a fixed limit on the 
total number of recursions done in a transaction.

> 
> I didn't see much mention of routing done independently of the route 
> headers. E.g. sending to an outbound proxy that is not mentioned in the 
> route header. In most cases I suppose that should still be ok. But when 
> done by the UAC it adds confusion to what should then be done when 
> receiving a 305. In particular if a UAC does this, then its outbound 
> proxy could never bypass itself using a 305. I guess that behavior could 
> be deprecated here, but I'm not certain what all the implications of 
> that are.

Hmm good question. My assumption was that the outbound proxy had been in 
the Route set. If it hadn't, I think the 305 gets processed as if it had 
been, in which case the 305 would replace it. That needs to be mentioned 
I think. Again it would go in ua-loose-route since that is where I have 
put all of this.

route-construct will therefore more or less become an update to 
service-route that also integrates the logic defined in loose-route.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 18:08:48 -0400

Thanks for the comments Jeroen. Sorry they are super-super late. I put 
this work aside for a long while.

inline.

Jeroen van Bemmel wrote:

> Jonathan,
> 
> The 305 re-routing mechanism in section 4 seems more complex than it 
> needs to be, and adds overhead to all requests. How about the following:

Way to complex in fact. More below.

> 
> 1. Each compliant proxy adds a new 'rt' flag to its Via header

Yes I like that and this is what I put into the UA loose route document.

> 2. The proxy / UAS that sends the 305 counts how many via's contain this 
> flag, starting from the top, and inserts this as a count into the 
> Redirect-Target header
> 3. 305 is forwarded upstream, each proxy decrements as currently 
> specified, when it becomes 0 the proxy recurses

I'm thinking, why even be this complicated. If you limit the 3xx to be 
to the previous hop only, things are much simpler. It also eliminates 
all these issues of dealing with SBCs and other nasties that remove Via 
headers.

> 
> If local policy says that downstream elements are not allowed to 
> redirect upstream, a proxy would remove the 'rt' flag from the received 
> top via

Right.

-Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 17 Oct 2006 01:28:52 +0200

>> 2. The proxy / UAS that sends the 305 counts how many via's contain
>> this flag, starting from the top, and inserts this as a count into
>> the Redirect-Target header
> all these issues of dealing with SBCs and other nasties that remove
> Via headers.

Yes, you could simplify it like that. Still can't avoid to scan the Via 
headers though, since the previous hop might be a stateless proxy which 
would not be able to perform the redirect (and hence MUST NOT insert a flag 
I suppose). So we would have "previous stateful hop that supports the 
mechanism". If there is no such hop, 305 should not be sent (as it would 
probably confuse older clients).

Regards,
Jeroen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 21:05:38 -0400

inline.

Jeroen van Bemmel wrote:

> would not be able to perform the redirect (and hence MUST NOT insert a 
> flag I suppose). So we would have "previous stateful hop that supports 
> the mechanism". If there is no such hop, 305 should not be sent (as it 
> would probably confuse older clients).

You don't need to scan the Via list. If the previous hop is a stateless 
proxy and didn't insert the flag (which it won't) you can't do the 305. 
You would never need to look beyond the previous hop since a redirect 
would have to be consumed by the previous hop, or you wouldn't be 
allowed to send it.

Thanks,
Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Oct 2006 01:00:40 -0500

> putting in the revision to route-construct.

Groovy. Now just remember that the next time I say something everybody 
thinks is crazy -- maybe five years later, it will sound more 
reasonable. Except this statement, of course, which will always sound 
crazy. ;-)

--
dean