Hi Markus,
From RFC 3261
"Note that when a UAS core sends a 2xx response to INVITE, the server transaction is
destroyed."
This is accepted as a bug in RFC 3261.
http://bugs.sipit.net/show_bug.cgi?id=769
The fix will involve having the server transaction continue to exist long
enough to drain any retransmissions of the INVITE
>>we had a discussion about handling of retransmitted INVITE after the UAS
>>was sending a 200 OK but did not received an ACK. The transaction layer
>>will open a new INVITE server transaction because the layer has no
>>information about the first initial INVITE. In the UAS core it is
>>possible to recognizing the INVITE as a retransmission. But what should
>>the UAS core do? I read section 13 and 17 but I found nothing.
Only one way is
UAS can ignore this retransmitted INVITE and clear the retransmitted invite transaction
>>Another discussion was going about that a retransmitted INVITE could be
>>slower as an ACK because the ACK is send direct. Our client will
>>complained about the CSeq number that is too low and the trouble is two
>>INVITE (initial + retransmitted) which are the same but two responses
>>(200 and 500). What can I do?
One option is to keep track of the INVITE transaction until the
ACK arrives. Although logically there is no transaction layer interaction
(as per section 17, RFC 3261), you can then identify the INVITE as a
duplicate and discard it.
Regards,
Thangarajan.
FlextronicsSoftware
Worlds largest SIP stack vendor
Markus Hofmann <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 02/17/2006 07:16 PM |
|
Hello,
we had a discussion about handling of retransmitted INVITE after the UAS
was sending a 200 OK but did not received an ACK. The transaction layer
will open a new INVITE server transaction because the layer has no
information about the first initial INVITE. In the UAS core it is
possible to recognizing the INVITE as a retransmission. But what should
the UAS core do? I read section 13 and 17 but I found nothing.
Another discussion was going about that a retransmitted INVITE could be
slower as an ACK because the ACK is send direct. Our client will
complained about the CSeq number that is too low and the trouble is two
INVITE (initial + retransmitted) which are the same but two responses
(200 and 500). What can I do?
Thank you for your help!
Markus Hofmann
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
*********************** FSS-Private ***********************
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
