July 2015 - FreeSWITCH-users - FreeSWITCH Mailing Lists

mod_rtmp onStatus messages
by Paul Cuttler 09 Jul '15

09 Jul '15

I was wondering about the onStatus messages that are sent by mod_rtmp to Flash Player. The RTMP Spec (see page 38 of http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specif…) says that the transaction ID for onStatus messages is supposed to be 0, but mod_rtmp uses 1. It seems to work fine, but I wanted to check if anyone knew if it might lead to problems not by following the spec. This is in rtmp_sig.c, for example in rtmp_i_play. regards, Paul

2 1

Fwd: sofia_reg_handle_register_token - exp possibly always false
by Podrigal, Aron 09 Jul '15

09 Jul '15

---------- Forwarded message ---------- From: Podrigal, Aron <aronp(a)guaranteedplus.com> Date: Tue, Jul 7, 2015 at 7:24 PM Subject: sofia_reg_handle_register_token - exp possibly always false To: freeswitch-dev <freeswitch-dev(a)lists.freeswitch.org> Hi, According to grep the function sofia_reg_handle_register_token is called from a single place src/mod/endpoints/mod_sofia/sofia_reg.c:2305 <https://freeswitch.org/stash/projects/FS/repos/freeswitch/browse/src/mod/en…> where the argument *v_event* would always be NULL at that time. So I'm wondering what the line at src/mod/endpoints/mod_sofia/sofia_reg.c:1297 <https://freeswitch.org/stash/projects/FS/repos/freeswitch/browse/src/mod/en…> if (v_event && *v_event) pres_on_reg = switch_event_get_header(*v_event, "send-presence-on-register"); is suppose to do, won't this always evaluate to false? -- Aron Podrigal - //Be happy :-) -- Aron Podrigal - //Be happy :-)

2 1

Fax problem
by Alexey Melnichuk 09 Jul '15

09 Jul '15

FreeSWITCH Version 1.4.20+git~20150703T164215Z~b95362f965~32bit (git b95362f 2015-07-03 16:42:15Z 32bit) I think I found bug in spandsp. `t4_image_put_handler_t` defined as (__cdecl) typedef int (*t4_image_put_handler_t)(void *user_data, const uint8_t buf[], size_t len); But `tXX_decode_put` functions defined as `__stdcall`. So when I do s->image_put_handler = (t4_image_put_handler_t) t4_t6_decode_put; ... s->image_put_handler(...) I got AV. After I declare t4_image_put_handler_t as __stdcall problem solved. (Alse need update declaretion to `pre_encoded_put` function) But I start getting heap corruption on `span_free((char *) s->tiff.file);` Problem is that it uses `strdup` function with different allocator. So I just copy function to `alloc.c` SPAN_DECLARE(char *) span_strdup(const char *str) { char *sdup; size_t len = strlen(str) + 1; sdup = (char *) span_alloc(len); memcpy(sdup, str, len); return sdup; } And use it as ds->tiff.file = span_strdup(file);

2 1

extra Bye message from Freeswitch
by Jurijs Ivolga 09 Jul '15

09 Jul '15

