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 <[EMAIL PROTECTED]> 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
