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.
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.
Good day All,
I understand that when I send a SIP INVITE and do not receive a 200 OK, it will keep sending INVITES at regular duration (until sip timeout).
However, If I have received a 100 Trying for the 1st INVITE and no 200 OK (still waiting for it), then will SIP Server send INVITEs as above regular duration?
Or no matter reliable/unreliable(1xx messages), since SIP Server has got a response it will just sit and wait for the 200 OK?
RFC3261 just talks about series of INVITEs sent due to no "200 OK" received from destination.
Please help to understand.
After receiving a provisional response (1xx), retransmissions of the INVITE message will end.
The relevant part from RFC3261 is in bold:
17.1.1.1 Overview of INVITE Transaction
The INVITE transaction consists of a three-way handshake. The client
transaction sends an INVITE, the server transaction sends responses,
and the client transaction sends an ACK. For unreliable transports
(such as UDP), the client transaction retransmits requests at an
interval that starts at T1 seconds and doubles after every
retransmission. T1 is an estimate of the round-trip time (RTT), and
it defaults to 500 ms. Nearly all of the transaction timers
described here scale with T1, and changing T1 adjusts their values.
The request is not retransmitted over reliable transports. After
receiving a 1xx response, any retransmissions cease altogether, and
the client waits for further responses. The server transaction can
send additional 1xx responses, which are not transmitted reliably by
the server transaction. Eventually, the server transaction decides
to send a final response. For unreliable transports, that response
is retransmitted periodically, and for reliable transports, it is
sent once. For each final response that is received at the client
transaction, the client transaction sends an ACK, the purpose of
which is to quench retransmissions of the response.
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.
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.
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.