- FreeSWITCH-users - FreeSWITCH Mailing Lists

Wrong release cause text, bug?
by David Villasmil 09 Jun '18

09 Jun '18

Hello guys, When hanging up a call with a specific release, FS sends the specific code, i.e.: if i release a call like so: <action inline="true" application="set" data="release_code=483 EXCHANGE_ROUTING_ERROR"/> The BYE message is as follows: SIP/2.0 483 EXCHANGE_ROUTING_ERROR Via: SIP/2.0/UDP 1.2.3.4:5080;rport=5080;branch=z9hG4bK0y1H2X8899veB Max-Forwards: 69 From: "david.villasmil" <sip:david.villasmil@1.2.3.4>;tag=t35r9gatZFcjj To: <sip:9999999@1.2.3.4:5080>;tag=pB7mFpUrc30gB Call-ID: e2da7a79-e537-1236-5691-02e1e654f872 CSeq: 123866386 INVITE User-Agent: FreeSWITCH-mod_sofia/1.6.20-37-987c9b9~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Reason: Q.850;cause=25;text="EXCHANGE_ROUTING_ERROR" Content-Length: 0 X-FS-Display-Name: 9999999 X-FS-Display-Number: sip:9999999@1.2.3.4 Remote-Party-ID: "9999999" <sip:9999999@1.2.3.4 >;party=calling;privacy=off;screen=no Another example: <action inline="true" application="set" data="release_code=410 NUMBER_CHANGED"/> The BYE message is SOMETIMES as follows: SIP/2.0 410 NUMBER_CHANGED Via: SIP/2.0/UDP 1.2.3.4:5080;rport=5080;branch=z9hG4bKZN8r02Q5c16UF Max-Forwards: 69 From: "david.villasmil" <sip:david.villasmil@1.2.3.4>;tag=Q8Se4ZQF8m9SF To: <sip:9999999@1.2.3.4:5080>;tag=mSm3B0SHjHmBm Call-ID: dfbb5497-e537-1236-5691-02e1e654f872 CSeq: 123866383 INVITE User-Agent: FreeSWITCH-mod_sofia/1.6.20-37-987c9b9~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Reason: Q.850;cause=22;text="NUMBER_CHANGED" Content-Length: 0 X-FS-Display-Name: 9999999 X-FS-Display-Number: sip:9999999@1.2.3.4 Remote-Party-ID: "9999999" <sip:9999999@54.84.149.30 >;party=calling;privacy=off;screen=no And other times as follows: SIP/2.0 410 Gone Via: SIP/2.0/UDP 1.2.3.4:32200 ;branch=z9hG4bK-d8754z-86e4295fca2efa0a-1---d8754z-;rport=32200 Max-Forwards: 69 From: <sip:david.villasmil@1.2.3.4;transport=UDP>;tag=42169b65 To: <sip:9999999@1.2.3.4;transport=UDP>;tag=pZ0N246BBcK7K Call-ID: YmU5YjEwODk2ZmZhODJjNDgzNTNlM2FiZWVmMjI2MDg. CSeq: 1 INVITE User-Agent: FreeSWITCH-mod_sofia/1.6.20-37-987c9b9~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Reason: Q.850;cause=16;text="NORMAL_CLEARING" Content-Length: 0 Remote-Party-ID: "9999999" <sip:9999999@1.2.3.4 >;party=calling;privacy=off;screen=no But I've noticed that when i do: <action inline="true" application="set" data="release_code=488 BEARERCAPABILITY_NOTIMPL"/> The BYE message is as follows: SIP/2.0 488 BEARERCAPABILITY_NOTIMPL Via: SIP/2.0/UDP 1.2.3.4:5080;rport=5080;branch=z9hG4bK3SDv7eUK14Z6D Max-Forwards: 69 From: "david.villasmil" <sip:david.villasmil@1.2.3.4>;tag=F3am0c2594H7a To: <sip:9999999@1.2.3.4:5080>;tag=6XDmXaZj5BQ8S Call-ID: aeb6624e-e539-1236-5691-02e1e654f872 CSeq: 123866772 INVITE User-Agent: FreeSWITCH-mod_sofia/1.6.20-37-987c9b9~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION" Content-Length: 0 X-FS-Display-Name: 9999999 X-FS-Display-Number: sip:9999999@1.2.3.4 Remote-Party-ID: "9999999" <sip:9999999@54.84.149.30 >;party=calling;privacy=off;screen=no So I guess, my question is why sometimes the "text" is set properly, and sometimes not?? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

