1 Apr
2004
1 Apr
'04
10:59 a.m.
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(a)sip.com and user 7000(a)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
1 Apr
1 Apr
12:42 p.m.
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
12:54 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
3 Apr
3 Apr
2:11 a.m.
New subject: [Sip-implementors] Re: [Serusers] FW: Forking Proxy
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Sip-implementors mailing list
Sip-implementors(a)cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
7542
days inactive
7543
days old
3 comments
4 participants
participants (4)
-
Jason Penton -
Juha Heinanen -
Klaus Darilion -
Paul Kyzivat