- FreeSWITCH-users - FreeSWITCH Mailing Lists

NOT_REGISTERED error
by Brian May 02 Aug '22

02 Aug '22

Hello, I seem to be having random issues that come and go. So will deal with them one at a time. First problem, the incoming call from one extension to another randomly gets blocked. But other times it works. Logs when calling 1005 from 1004: === cut === EXECUTE [depth=0] sofia/internal-ipv6/1004(a)sip.microcomaustralia.com.au bridge(user/1005(a)sip.microcomaustralia.com.au) 2022-08-01 20:06:45.066758 98.33% [DEBUG] switch_channel.c:1269 sofia/internal-ipv6/1004(a)sip.microcomaustralia.com.au EXPORTING[export_vars] [RFC2822_DATE]=[Mon, 01 Aug 2022 20:06:45 +1000] to event 2022-08-01 20:06:45.066758 98.33% [DEBUG] switch_channel.c:1269 sofia/internal-ipv6/1004(a)sip.microcomaustralia.com.au EXPORTING[export_vars] [dialed_extension]=[1005] to event 2022-08-01 20:06:45.066758 98.33% [DEBUG] switch_ivr_originate.c:2281 Parsing global variables 2022-08-01 20:06:45.066758 98.33% [DEBUG] switch_channel.c:1269 sofia/internal-ipv6/1004(a)sip.microcomaustralia.com.au EXPORTING[export_vars] [RFC2822_DATE]=[Mon, 01 Aug 2022 20:06:45 +1000] to event 2022-08-01 20:06:45.066758 98.33% [DEBUG] switch_channel.c:1269 sofia/internal-ipv6/1004(a)sip.microcomaustralia.com.au EXPORTING[export_vars] [dialed_extension]=[1005] to event 2022-08-01 20:06:45.066758 98.33% [DEBUG] switch_ivr_originate.c:2281 Parsing global variables 2022-08-01 20:06:45.066758 98.33% [NOTICE] switch_channel.c:1123 New Channel sofia/internal-ipv6/1005@59.167.180.193:50138 [43494707-9a11-45a6-956e-c6096b48f60b] 2022-08-01 20:06:45.066758 98.33% [DEBUG] mod_sofia.c:5121 (sofia/internal-ipv6/1005@59.167.180.193:50138) State Change CS_NEW -> CS_INIT 2022-08-01 20:06:45.066758 98.33% [DEBUG] switch_core_state_machine.c:581 (sofia/internal-ipv6/1005@59.167.180.193:50138) Running State Change CS_INIT (Cur 2 Tot 34) 2022-08-01 20:06:45.066758 98.33% [NOTICE] switch_ivr_originate.c:3039 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED] === cut === But the user is registered: === cut === freeswitch@huey> show registrations reg_user,realm,token,url,expires,network_ip,network_port,network_proto,hostname,metadata 1000,sip.microcomaustralia.com.au,3136333931393535353535353131-bybjp0g3gomy,sofia/internal/sip:1000@192.168.2.97:45452;line=10p5s5g9,1659350487,192.168.2.97,45452,udp,huey, 1004,sip.microcomaustralia.com.au,5rG1JkQ51w4XzyjV7ET8ng..,sofia/internal-ipv6/sip:1004@[2001:44b8:4112:8a05:859:d448:94ef:d733]:35862;rinstance=e736892a33822d9d;transport=tcp,1659348746,2001:44b8:4112:8a05:859:d448:94ef:d733,36207,tcp,huey, 1005,sip.microcomaustralia.com.au,kJaeILXv1Nta2tQEo8AV7A..,sofia/internal-ipv6/sip:1005@59.167.180.193:50138;transport=TCP;rinstance=e58807bf09569293,1659349053,2001:44b8:4112:8a02:e88:d16b:f1f6:c2ed,34495,tcp,huey, 3 total. freeswitch@huey> sofia status profile internal-ipv6 reg Registrations: ================================================================================================= Call-ID: 5rG1JkQ51w4XzyjV7ET8ng.. User: 1004(a)sip.microcomaustralia.com.au Contact: "" <sip:1004@[2001:44b8:4112:8a05:859:d448:94ef:d733]:35862;rinstance=e736892a33822d9d;transport=tcp> Agent: Zoiper v2.10.17.3-mod Status: Registered(TCP)(unknown) EXP(2022-08-01 20:12:26) EXPSECS(314) Ping-Status: Reachable Ping-Time: 0.00 Host: huey IP: 2001:44b8:4112:8a05:859:d448:94ef:d733 Port: 36207 Auth-User: 1004 Auth-Realm: sip.microcomaustralia.com.au MWI-Account: 1004(a)sip.microcomaustralia.com.au Call-ID: kJaeILXv1Nta2tQEo8AV7A.. User: 1005(a)sip.microcomaustralia.com.au Contact: "" <sip:1005@59.167.180.193:50138;transport=TCP;rinstance=e58807bf09569293> Agent: Z 5.5.13 v2.10.18.3 Status: Registered(TCP)(unknown) EXP(2022-08-01 20:17:33) EXPSECS(621) Ping-Status: Reachable Ping-Time: 0.00 Host: huey IP: 2001:44b8:4112:8a02:e88:d16b:f1f6:c2ed Port: 34495 Auth-User: 1005 Auth-Realm: sip.microcomaustralia.com.au MWI-Account: 1005(a)sip.microcomaustralia.com.au Total items returned: 2 ================================================================================================= freeswitch@huey> sofia status profile internal reg Registrations: ================================================================================================= Call-ID: 3136333931393535353535353131-bybjp0g3gomy User: 1000(a)sip.microcomaustralia.com.au Contact: "Extension" <sip:1000@192.168.2.97:45452;line=10p5s5g9> Agent: snomD785/10.1.84.15 Status: Registered(UDP)(unknown) EXP(2022-08-01 21:11:27) EXPSECS(3632) Ping-Status: Reachable Ping-Time: 0.00 Host: huey IP: 192.168.2.97 Port: 45452 Auth-User: 1000 Auth-Realm: sip.microcomaustralia.com.au MWI-Account: 1000(a)sip.microcomaustralia.com.au Total items returned: 1 ================================================================================================= === cut === While there are some things I don't understand here, fact is I believe sofia/internal-ipv6/1005 should be registered.... Curiously calls in the other direction - 1005 to 1004 work fine at the moment. I thought maybe the IPv6 profile was causing problems, so I deleted it, but get similar problems: === cut === EXECUTE [depth=0] sofia/internal/1004(a)59.167.180.194 bridge(user/1005(a)sip.microcomaustralia.com.au) 2022-08-01 20:32:37.711523 98.03% [DEBUG] switch_channel.c:1269 sofia/internal/1004(a)59.167.180.194 EXPORTING[export_vars] [RFC2822_DATE]=[Mon, 01 Aug 2022 20:32:37 +1000] to event 2022-08-01 20:32:37.711523 98.03% [DEBUG] switch_channel.c:1269 sofia/internal/1004(a)59.167.180.194 EXPORTING[export_vars] [dialed_extension]=[1005] to event 2022-08-01 20:32:37.711523 98.03% [DEBUG] switch_ivr_originate.c:2281 Parsing global variables 2022-08-01 20:32:37.711523 98.03% [DEBUG] switch_channel.c:1269 sofia/internal/1004(a)59.167.180.194 EXPORTING[export_vars] [RFC2822_DATE]=[Mon, 01 Aug 2022 20:32:37 +1000] to event 2022-08-01 20:32:37.711523 98.03% [DEBUG] switch_channel.c:1269 sofia/internal/1004(a)59.167.180.194 EXPORTING[export_vars] [dialed_extension]=[1005] to event 2022-08-01 20:32:37.711523 98.03% [DEBUG] switch_ivr_originate.c:2281 Parsing global variables 2022-08-01 20:32:37.711523 98.03% [NOTICE] switch_channel.c:1123 New Channel sofia/internal/1005@59.167.180.193:50138 [e2d0ccc0-26eb-4b99-9aff-162a182435dd] 2022-08-01 20:32:37.711523 98.03% [DEBUG] mod_sofia.c:5121 (sofia/internal/1005@59.167.180.193:50138) State Change CS_NEW -> CS_INIT 2022-08-01 20:32:37.711523 98.03% [DEBUG] switch_core_state_machine.c:581 (sofia/internal/1005@59.167.180.193:50138) Running State Change CS_INIT (Cur 2 Tot 6) 2022-08-01 20:32:37.711523 98.03% [NOTICE] switch_ivr_originate.c:3039 Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED] 2022-08-01 20:32:37.711523 98.03% [DEBUG] switch_core_state_machine.c:624 (sofia/internal/1005@59.167.180.193:50138) State INIT 2022-08-01 20:32:37.711523 98.03% [DEBUG] mod_sofia.c:97 sofia/internal/1005@59.167.180.193:50138 SOFIA INIT 2022-08-01 20:32:37.711523 98.03% [INFO] sofia_glue.c:1651 sofia/internal/1005@59.167.180.193:50138 sending invite call-id: (null) === cut === === cut === freeswitch@huey> sofia status profile internal reg Registrations: ================================================================================================= Call-ID: 3136333931393535353535353131-bybjp0g3gomy User: 1000(a)sip.microcomaustralia.com.au Contact: "Extension" <sip:1000@192.168.2.97:45452;line=10p5s5g9> Agent: snomD785/10.1.84.15 Status: Registered(UDP)(unknown) EXP(2022-08-01 21:11:27) EXPSECS(2322) Ping-Status: Reachable Ping-Time: 0.00 Host: huey IP: 192.168.2.97 Port: 45452 Auth-User: 1000 Auth-Realm: sip.microcomaustralia.com.au MWI-Account: 1000(a)sip.microcomaustralia.com.au Call-ID: JStfFaD7O6YhbD5glF1O2w.. User: 1004(a)sip.microcomaustralia.com.au Contact: "" <sip:1004@192.168.5.69:35862;rinstance=424e027f47c09f90;transport=tcp> Agent: Zoiper v2.10.17.3-mod Status: Registered(TCP)(unknown) EXP(2022-08-01 20:42:37) EXPSECS(592) Ping-Status: Reachable Ping-Time: 0.00 Host: huey IP: 192.168.5.69 Port: 55579 Auth-User: 1004 Auth-Realm: 59.167.180.194 MWI-Account: 1004(a)sip.microcomaustralia.com.au Call-ID: pffe0efiQEXsqtVIjbxNoA.. User: 1005(a)sip.microcomaustralia.com.au Contact: "" <sip:1005@59.167.180.193:50138;transport=TCP;rinstance=dafd96f89850cb02> Agent: Z 5.5.13 v2.10.18.3 Status: Registered(TCP)(unknown) EXP(2022-08-01 20:43:24) EXPSECS(639) Ping-Status: Reachable Ping-Time: 0.00 Host: huey IP: 192.168.2.216 Port: 51245 Auth-User: 1005 Auth-Realm: sip.microcomaustralia.com.au MWI-Account: 1005(a)sip.microcomaustralia.com.au Call-ID: CkKLFKmXc User: 1001(a)sip.microcomaustralia.com.au Contact: "home" <sip:28256742@192.168.5.213:53628;transport=tcp;ob> Agent: unknown Status: Registered(TCP)(unknown) EXP(2022-08-01 20:48:31) EXPSECS(946) Ping-Status: Reachable Ping-Time: 0.00 Host: huey IP: 192.168.5.213 Port: 53628 Auth-User: 1001 Auth-Realm: sip.microcomaustralia.com.au MWI-Account: 1001(a)sip.microcomaustralia.com.au Total items returned: 4 ================================================================================================= freeswitch@huey> show registrations reg_user,realm,token,url,expires,network_ip,network_port,network_proto,hostname,metadata 1000,sip.microcomaustralia.com.au,3136333931393535353535353131-bybjp0g3gomy,sofia/internal/sip:1000@192.168.2.97:45452;line=10p5s5g9,1659352287,192.168.2.97,45452,udp,huey, 1004,sip.microcomaustralia.com.au,JStfFaD7O6YhbD5glF1O2w..,sofia/internal/sip:1004@192.168.5.69:35862;rinstance=424e027f47c09f90;transport=tcp,1659350557,192.168.5.69,55579,tcp,huey, 1005,sip.microcomaustralia.com.au,pffe0efiQEXsqtVIjbxNoA..,sofia/internal/sip:1005@59.167.180.193:50138;transport=TCP;rinstance=dafd96f89850cb02,1659350604,192.168.2.216,51245,tcp,huey, 1001,sip.microcomaustralia.com.au,CkKLFKmXc,sofia/internal/sip:28256742@192.168.5.213:53628;transport=tcp;ob,1659350911,192.168.5.213,53628,tcp,huey, 4 total. === cut === As a result I put IPv6 back again. 1001 is an experimental client which I don't entirely trust, but don't think that is causing any issues for calls where it is not involved. Just quick summary of the some of the other issues: * Occasionally the calls just freeze. Nothing shown in freeswitch logs. No sign of any packets being dropped. Just client (zoiper) freezes and does nothing. I suspect this might be a client issue, maybe nothing to do with freeswitch. * (the real problem I am trying to investigate) outgoing PSTN calls work fine. But incoming calls from our VOIP provider - there is a 10+ second delay on all incoming audio, and I can't see any reason for this. i.e. I mean I say something on remote end, wait 10 seconds, then it is received at local end. * Turning on echo cancellation on a Linux based host running zoiper seemed to cut out audio after about 1 second. So I disabled that option, seems to have fixed that problem. Any ideas? -- Brian May <brian(a)linuxpenguins.xyz> https://linuxpenguins.xyz/brian/