2 3

SIP over TLS configuration problem
by fabio 08 Jun '18

08 Jun '18

Hi all I'm a Freeswitch newbie and I'm trying to setup SIP over TLS in my FS version 1.5.15. As first step I have configured a SIP Gateway that successfully registers to a dedicated SIP Registrar/Proxy (opensips) using SIP over UDP. With this configuration I can successfully place outbound and inbound calls without any problem. Everything works as a charm. Further I have tried to switch to SIP over TLS and I followed the steps described in https://freeswitch.org/confluence/display/FREESWITCH/SIP+TLS. I have installed the agent.pem and cafile.pem generated by opensips (my SIP Registrar) and I configured FS to use them. After restart the sofia gateway profile can successfully register to the SIP Registrar by SIP over TLS. Further I can successfully place outbound call (from internal channel through the SIP gateway). It sounds great! Unfortunately FS fails to handle inbound calls (SIP INVITE from an external SIP UA registered to the same SIP Registrar to the SIP UA extension of the FS SIP gateway). I have tried to trace all the logs I can. Here below some traces from the FS console when an inbound INVITE is received: tport.c:2749 tport_wakeup_pri() tport_wakeup_pri(0xb7f28): events IN tport.c:862 tport_alloc_secondary() tport_alloc_secondary(0xb7f28): new secondary tport 0x1398c0 tport_type_tcp.c:203 tport_tcp_init_secondary() tport_tcp_init_secondary(0x1398c0): Setting TCP_KEEPIDLE to 30 tport_type_tcp.c:209 tport_tcp_init_secondary() tport_tcp_init_secondary(0x1398c0): Setting TCP_KEEPINTVL to 30 tport_type_tls.c:610 tport_tls_accept() tport_tls_accept(0x1398c0): new connection from tls/10.3.10.110:38632/sips tport_tls.c:919 tls_connect() tls_connect(0x1398c0): events NEGOTIATING tport_tls.c:1008 tls_connect() tls_connect(0x1398c0): TLS setup failed (error:00000001:lib(0):func(0):reason(1)) tport.c:2090 tport_close() tport_close(0x1398c0): tls/10.3.10.110:38632/sips tport.c:2263 tport_set_secondary_timer() tport(0x1398c0): set timer at 0 ms because zap In order to simplify the test I have also tried to connect to the 5061 TLS port by a simple openssl command from a linux shell of the SIP Registrar box: openssl s_client -connect 10.11.4.103:5061 -tls1_2 CONNECTED(00000003) 3074304200:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40 3074304200:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1528361426 Timeout : 7200 (sec) Verify return code: 0 (ok) --- In the FS console I read the same traces received in the previous test with the inbound call. tport.c:2749 tport_wakeup_pri() tport_wakeup_pri(0xb7f28): events IN tport.c:862 tport_alloc_secondary() tport_alloc_secondary(0xb7f28): new secondary tport 0x248210 tport_type_tcp.c:203 tport_tcp_init_secondary() tport_tcp_init_secondary(0x248210): Setting TCP_KEEPIDLE to 30 tport_type_tcp.c:209 tport_tcp_init_secondary() tport_tcp_init_secondary(0x248210): Setting TCP_KEEPINTVL to 30 tport_type_tls.c:610 tport_tls_accept() tport_tls_accept(0x248210): new connection from tls/10.11.4.103:33168/sips tport_tls.c:919 tls_connect() tls_connect(0x248210): events NEGOTIATING tport_tls.c:1008 tls_connect() tls_connect(0x248210): TLS setup failed (error:00000001:lib(0):func(0):reason(1)) tport.c:2090 tport_close() tport_close(0x248210): tls/10.11.4.103:33168/sips tport.c:2263 tport_set_secondary_timer() tport(0x248210): set timer at 0 ms because zap I have attached also a wireshark capture of the inbound call. In this capture the SIP Registrar has IP 10.3.10.110. The FS device is 10.11.4.103. The Client Hello is sent by the SIP Registrar, but the FS device replies with an "Alert: Level: fatal, Description: handshake failure (40). I guess that there is some misconfiguration related to the TLS version or proposed ciphers or any certifcates but I cannot understand what. For comparison I have tried to run the same openssl command from FS to the external SIP Registrar (outbound). openssl s_client -connect 10.3.10.110:5061 -tls1_2 CONNECTED(00000003) depth=1 CN = Your_NAME, ST = Your_STATE, C = CO, emailAddress = YOUR_EMAIL, O = YOUR_ORG_NAME verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=XY/ST=Some State/O=My Large Organization Name/OU=My Subunit of Large Organization/CN=somename.somewhere.com/emailAddress=root@somename.somewhere… i:/CN=Your_NAME/ST=Your_STATE/C=CO/emailAddress=YOUR_EMAIL/O=YOUR_ORG_NAME 1 s:/CN=Your_NAME/ST=Your_STATE/C=CO/emailAddress=YOUR_EMAIL/O=YOUR_ORG_NAME i:/CN=Your_NAME/ST=Your_STATE/C=CO/emailAddress=YOUR_EMAIL/O=YOUR_ORG_NAME --- Server certificate -----BEGIN CERTIFICATE----- MIIC6TCCAdGgAwIBAgIBATANBgkqhkiG9w0BAQUFADBpMRIwEAYDVQQDFAlZb3Vy X05BTUUxEzARBgNVBAgUCllvdXJfU1RBVEUxCzAJBgNVBAYTAkNPMRkwFwYJKoZI hvcNAQkBFgpZT1VSX0VNQUlMMRYwFAYDVQQKFA1ZT1VSX09SR19OQU1FMB4XDTE4 MDUwODEyMzcyM1oXDTE5MDUwODEyMzcyM1owgb8xCzAJBgNVBAYTAlhZMRMwEQYD VQQIEwpTb21lIFN0YXRlMSMwIQYDVQQKExpNeSBMYXJnZSBPcmdhbml6YXRpb24g TmFtZTEpMCcGA1UECxMgTXkgU3VidW5pdCBvZiBMYXJnZSBPcmdhbml6YXRpb24x HzAdBgNVBAMTFnNvbWVuYW1lLnNvbWV3aGVyZS5jb20xKjAoBgkqhkiG9w0BCQEW G3Jvb3RAc29tZW5hbWUuc29tZXdoZXJlLmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sA MEgCQQDL7uikSc1kVIvw5rhyQzk2dSJcmJ6EJ1LSmtAoafZH8bqfZ25cDQZQGi05 YcuxGR0vSaW7xPnyhaWCLQlxQFx7AgMBAAGjDTALMAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggEBAHv4WzGdYhoEyHZmBQTVjdEKOVBMnNoOqum79uzWtSzSjG4E pP/9c331uT7fBZ/Z7XNhIV+PbDZXorLgUhwwT7zxYURNnV52Of2SWRmWtPBrgEX1 +8S0IMtJFfJta8FAfTTaNqLpRDaiTQs3em1Maxls15cTyRQzMIjIJnY4eRrh5CNM YV/+kg/lpKAe0awiMu96cxpnMdz9h33g7RedBnh9wDi6k7pfYtvlC6o4snZO01AN 8qRiQf54OPvKcVeseJFBPWLhdYns6g+/SXhq1Lek2us93ZpuKgIaBtzkyDm2+SFa QXF9f0a+UuEdPvrtvMjAijcDwcaXq0r2f2MA++M= -----END CERTIFICATE----- subject=/C=XY/ST=Some State/O=My Large Organization Name/OU=My Subunit of Large Organization/CN=somename.somewhere.com/emailAddress=root@somename.somewhere… issuer=/CN=Your_NAME/ST=Your_STATE/C=CO/emailAddress=YOUR_EMAIL/O=YOUR_ORG_NAME --- No client certificate CA names sent --- SSL handshake has read 1979 bytes and written 337 bytes --- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 512 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES256-GCM-SHA384 Session-ID: EA8B17008E58F1D04CD1CEA53103CF477AA9DE0DC80A4FF4F0DD4814031E4C15 Session-ID-ctx: Master-Key: D28ED5C21D288944D2277AF86FE82A9BF3BEDABAA14DBCD5AE32B190EF0A0CA6AB99719E751E6DD4FECAA9DD1307A3C0 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 2f c5 82 ea bf 8b 66 49-bc bc ee 48 1a fb 8e 6c /.....fI...H...l 0010 - de 42 d9 e0 6e 36 40 78-06 cc 68 c6 74 6d 6e aa .B..n6@x..h.tmn. 0020 - b6 53 8a ed b2 8d 5a c4-02 e1 88 8b d2 a9 56 5f .S....Z.......V_ 0030 - ee c6 b9 14 55 da 37 df-8f aa af 81 b4 22 4e be ....U.7......"N. 0040 - 9c c5 87 d6 46 22 47 03-4a 88 dd 1e 9d 05 81 09 ....F"G.J....... 0050 - c3 8b 9f 44 29 90 4d 93-c9 f5 41 e2 4d 72 1b de ...D).M...A.Mr.. 0060 - 8d c2 15 ab 49 ad da 26-0e 72 a9 01 02 3e 89 33 ....I..&.r...>.3 0070 - 6e 6c 2f 20 1c 15 06 7a-8d c5 a6 6e ee 46 d2 76 nl/ ...z...n.F.v 0080 - 63 c1 89 1e 9b 3c a1 10-d0 78 31 9e e6 8e 86 ab c....<...x1..... 0090 - ff bc 3a 4c ab 3d 33 8f-e9 56 c5 f1 45 46 73 41 ..:L.=3..V..EFsA Start Time: 1528361487 Timeout : 7200 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- closed In this case the command seems to have been successfully executed. I remark that the outbound TLS transactions seems to be working fine also from FS (SIP Registrar, SIP INVITE in outbound don't have any problem). If required I can provide also the FS configuration files (vars.xml, sofia.conf.xml, etc etc). Any help will be greatly appreciated. Thanks in advance Best regards fabio

