Some calls failing with media timeout #122
Comments
|
what version of freeswitch are you using and what linux distribution? |
|
we are using this docker file https://github.com/drachtio/docker-drachtio-freeswitch-mrf/blob/main/Dockerfile FreeSWITCH Version 1.10.5-release+git |
|
on a ubuntu machine vm |
|
OK. media timeout from the freeswitch side means that it did not receive any RTP packets from the far end. It would be necessary to be able to see all the SIP signaling for a failed call, and possibly a network pcap as well. But generally this means that the far end was not able to send packets to the advertised freeswitch address. If this is intermittent I would check to be sure you have opened the full rtp port range on your server to allow incoming traffic to all of the udp ports that freeswitch is listening on |
|
Hi Dave, i am not an expert with freeswitch, so we are using all the default configurations, how can we check what all ports are open for rtp ? for drachtio we have 50XX tls port open. and yes this is intermittent issue with a few calls. |
|
you will find the rtp min and max port range in /usr/local/freeswitch/config/autoload_configs/switch.conf.xml In the image you are using it should be 25000-39000/udp, so make sure you are allowing all traffic in to those ports |
|
So, this is what you mean by allowing traffic to this fs docker instance right ? |
|
no, I mean the server itself also needs to be configured to allow traffic in to those ports. As far as what you have above which seems to be from a docker-compose file, it is correct as far as telling docker how to direct traffic that does make it in to those ports, but I would also comment that I have seen docker have problems and be very slow when configured to map thousands of ports like that. |
|
yeah my FS server allows the traffic to these port and docker is using network mode host, so you mean i need to check for these port allowed in VM or the source from where i am receiving calls ? |
|
correct |
|
m=audio 30788 RTP/SAVP 0 101\r i can see that some of the failed calls belong to the ports which are below or above the said range, how can i update this range in my configs should i add this to vars file ? with new ports but its also failing for one port that is within the range. |
|
I can't be sure but I think what you reprinted above is from the SDP offered by the far end? It is not relevant what ports they are sending from. |
|
HI Dave, yes above is from SDP, i thought these are target ports, where can i get those ? |
|
also the error message that i get here |
|
what is audio_stream_adapter.cpp ? I don't recognize it as any code in this repo |
|
as far as ms.connectCaller timing out, that means that freeswitch was unable to make an outbound tcp socket connection to the drachtio-fsmrf application. Can you show me a freeswitch log for that error, including the sip messages |
|
@davehorton this issue is intermittent, we are unable to reproduce it, looking for logs but is there anything we can try that could help solving this issue ? or any possible reason since 2-3 calls out of 100s are failing |
|
Logs for Freeswitch and drachtio for a faulty call https://gist.github.com/sachinlevel/c31a9b6c8337caf8f3f36d02bedb15c7 these are for two call invites, basically for each call we get two invites one for customer and other for agent, |
|
@davehorton did you check the logs ? we are still facing this issue intermittently. |
|
@davehorton these are the required details. Drachtio logs : https://gist.github.com/sachinlevel/c31a9b6c8337caf8f3f36d02bedb15c7 Request object that failed : https://gist.github.com/sachinlevel/0a80a4e8b0b4e305cf90deadf7598de1 |
|
ms.connectCaller(req, res) fails with Connection timeout, and on retrying using same ms.connectCaller(req, res) - using the same request it fails with "Response#send: final response already sent" |
|
The "Connection timeout" in the application log you posted is usually because Freeswitch can't reach your Node.js/drachtio-fsmrf app. Can your freeswitch reach See a similar issue someone had here in a drachtio-fsmrf issue |
|
But, the original issue you posted seemed to be something else that isn’t in the last logs you posted. So, there might be multiple issues going on here. |
|
@byoungdale for the issue that you mentioned for them no call is connecting, for us most of the calls are connecting roughly around 3 calls per 100 calls are failing to connect to FS. was wondering why would that happen, and this issue is intermittent , if you can guide us how can we correctly retry to connect to FS, that would be helpful since retrying same request is failing with "Response#send: final response already sent" |
Hi Dave,
We are using this module (https://github.com/drachtio/drachtio-freeswitch-modules/blob/main/examples/google_transcribe.js) to trancribe calls, but some calls from drachtio to freeswitch are failing with media timeout, also i am not setting up this variable, so it should be using its default value, what could be possibly wrong and how can we correct it ?
it fails while connecting to FS, => ms.connectCaller(req, res)
/usr/local/freeswitch/log# grep -i "Timeout" freeswitch.log
2023-06-07 06:03:17.689310 [WARNING] sofia.c:5227 rtp-timeout-sec deprecated use media_timeout variable.
2023-06-07 06:03:17.689334 [WARNING] sofia.c:5234 rtp-hold-timeout-sec deprecated use media_hold_timeout variable.
2023-06-30 04:28:16.337857 [WARNING] sofia.c:5227 rtp-timeout-sec deprecated use media_timeout variable.
2023-06-30 04:28:16.337878 [WARNING] sofia.c:5234 rtp-hold-timeout-sec deprecated use media_hold_timeout variable.
db492d19-0caf-49df-8e99-330769961f85 2023-06-30 17:39:16.083379 [NOTICE] switch_core_media.c:2935 Hangup sofia/drachtio_mrf/[email protected]:5060 [CS_EXECUTE] [MEDIA_TIMEOUT]
Reason: SIP;cause=604;text="MEDIA_TIMEOUT"
c93129ab-bf73-49ea-832a-ee06b371de7e 2023-07-01 03:05:46.763366 [NOTICE] switch_core_media.c:2935 Hangup sofia/drachtio_mrf/[email protected]:5060 [CS_EXECUTE] [MEDIA_TIMEOUT]
Reason: SIP;cause=604;text="MEDIA_TIMEOUT"
2fe67026-d5a4-4c4f-bb8d-42b66fb11db7 2023-07-01 03:05:46.783374 [NOTICE] switch_core_media.c:2935 Hangup sofia/drachtio_mrf/[email protected]:5060 [CS_EXECUTE] [MEDIA_TIMEOUT]
Reason: SIP;cause=604;text="MEDIA_TIMEOUT"
69c38a74-8e67-47ce-ab33-53986d46d42f 2023-07-06 17:50:01.263340 [NOTICE] switch_core_media.c:2935 Hangup sofia/drachtio_mrf/[email protected]:5060 [CS_EXECUTE] [MEDIA_TIMEOUT]
Reason: SIP;cause=604;text="MEDIA_TIMEOUT"
2c421ff1-a6ea-4589-8c2b-9eacbd532689 2023-07-06 17:50:01.283335 [NOTICE] switch_core_media.c:2935 Hangup sofia/drachtio_mrf/[email protected]:5060 [CS_EXECUTE] [MEDIA_TIMEOUT]
Reason: SIP;cause=604;text="MEDIA_TIMEOUT"
05aef738-d580-42d6-ac27-ff37ee356654 2023-07-07 21:01:24.303403 [NOTICE] switch_core_media.c:2935 Hangup sofia/drachtio_mrf/[email protected]:5060 [CS_EXECUTE] [MEDIA_TIMEOUT]
Reason: SIP;cause=604;text="MEDIA_TIMEOUT"
4606db18-b9cc-426a-9cf1-0c08324adcd8 2023-07-07 21:01:24.383350 [NOTICE] switch_core_media.c:2935 Hangup sofia/drachtio_mrf/[email protected]:5060 [CS_EXECUTE] [MEDIA_TIMEOUT]
Reason: SIP;cause=604;text="MEDIA_TIMEOUT"
64425d08-b0ff-4a33-bfbb-ef6abec66514 2023-07-18 19:26:30.303360
The text was updated successfully, but these errors were encountered: