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.
Related
I am testing the integration of a SIP Server(just a PBX) with another PBX.
The incoming call comes into the PBX and is sent to my SIP Server.
Once the call arrives on my SIP Server, it is then again sent back to a user who is registered to my PBX. Here we have 2 call legs – one from the caller to PBX and another from Sip Server to called party.
The call is set up correctly and there is no issue with audio as well.
When the called party releases the call, my SIP Server sends a BYE message to called party and caller in the same TCP packet.
Upon running a Wireshark trace I found that BYE message from my SIP Server reaches the called party but never reaches the caller.
I know there is a firewall between my SIP Server and PBX.
Question:
Is there an option for how to prevent multiple SIP messages in a single TCP packet? Other than using UDP or fight against FW?
>> BYE from SIP Server to called party and it gets a 200 OK:
11:39:03.163: Sending [31,TCP] 462 bytes to 10.cc.dd.ddf:5060 >>>>>
BYE sip:+xxxxxxxxx#10.xx.cc.vv:1122;transport=tcp SIP/2.0
Call-ID: 003BA5CE-58A9-1D9C-ACEB-886231C0AA77-57379#1xx.vv.vv.vvv
<................>
>> BYE from SIP Server to the caller and it never makes it to the PBX:
11:39:03.163: Sending [31,TCP] 448 bytes to 10.cc.dd.ddf:5060 >>>>>
BYE sip:+420702252645#10.cc.cc.bb:5060;transport=tcp SIP/2.0
Call-ID: acda8080-da917a0e-5a26b-8a61610a#10.xx.cc.vvb
Is there an option for how to prevent multiple SIP messages in a single TCP packet?
While the setup your describe is confusing (images with setup and message flow might make it more clear) and the question by itself is likely off-topic (unrelated to programming), this specific part of the question can be answered:
There is no option like this in SIP. While your specific but unknown endpoint or PBX might have such an option it is unlikely. The sender is fully within the specification if it packs multiple SIP messages to the same hop (i.e. SIP endpoint or SIP proxy) into the same TCP connection where they also can end up in the same packet because this is how TCP works. If the recipient has problems with this then it is a bug in the recipient and should be fixed there instead of working around it in every possible peer.
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.
I am just curious, what is the fundamental reason to have 200 OK responses from a remote end point to be ACKed by the local end point? RFC 3261 states that it is needed for stability purposes but does not go into details. The only reason that comes to my head is the case with call forking. So, if an AOR is registered at multiple end points and these end points respond simultaneously with a 200 OK message, then an ACK will actually indicate which of the remote parties will participate in a peer-to-peer connection. Is there any other reason to end and INVITE hand shake with an ACK?
It's because SIP needs some responses (only INVITE responses in practise) to be reliably transmitted in situations where the underlying transport is unreliable, such as with UDP.
The ACK request is the way for the (UAC User Agent Client) to let the UAS (User Agent Server) know that it received the final response to an INVITE request. Without employing something like the ACK request there would always be the risk that the UAS response would not get through to the UAC and the call would be left sitting in an incorrect state.
The ACK request doesn't have any specific role in call forking. In the case you've described in a call with multiple end points BYE requests will be sent to any call legs that are not required. ACK requests still need to be sent to any UAS that responds irrespective of whether the UAC wants that call leg to proceed or not.
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.