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

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 May 2006 10:20:17 -0400

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. 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.

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.

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

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.

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.

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 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.

	Paul

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Fri, 5 May 2006 16:00:13 -0500

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 6 May 2006 01:59:12 +0200

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:

1. Each compliant proxy adds a new 'rt' flag to its Via header
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

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

Another alternative would be for the proxy/UAS that sends the 305 to remove 
all rt flags starting from the top, except the last of a continuous series. 
A proxy would then recurse on 305 iff it finds the 'rt' flag still in its 
Via header.

For your example:
REGISTER
via: p-3;tr
via: p-2;tr
via: p-1  <-- does not support it
via: uac

p-4 would formulate:
305 Use Proxy
via: p-3  <-- removed
via: p-2;tr
via: p-1  <-- still does not support it
via: uac

p-2 would receive:
305 Use Proxy
via: p-2;tr    <-- set, implies recurse
via: p-1  <-- still does not support it
via: uac

This avoids the overhead of adding headers to all requests (and to 305 
responses)

Regards,

jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 6 May 2006 12:56:12 +0200

> upstream, a proxy would remove the 'rt' flag from the received top via

Better yet: instead of removing the 'rt' flag, the proxy would simply 
recurse regardless of the Redirect-Target count (A) or presence of the 'tr' 
flag (solution B below). No need to modify the request to implement this 
policy

In addition, I think we would need the following mechanism: proxy P-3 in 
your example adds a new header containing the current value of Max-Forwards 
found in the request. The element recursing on the 305 must then set its 
Max-Forwards to this value - 1, to avoid infinite loops in case of bad 
configuration (i.e. proxies playing ping-pong)

Regards,
Jeroen

> Another alternative would be for the proxy/UAS that sends the 305 to 
> remove all rt flags starting from the top, except the last of a continuous 
> series. A proxy would then recurse on 305 iff it finds the 'rt' flag still 
> in its Via header.
>
> For your example:
> REGISTER
> via: p-3;tr
> via: p-2;tr