Hi! I started to run some performance tests against Freeswitch and in 5-10% tests are failing because of Freeswitch sending extra bye message. I would like to add that I got such messages on very low load, 1 new call in 5 seconds and first fail was after 9th call. Here how call looks like in 90-95% of time: SIPp UAC Freeswitch |(1) INVITE | |------------------>| |(2) 100 (optional) | |<------------------| |(3) 200 | |<------------------| |(4) ACK | |------------------>| |(5) BYE | |------------------>| |(6) 200 | |<------------------| Below you can see how call looks like in 5-10% of time. Somehow Freeswitch replies on bye message from Sipp with extra bye(around 5-10% of all calls) and it creates a mess: SIPp UAC Freeswitch |(1) INVITE | |------------------>| |(2) 100 (optional) | |<------------------| |(3) 200 | |<------------------| |(4) ACK | |------------------>| |(5) BYE | |------------------>| |(6) BYE | |<------------------| |(7) 200 | |------------------>| |(8) 200 | |<------------------| I'm not sure, but I think such behavior is not expected. Maybe somebody can let me know if it is proper Freeswitch behavior and if it is, why such behavior only happens with 5-10% of calls. Below you can find full sip trace, for a call with extra bye message. U 2015/07/09 11:07:07.269998 sippserver:5060 -> freeswitchserver:5060 INVITE sip:service@freeswitchserver:5060 SIP/2.0. Via: SIP/2.0/UDP sippserver:5060;branch=z9hG4bK-11560-9-0. From: sipp <sip:sipp@sippserver:5060>;tag=11560SIPpTag009. To: service <sip:service@freeswitchserver:5060>. Call-ID: 9-11560@sippserver. CSeq: 1 INVITE. Contact: sip:sipp@sippserver:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 139. . v=0. o=user1 53655765 2353687637 IN IP4 sippserver. s=-. c=IN IP4 sippserver. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. # U 2015/07/09 11:07:07.271005 freeswitchserver:5060 -> sippserver:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP sippserver:5060;branch=z9hG4bK-11560-9-0. From: sipp <sip:sipp@sippserver:5060>;tag=11560SIPpTag009. To: service <sip:service@freeswitchserver:5060>. Call-ID: 9-11560@sippserver. CSeq: 1 INVITE. User-Agent: FreeSWITCH-mod_sofia/1.4.18~64bit. Content-Length: 0. . # U 2015/07/09 11:07:07.276784 freeswitchserver:5060 -> sippserver:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP sippserver:5060;branch=z9hG4bK-11560-9-0. From: sipp <sip:sipp@sippserver:5060>;tag=11560SIPpTag009. To: service <sip:service@freeswitchserver:5060>;tag=S3Kvy09a3BrtS. Call-ID: 9-11560@sippserver. CSeq: 1 INVITE. Contact: <sip:service@freeswitchserver:5060;transport=udp>. User-Agent: FreeSWITCH-mod_sofia/1.4.18~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. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 168. Remote-Party-ID: "service" <sip:service@freeswitchserver >;party=calling;privacy=off;screen=no. . v=0. o=FreeSWITCH 1436408221 1436408222 IN IP4 freeswitchserver. s=FreeSWITCH. c=IN IP4 freeswitchserver. t=0 0. m=audio 21006 RTP/AVP 0. a=rtpmap:0 PCMU/8000. a=ptime:20. # U 2015/07/09 11:07:07.277349 sippserver:5060 -> freeswitchserver:5060 ACK sip:service@freeswitchserver:5060 SIP/2.0. Via: SIP/2.0/UDP sippserver:5060;branch=z9hG4bK-11560-9-5. From: sipp <sip:sipp@sippserver:5060>;tag=11560SIPpTag009. To: service <sip:service@freeswitchserver:5060>;tag=S3Kvy09a3BrtS. Call-ID: 9-11560@sippserver. CSeq: 1 ACK. Contact: sip:sipp@sippserver:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . # U 2015/07/09 11:07:07.278861 sippserver:5060 -> freeswitchserver:5060 BYE sip:service@freeswitchserver:5060 SIP/2.0. Via: SIP/2.0/UDP sippserver:5060;branch=z9hG4bK-11560-9-7. From: sipp <sip:sipp@sippserver:5060>;tag=11560SIPpTag009. To: service <sip:service@freeswitchserver:5060>;tag=S3Kvy09a3BrtS. Call-ID: 9-11560@sippserver. CSeq: 2 BYE. Contact: sip:sipp@sippserver:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . # U 2015/07/09 11:07:07.278931 freeswitchserver:5060 -> sippserver:5060 BYE sip:sipp@sippserver:5060 SIP/2.0. Via: SIP/2.0/UDP freeswitchserver;rport;branch=z9hG4bKF5jjXD7vrF3Qp. Max-Forwards: 70. From: service <sip:service@freeswitchserver:5060>;tag=S3Kvy09a3BrtS. To: sipp <sip:sipp@sippserver:5060>;tag=11560SIPpTag009. Call-ID: 9-11560@sippserver. CSeq: 77878549 BYE. User-Agent: FreeSWITCH-mod_sofia/1.4.18~64bit. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY. Supported: timer, path, replaces. Reason: Q.850;cause=16;text="NORMAL_CLEARING". Content-Length: 0. . # U 2015/07/09 11:07:07.279599 sippserver:5060 -> freeswitchserver:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP freeswitchserver;rport;branch=z9hG4bKF5jjXD7vrF3Qp. From: service <sip:service@freeswitchserver:5060>;tag=S3Kvy09a3BrtS. To: sipp <sip:sipp@sippserver:5060>;tag=11560SIPpTag009. Call-ID: 9-11560@sippserver. CSeq: 77878549 BYE. Contact: <sip:sippserver:5060;transport=UDP>. Content-Length: 0. . # U 2015/07/09 11:07:07.280338 freeswitchserver:5060 -> sippserver:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP sippserver:5060;branch=z9hG4bK-11560-9-7. From: sipp <sip:sipp@sippserver:5060>;tag=11560SIPpTag009. To: service <sip:service@freeswitchserver:5060>;tag=S3Kvy09a3BrtS. Call-ID: 9-11560@sippserver. CSeq: 2 BYE. Content-Length: 0. . I will appreciate any help! Thank you!

1 1

No Bridge Media
by Vishal Sharma 09 Jul '15

09 Jul '15

Hi, When I use following commnd on fs_cli, I can hear ring sound or any message telecome provider play on destination number originate freetdm/outgoing/r/09899790092 &bridge(freetdm/outgoing/r/09899488723) but when I use one of following commands freeswitch@internal> originate {bridge_early_media=true}freetdm/outgoing/r/09899790092 &bridge (freetdm/outgoing/r/09899488723) freeswitch@internal> originate {bridge_early_media=true}freetdm/outgoing/r/09899790092 &bridge({bridge_early_media=true}freetdm/outgoing/r/09899488723) or when I bridge a call which is received on FS, I don't get bridge media. Is there any perticular config required, or it's bug.. Regards, Vishal Sharma -- SuperReceptionist is now available on Android mobiles. Track your business on the go with call analytics, recordings, insights and more: Download the app here <https://play.google.com/store/apps/details?id=com.superreceptionist>