4 4

Can't get release cause on dialplan
by David Villasmil 07 Jun '18

07 Jun '18

Hello guys, I've got the following extension: <include> <extension name="public_did0"> <condition field="destination_number" expression="^9999999$"> <action application="set" data="failure_causes=USER_BUSY,NO_ANSWER"/> <action application="bridge" data="{continue_on_fail=true,hangup_after_bridge=false}sofia/external/ 9999999@1.2.3.4:5080 <http://9999999@54.84.149.30:5080>"/> <action application="log" data="CRIT Hangup cause was: ${bridge_hangup_cause}"/> </condition> </extension> </include> But it just shows: 2018-06-07 18:29:42.639898 [DEBUG] switch_ivr_originate.c:3848 Originate Resulted in Error Cause: 65 [BEARERCAPABILITY_NOTIMPL] 2018-06-07 18:29:42.639898 [INFO] mod_dptools.c:3436 Originate Failed. Cause: BEARERCAPABILITY_NOTIMPL 2018-06-07 18:29:42.639898 [DEBUG] switch_channel.c:4758 Failure causes [USER_BUSY,NO_ANSWER]: Cause: BEARERCAPABILITY_NOTIMPL EXECUTE sofia/external/david.villasmil@test-fs02 log(CRIT Hangup cause was: ) 2018-06-07 18:29:42.639898 [CRIT] mod_dptools.c:1742 Hangup cause was: 2018-06-07 18:29:42.639898 [NOTICE] Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

