The audio stream of the 1st call gets broken when the 2nd incoming call is received (AUD-4629)

EdwardRyu commented 1 year ago

Environment

Audio development kit: ESP32-LyraT Audio kit version : v4.3 Module or chip used: ESP32-WROVER-E IDF version: v4.4.4 ADF version: v2.5

Problem Description

The audio stream of the 1st call gets broken when the 2nd incoming call is received.

Test Steps

'100' is ESP32 device
'101' is MicroSIP device.
'102' is Linphone device.
A call is established between 100 and 101.
Another call is triggered from '102' device.
The 2nd call gets disconnected by the server. This could be a normal.
Audio stream of the 1st call got broken due to ESP_RTC_EVENT_AUDIO_SESSION_END event.

Log snippets.

[2023-05-29 09:22:40.191] BYE sip:100@10.0.28.115:17646 SIP/2.0 [2023-05-29 09:22:40.191] CSeq: 2 BYE [2023-05-29 09:22:40.191] From: "102" sip:102@epicsafetysiptest.sip.twilio.com;tag=21403438_c3356d0b_32daf26f-b691-43e3-8996-fb40f31b9e1c [2023-05-29 09:22:40.209] To: sip:100@10.0.28.115:17646;tag=721849357 [2023-05-29 09:22:40.209] Call-ID: 95d82cb71de35d9404b96f5362038686@0.0.0.0 [2023-05-29 09:22:40.209] Max-Forwards: 69 [2023-05-29 09:22:40.209] User-Agent: Twilio [2023-05-29 09:22:40.209] Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bK6638.c6752f25a321195db8d5fb57e5c35df8.0 [2023-05-29 09:22:40.209] Via: SIP/2.0/UDP 172.25.1.250:5060;rport=5060;received=54.221.78.31;branch=z9hG4bK32daf26f-b691-43e3-8996-fb40f31b9e1c_c3356d0b_515-5585985856740431574 [2023-05-29 09:22:40.209] X-Twilio-CallSid: CA97cfc8db46dff83627aa06299eae43a3 [2023-05-29 09:22:40.209] Content-Length: 0

[2023-05-29 09:22:40.209] I (229276) SIP: [1970-01-01/00:03:24]<<====================== [2023-05-29 09:22:40.209] D (229278) SIP_SERVICE: _esp_sip_event_handler event 8 [2023-05-29 09:22:40.209] I (229278) SIP_SERVICE: ESP_RTC_EVENT_AUDIO_SESSION_END [2023-05-29 09:22:40.209] D (229278) AUDIO_PIPELINE: audio_element_stop

Log

teraterm_COM8_20230529_092056.log

Required behavior.

2nd call can be rejected, but there should be no harm for existing 1st call.
at least, it should tell the difference of ESP_RTC_EVENT_AUDIO_SESSION_END events between existing call and new one.

EdwardRyu commented 1 year ago

Call waiting feature doesn't seem to be supported by ESP-ADF, but the media library accepts for the 2nd incoming call automatically and then it ends up with a mess after receiving BYE from server for the 2nd call.

ahhfzhang commented 1 year ago

Hi Edward,

Thanks for your report.

The 2nd incoming should be rejected, let me check then reply to you.

ahhfzhang commented 1 year ago

Hi Edward，

libesp_media_protocols_esp32.zip Please help to replace to esp-adf-libs\esp_media_protocols\lib\esp32 directory and test again.

Thanks.

EdwardRyu commented 1 year ago

Thanks Michael for the patch.

I have tested it, however, it seems that we still have a corner case in which the problem still exist.

For example, when call is connected with the 1st incoming call and audio session started successfully, the patch works fine. i.e., the 2nd incoming call is rejected.

However, when the 1st call is still in progress and not answered yet or not connected yet and then the 2nd call is received, then the call gets messed up.

Here I am attaching the new log.

Issue_1011_after_applying_1st_patch.txt

the 1st call triggered from 101 to 100.
call is still in incoming call state.
the 2nd call triggered from 102 to 100.
another incoming call event occurs.
user answered the call on ESP device, then the 2nd call is connected.

Please check the log and get back to me.

Thanks, Edward

EdwardRyu commented 1 year ago

We have the same problem in case of outgoing call from 100(ESP) to 101 for the 1st call.

ahhfzhang commented 1 year ago

Hi Edward，

Yes, this case should be handle, here is the patch. libesp_media_protocols_esp32.zip

EdwardRyu commented 1 year ago

Hi Michael,

The new one worked fine and resolved the issue. Thanks for your support.

Regards, Edward

espressif / esp-adf