April 2018 - FreeSWITCH-users - FreeSWITCH Mailing Lists

valet_park and caller Id number
by Preston Hagar 30 Apr '18

30 Apr '18

I've setup mod_valet_park to have a set of "parking slots" so that our receptionist can park the calls in, page for someone to pickup, and then that person can dial in and pick up. That is all working well. I'm using Voice Operator Panel (VOP) for the receptionist software and want them to be able to monitor presence on the parking slots so that they can see which ones have calls parked that haven't been picked up. I'd also like them to be able to see the caller id of the call parked in each slot. VOP is monitoring presence fine, but for callerId it just shows "park" as the number. I traced the presence packets in the console and the problem is that in the remote->identity display section of the notify packet, it has "park" as the value to display, instead of the caller id number parked there. (see example XML below). I have a couple of questions: 1. Is it even possible to get mod_valet_park/freeswitch to report the parked caller id number in presence requests in the current mod_valet_park? If so, how is it done? 2. If it isn't in the current code, can anyone point me to the code block that generates that remote XML section of the presence notification? I poked around in the valet_send_presence function of mod_valet_parking.c, but can't seem to figure out how that block is built. I will admit that I'm still getting up to speed on how Presence works in FreeSWITCH. Thanks for your help! Here is a sample notify block: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:park+8001@pbx.myfreeswitchdomain.com"> <dialog id="8001" direction="recipient"> <state>confirmed</state> <local> <identity display="park">sip:8001@pbx.myfreeswitchdomain.com ;proto=park</identity> <target uri="sip:8001@pbx.myfreeswitchdomain.com;proto=park"> <param pname="+sip.rendering" pvalue="no"/> </target> </local> <remote> <identity display="park">sip:8001</identity> <target uri="sip:park+8001@pbx.myfreeswitchdomain.com"/> </remote> </dialog> </dialog-info>

2 3

FreeSwitch not preserving the 'Via' in the answer to the BYE message
by Stefano Bertuola 30 Apr '18

30 Apr '18

Hi all. I have an issue/doubt regarding Via header. The scenario is a FreeSwitch connected to a Mavenir's IMS; call is generated by FS towards Mavenir's IMS (it is ok) and release (BYE) is coming from IMS: Request-Line: BYE sip:gw+ibcf_gateway@192.168.242.42:5060;transport=udp;gw=ibcf_gateway SIP/2.0 Message Header [truncated]Via: SIP/2.0/UDP scscf.ims.mnc001.mcc001.3gppnetwork.org:5060;rport;branch=z9hG4bKmavodi-0-4c-bf-2-640020-4df45e927c208f36,SIP/2.0/UDP tas.ims.mnc001.mcc001.3gppnetwork.org:5060;received=192.168.239.37;rport=5060;branch=z9hG4bK Transport: UDP Sent-by Address: scscf.ims.mnc001.mcc001.3gppnetwork.org Sent-by port: 5060 RPort: rport Branch: z9hG4bKmavodi-0-4c-bf-2-640020-4df45e927c208f36 Transport: UDP Sent-by Address: tas.ims.mnc001.mcc001.3gppnetwork.org Sent-by port: 5060 Received: 192.168.239.37 RPort: 5060 Branch: z9hG4bKmavodi-0-7e-76-1-ffffffff-3029420078-24076 Max-Forwards: 69 From: <sip:+628811451570@ims.mnc001.mcc001.3gppnetwork.org>;tag=mavodi-0-7e-76-1-ffffffff-_000C2939994E-5e0c-a2ac4700-5df-5ae2f6d8-24075 To: "+628811452131" <sip:+628811452131@192.168.242.42>;tag=HHXppypZBv2aS Call-ID: f4973e3c-c4a8-1236-15b0-000c29581a5f CSeq: 122076474 BYE Content-Length: 0 P-Access-Network-Info: 3GPP-E-UTRAN-TDD;utran-cell-id-3gpp=5102800640033101 P-Charging-Vector: icid-value=0.82.760-1524823768.21;icid-generated-at=192.168.239.35;term-ioi=Ioi1;orig-ioi=22345 P-Charging-Function-Addresses: ccf=ims.mnc001.mcc001.3gppnetwork.org;ecf=ims.mnc001.mcc001.3gppnetwork.org… Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP scscf.ims.mnc001.mcc001.3gppnetwork.org:5060;rport=5060;branch=z9hG4bKmavodi-0-4c-bf-2-640020-4df45e927c208f36;received=192.168.239.36 Transport: UDP Sent-by Address: scscf.ims.mnc001.mcc001.3gppnetwork.org Sent-by port: 5060 RPort: 5060 Branch: z9hG4bKmavodi-0-4c-bf-2-640020-4df45e927c208f36 Received: 192.168.239.36 From: <sip:+628811451570@ims.mnc001.mcc001.3gppnetwork.org>;tag=mavodi-0-7e-76-1-ffffffff-_000C2939994E-5e0c-a2ac4700-5df-5ae2f6d8-24075 To: "+628811452131" <sip:+628811452131@192.168.242.42>;tag=HHXppypZBv2aS Call-ID: f4973e3c-c4a8-1236-15b0-000c29581a5f CSeq: 122076474 BYE User-Agent: FreeSwitch Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Content-Length: 0 In the 200 OK replied back by FS to the BYE message, part of the 'Via' header is "missing". According to RFC 3261: "The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering". Is it a expected behavior? Any variable to set in order to get the "original" 'Via' header in the answer? Br. Stefano