2 2

warn and hangup after xx seconds
by Francesco Facco de Lagarda 07 Jun '18

07 Jun '18

I am scripting in js I have both analogue and digital trunks out (analogue trunks out don't give me the "answer" event) Lets say we have a "totTime" variable for max length of call I need to play a warning at totTime - 30 And hangup at totTime.. I have tried using: sessOut.execute("set", "execute_on_answer_1=sched_hangup +" + totTime + " alloted_timeout"); sessOut.execute("set", "execute_on_answer_2=sched_broadcast +" + (totTime - 30) + "layback::" + soundDir + "time_off.wav both"); But I can only get one or the other to work.. never both! Also, how would I schedule there two events for analogue lines (where I don't have "on_answer") Thanks all

1 1

Eavesdrop - allow bleg whisper and conference but deny aleg whisper
by Alexis 07 Jun '18

07 Jun '18

Hi, Is it possible to permit one-leg whispering and deny other-leg whispering using eavesdrop application ? I want to permit my users to whisper "company employee leg" or do 3 ways conference but not to whisper only "other leg peoples". It seems that eavesdrop_whisper_aleg=false set which "eavesdrop mode" is set at the beginning of eavesdrop application but doesn't restrict any DTMF (i.e doesn't disable DTMF 2 [whisper with the other half]). -- Alexis

1 0

FS skips an RTP timestamp after an RTCP Sender Report
by David Witham 07 Jun '18

07 Jun '18