1 2

CONVERT 3XX to 603
by Patrick Karton 26 Jul '22

26 Jul '22

Hello All, is there a way for freeswitch to convert receive response code to another code. i would like for example to convert 3xx received code to 603 code. Thanks.

3 3

FS does not relay X-header in 401 and 407 responses
by Patrick Karton 26 Jul '22

26 Jul '22

i noticed that Freeswitch does not relay X-header in 401 or 407 response code !!! is there a way to enable it Thanks.

3 4

Audio quality
by Adiseshu Channasamudhram 25 Jul '22

25 Jul '22

Hello There, I'm having the below audio issue and would really appreciate any help Caller =======Carrier========FS SBC======IVR When i took a packet capture on the FS, I could observe that the audio stream quality from IVR to SBC is really good when compared to the audio quality stream between the SBC and the caller. Bad quality => first syllable of certain words lost, choppy ... Using PCMU 8K on both legs ... Between SBC and IVR - Max Delta is 96ms, max jitter is 22.5 Between sbc and caller - max delta is 120 and max jitter is 9.5 Any suggestion or help would be greatly appreciated Regards A

2 2

Using Specific TLS Ciphers (1.10.7)
by Michael Meehan 14 Jul '22

14 Jul '22

We’ve been trying to prevent using specific ciphers, mainly Diffie-Hellman. According to the documentation I’ve seen and previous posts in this group, that should be accomplished by using something like this: <X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=TLS_RSA_WITH_AES_128_CBC_SHA256"/> This doesn’t work. This specific cipher is offered in the CLIENT HELLO and shown as also supported from the SERVER HELLO response amongst others, however, we continue to see DH as being agreed upon: tport_tls.c:974 tls_connect() tls_connect(0x7ff738006e70): events CONNECTING tport_tls.c:974 tls_connect() tls_connect(0x7ff738006e70): events NEGOTIATING tport_tls.c:974 tls_connect() tls_connect(0x7ff738006e70): events NEGOTIATING tport_tls.c:617 tls_post_connection_check() tls_post_connection_check(0x7ff738006e70): TLS cipher chosen (name): ECDHE-RSA-AES128-GCM-SHA256 tport_tls.c:619 tls_post_connection_check() tls_post_connection_check(0x7ff738006e70): TLS cipher chosen (version): TLSv1/SSLv3 tport_tls.c:622 tls_post_connection_check() tls_post_connection_check(0x7ff738006e70): TLS cipher chosen (bits/alg_bits): 128/128 tport_tls.c:625 tls_post_connection_check() tls_post_connection_check(0x7ff738006e70): TLS cipher chosen (description): ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD Other attempts have been made using the following, which also doesn’t appear to function as expected. <X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=ALL:!ADH:!DH:!ECDH:!LOW:!EXP:!MD5:@STRENGTH"/> Any help is appreciated, thanks. FreeSWITCH Version 1.10.7-release.13~64bit (-release.13 64bit) CENTOS 7 3.10.0-1160.62.1.el7.x86_64

