Hi,
I have the following standard scenario:
UAC ---> UAS: INVITE
UAS ---> UAC: 100 Trying
UAS ---> UAC: 180 Ringing
UAS ---> UAC: 200 OK (INVITE)
UAC ---> UAS: ACK
UAC ---> UAS: BYE [ immediately ]
UAS ---> UAC: 200 OK (BYE)
The ACK + BYE are both sent upon receiving the 200 response, in that order
but without delay.
When sending the 200 OK the UAS starts a retransmission timer ( at intervals
T1, 2*T1, ... etc up to T2, as per RFC3261)
When sending the ACK the UAC starts a linger timer (64*T1), to catch any
retransmitted 200 OKs and ACK them (also as per RFC3261)
At the UAS side, since the ACK is a new transaction with its own branch id,
no matching server transaction is found but normally a matching dialog is
found. The dialog then signals the INVITE servertransaction that an ACK was
received, which stops the retransmission of the 2xx response
However, when the ACK is lost for some reason but the BYE is not, the dialog
is terminated at the UAS side. Newly arriving ACKs no longer match any
dialog, so the retransmission of the 2xx responses is never stopped and
always continues until 64*T1 (10 retransmissions). Each 2xx triggers an ACK
My question is: how should this be handled? Should reception of a BYE abort
retransmission of the 2xx, or should the dialog linger as long as the INVITE
server transaction has not finished? RFC3261 recommends that the UAS
responds to any remaining requests with a 487 Request terminated, but since
it has already responded with 2xx I don't think it should change its mind
for that one
Regards,
Jeroen
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