1 0

SIP PUBLISH and custom events
by Ronnie Beck 30 Apr '18

30 Apr '18

Hi All, I have a configuration question regarding SIP Events (rfc 3903). I have a custom VoIP client which PUBLISHes events which are custom i.e. they are not types which a phone would understand like "presence" or "call-info". When my client attempts to publish such events by sending a publish SIP request, Freeswitch replies with a "BAD EVENT" message. The supported messages seem to be: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Is this list configurable? Or is there a way that I can configure the publishing of event, the "Event" header of which I define? Must I write a freeswitch module for handling the subscriptions for this or can this be handled via a configuration and perhaps an additional event socket module which I would have to write? Any help is greatly appreciated. Cheers, Aaron

1 0

Sangoma A102, PRIs, Caller ID Name, and Facility
by Preston Hagar 27 Apr '18

27 Apr '18

Hi all, We are working on setting up a FreeSWITCH system using a PRI connected to a Sangoma A102DE card. Everything is working, except Caller ID Name (we get caller ID number). The Caller ID is getting passed in the SETUP message, but the Sangoma libraries don't seem to pull it out. If we try setting facility=yes in the freetdm.conf.xml file, FreeSwitch segfaults (in the ftmod_sangoma_isdn.so file), so at least right now, that isn't a fix. We have a ticket open with Sangoma, but it is taking a while. I am just curious, does anyone out there have a FreeSwitch system working with a Sangoma card hooked to a PRI and receiving caller ID names? If so, are you willing to share any model/config information? This is our last step to get this off the ground, so any help anyone can provide would be greatly appreciated. Thanks! Preston

1 0

Re: [Freeswitch-users] Freeswitch 1.6.19 and T.38 / INCOMPATIBLE_DESTINATION
by Dominique Jeannerod 27 Apr '18

27 Apr '18