1 1

Speeding up FreeSWITCH load time
by TTT 14 Jul '22

14 Jul '22

Is there a guide on how to speed FS loading times? FS takes 10+ seconds to start which seems long (for a very simple configuration).

6 15

Recover queues after crash
by TTT 11 Jul '22

11 Jul '22

I have call recovery enabled, which is properly restoring active calls after a crash. But what about queues? Are they recovered too? Where is the information about call queues kept? Thanks!

1 0

Recording calls causes FS generated RTP packets with different timestamp on missed packets
by Shaun Stokes 11 Jul '22

11 Jul '22

Hi All, We're having issues when recording calls, using either record_session or uuid_record. FreeSWITCH is generating RTP packets to fill in the gaps when there's missed RTP packets (packet loss), but the FreeSWITCH generated RTP packets use a different timestamp. This causes jitter and periods of silence on active calls. The only solution seems to be enabling RTP rewrite timestamps, but this causes audio delay\sync issues. [cid:cfdedbcf-5048-4f07-8fe1-1c761ffdfee6] [cid:768e2f51-801b-4411-aade-a77cecad6d45] We've tried with and with-out the following, but there's no change. * bridge_generate_comfort_noise * send_silence_when_idle * suppress_cng * suppress-cng (SIP profile param) Has anyone come across this before, and is there a solution? Thanks, Shaun

