Well this again raises couple of doubts in my mind, as described below;
In case of Preconfigured route:-
1. The Route should contain the URI of next Hop or remote target or any one
of these two? what is actually recommended?
2. What should the behavior of the Proxy if Route header in INVITE is set to
next Hop(which is the address of the Proxy itself)
3. What should be the behavior of the Proxy if Route header in INVITE is set
to remote target or some other address?
4.Lets consider the call is between:
UserA---Proxy---UserB
UserA send a INVITE with preconfigured Route. so lets say the INVITE will
contain the Route header that contains the address of next Hop(i.e of
Proxy). But the Proxy doesn't want to see all messaging thru out the call,
So the proxy doesn't include Record-Route in INVITE while sending it to the
dest. UA(i.e to User B).
So as consequence, there will be no Record-Route in 18x and 200 Response
from User B.
Now my doubt is
i. will this ACK,will Contain Route Header or not? if yes, then what will
be its Value? will be same as that present in INVITE or there will be no
Route in ACK in this case??
ii. the ACK which be sent to UserB directly from UserA or thru the proxy
5. The following doubt is related to when there are multiple proxies are
involved in the call:-
Lets consider the call is between:
UserA---Proxy1---Proxy2---UserB
In the above scenario, UserA includes a Route header(case-1:Route contains
only pxy1-ipaddr, case-2: Route contains both pxy1 and pxy2 ipaddr) in
initial INVITE. This time PXY-2 inserts Record-Route in INVITE where as
PXY-1 doesn't. So PXY-2 will see all messages thru out the call and hence
there will be Record-Route in 18x and 200-OK messages which is the address
inserted by PXY-2.
Now my doubt is
i. In ACK, what will be the value of the Route header? will be same as that
present in INVITE or as the Record-Route value received in 200-OK??
ii. So in this case, the ACK which be sent directly to PXY-2 from User A or
to the PXY-1
Can somebody throw lights on these above queries w.r.t strict and loose
routing as well.
Thank you all.
Regards,
Manoj
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Vijay K.
Gurbani
Sent: Tuesday, October 15, 2002 9:17 AM
To: Vijay Kamath
Cc: [EMAIL PROTECTED]; AJIT KATANKOT
Subject: Re: [Sip-implementors] Preconfigured route
Vijay Kamath wrote:
> At SIPIT11, we found an issue when we want to configure a local outbound
> proxy using the procedures specified in rfc3261(sec 8.1.2).
>
> Here is a sample INVITE which we send :-
>
> INVITE sip:1.2.3.4:5060 SIP/2.0
> To:ua1<sip:[EMAIL PROTECTED]:5060>
> From:sipit1<sip:[EMAIL PROTECTED]>;tag=52792329608rc880
> Call-ID:130920245025z2qi
> CSeq:2 INVITE
> Via:SIP/2.0/UDP 65.243.118.179:5060;branch=z9hG4bK56241282309bvhjg
> Contact:sip:65.243.118.179
> Route:ua1<sip:[EMAIL PROTECTED]:5060>
>
> We found that some implentations that didn't support loose-routing,
> never looked at the topmost ROUTE header for determining the target set.
> They just look at the request-uri which would be that of the proxy
> itself, since it is a strict-router.
So you are using a strict-routing proxy (rfc2543) with a pre-loaded
route (specified in rfc3261). Certainly mixes things up nicely :-)
> So the proxy responds with 404, as the user part was missing in
> the request-uri.
The user part is optional in the R-URI.
> Is this a backward compatibility problem with older proxies?
It's not the question of backward compatibility or loose-routing; it
boils down to a mis-behaving proxy.
Since the request identifies a resource on the proxy (as indicated
in the R-URI), the proxy now has to make a decision on what to do with
the request; i.e. if it should send it forward, or generate a final
response (assuming it is not a stateless proxy).
Since the request has a Route header, the proxy should have removed the
Route header and put it in the R-URI and send the request there (note
that the topmost Route header does not have a ;lr, so the proxy's
behavior degenerates to a strict-router and hence the rewrite on the
R-URI -- in your case, the proxy was a strict router anyway, so it
would have done this as its default behavior).
Regards,
- vijay
--
Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566 Voice: +1 630 224 0216
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
