search

espressif / esp-adf

Espressif Audio Development Framework
Other
1.55k stars 689 forks source link

Cannot Hang up VoIP Call Correctly (AUD-4302) #932

Closed wenxiao11 closed 1 year ago

wenxiao11 commented 1 year ago

Environment

Problem Description

The VoIP call session is not ended correctly when caller is not the ESP device. That is, if I use MicroSIP to call the device, the device accept the call and then hangup, the session cannot be ended. However, if I do it reversely, use device to call MicroSIP and MicroSIP hangup, the session is closed correctly.

Expected Behavior

Receive 200 OK message

Actual Behavior

Receive 481 Call/Transaction Does not Exist

Steps to Reproduce

  1. Register both MicroSIP (101) and ESP device (100)
  2. 101 send call to 100
  3. 100 accept the call, the session start
  4. 100 hangup, the audio pipeline closed, the session is not closed

Debug Logs

log.txt: The SIP BYE messages for both success and fail cases success.log: Full log for the successful case. (Device call, MicroSIP hangup) fail.log: Full log for the fail case. (MicroSIP call, Device hangup)

ahhfzhang commented 1 year ago

Hi @wenxiao11

Can you try to update to release/v2.4, because the new version has some sip bugfixes.

But I also see some errors like the CSeq should not be 3, due to the fail.log is incomplete and some SIP fields are missing, so it's not easy to analyze the reasons.

Thanks.

charon22 commented 1 year ago

Hi @ahhfzhang I am Sungsu working with Wenxiao11. First of all, we were using the 2022 Feb version of esp-adf. We tested with ESP32-LyraT 4.3 with the latest version 2.4 as you recommened. The hangup problem still occurs. To reproduce this problem, a more detailed explanation is as follows.

Test Environment :

We have reached out to Twilio regarding this issue. Twilio answer said that there is a problem with Hang up on the device. Please confirm.

Below is Twilio's answer: Please check it out and let me know how to solve it.

Thanks Sungsu

===============================================================================

In summary you will need to make changes on your end as your hardware client is sending the wrong SIP BYE request URI(RURI). Here is my detail analysis on the issue that you have faced.

SIP BYE Request URI should be populated based on the contact header that was shared previously. In the success BYE case, this was followed and as such there was no issue. Contact header from SIP 200 (from Twilio to your SIP Client): image

SIP BYE RURI based on the above contact header: image

In the failed BYE case, if we look at the contact header at SIP from the INVITE that is send from Twilio to your SIP client:

image

The SIP BYE generated from your hardware client is sip:101@epicsafetysiptest.sip.twilio.com:5060. The correct RURI should be sip:101@172.25.78.174:5060. Once you make this changes it should not be throwing such error again.

image

ahhfzhang commented 1 year ago

Hi @charon22

As twillo replied, we should use the 'INVITE' contact header, but it was cleared by ‘OPTION’, so it replaced by new one. I think the latest ADF master had fix this issue, we use keep-alive instead of 'option' to keep the NAT hole opened. So you can set 'send_options = false' and try again.

Thanks.

charon22 commented 1 year ago

Hi @ahhfzhang As you said, I set send_option to false and tested it. However, the same problem still occurred. (FAIL)

static esp_err_t wifi_service_cb(..) { ..... sip_config_t sip_cfg = { .uri = SIP_URI, .event_handler = _sip_event_handler, .send_options = false, .... }

I will send you the corresponding device logo.

You can check that send_option is set to false in the log as follows in the log. I (4549) VOIP_EXAMPLE: [ 5 ] Create SIP Service I (4549) VOIP_EXAMPLE: send_options (0)

Lyrat device log

teraterm_COM7_20230201_092223.log

Thanks

ahhfzhang commented 1 year ago

Hi @charon22

Thanks, we will fix it soon.

charon22 commented 1 year ago

Hi @ahhfzhang We look forward to your corrections. Thank you