Yes, you're right, and i apologize for that. I tested in the meantime (sent another mail in parallel), and it still doesn't work. I have the same error as in JIRA 10422 : https://freeswitch.org/jira/browse/FS-10422 I've got " T38 IS NOT POSSIBLE on request " on the FIRST invite (not a RE-INVITE) 2018-04-27 9:40 GMT+02:00 Sergey Safarov <s.safarov(a)gmail.com>: > Think you not applied recommendation > > If you wish to retain the previous behavior you can set fax_enable_t38=true > in your vars.xml, You can also not set that and just set refuse_t38=true if > you wish to never do t.38. > > > пт, 27 апр. 2018 г. в 10:03, Dominique Jeannerod < > dominique.jeannerod(a)interact-iv.com>: > >> Thanks a lot for this answer. >> I already read this information mail, and read the changes done for t38 >> re-invite. >> The problem i have is NOT on the reinvite but directly on the first >> invite of the Call >> Do you think the behaviour also changed for the first invite ? >> >> Anyway, i will try the new configuration parameter, and test if it fixes >> my problem. >> My short term fallback plan would just be to downgrade to the 1.6.8 >> version we already have on production. >> >> >> Le jeu. 26 avr. 2018 à 23:52, Michael Jerris <mike(a)jerris.com> a écrit : >> >>> http://lists.freeswitch.org/pipermail/freeswitch-users/ >>> 2017-January/124459.html >>> >>> On Apr 26, 2018, at 5:20 PM, Dominique Jeannerod < >>> dominique.jeannerod(a)interact-iv.com> wrote: >>> >>> Hello, >>> >>> I currently use Freeswitch 1.6.8-1 in production, and have some ISDN >>> gateways sending SDP including T.38 for voice calls (not faxes). Calls are >>> handled without problems by freeswitch. >>> >>> I have another platform, with freeswitch 1.6.19 and same configuration. >>> However, voice calls received with SDP including t.38 are rejected with >>> 488 INCOMPATIBLE_DESTINATION : >>> ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] >>> switch_core_media.c:4028 sofia/internal_1/33183817938@gv-ics-prd-301 >>> T38 REFUSE on request >>> ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 >>> [NOTICE] sofia.c:7566 Hangup sofia/internal_1/33183817938@gv-ics-prd-301 >>> [CS_NEW] [INCOMPATIBLE_DESTINATION] >>> >>> I didn't find any valid configuration to make those calls accepted, >>> except configuring proxy_media, which I don't want to use. >>> >>> Is this behaviour a "normal" behaviour ? Could it be a bug ? >>> This is a very big issue for us ... >>> >>> >>> ____________________________________________________________ >>> _____________ >>> Professional FreeSWITCH Consulting Services: >>> consulting(a)freeswitch.org >>> http://www.freeswitchsolutions.com >>> >>> Official FreeSWITCH Sites >>> http://www.freeswitch.org >>> http://confluence.freeswitch.org >>> http://www.cluecon.com >>> >>> FreeSWITCH-users mailing list >>> FreeSWITCH-users(a)lists.freeswitch.org >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>> http://www.freeswitch.org >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting(a)freeswitch.org >> http://www.freeswitchsolutions.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://confluence.freeswitch.org >> http://www.cluecon.com >> >> FreeSWITCH-users mailing list >> FreeSWITCH-users(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting(a)freeswitch.org > http://www.freeswitchsolutions.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://confluence.freeswitch.org > http://www.cluecon.com > > FreeSWITCH-users mailing list > FreeSWITCH-users(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org >

2 1

SIMCOM LTE modems with USB Audio
by Stanislav Sinyagin 27 Apr '18

27 Apr '18

hi, I wrote about a year ago about SIMCOM SIM7100 series LTE modems and that they support USB audio. Now the vendor offers also SIM7500 and SIM7600 modems, also with USB audio, and in addition these newer models support 16-bit audio streams. Unfortunately I didn't find the free time to make a FreeSWITCH module for them, but if someone wants to sponsor such a development, or actually develop it, I'll be glad to work together. I've got a SIM7100E modem, and SIM7500E is ordered and is on the way. The SIM7500 series is cheaper, but it only supports 10Mbps downstream for mobile data. The SIM7600 supports up to 150Mbps. But for voice applications, data transfer rate should be irrelevant in any way. cheers, stanislav

3 5

Some changes in events messages from mod_callcenter ?
by Peter Nerád 27 Apr '18

27 Apr '18

Hi, I m parsing some events from callcenter in my app. I m upgrade freeswitch to 1.6.20 version... i have problems to parse this events now because some values in events messages are now in uuid format, not text. In this new version: CC-Queue: 13b5a0a3-c8ec-428d-a8f6-36e32cbd3912 CC-Agent: 5b5e51b2-94b0-4b64-85d8-28fde9505894 which is not same as CC-Agent-UUID In the past version: CC-Queue: support@default CC-Agent: AgentNameHere Is there any option in config i can change the CC-QUEUE and CC-AGENT to the past format or it is a bug ? Im using a fusionpbx to manage mod_callcenter... som maybe there is some error...

1 0

Re: [Freeswitch-users] Freeswitch 1.6.19 and T.38 / INCOMPATIBLE_DESTINATION
by Dominique Jeannerod 27 Apr '18

27 Apr '18

