Hi All
Sorry about the last post - I have attached the call flow as an image this time :-)
I have a question about the CORRECT operation of UA when making a call via a forking proxy:
(see attached image for call flow) Lets say UA1 calls 7000@sip.com and user 7000@sip.com is available at UA2 and UA3 i.e. the Proxy forks the request.
* UA1 is using the to-tag of the first 180 RINGING it received (frame 5) no matter what the to-tag in the 200 OK is * My question here is: who is in the wrong???? The proxy or UA1? * Should the proxy change the to-tag of the ACK before forewarding it to UA3???
Jason Penton Rhodes University Grahamstown South Africa
i kept on reading rfc3261 and came to the following conclusion:
each 1xx response to the invite creates its own dialog at the uac. when the uac receives 200 ok, the dialog with matching dialog id is transitioned from early to confirmed state. the other dialogs still remain in early state until 64*T1 seconds has passed, at which point they are terminated. the ack is sent to the 200 ok and always has to tag that matches the one in the 200 ok (in jason's example 5678).
-- juha
Yes, that's a good description.
klaus
Juha Heinanen wrote:
i kept on reading rfc3261 and came to the following conclusion:
each 1xx response to the invite creates its own dialog at the uac. when the uac receives 200 ok, the dialog with matching dialog id is transitioned from early to confirmed state. the other dialogs still remain in early state until 64*T1 seconds has passed, at which point they are terminated. the ack is sent to the 200 ok and always has to tag that matches the one in the 200 ok (in jason's example 5678).
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I agree. Note that it is also possible that the 200 which arrives has a to-tag different from any of those received in 1xx responses. In that case it would establish a new dialog, and the ACK would be sent over that.
Paul
Klaus Darilion wrote:
Yes, that's a good description.
klaus
Juha Heinanen wrote:
i kept on reading rfc3261 and came to the following conclusion:
each 1xx response to the invite creates its own dialog at the uac. when the uac receives 200 ok, the dialog with matching dialog id is transitioned from early to confirmed state. the other dialogs still remain in early state until 64*T1 seconds has passed, at which point they are terminated. the ack is sent to the 200 ok and always has to tag that matches the one in the 200 ok (in jason's example 5678).
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
-
Jason Penton -
Juha Heinanen -
Klaus Darilion -
Paul Kyzivat