In my application, I send an invite request and cancel this one. I receive the 200 ok (of my cancel) and I want to send the ACK request but the dialog is not yet established, so how can I send this ack ?
However, I think it's not clear for me the difference between dialog and transaction, could you shed some light on this point for me ?
Thanks in advance.
The CANCEL scenario requires that the remote side sends OK response to CANCEL, but also 487 response to the INVITE, otherwise the transaction is not complete. Only after 487 you can send ACK. The JAIN-SIP stack sends ACK to error responses automatically in most cases. In this case ACK will be sent automatically when you receive 487, you don't need to send it yourself. You only need to send ACK for successful transactions that are not CANCELed.
Related
I am facing an issue regrading the Sip call my flow is as below.
A Party sends INVITE to SIP agent
SIP Agent sends INVITE to B party
B replies with 100 (Trying)
B sends SIP 488 (Not Acceptable Here)
Cal Disconected
Sip Agent sends 488 (Not Acceptable Here) to A
A Send ACK
B sends SIP 488 (Not Acceptable Here)
SIP Agent sends an INVITE
B sends SIP 488 (Not Acceptable Here)
SIP Agent sends an INVITE
in this flow at point 4 B party is sending 488 message, for this B party is expecting an ACK for this.. as we are not sending ACK B party is sending 488 again and again.
My Question.. is it mandatory that on receiving 488 Error case should we send ACK before disconnecting the call.. if we send ACK will there be any issue.
My Question.. is it mandatory that on receiving 488 Error case should
we send ACK before disconnecting the call..
You need to be really precise here, 488 (similar to 606 btw) can be received on an initial INVITE transaction or in a RE-INVITE transaction.
In your case, it is an initial INVITE so yes the ACK is compulsory and the call is terminated.
In case of RE-INVITE, the ACK is compulsory but the call is not terminated.
if we send ACK will there be any issue.
From a signaling standpoint there is no problem at all, the call setup has failed and the user may retry another call with a different codec for instance.
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.
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.