Hi all, Wondering if others have seen this. Running FS 1.6.20 on Debian 8 as B2BUA, no proxy media. I'm not sure if this is a bug or whether its environmental in some way. If we dig further and think it really is a bug we'll log a proper bug tomorrow. A call comes in interface A, does not have any RTCP packets. Call is bridged to interface B which does contain RTCP packets. Same confg on both sofia profiles. The RTP packet in the A->B stream immediately after the RTCP packet sent by FS skips a timestamp, even though the sequence number increments correctly. e.g Interface A packets 4.58 seconds RTP timestamp=855198950 seq=53269 4.60 seconds RTP timestamp=855199110 seq=53270 4.62 seconds RTP timestamp=855199270 seq=53271 4.64 seconds RTP timestamp=855199430 seq=53272 Interface B packets 4.77 seconds RTP timestamp=855198950 seq=20446 4.79 seconds RTP timestamp=855199110 seq=20447 4.80 seconds RTCP Sender Report ??? 4.83 seconds RTP timestamp=855199430 seq=20448 In the above example, the packet with timestamp 855199270 does not appear at 4.81 seconds as expected and the next packet contains the next timestamp 855199430 but the sequence numbers keep incrementing normally. Its like FS has dropped that packet internally. We can hear this as an audio artefact when listening to the call. In this case I don't think rewriting timestamps will help if the packet is being dropped - we'll still hear the missing audio. Secondly, in troubleshooting this issue, I've noticed that most of our traffic does not contain RTCP packets, but some do and I can't seem to find any rhyme or reason for this behaviour. Does anyone know why a call will or won't contain RTCP? I had 2 calls in a minute go via 2 FS boxes running the same config, same FS version, same A to B numbers and path through the network and one had RTCP and one didn't. You'd think if the same CPE made the same call to the same FS configuration (albeit a different physical box on the same LAN segment), that you'd see the same behaviour. thanks, David

1 0

What is wrong with my originate ?
by Pierre Couderc 06 Jun '18

06 Jun '18

originate sofia/internal/98%free.couderc.eu 0033484253887 XML int.example.net See my traces below. The strange is that if I call from my extension 98 the same number all is fine. I understand it may be question of CODEC, as when calling from 98 I see PCMA, PCMU in the traces. But how to correct? Thanks to read me. Pierre Couderc ...... 2018-06-02 08:47:43.279349 [DEBUG] sofia_glue.c:1295 sofia/external/0033484253887 sending invite version: 1.6.20 -37-987c9b9 64bit Local SDP: v=0 o=FreeSWITCH 1527903329 1527903330 IN IP4 192.168.163.67 s=FreeSWITCH c=IN IP4 192.168.163.67 t=0 0 m=audio 25934 RTP/AVP 9 101 13 a=rtpmap:9 G722/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 a=sendrecv 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:40 sofia/external/0033484253887 Standard INIT 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:48 (sofia/external/0033484253887) State Change CS_INIT -> CS_ROUTING 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:627 (sofia/external/0033484253887) State INIT going to sleep 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:584 (sofia/external/0033484253887) Running State Change CS_ROUTING (Cur 2 Tot 201) 2018-06-02 08:47:43.279349 [DEBUG] sofia.c:7084 Channel sofia/external/0033484253887 entering state [calling][0] 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:643 (sofia/external/0033484253887) State ROUTING 2018-06-02 08:47:43.279349 [DEBUG] mod_sofia.c:143 sofia/external/0033484253887 SOFIA ROUTING 2018-06-02 08:47:43.279349 [DEBUG] switch_ivr_originate.c:67 (sofia/external/0033484253887) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:643 (sofia/external/0033484253887) State ROUTING going to sleep 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:584 (sofia/external/0033484253887) Running State Change CS_CONSUME_MEDIA (Cur 2 Tot 2 01) 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:662 (sofia/external/0033484253887) State CONSUME_MEDIA 2018-06-02 08:47:43.279349 [DEBUG] switch_core_state_machine.c:662 (sofia/external/0033484253887) State CONSUME_MEDIA going to sleep 2018-06-02 08:47:43.339353 [DEBUG] switch_rtp.c:7308 Correct audio ip/port confirmed. 2018-06-02 08:47:43.339353 [DEBUG] sofia.c:7084 Channel sofia/external/0033484253887 entering state [calling][0] 2018-06-02 08:47:43.399358 [DEBUG] sofia.c:7084 Channel sofia/external/0033484253887 entering state [terminated][488] 2018-06-02 08:47:43.399358 [NOTICE] sofia.c:8273 Hangup sofia/external/0033484253887 [CS_CONSUME_MEDIA] [INCOMPATIBLE_DESTINATION] 2 ....

