Hi Paul,
Do you mean to say that both first 2xx as well as its retransmission will
have same r-r as seen by UAC? I am talking about response and the
retransmission of the same response but not two different responses to the same
UAC. One more thing, the issue is not related to double record-route. Let me be
more specific in my question:
Is it possible for a response (say 200 OK) and its retransmission to have
different r-r when they reach UAC? Different r-r means if ACK is to be sent for
retransmitted response it will traverse entirely different path (i.e, it will
have different route set) as compared to the ACK to first 200 OK.
Thanks,
Praveen
Paul Kyzivat <[EMAIL PROTECTED]> wrote: I agree with Kasturi regarding the
meaning of that text. It allows a
proxy that record-routes to provide a different value to the UAS and
UAC. However that mechanism is no longer in favor. It is considered
preferable for the proxy to "double record route" when it proxies the
request and then do nothing to the responses.
The double r-r means inserting two entries for itself - one appropriate
for the UAC and the other appropriate for the UAS.
The language you quote does not give permission to alter the r-r with
different responses to the same request. The value as seen by the UAC
must not change from one response to another.
Thanks,
Paul
KASTURI Narayanan (kasnaray) wrote:
> What you metnitoned below refers to the case where a proxy may be at the
> Edge of a private Network and Public Network or
> when a proxy has to provide VPN tunnel towards one end.
> Meaning proxy has to support 2 IP addresses one towards the UAC and one
> towards the UAS.
> In these cases Proxy-P1 might have inserted IP1 towards the UAS in
> INVITE and when the Proxy-PI receives the 200 Response
> for the same transaction with the IP1 in the route-header if it needs it
> can change it to IP2.
> So that UAC has IP1 as Record-Route and UAS has IP2 both pointing to the
> same proxy.
>
>
>
>
>
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of praveen dandin
>> Sent: Friday, October 19, 2007 12:13 AM
>> To: Nebojsa Miljanovic
>> Cc: Sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Is route set be recomputed
>> while sending ACKfor retransmitted 2xx?
>>
>> Thanks for your inputs Nebojsa and Vikram. I understand that
>> the retransmitted 2xx has to follow the same path as the
>> first 2xx. Now I have a doubt that whether an intermediate
>> proxy can change the record-route to indicate that it will be
>> available at some different URI in future before forwarding
>> the retransmitted 2xx [ this is to ensure that ACK for the
>> retransmitted 2xx will be reached to the UAS from UAC if that
>> particular proxy goes down]. Eg, if 'proxy x -> proxy y- >
>> proxy z' is the record route of first 2xx, then in that case,
>> can proxy y modify the record route in retransmitted 2xx to
>> be 'proxy x-> proxy a-> proxy z' ?? [ i.e., proxy y modifies
>> its URI to be 'proxy a' in record route indicating that it
>> will be reached at 'proxy a' in future, so that if ACK needs
>> to be sent for the retransmitted 2xx (with the updated record
>> route) UAC sends ACK with the new route set]. Please see the
>> RFC 3261 quote below:
>> section 16.7.8 of RFC 3261 :
>> If the selected response contains a Record-Route header
>> field value originally provided by this proxy,
>> the proxy MAY choose to rewrite the value before forwarding
>> the response. This allows the proxy to
>> provide different URIs for itself to the next upstream and
>> downstream elements. A proxy may choose
>> to use this mechanism for any reason. For instance, it is
>> useful for multi-homed hosts.
>>
>> What does 'selected response' mean here?
>>
>> Regards,
>> Praveen
>>
>> Nebojsa Miljanovic wrote:
>> Since 200 OK responses must follow the Vias listed in
>> INVITE, they cannot be retransmitted over different proxies.
>>
>>
>> On 10/17/2007 2:12 AM, praveen dandin wrote:
>>> Hi,
>>> Consider the following scenario ( proxies between UAC and
>> UAS are not
>>> shown) UAC UAS INVITE
>>> |-------------------------------------------->|
>>> 180
>>> |<--------------------------------------------|
>>> first 200 OK with record route1
>>> |<--------------------------------------------|
>>> ACK with route set1
>>> |----------------------------------------------->|
>>> retransmitted 200 OK with record route2
>>> |<------------------------------------------------|
>>> retransmitted ACK with route set = route set1 or route set2 ??
>>> |--------------------------------------------------->|
>>>
>>> The retransmitted 200 OK is same as the first 200 OK except
>> it differs in record route. This might be due to the fact
>> that retransmitted 200 OK has traced the path different from
>> the first 200 OK. I have following queries related to this issue.
>>> 1) Is it possible for the retransmitted 200 OK to have a
>> different Record - route than that of the first 200 OK i.e,
>> can retransmitted 200 OK trace a path that is different from
>> the one the first 200 OK had traced ??
>>> Some info: section 16.7.8 of RFC 3261 says the following:
>>> If the selected response contains a Record-Route header field value
>>> originally provided by this proxy, the proxy MAY choose to
>> rewrite the
>>> value before forwarding the response. This allows the proxy
>> to provide
>>> different URIs for itself to the next upstream and
>> downstream elements. A proxy may choose to use this mechanism
>> for any reason. For instance, it is useful for multi-homed hosts.
>>> Here is it only for the first response or is it also valid
>> for the retransmitted responses??
>>> 2) If the scenario of (1) is possible then should the ACK
>> be recomputed with different route set before sending it to its peer??
>>> Some info:
>>> (i) RFC 3261 section 13.2.2.4 quotes:
>>> "Once the ACK has been constructed, the procedures of [4]
>> are used to
>>> determine the destination address, port and transport. However, the
>>> request is passed to the transport layer directly for transmission,
>>> rather than a client transaction. This is because the UAC
>> core handles
>>> retransmissions of the ACK, not the transaction layer. The
>> ACK MUST be
>>> passed to the client transport every time a retransmission
>> of the 2xx
>>> final response that triggered the ACK arrives.
>>> The UAC core considers the INVITE transaction completed
>> 64*T1 seconds
>>> after the reception of the first 2xx response."
>>>
>>> Here it mentions about the retransmission but not about
>> recomputation of ACK with new Route set.
>>> (ii)RFC 3261 section 13.2.2.4 quotes:
>>> If the dialog identifier in the 2xx response matches the dialog
>>> identifier of an existing dialog, the dialog MUST be
>> transitioned to
>>> the "confirmed" state, and the route set for the dialog
>> MUST be recomputed based on the 2xx response using the
>> procedures of Section 12.2.1. Otherwise, a new dialog in the
>> "confirmed"
>>> state MUST be constructed using the procedures of Section 12.1.2.
>>>
>>> I hope this is only for first 2xx received or for the
>> forked 2xx. Is it valid for retransmitted 2xx also??
>>> Let me know if further clarification is desired.
>>>
>>> Thanks in advance,
>>> Praveen
>>>
>>>
>>> ---------------------------------
>>> Share files, take polls, and discuss your passions - all
>> under one roof. Click here.
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>
>>
>>
>>
>> ---------------------------------
>> Now you can chat without downloading messenger. Click here
>> to know how.
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
---------------------------------
Chat on a cool, new interface. No download required. Click here.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
