1

I am facing an issue regrading the Sip call my flow is as below.

  1. A Party sends INVITE to SIP agent
  2. SIP Agent sends INVITE to B party
  3. B replies with 100 (Trying)
  4. B sends SIP 488 (Not Acceptable Here)
  5. Cal Disconected
  6. Sip Agent sends 488 (Not Acceptable Here) to A
  7. A Send ACK
  8. B sends SIP 488 (Not Acceptable Here)
  9. SIP Agent sends an INVITE
  10. B sends SIP 488 (Not Acceptable Here)
  11. 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.

Bijith Vijayan
  • 13
  • 4

1 Answers1

1

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.

tomrtc
  • 517
  • 6
  • 10
  • Hi Thanks for the update.. its really helpfull.. can you please confirm is it because of as we are not sending ACK for 488 message Bparty is resending 488 again and again. B sends SIP 488 (Not Acceptable Here) SIP Agent sends an INVITE B sends SIP 488 (Not Acceptable Here) SIP Agent sends an INVITE – Bijith Vijayan Jun 01 '21 at 06:14
  • Yes, I confirm the 488 must be ACKed. For the second point, if the INVITE is repeated without any changes then it is quite normal to always receive 488. You may try to investigate why the 488 is generated, most of the time it is a codec issue but maybe something in SIP headers is not understood and/or possible. – tomrtc Jun 01 '21 at 11:28