2 2

Re: [Freeswitch-users] Achieving TLS + SRTP for inbound calls
by David P 06 Jun '18

06 Jun '18

While waiting for suggestions, I tried more things. In particular, I tested whether gentls_cert was present in our FS install (which is at /opt/freeswitch/ on ubuntu). It is present, but the CA root cert step writes to {prefix}/etc/freeswitch/tls/CA/ instead of {prefix}/conf/ssl/CA/. In particular, the root CA step generates: etc/freeswitch/tls/ cafile.pem etc/freeswitch/tls/CA/ cacert.pem cakey.pem config.tpl And the server cert step generates: etc/freeswitch/tls/ agent.pem etc/freeswitch/tls/CA/ cacert.srl Reviewing agent.pem shows it's fine: openssl x509 -noout -inform pem -text -in /opt/freeswitch/etc/freeswitch/tls/agent.pem But it's owned by user root group root, so: cd /opt/freeswitch/etc/freeswitch/tls/ chmod 640 agent.pem CA/cacert.pem chown root.freeswitch agent.pem CA/cacert.pem Then I edited /opt/freeswitch/etc/freeswitch/vars.xml to set internal_ssl_enable and external_ssl_enable to true. Then I restarted FS. I checked the CLI and it shows "WS SETUP FAILED" repeatedly. *Any suggestion?* Blazing ahead...then I exposed the public IP of the FS machine under a subdomain of the CA root cert's domain. (I used a wildcard subdomain for -org when generating both certs; maybe giving a wildcard this way is unnecessary or counterproductive.) Now, the part that puzzles me: I'm already using a "real CA" cert in order to serve my verto client files over https from my DNS name, so browsers won't show security warnings. But I bet I need to have the same CA root cert installed in FS as I use in the webserver, right? I saw the note that commercial certs should work, but *it's not clear what steps to follow to install one*. Cheers, David On Tue, May 22, 2018 at 9:50 PM, David P <davidswalkabout(a)gmail.com> wrote: > We use conferences to allow a verto user to call and connect with an > Asterisk channel. We would like to secure both signalling and media via TLS > + SRTP, and I've read https://freeswitch.org/ > confluence/display/FREESWITCH/SIP+TLS a few times to understand how to do > this. Note that that page has a broken link: https://wiki.freeswitch.org/ > wiki/Secure_RTP > > First, is it still true that FS doesn't offer prebuilt installs (for > Ubuntu) to support this kind of security? > > Assuming that it must be compiled, I began to follow > https://freeswitch.org/confluence/display/FREESWITCH/Debian+8+Jessie with > the additional first step of: apt-get install libssl-dev > > I soon ran into "Unable to locate package freeswitch-video-deps-most". > > What should I try next? > > Cheers, > David >

2 2

Energy level for record_session
by Ciprian Dosoftei 05 Jun '18

05 Jun '18

