praveen dandin wrote:
> 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.
This is not an area for which I feel I have great expertise. But it is
my understanding that the R-R, as seen by the UAC, should be the same in
all responses that carry the same to-tag. So that excludes responses
from different UASs due to forking.
If these had different R-R, then that would constitute changing the
route for a dialog, which isn't allowed.
Paul
> 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.
> <http://in.rd.yahoo.com/tagline_webmessenger_10/*http://in.messenger.yahoo.com/webmessengerpromo.php>
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