So, I tested with " <X-PRE-PROCESS cmd="set" data="fax_enable_t38=true"/>" in vars.xml, which i didn't do previously. The behaviour is quite different. However, the call is directly rejected after the first INVITE (which is not a REINVITE), but instead of having " T38 REFUSE on request", i have : 2018-04-27 09:28:48.697285 [DEBUG] switch_core_media.c:4041 sofia/internal_2/698778763@gv-ics-prd-301 T38 ACCEPT on request 2018-04-27 09:28:48.697285 [DEBUG] switch_core_media.c:4146 sofia/internal_2/698778763@gv-ics-prd-301 T38 IS NOT POSSIBLE on request 2018-04-27 09:28:48.697285 [NOTICE] sofia.c:7566 Hangup sofia/internal_2/698778763@gv-ics-prd-301 [CS_NEW] [INCOMPATIBLE_DESTINATION] Is there another parameter to configure to allow T38 ? Add a codec (I only have PCMA, and PCMU) Full log : INVITE sip:0170993650@10.9.30.34:5060 SIP/2.0 Record-Route: <sip:10.3.1.220;lr=on> Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK002b.b2b0e9d2.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac408981189 Max-Forwards: 69 From: <sip:698778763@gv-ics-prd-301>;tag=1c408970979 To: <sip:0170993650@10.3.1.220;user=phone> Call-ID: 408970087274201872848(a)10.3.1.231 CSeq: 1 INVITE Contact: <sip:698778763@10.3.1.231:5060> Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Remote-Party-ID: <sip:698778763@10.3.1.220 >;party=calling;privacy=off;screen=yes;screen-ind=3;npi=1;ton=2 Remote-Party-ID: <sip:0170993650@10.3.1.220>;party=called;npi=1;ton=2 User-Agent: Audiocodes-Sip-Gateway-Mediant 3000/v.6.00A.056 Content-Type: application/sdp Content-Length: 413 v=0 o=AudiocodesGW 408954776 408954489 IN IP4 10.3.1.231 s=Phone-Call c=IN IP4 10.3.1.231 t=0 0 m=audio 7850 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv m=image 7852 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:33600 a=T38FaxMaxBuffer:3000 a=T38FaxMaxDatagram:560 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy ------------------------------------------------------------------------ send 374 bytes to udp/[10.3.1.220]:5060 at 09:28:49.974884: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK002b.b2b0e9d2.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac408981189 Record-Route: <sip:10.3.1.220;lr=on> From: <sip:698778763@gv-ics-prd-301>;tag=1c408970979 To: <sip:0170993650@10.3.1.220;user=phone> Call-ID: 408970087274201872848(a)10.3.1.231 CSeq: 1 INVITE User-Agent: FreeSWITCH Content-Length: 0 ------------------------------------------------------------------------ 2018-04-27 09:28:49.957287 [NOTICE] switch_channel.c:1104 New Channel sofia/internal_2/698778763@gv-ics-prd-301 [233f8391-10e6-4877-a792-6ad2a0f651e0] 2018-04-27 09:28:49.957287 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_2/698778763@gv-ics-prd-301) Running State Change CS_NEW (Cur 1 Tot 2) 2018-04-27 09:28:49.957287 [DEBUG] sofia.c:9874 sofia/internal_2/698778763@gv-ics-prd-301 receiving invite from 10.3.1.220:5060 version: 1.6.19 64bit 2018-04-27 09:28:49.957287 [DEBUG] sofia.c:7085 Channel sofia/internal_2/698778763@gv-ics-prd-301 entering state [received][100] 2018-04-27 09:28:49.957287 [DEBUG] sofia.c:7095 Remote SDP: v=0 o=AudiocodesGW 408954776 408954489 IN IP4 10.3.1.231 s=Phone-Call c=IN IP4 10.3.1.231 t=0 0 m=audio 7850 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 m=image 7852 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:33600 a=T38FaxMaxBuffer:3000 a=T38FaxMaxDatagram:560 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4449 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4504 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4449 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMU:0:8000:20:64000:1] 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4365 Set telephone-event payload to 101@8000 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:3061 Set Codec sofia/internal_2/698778763@gv-ics-prd-301 PCMA/8000 20 ms 160 samples 64000 bits 1 channels 2018-04-27 09:28:49.957287 [DEBUG] switch_core_codec.c:111 sofia/internal_2/698778763@gv-ics-prd-301 Original read codec set to PCMA:8 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4708 Set telephone-event payload to 101@8000 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4767 sofia/internal_2/698778763@gv-ics-prd-301 Set 2833 dtmf send payload to 101 recv payload to 101 2018-04-27 09:28:49.977279 [DEBUG] switch_core_media.c:4041 sofia/internal_2/698778763@gv-ics-prd-301 T38 ACCEPT on request 2018-04-27 09:28:49.977279 [DEBUG] switch_core_media.c:4146 sofia/internal_2/698778763@gv-ics-prd-301 T38 IS NOT POSSIBLE on request 2018-04-27 09:28:49.977279 [NOTICE] sofia.c:7566 Hangup sofia/internal_2/698778763@gv-ics-prd-301 [CS_NEW] [INCOMPATIBLE_DESTINATION] 2018-04-27 09:28:49.977279 [DEBUG] switch_core_state_machine.c:603 (sofia/internal_2/698778763@gv-ics-prd-301) State NEW 2018-04-27 09:28:49.977279 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_2/698778763@gv-ics-prd-301) Running State Change CS_HANGUP (Cur 1 Tot 2) 2018-04-27 09:28:49.977279 [DEBUG] switch_core_state_machine.c:850 (sofia/internal_2/698778763@gv-ics-prd-301) Callstate Change DOWN -> HANGUP 2018-04-27 09:28:49.977279 [DEBUG] switch_core_state_machine.c:852 (sofia/internal_2/698778763@gv-ics-prd-301) State HANGUP 2018-04-27 09:28:49.977279 [DEBUG] mod_sofia.c:438 Channel sofia/internal_2/698778763@gv-ics-prd-301 hanging up, cause: INCOMPATIBLE_DESTINATION 2018-04-27 09:28:49.977279 [DEBUG] mod_sofia.c:577 Responding to INVITE with: 488 send 720 bytes to udp/[10.3.1.220]:5060 at 09:28:49.978310: ------------------------------------------------------------------------ SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK002b.b2b0e9d2.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac408981189 Max-Forwards: 69 From: <sip:698778763@gv-ics-prd-301>;tag=1c408970979 To: <sip:0170993650@10.3.1.220;user=phone>;tag=vy16j7B2HN1Xm Call-ID: 408970087274201872848(a)10.3.1.231 CSeq: 1 INVITE User-Agent: FreeSWITCH Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION" Content-Length: 0 Remote-Party-ID: "0170993650" <sip:0170993650@10.3.1.220 >;party=calling;privacy=off;screen=no 2018-04-27 8:24 GMT+02:00 Dominique Jeannerod < dominique.jeannerod(a)interact-iv.com>: > Thanks a lot for this answer. > I already read this information mail, and read the changes done for t38 > re-invite. > The problem i have is NOT on the reinvite but directly on the first invite > of the Call > Do you think the behaviour also changed for the first invite ? > > Anyway, i will try the new configuration parameter, and test if it fixes > my problem. > My short term fallback plan would just be to downgrade to the 1.6.8 > version we already have on production. > > Le jeu. 26 avr. 2018 à 23:52, Michael Jerris <mike(a)jerris.com> a écrit : > >> http://lists.freeswitch.org/pipermail/freeswitch-users/ >> 2017-January/124459.html >> >> On Apr 26, 2018, at 5:20 PM, Dominique Jeannerod < >> dominique.jeannerod(a)interact-iv.com> wrote: >> >> Hello, >> >> I currently use Freeswitch 1.6.8-1 in production, and have some ISDN >> gateways sending SDP including T.38 for voice calls (not faxes). Calls are >> handled without problems by freeswitch. >> >> I have another platform, with freeswitch 1.6.19 and same configuration. >> However, voice calls received with SDP including t.38 are rejected with >> 488 INCOMPATIBLE_DESTINATION : >> ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] >> switch_core_media.c:4028 sofia/internal_1/33183817938@gv-ics-prd-301 T38 >> REFUSE on request >> ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [NOTICE] >> sofia.c:7566 Hangup sofia/internal_1/33183817938@gv-ics-prd-301 [CS_NEW] >> [INCOMPATIBLE_DESTINATION] >> >> I didn't find any valid configuration to make those calls accepted, >> except configuring proxy_media, which I don't want to use. >> >> Is this behaviour a "normal" behaviour ? Could it be a bug ? >> This is a very big issue for us ... >> >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting(a)freeswitch.org >> http://www.freeswitchsolutions.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://confluence.freeswitch.org >> http://www.cluecon.com >> >> FreeSWITCH-users mailing list >> FreeSWITCH-users(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org > >