3 4

sip trunk with edgemarc
by Joli Martinez 09 Jul '15

09 Jul '15

Hello, I have an Edgemarc as an SBC and behind it is a Freeswitch pbx. I have configured the edgemarc as scenario 1 on the link below. So only does topology hiding but Freeswitch does the registration. On the sip-profile external I have my xml file which points to the LAN side of the Edgemarc. I am unable to register to the provider I get 503 service unvail. https://edgewaternetworks.com/wp-content/uploads/2014/07/Edgewater_Configur… Please help.

2 1

Sangoma's FreeTDM installation and setup on CentOS 6.6 with FreeSWITCH 1.4.20
by Andrew Keil 09 Jul '15

09 Jul '15

To all, There are some important bug fixes in Sangoma's FreeTDM and everyone should use the Sangoma updated version. In order to fast-track the changes I have created a tar.gz file on my FTP site and a PDF document (see attached) to setup the latest production release of FreeSWITCH (version 1.4.20) on CentOS 6.6 with the Sangoma updated FreeTDM 1.9.0. It may help anyone using FreeSWITCH with Sangoma hardware for the first time. Sangoma hope to merge FreeTDM (with the fixes) with FreeSWITCH in August/September this year. I will attempt to keep the PDF and FreeTDM tar.gz file up-to-date alongside future production releases of FreeSWITCH. FYI: Sangoma support also have a copy of this PDF file and they are thankful for the efforts I have made to fast-track new FreeSWITCH users to use their hardware. As with any instruction document, Visytel Pty Ltd accepts no liability or loss of earnings from following the attached PDF. Kind Regards, Andrew Keil Visytel Pty Ltd

1 0

park_after_bridge still broken in 1.4.20
by Ali Pey 08 Jul '15

08 Jul '15

Hello, A fix went in 1.4.20 for this: - FS-7636 <https://freeswitch.org/jira/browse/FS-7636> Fixed an issue with transfer_after_bridge and park_after_bridge pre-empting transfers However, park after bridge still doesn't work in 1.4.20. It only works if I downgrade to 1.4.15. Is there a bug open for this? Should I open a new bug or re-open FS-7636? Regards, Ali Pey

2 1

no audio with bypass_media_after_bridge
by stefano 08 Jul '15

08 Jul '15

Hello, I'm trying to use "bypass_media_after_bridge" in my dialplan. In this scenario I have a) softphone client using g729 b) FS version: FreeSWITCH Version 1.5.13b~64bit ( 64bit) c) Dialogic HMP 3.0 (g729 + g711) I'd like to use FS in passthrough mode so calls from a) will be rerouted to c). If I use the "bypass_media_after_bridge" signalling of calls is ok but i have no audio on a). If I use "bypass_media" audio is ok but I don't have the answer 200 OK back to my softphone a) This is my dialplan: <extension name="calls_to_ivr"> <condition field="destination_number" expression="^9999"> <action application="export" data="jitterbuffer_msec=60:200:40"/> <action application="set" data="bypass_media_after_bridge=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="ignore_early_media=true"/> <action application="set" data="effective_caller_id_number=1234"/> <action application="bridge" data="{execute_on_answer=start_dtmf_generate}sofia/internal/9000(a)10.1.1.1"/> <action application="pre_answer"/> </condition> </extension> In my sip profile the "inbound-late-negotiation" param is set to true. Is there any mistake in my dialplan? Thanks, Stefano F. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/no-audio-with-bypass-media-af… Sent from the freeswitch-users mailing list archive at Nabble.com.

2 1

Fax problem
by Alexey Melnichuk 08 Jul '15

08 Jul '15

FreeSWITCH Version 1.4.20+git~20150703T164215Z~b95362f965~32bit (git b95362f 2015-07-03 16:42:15Z 32bit) I think I found bug in spandsp. `t4_image_put_handler_t` defined as (__cdecl) typedef int (*t4_image_put_handler_t)(void *user_data, const uint8_t buf[], size_t len); But `tXX_decode_put` functions defined as `__stdcall`. So when I do s->image_put_handler = (t4_image_put_handler_t) t4_t6_decode_put; ... s->image_put_handler(...) I got AV. After I declare t4_image_put_handler_t as __stdcall problem solved. (Alse need update declaretion to `pre_encoded_put` function) But I start getting heap corruption on `span_free((char *) s->tiff.file);` Problem is that it uses `strdup` function with different allocator. So I just copy function to `alloc.c` SPAN_DECLARE(char *) span_strdup(const char *str) { char *sdup; size_t len = strlen(str) + 1; sdup = (char *) span_alloc(len); memcpy(sdup, str, len); return sdup; } And use it as ds->tiff.file = span_strdup(file);

1 0