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