Hello everyone! I have checked the Confluence documentation and I cannot seem to find energy level settings for the record_session application (not record). I do however see references to a RECORD_SILENCE_THRESHOLD variable in the source code, if I am looking at the right file ( https://docs.freeswitch.org/switch__ivr__async_8c_source.html line 2688). Could it be enforced through a channel variable setting prior to executing the application? My usage scenario is pretty straight forward: I am using record_session (with RECORD_READ_ONLY set) to record each individual channel in a conference separately, which works great, but it also captures much more background noise than ideal, which for muxed mod_conference recordings is not an issue as the energy level setting will naturally clean the recording prior to muxing. I also want the recording to continue should there be excessive silence from a channel (unlike record for which a silence hits threshold is almost always desirable). Thank you! -- Best Regards, Ciprian Dosoftei The information transmitted is intended only for the addressee and may contain privileged and/or confidential material. If you are not the intended recipient, kindly contact the sender and delete the message. Any disclosure, distribution or copying of this message is strictly prohibited without the expressed permission of the sender.

1 0

Re: [Freeswitch-users] No ACK for 200 OK
by Xenia Obolenskaya 05 Jun '18

05 Jun '18

Dear Michael Jerris, Thank you for your consideration! sofia loglevel tport 9 Sofia log level for component [tport] has been set to [9] Here is the log when the parameter in the gateway was commented out  In the received packet in the header Contact: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5060;transport=udp> the selected transport is udp!!! Freeswitch does not sent ACK As for tport log I do not see any fatal errors in this case, maybe you, as a specialist, can see? tport.c:3023 tport_deliver() tport_deliver(0x7f4e6c0ce360): msg 0x7f4e6c0e7520 (1184 bytes) from tls/[2a02:7b43:1eb0:eb21::2]:5061/sips next=(nil) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e6c0ce360): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e58096970): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e58096970) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e58096970): tls_read() returned 4 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e58096970) msg 0x7f4e58068390 from (tls/181.201.33.15:39478) has 4 bytes, veclen = 1 tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e6c0ce360): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e6c0ce360) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e6c0ce360): tls_read() returned 845 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e6c0ce360) msg 0x7f4e6c0e7520 from (tls/[2a02:7b43:1eb0:eb21::2]:5061) has 845 bytes, veclen = 1 tport.c:2296 tport_set_secondary_timer() tport(0x7f4e6c0ce360): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e6c0ce360): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e6c0ce360) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e6c0ce360): tls_read() returned 339 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e6c0ce360) msg 0x7f4e6c0e7520 from (tls/[2a02:7b43:1eb0:eb21::2]:5061) has 339 bytes, veclen = 1 recv 1184 bytes from tls/[2a02:7b43:1eb0:eb21::2]:5061 at 07:05:06.088128: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/TLS [2a02:f680:e0:1210::2123]:5061;branch=z9hG4bK0UjgcDj2ae5Zr;rport=54911 From: "Extension 1000" <sip:1000@ [2a02:f680:e0:1210::2123]>;tag=1mKgNjj91mpSe To: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5061>;tag=jmg806XU07Dee Call-ID: 6368d0a7-e318-1236-2fbf-525400af4b7f CSeq: 123749671 INVITE Contact: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20171120T163416Z~b1b21d0695~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 339 X-FS-Display-Name: Outbound Call X-FS-Display-Number: sip:1000%@[2a02:7b43:1eb0:eb21::2] X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1528150294 1528150295 IN IP6 2a02:7b43:1eb0:eb21::2 s=FreeSWITCH c=IN IP6 2a02:7b43:1eb0:eb21::2 t=0 0 m=audio 21180 RTP/SAVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=crypto:1 AEAD_AES_256_GCM_8 inline:eezgaWEZZUvKciFAkpVWpZhdv39wLjvIyzMZMbmk6FbkYfnrFAm9eziQq5M ------------------------------------------------------------------------ tport.c:3023 tport_deliver() tport_deliver(0x7f4e6c0ce360): msg 0x7f4e6c0e7520 (1184 bytes) from tls/[2a02:7b43:1eb0:eb21::2]:5061/sips next=(nil) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e6c0ce360): reset timer tport.c:2296 tport_set_secondary_timer() tport(0x7f4e6c0ce360): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e58096970): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e58096970) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e58096970): tls_read() returned 565 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e58096970) msg 0x7f4e58068390 from (tls/181.201.33.15:39478) has 565 bytes, veclen = 1 tport.c:3023 tport_deliver() tport_deliver(0x7f4e58096970): msg 0x7f4e58068390 (573 bytes) from tls/181.201.33.15:39478/sips next=(nil) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer tport.c:3257 tport_tsend() tport_tsend(0x7f4e58096970) tpn = TLS/ 181.201.33.15:39478 tport_type_tls.c:534 tport_tls_send() tport_tls_writevec: vec 0x7f4e58047300 0x7f4e58097d90 628 (628) tport.c:3594 tport_vsend() tport_vsend(0x7f4e58096970): 628 bytes of 628 to tls/181.201.33.15:39478 tport.c:3492 tport_send_msg() tport_vsend returned 628 tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f4e58096970): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f4e58096970) tport_type_tls.c:434 tport_tls_recv() tport_tls_recv(0x7f4e58096970): tls_read() returned 562 tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x7f4e58096970) msg 0x7f4e58068390 from (tls/181.201.33.15:39478) has 562 bytes, veclen = 1 tport.c:3023 tport_deliver() tport_deliver(0x7f4e58096970): msg 0x7f4e58068390 (562 bytes) from tls/181.201.33.15:39478/sips next=(nil) tport.c:2296 tport_set_secondary_timer() tport(0x7f4e58096970): reset timer =========================================================================== And here is the log when the parameter in the gateway was uncommented <param name="register-transport" value="tls"/> and Freeswitch worked smoothly recv 1184 bytes from tls/[2a02:7b43:1eb0:eb21::2]:5061 at 07:10:20.917599: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/TLS [2a02:f680:e0:1210::2123]:5061;branch=z9hG4bKFKyaBgKr06NHH;rport=48779 From: "Extension 1000" <sip:1000@ [2a02:f680:e0:1210::2123]>;tag=FQ30U1X208Qje To: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5061>;tag=prNB8j19mB7rc Call-ID: 31efea17-e319-1236-2fbf-525400af4b7f CSeq: 123749844 INVITE Contact: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5061;transport=tls> User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20171120T163416Z~b1b21d0695~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 339 X-FS-Display-Name: Outbound Call X-FS-Display-Number: sip:1000%@[2a02:7b43:1eb0:eb21::2] X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1528143500 1528143501 IN IP6 2a02:7b43:1eb0:eb21::2 s=FreeSWITCH c=IN IP6 2a02:7b43:1eb0:eb21::2 t=0 0 m=audio 28320 RTP/SAVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=crypto:1 AEAD_AES_256_GCM_8 inline:7/8wl/6LKSgPhTNg1czXmvO1xFiiRNmC4Ugk8MYVqOFe+SMuWdbCWdH6hCE ------------------------------------------------------------------------ tport.c:3023 tport_deliver() tport_deliver(0x7f4e740d82a0): msg 0x7f4e740b6be0 (1184 bytes) from tls/[2a02:7b43:1eb0:eb21::2]:5061/sips next=(nil) tport.c:4222 tport_release() tport_release(0x7f4e740d82a0): 0x7f4e740d7590 by 0x7f4e740d2e30 with 0x7f4e740b6be0 tport.c:2296 tport_set_secondary_timer() tport(0x7f4e740d82a0): reset timer 2018-06-05 07:10:20.914430 [INFO] sofia.c:1279 sofia/external-ipv6/1000 Update Callee ID to "Outbound Call" <sip:1000%@[2a02:7b43:1eb0:eb21::2]> 2018-06-05 07:10:20.914430 [DEBUG] sofia.c:7084 Channel sofia/external-ipv6/1000 entering state [completing][200] 2018-06-05 07:10:20.914430 [DEBUG] sofia.c:7094 Remote SDP: v=0 o=FreeSWITCH 1528143500 1528143501 IN IP6 2a02:7b43:1eb0:eb21::2 s=FreeSWITCH c=IN IP6 2a02:7b43:1eb0:eb21::2 t=0 0 m=audio 28320 RTP/SAVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=crypto:1 AEAD_AES_256_GCM_8 inline:7/8wl/6LKSgPhTNg1czXmvO1xFiiRNmC4Ugk8MYVqOFe+SMuWdbCWdH6hCE tport.c:4588 tport_by_name() tport(0x7f4e74083b20): found 0x7f4e740d82a0 by name tls/[2a02:7b43:1eb0:eb21::2]:5061 tport.c:3257 tport_tsend() tport_tsend(0x7f4e740d82a0) tpn = tls/[2a02:7b43:1eb0:eb21::2]:5061 tport_type_tls.c:534 tport_tls_send() tport_tls_writevec: vec 0x7f4e74085160 0x7f4e740d8840 483 (483) tport.c:3594 tport_vsend() tport_vsend(0x7f4e740d82a0): 483 bytes of 483 to tls/[2a02:7b43:1eb0:eb21::2]:5061 tport.c:3492 tport_send_msg() tport_vsend returned 483 send 483 bytes to tls/[2a02:7b43:1eb0:eb21::2]:5061 at 07:10:20.921598: ------------------------------------------------------------------------ ACK sip:1000@[2a02:7b43:1eb0:eb21::2]:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS [2a02:f680:e0:1210::2123]:5061;branch=z9hG4bKgvQ3cB4UXFc4c Max-Forwards: 70 From: "Extension 1000" <sip:1000@ [2a02:f680:e0:1210::2123]>;tag=FQ30U1X208Qje To: <sip:1000@[2a02:7b43:1eb0:eb21::2]:5061>;tag=prNB8j19mB7rc Call-ID: 31efea17-e319-1236-2fbf-525400af4b7f CSeq: 123749844 ACK Contact: <sip:gw+lt_ipv6@ [2a02:f680:e0:1210::2123]:5061;tport=tcp;transport=tls;gw=lt_ipv6> Content-Length: 0 ------------------------------------------------------------------------ tport.c:2296 tport_set_secondary_timer() tport(0x7f4e740d82a0): reset timer Regards, Xenia Obolenskaya

1 0