1 1

Freeswitch 1.6.19 and T.38 / INCOMPATIBLE_DESTINATION
by Dominique Jeannerod 27 Apr '18

27 Apr '18

Hello, I currently use Freeswitch 1.6.8-1 in production, and have some ISDN gateways sending SDP including T.38 for voice calls (not faxes). Calls are handled without problems by freeswitch. I have another platform, with freeswitch 1.6.19 and same configuration. However, voice calls received with SDP including t.38 are rejected with 488 INCOMPATIBLE_DESTINATION : ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4028 sofia/internal_1/33183817938@gv-ics-prd-301 T38 REFUSE on request ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [NOTICE] sofia.c:7566 Hangup sofia/internal_1/33183817938@gv-ics-prd-301 [CS_NEW] [INCOMPATIBLE_DESTINATION] I didn't find any valid configuration to make those calls accepted, except configuring proxy_media, which I don't want to use. Is this behaviour a "normal" behaviour ? Could it be a bug ? This is a very big issue for us ... Here is the log extract : recv 1391 bytes from udp/[10.9.30.152]:5060 at 23:47:39.443941: ------------------------------------------------------------------------ INVITE sip:0170993660@10.9.30.188:5060 SIP/2.0 Record-Route: <sip:10.9.30.152;lr=on> Record-Route: <sip:10.3.1.220;lr=on> Via: SIP/2.0/UDP 10.9.30.152;branch=z9hG4bK51d.d7e922c4.0 Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK51d.ba6f34d1.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac1339541470 Max-Forwards: 68 From: <sip:33183817938@gv-ics-prd-301>;tag=1c1339531455 To: <sip:0170993660@10.3.1.220;user=phone> Call-ID: 13395229682542018214736(a)10.3.1.231 CSeq: 1 INVITE Contact: <sip:33183817938@10.3.1.231:5060> Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Remote-Party-ID: <sip:33183817938@10.3.1.220 >;party=calling;privacy=off;screen=yes;screen-ind=3;npi=1;ton=1 Remote-Party-ID: <sip:0170993660@10.3.1.220>;party=called;npi=1;ton=2 User-Agent: Audiocodes-Sip-Gateway-Mediant 3000/v.6.00A.056 Content-Type: application/sdp Content-Length: 417 v=0 o=AudiocodesGW 1339507326 1339507042 IN IP4 10.3.1.231 s=Phone-Call c=IN IP4 10.3.1.231 t=0 0 m=audio 23970 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv m=image 23972 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:33600 a=T38FaxMaxBuffer:3000 a=T38FaxMaxDatagram:560 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy ------------------------------------------------------------------------ send 477 bytes to udp/[10.9.30.152]:5060 at 23:47:39.444372: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.9.30.152;branch=z9hG4bK51d.d7e922c4.0 Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK51d.ba6f34d1.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac1339541470 Record-Route: <sip:10.9.30.152;lr=on> Record-Route: <sip:10.3.1.220;lr=on> From: <sip:33183817938@gv-ics-prd-301>;tag=1c1339531455 To: <sip:0170993660@10.3.1.220;user=phone> Call-ID: 13395229682542018214736(a)10.3.1.231 CSeq: 1 INVITE User-Agent: FreeSWITCH Content-Length: 0 ------------------------------------------------------------------------ ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [NOTICE] switch_channel.c:1104 New Channel sofia/internal_1/33183817938@gv-ics-prd-301 [ba17b1eb-961d-43fe-b820-cb469a8f292d] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_1/33183817938@gv-ics-prd-301) Running State Change CS_NEW (Cur 1 Tot 69) ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] sofia.c:9874 sofia/internal_1/33183817938@gv-ics-prd-301 receiving invite from 10.9.30.152:5060 version: 1.6.19 64bit ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] sofia.c:7085 Channel sofia/internal_1/33183817938@gv-ics-prd-301 entering state [received][100] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] sofia.c:7095 Remote SDP: ba17b1eb-961d-43fe-b820-cb469a8f292d v=0^M ba17b1eb-961d-43fe-b820-cb469a8f292d o=AudiocodesGW 1339507326 1339507042 IN IP4 10.3.1.231^M ba17b1eb-961d-43fe-b820-cb469a8f292d s=Phone-Call^M ba17b1eb-961d-43fe-b820-cb469a8f292d c=IN IP4 10.3.1.231^M ba17b1eb-961d-43fe-b820-cb469a8f292d t=0 0^M ba17b1eb-961d-43fe-b820-cb469a8f292d m=audio 23970 RTP/AVP 8 101^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=rtpmap:8 PCMA/8000^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=rtpmap:101 telephone-event/8000^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=fmtp:101 0-15^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=ptime:20^M ba17b1eb-961d-43fe-b820-cb469a8f292d m=image 23972 udptl t38^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxVersion:0^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38MaxBitRate:33600^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxMaxBuffer:3000^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxMaxDatagram:560^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxRateManagement:transferredTCF^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxUdpEC:t38UDPRedundancy^M ba17b1eb-961d-43fe-b820-cb469a8f292d ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4449 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4504 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4449 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMU:0:8000:20:64000:1] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4365 Set telephone-event payload to 101@8000 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:3061 Set Codec sofia/internal_1/33183817938@gv-ics-prd-301 PCMA/8000 20 ms 160 samples 64000 bits 1 channels ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_codec.c:111 sofia/internal_1/33183817938@gv-ics-prd-301 Original read codec set to PCMA:8 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4708 Set telephone-event payload to 101@8000 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4767 sofia/internal_1/33183817938@gv-ics-prd-301 Set 2833 dtmf send payload to 101 recv payload to 101 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4028 sofia/internal_1/33183817938@gv-ics-prd-301 T38 REFUSE on request ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [NOTICE] sofia.c:7566 Hangup sofia/internal_1/33183817938@gv-ics-prd-301 [CS_NEW] [INCOMPATIBLE_DESTINATION] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:603 (sofia/internal_1/33183817938@gv-ics-prd-301) State NEW ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_1/33183817938@gv-ics-prd-301) Running State Change CS_HANGUP (Cur 1 Tot 69) ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:850 (sofia/internal_1/33183817938@gv-ics-prd-301) Callstate Change DOWN -> HANGUP ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:852 (sofia/internal_1/33183817938@gv-ics-prd-301) State HANGUP ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] mod_sofia.c:438 Channel sofia/internal_1/33183817938@gv-ics-prd-301 hanging up, cause: INCOMPATIBLE_DESTINATION ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] mod_sofia.c:577 Responding to INVITE with: 488 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:60 sofia/internal_1/33183817938@gv-ics-prd-301 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:852 (sofia/internal_1/33183817938@gv-ics-prd-301) State HANGUP going to sleep ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:619 (sofia/internal_1/33183817938@gv-ics-prd-301) State Change CS_HANGUP -> CS_REPORTING ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_1/33183817938@gv-ics-prd-301) Running State Change CS_REPORTING (Cur 1 Tot 69) send 784 bytes to udp/[10.9.30.152]:5060 at 23:47:39.446918: ------------------------------------------------------------------------ SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/UDP 10.9.30.152;branch=z9hG4bK51d.d7e922c4.0 Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK51d.ba6f34d1.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac1339541470 Max-Forwards: 68 From: <sip:33183817938@gv-ics-prd-301>;tag=1c1339531455 To: <sip:0170993660@10.3.1.220;user=phone>;tag=9USNQNQDByZ6a Call-ID: 13395229682542018214736(a)10.3.1.231 CSeq: 1 INVITE User-Agent: FreeSWITCH Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION" Content-Length: 0 Remote-Party-ID: "0170993660" <sip:0170993660@10.3.1.220 >;party=calling;privacy=off;screen=no Thanks with anticipation D. Jeannerod

3 3

Implementing emergency calls ... or call priority ?
by Peter Nerád 27 Apr '18

27 Apr '18

Whats are best practicies to implement emergency calls ? I can identify such a call by regexp but how to handle those calls ? Is there some build param to be set ? How I can set priority for call ? e.g. I have limited capacity for outgoing and incoming call to 10. I need to drop some calls with small priority to allow emergency call, but I have no idea where to start. Can somebody give me right direction for this ? Thank you very much PS: Google does not helped me :(

3 4