1 1

xml_cdr problem using sip_from_user
by Jason Holden 04 Jul '22

04 Jul '22

All, Currently using fs 1.8.56 on a demo unit. I’ve noticed that on some CDRS the sip_from_user shows the dialed number that the extension placed when it should show the extension number. This is a speratic issue and I can’t narrow down why this may be happening. I am using a php script to post my CDRS. Does anyone have any suggestions? I do have set to record a / b legs of the call and to prefix the a leg. A snippit from the php script is below. $var = $cdr->variables; $sql = sprintf("INSERT INTO cdrClients (site_code,npa,call_direction,cac_call_type_id,call_uuid,direction,user,domain,from_user,from_host,to_user,to_host,req_user,req_host,bridge_channel,sip_term_status,sip_term_cause,sip_hangup_disposition,bridge_hangup_cause,hangup_cause,hangup_cause_q850,start_stamp,answer_stamp,end_stamp,duration,billsec) VALUES('%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s');", $var->site,$var->NPA,$var->call_direction,$var->cac_call_type_id,$var->call_uuid,$var->direction,$var->user_name,$var->domain_name,$var->sip_from_user,$var->sip_from_host,$var->sip_to_user,$var->sip_to_host,$var->sip_req_user,$var->sip_req_host,rawurldecode($var->bridge_channel),$var->sip_term_status,$var->sip_term_cause,$var->sip_hangup_disposition,$var->bridge_hangup_cause,$var->hangup_cause,$var->hangup_cause_q850,rawurldecode($var->start_stamp),rawurldecode($var->answer_stamp),rawurldecode($var->end_stamp),$var->duration,$var->billsec); Jason Holden Phone: 1-866-836-9198 X405 Direct: 7868009949 www.thinksimplicity.com <http://www.thinksimplicity.com>

3 2

Trigger playback via network request
by David P 02 Jul '22

02 Jul '22

I would like to trigger playback into a channel, and I'd like to do that using a networked request that indicates the filename. Is there a better way to do it than the following? I'm considering using ESL (in inbound mode). I already have a large dialplan, and rather than reimplement all of it as ESL commands, I thought I could add the uuid_park application into the dialplan at the spot where the inbound channel(s) should be fully configured and active. There would be a separate server running an ESL client, and once it gets an ESL CHANNEL_ANSWER event it would be able to invoke playback until it receives a CHANNEL_DESTROY event. I considered other programmatic ways of doing playback such as mod_python, but they don't address the networked requirement.

1 0