Subject: [Sip] clarifying the construction of the route header field at UA

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jul 2005 11:40:19 -0400

Folks,

I've run into some issues recently in environments making use of the 
service-route header field (RFC3608). In particular, there are now many 
sources that can be used to construct the route header field that a UA 
uses in a request:

* record-routes
* service-route
* 305 Use Proxy
* configuration, either through DHCP or the config framework

It was unclear how these various sources are reconciled to provide the 
final set, and which messages that set actually applies to (i.e., does 
it get used in REGISTER?).

I've written up an I-D that tries to summarize the issue and proposes 
some clarifications:

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct-00.txt

Comments and questions welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: "Kasturi Narayanan \(kasnaray\)" <[email-masked]>
Date: Tue, 26 Jul 2005 07:07:43 -0700

Jonathan,
	I have the following question/clarification.

1)In section 5.3 there is a sentence regarding 305 response handling
processing.

It says "This processing
   applies to requests both inside and outside of a dialog, and applies
   to all request methods, including REGISTER, with the exception of ACK
   and CANCEL."

Need clarification. 
How long shld a contact returned in 305 response be treated as valid. Is
it temporary or shld be based on expires header. "If the above sentence
meant that subsequent requests (all) shld be sent thru the contact
received in 305. 
Or
Does this sentence mean that mid-call dialogs also may result in 305. Is
this the case? For example a Re-Invite may result in 305? So that
subsequent requests for that call are sent thru a different proxy.

2) with regard to section 5.3 (and related to section 6) for backward
compatibility.

 UAC pre-populates Route headers A, B, C and D in the initial Invite
towards UAS  Proxy D decides to send a 305 with Proxy E's  Contact.
Proxies C,B do not handle the 305 and relay it back towards Proxy A.
Then Proxy A while construction the new Request will remove the Top most
route header which belongs to proxy B and replace it with the
Route-header corresponding to Proxy-E and send the Request towards Proxy
E. When Proxy E receives this Request it is going to POP route-header E
and send it towards C which in turn is going to send it towards D. D may
again send a 305 which C and E just relay it back towards A.

This may need protection in the proxies or UAC to make sure which entity
in the network is sending the 305 and in this case however the call is
not going to succeed at all because the route-header corresponding to D
is always there. So the requirement that the immediate preceding hop
shld handle the 305 is almost mandatory.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Rosenberg (jdrosen)
> Sent: Monday, July 25, 2005 10:40 AM
> To: IETF SIP List
> Subject: [Sip] clarifying the construction of the route header field
at UA
> I've written up an I-D that tries to summarize the issue and proposes
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct-
> 00.txt