In my investigation of XX-5913 involving a call setup between a remote
worker and an AudioCodes Gateway, I've noticed some oddities on the
Gateway side of things and require some clarification on the SIP spec.
The scenario is as follows:
1. Remote worker initiates a call that is to go out the AudioCodes
Gateway.
2. Gateway 200 OK's the call but this response never makes it to the
Remote Worker and
as a result no ACK is sent for the 200 OK.
3. Remote worker CANCELs the INVITE after about 1 minute since the
INVITE was sent and the Proxy 200 OK's it right away. Call State Event
generation doesn't look at CANCELs and even if it did wouldn't have seen
this one since the Proxy responded right away.
Call State Event generation (in the Proxy), believes the call was
established because of the 200 OK and because no BYE was ever sent, the
call is still believed to be active (until CDR sees the call in active
state for 8 hours at which point it sets the completion state to Unknown
and closes the record).
My questions regarding the SIP spec (RFC 3261) are as follows:
1. In section 13.3.1.4 "The INVITE is Accepted", it states that the UAS
when sending a 2XX response must ("it is necessary") to retransmit the
2XX response at a specified interval until the ACK to this response
arrives. In addition, this retransmission must be done independent of
"whatever transport protocol" is used to send the response.
Is it correct to say that even if the transport protocol is TCP
(which is reliable), then the AudioCodes Gateway should have been
re-transmitting these 200 OK's because no ACK was ever seen? If this is
the case, then I believe a new issue should be opened against the
AudioCodes.
2. In the same section "The INVITE is Accepted", it states the if the
server retransmits the 2XX response without ever receiving an ACK, the
dialog is confirmed, but the session SHOULD be terminated by sending a
BYE.
Does anyone know why its SHOULD and not MUST? If it was MUST, then
CDR would have closed the call record when the BYE was seen.
Thanks in advance.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
