[SIPForum-discussion] Record-Route and Route headers

jayant dasgupta technojayant at yahoo.com
Tue Jan 12 09:50:29 UTC 2010


Hello Sreekant ,

What you are actually referring is the Outbound-Proxy concept in SIP .
The lines you have quoted from the draft is present in RFC 3261 as well .
Refer 8.1.1.1 Request-URI 2nd Para :-


   In some special circumstances, the presence of a pre-existing route
   set can affect the Request-URI of the message.  A pre-existing route
   set is an ordered set of URIs that identify a chain of servers, to
   which a UAC will send outgoing requests that are outside of a dialog.
   Commonly, they are configured on the UA by a user or service provider
   manually, or through some other non-SIP mechanism.  When a provider
   wishes to configure a UA with an outbound proxy, it is RECOMMENDED
   that this be done by providing it with a pre-existing route set with
   a single URI, that of the outbound proxy.

   When a pre-existing route set is present, the procedures for
   populating the Request-URI and Route header field detailed in Section
   12.2.1.1 MUST be followed (even though there is no dialog), using the
   desired Request-URI as the remote target URI.

So your requirement of sending an initial Register to a particular IP:Port
is satisfied here .

But as Vijay also pointed out , once UAC receives a Record-Route ,
added by proxies , the Record-Route takes priority over the outbound-proxy concept.

If you want all the messages to go via outbound proxy , the following should be done :-
200 ok to initial INVITE should 
contain Record-Route header with outbound proxy IP address and Port used for 
sending INVITE as hostport in the topmost Record-Route  header. This is to 
ensure that all the subsequent request in the call will go through the same 
outbound proxy IP and Port. 
 
If no record route is present, 
route set will be set to empy set. 200 OK response to intial INVITE overrides 
any outbound proxy cofniguration for the future requests in the dialog. So, if 
200 oK response to INVITE doesnot contain Record-Route, subseqent requests will 
be sent directly to the remote target.
Regards,Jayant


--- On Mon, 1/11/10, Vijay Tiwari <vijay11tiwari at gmail.com> wrote:

From: Vijay Tiwari <vijay11tiwari at gmail.com>
Subject: Re: [SIPForum-discussion] Record-Route and Route headers
To: "sreekant nair" <sreekant_nair at yahoo.com>
Cc: discussion at sipforum.org
Date: Monday, January 11, 2010, 11:26 AM

hello sreekant
 
i am agree on your point but my question to you that are you talking about draft. and its not necessary that everyone support this draft.
 
Thanks
vijay


On Sun, Jan 10, 2010 at 10:07 PM, sreekant nair <sreekant_nair at yahoo.com> wrote:




Hi Vijay,
 
Thanks for the information, however I have to disagree slightly with your inputs. 
 
As per the draft-rosenberg-sip-route-construct-02 it states that clients may use "pre-existing route.. set configured on the UA by a user or service provider manually, or through some other non-SIP mechanism." The draft describes a way to get the route using SIP which, is the method you stated.

 
My requirement is that even the initial request (for e.g. REGISTER) must follow the route mentioned. Therefore I have to have the UA1 include the route header which can only be known using pre-programmed routes. 


Thanks in advance for your time. 

Regards
Sreekant






From: Vijay Tiwari <vijay11tiwari at gmail.com>
To: sreekant nair <sreekant_nair at yahoo.com>

Cc: discussion at sipforum.org
Sent: Sat, January 9, 2010 5:12:41 AM

Subject: Re: [SIPForum-discussion] Record-Route and Route headers





Hello Sreekant
 
U1  -> P1  -> P2  -> U2

 
Yes you can you both header in  P1  -> P2 legs.
 
but i want to includes some thing before you made any conclusion. one thing i want to say that  first proxies add record-route header field into invite message then send invite message to UAS(U2) and  then UAS(U2) send back  180 and 200 response to proxies and UAC with record-route header field and when UAC(U1) received record-route headers then UAC add route header into next all subsequent requests.

 
so U1 could not send route header field at first intense. so receiving record-route from proxies and UAS in 180 and 200 response after that U1 send route header field into next subsequent. 

 
Thanks
Vijay

 




On Fri, Jan 8, 2010 at 3:44 AM, sreekant nair <sreekant_nair at yahoo.com> wrote:




Hello,


I have a question with respect to Record-Route and Route headers.

Is it possible for SIP messages to have both a Record-Route Header AND a Route header in the same message?

This is my scenario


U1  -> P1  -> P2  -> U2


Where 
U1 : User Agent 1

U2 : User Agent 2
P1 : Proxy 1

P2 : Proxy 2


Is it valid to construct the messages in the following format( Note: I use symbolic representations)


U1 -> P1              
INVITE: U2 at domain.com
VIA : U1.X.Y.Z

Route: P1.A1.B1.C1;lr
Route: P2.A2.B2.C2;lr

P1 -> P2

INVITE: U2 at domain.com
VIA : P1.A1.B1.C1

VIA : U1.X.Y.Z
Record-Route: P1.A1.B1.C1;

Route: P2.A2.B2.C2;lr

P2 -> U2

INVITE: U2 at domain.com
VIA : P2.A2.B2.C2

VIA : P1.A1.B1.C1

VIA : U1.X.Y.Z
Record-Route: P2.A2.B2.C2

Record-Route: P1.A1.B1.C1


Is it valid to have both a Route and Record-Route headers in the P1->P2 leg of the 

Thanks in advance to all in response. 


Regards
Sreekant Nair




_______________________________________________
This is the SIP Forum discussion mailing list

TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org





-- 
They can because they think they can.





-- 
They can because they think they can.




-----Inline Attachment Follows-----

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100112/76bb2039/attachment-0002.html>


More information about the discussion mailing list