Please tell me when a SIP call return 487 Request Terminated?
Is it a termination issue?
The 487 Response indicates that the previous request was terminated by user/application action. The most common occurrence is when the CANCEL happens as explained above. But it is also not limited to CANCEL. There are other cases where such responses can be relevant. So it depends on where you are seeing this behavior and whether its a user or application action that caused it.
15.1.2 UAS Behavior==> BYE Handling in RFC 3261
The UAS MUST still respond to any pending requests received for that
dialog. It is RECOMMENDED that a 487 (Request Terminated) response
be generated to those pending requests.
It's the response code a SIP User Agent Server (UAS) will send to the client after the client sends a CANCEL request for the original unanswered INVITE request (yet to receive a final response).
Here is a nice CANCEL SIP Call Flow illustration.
Related
I have a question about SIP, when read RFC [3311] UPDATE request, it doesn't mention that it's not invalid behavior in SIP. Here is the call flow:
UAC sends INVITE request
UAS sends 1xx INVITE to UAC
UAC sends UPDATE request
UAS send 2xx INV
UAS send 2xx UPDATE
I supposes some reasons that made the 200OK for INVITE come first then 2xx response for UPDATE request coming after. Is this case a pass case in SIP call follow ?
Thank you guys.
Yes, that's perfectly OK.
This can happen when the UPDATE request and the 2xx INVITE response are sent 'simultaneously' and thus cross each other.
After the UAS has sent the 2xx INVITE response it will receive the UPDATE request and immediately send the 2xx UPDATE response. This means the session that was established due to the INVITE request/response will have a short lifespan since its session parameters will be updated according to the UPDATE session parameters.
The 200 OK of the PRACK is received later at the UAC than the 200 OK of the INVITE provided that the UAS had sent them in proper order..what should be the behavior of the UAC? Will it silently drop the packet? Or will it establish the dialog ?
I see nothing in standard that somehow bounds 200 OK for INVITE and 200 OK for PRACK on the client side. UAC should handle 2xx response to INVITE according to
RFC 3261 - 13.2.2.4 2xx Responses
Multiple 2xx responses may arrive at the UAC for a single INVITE
request due to a forking proxy. Each response is distinguished by
the tag parameter in the To header field, and each represents a
distinct dialog, with a distinct dialog identifier.
If the dialog identifier in the 2xx response matches the dialog
identifier of an existing dialog, the dialog MUST be transitioned to
the "confirmed" state, and the route set for the dialog MUST be
recomputed based on the 2xx response using the procedures of Section
12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2.
And it has to handle response to PRACK based on RFC 3262
Note that the PRACK is like any other non-INVITE request within a
dialog.
There is requirement for UAS
The UAS MAY send a final response to the initial request before
having received PRACKs for all unacknowledged reliable provisional
responses, unless the final response is 2xx and any of the
unacknowledged reliable provisional responses contained a session
description. In that case, it MUST NOT send a final response until
those provisional responses are acknowledged.
So it would seem that UAC receiving 2xx response could decide that UAS has received the PRACK and stop its retransmissing - But there is nothing like that stated in the RFC. So even after receiving 2xx response to the INVITE UAC should continue retransmitting PRACK till it is acknowledged.
What are all the possible scenarios for an originating system to receive a 487 (Request Terminated) message from the destination end in response to an Invite message, before receiving 18X messages from the destination, and without any CANCEL message sent by the originator after sending the INVITE message?
The 487 Request terminated is created only as reaction to the CANCEL request. Nevertheless the CANCEL may be generated by a stateful proxy. See the RFC-3261 chapter 16.10. A stateful proxy may generate the CANCEL due to timer expiration for example.
The CANCEL request must not be sent before a provisional response is received. But the provisional response do not need to be a 18x response. UAC or proxy may send CANCEL even after 100 Trying is received. And moreover it is sufficient that the proxy receives a provisional response.
So there is the answer:
There are almost infinite number of all possible scenarios because there are plenty of SIP proxy implementations and their configurations and they may have a lot of reasons to cancel a transaction.
According to sip protocol when first invite send, sip returns proxy authentication required message (if there are any proxy server available), then client send an acknowledge message. But what happen if the acknowledge message failed to reach the sip server? Server returns forbidden after sometimes and ignore all new invite with authentication header. Also when sip gets multiple acknowledge message it's immediately send forbidden.
If your question is what would the correct behaviour be for a SIP server that has issued a 407 and not received an ACK for it, please see RFC 3261 17.2.1 for the description of the INVITE server transaction.
Sending the 407 moves the state machine into the "Completed" state, at which point the G and H timers have to be be set. When G fires, the 407 response needs to be retransmitted. And if all the ACK messages get lost, then timer H will make the server transaction give up eventually. But if the second ACK reaches the server then that's it. You will have seen two 407 responses, one with a lost ACK, the second one with a successful ACK.
The handling of the subsequent INVITE with the credentials should be entirely independent with the previously described process. The INVITE message with the credentials will constitute a separate dialogue forming transaction.
i am receiving multiple 2** responses for a call. The problem is that once the call is connected and the server receives the "ACK" packet and the call starts successsfully, server again sends the "OK" response packet back to the callee and recieves the "ACK" packet again for it. This happens multiple times before the call gets terminated automatically. Can somebody explain to me why this is happening that my server is sending the "OK" response even after the call is connected successfully and what can be the possible solution for the problem? Thanks in advance for any help.
A SIP UAS will retransmit the 2xx response multiple times until it receives the ACK request from the UAC. See the SIP RFC chapter "13.3 UAS Processing" for the gory details.
Most often this sort of problem happens when the ACK sent by the UAC is invalid and thus prevents the UAS from matching it to the INVITE transaction. ACK requests have special rules about their construction see 13.2.2.4 2xx Responses. To make things even more difficult the construction of the ACK request differs for 2xx and non-2xx final responses.