- FreeSWITCH-users - FreeSWITCH Mailing Lists

Not send a ptime attr in SDP
by Ashou Han 18 Sep '13

18 Sep '13

Hi, How to set the FreeSwitch to NOT send the ptime attribute in SDP part, that is the a=ptime:20 not show up in the SDP message. Thanks, Ashou Han

7 9

Gregory Alan Dunn & Brian K West, after 18 years, are getting married!
by Raymond Chandler 18 Sep '13

18 Sep '13

Friends, As some of you may have heard by now, our very own Brian K West (a.k.a. bkw_) is going to be marrying the love of his life, Gregory A Dunn. The ceremony will be held on October 7th in NYC. Please join with us all in congratulating him and his spouse to be. For those of you who would like to help out with the costs of the planning and ceremony, or would just like to send them a gift, his paypal address is brian(a)bkw.org. No gift is too small (or too large ;-)) If you're in, or around, NYC on the 6th or 7th, we'd entertain the idea of having a FreeSWITCH Users' dinner somewhere in the area on one of those two nights if there's enough interest. Feel free to email me privately (at weddingplanner(a)freeswitch.org) if you'll be in the area and interested in congratulating them, in person, over dinner. -Ray

7 12

Hey Guys Don¹t forget the Weekly Call today!
by Ken Rice 18 Sep '13

18 Sep '13

Hey Guys, Todays FreeSWITCH call, Building Packages, Other announcements, and Jira! On the Building Packages I will be talking how to build your own RPMs and how to roll your own Debian packages. We¹ll also have Travis Cross with us to talk about how the packaging works so you can target a specific platform without too much trouble. So Join us at 1P Eastern in the normal spots! sip:888@conference.freeswitch.org. -- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch

1 0

Softphone behind NAT registers but cannot be dialed
by Maciej Aniserowicz 18 Sep '13

18 Sep '13

Hi, I have a "NAT situation":). My FS machine is not behind NAT, but one of the softphones (Twinkle) is. It registers correctly, but after viewing registrations on the profile I do not see any NAT-related info in Contact header. I cannot dial to this extension, I get this after ~30sec: -ERR RECOVERY_ON_TIMER_EXPIRE The interesting thing is that when I execute this command: acl <external IP of network with Twinkle> localnet.auto it returns true. I tried removing this line from profile configuration, but it did not change anything: <param name="local-network-acl" value="localnet.auto"/>. I also defined my own ACL <list name="nat.twinkle" default="allow"> <node type="allow" cidr="<IP>/32"/> </list> and applied it to the profile: <param name="apply-nat-acl" value="nat.twinkle"/> Still - no luck. I even tried to enable aggressive-nat-detection even though it's not recommended, but I did not change anything. I restarted FS after each configuration modification, then flushed all registrations on the profile and re-registered my softphones. How else can I try to solve this issue? And one more question: is there any way to view the autogenerated ACLs localnet.auto and nat.auto ? Best regards, Maciej Aniserowicz

2 1

Re: [Freeswitch-users] OpenSIPs + Freeswitch + Registrations
by Chris B. Ware 18 Sep '13

18 Sep '13

Steven, I already use db on sip profiles, switch.conf. Have you a working situation where a register received from FS box 2 is known to FS box 1? As I said "show registrations" work but sofia_contact not. My solution has been a lua script to retrive url from db.

3 3

Re: [Freeswitch-users] H323 trunks
by Jeff Leung 18 Sep '13

18 Sep '13

see yate Shishko <shishko69(a)gmail.com> wrote: Sure, I did it successfully using mod_h323. http://wiki.freeswitch.org/wiki/Mod_h323 Denis On Sri, 2013-09-18 at 12:50 +0100, Richard Mace wrote: > Hi all, we have an existing traditional PBX which supports h323. Would > it be possible to have multiple sip phones talking to freeSWITCH and > the h323 trunks going from freeSWITCH to the traditional PBX, which > would then route the calls out to the existing isdn trunks? > > Richard > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting(a)freeswitch.org > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.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 FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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

Bridge Failover
by Andre 18 Sep '13

18 Sep '13

HI, is there a difference in fail over for a bridge from this: <action application="bridge" data="sofia/gateway/primary/dialstring|sofia/gateway/secondary/dialstring"/> Or just adding to bridges? <action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/gateway/primary/dialstring "/> <action application="bridge" data="sofia/gateway/secondary/dialstring"/> What is the best way for failover?

4 4

Detecting voicemail in a mod_httapi-based ivr script
by Rafal Gwizdala 18 Sep '13

18 Sep '13

Hi, is it possible to use mod_avmd from mod_httapi xml scripts? I'd like the script to recognize if voicemail is being recorded and if so, play a message dedicated for that purpose. Thanks Rafal

1 1

Sporadic outbound call drops and dynamic IP address updates
by Tim Bock 18 Sep '13

18 Sep '13

Hi, Running freeswitch 1.2.12, built on Debian 7.0. My ext-rtp-ip and ext-sip-ip are set to the freeswitch stun server. The DSL modem has a dynamic IP address, and I'm not currently using a dynamic dns updater (switching to a static IP in a few weeks). I've been having a sporadic issue where outbound calls only last for 25 seconds or so, and are then dropped. The Nexvortex tech said that it was a problem with my FS pbx--that it was ignoring the Contact header and continuing to send to the proxy (66.23.129.253 in this example). I initially thought it might be some problem with the 1.3 version of freeswitch I was using, so I rebuilt using the latest stable (described above). The problem seemed to go away...for a day or so. It was back again today, and no changes were made in the interim. While I was stumbling through trying to figure out what was wrong, magically the outbound calls started behaving again. Again, I didn't touch the configuration...I was just making calls and trying to make sense of the debug info I was seeing (via wireshark and sip trace). I am fairly new to debugging SIP at this level. Below are some excerpts from the sip trace...this was a *successful* outbound call (no drop after 25 seconds). My question is: Is there any merit to what the tech said? I see in this sequence that NV sets the Contact header, but FS continues to send to the 66.23 address, though I also see in the trace that the Contact address is contained in the FS response. I also notice NV seems to be using Sonus, though I didn't see anything on the "RTP Issues" page which seemed relevant. Does anyone have any thoughts about why sometimes everything works ok and other times it doesn't? I have a second FS box (identical platform) registered with a different provider...zero problems. A second, but less pressing question: does FS automatically handle changes to a dynamic external IP address? As I'm using stun, it seems like it should, but the modem received a new address midday a few days ago, and I could no longer receive calls. A "sofia status" revealed that the external profile still showed the old external IP (and this was several hours later). I just restarted FS and everything was fine, but was wondering if I have some config parameter wrong somewhere that it didn't update on its own. Thanks for any help... Tim I fuzzed my phone #s, IPs, and some Proxy Auth info, but everything else should be as logged. recv 874 bytes from udp/[66.23.129.253]:5060 at 02:57:16.514012: ------------------------------------------------------------------------ SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 192.168.0.2:5080;rport=5080;branch=z9hG4bKF9DB405pNct2S Record-Route: <sip:66.23.129.254:5060;lr>,<sip:15136852816@66.23.129.253:5060;nat=y es;ftag=r011rpa0Syg0S;lr=on> From: "Kitchen Angels" <sip:15054717780@px3.nexvortex.com>;tag=r011rpa0Syg0S To: <sip:15136852816@px3.nexvortex.com>;tag=gK07d8165c Call-ID: dcb948b2-9ab0-1231-c297-001cc0382911 CSeq: 49400454 INVITE Contact: <sip:72.15.219.140;did=27d.e851d0a3> Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Content-Length: 235 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 17065 29458 IN IP4 208.79.54.210 s=SIP Media Capabilities c=IN IP4 208.79.54.212 t=0 0 m=audio 18928 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 recv 1034 bytes from udp/[66.23.129.253]:5060 at 02:57:21.804773: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.2:5080;rport=5080;branch=z9hG4bKF9DB405pNct2S Record-Route: <sip:66.23.129.254:5060;lr>,<sip:15136852816@66.23.129.253:5060;nat=y es;ftag=r011rpa0Syg0S;lr=on> From: "Bob" <sip:15136857780@px3.nexvortex.com>;tag=r011rpa0Syg0S To: <sip:15136852816@px3.nexvortex.com>;tag=gK07d8165c Call-ID: dcb948b2-9ab0-1231-c297-001cc0382911 CSeq: 49400454 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay , multipart/mixed Contact: <sip:72.15.219.140;did=27d.e851d0a3> Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Require: timer Supported: timer Session-Expires: 1800;refresher=uac Content-Length: 235 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 17065 29458 IN IP4 208.79.54.210 s=SIP Media Capabilities c=IN IP4 208.79.54.212 t=0 0 m=audio 18928 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 send 774 bytes to udp/[66.23.129.253]:5060 at 02:57:21.811091: ------------------------------------------------------------------------ ACK sip:72.15.219.140;did=27d.e851d0a3 SIP/2.0 Via: SIP/2.0/UDP 175.29.62.55:5080;rport;branch=z9hG4bKgj735UptjNgNN Route: <sip:15136852816@66.23.129.253:5060;nat=yes;ftag=r011rpa0Syg0S;lr=on> Route: <sip:66.23.129.254:5060;lr> Max-Forwards: 70 From: "Bob" <sip:15136857780@px3.nexvortex.com>;tag=r011rpa0Syg0S To: <sip:15136852816@px3.nexvortex.com>;tag=gK07d8165c Call-ID: dcb948b2-9ab0-1231-c297-001cc0382911 CSeq: 49400454 ACK Contact: <sip:gw+nexvortex-main@175.29.62.55:5080;transport=udp;gw=nexvortex-main> Proxy-Authorization: Digest username="dummy", realm="nexvortex.com", nonce="U jkXvFI5FpDt+8Hzk/viti", algorithm=MD5, uri="sip:15136852816@px3.nexvortex.co m", response="20200d7ccb42e873a3f4e16c8f9d9de9" Content-Length: 0 send 1033 bytes to udp/[66.23.129.253]:5060 at 02:58:13.951291: ------------------------------------------------------------------------ BYE sip:72.15.219.140;did=27d.e851d0a3 SIP/2.0 Via: SIP/2.0/UDP 175.29.62.55:5080;rport;branch=z9hG4bKHU0v7p7XFy67g Route: <sip:15136852816@66.23.129.253:5060;nat=yes;ftag=r011rpa0Syg0S;lr=on> Route: <sip:66.23.129.254:5060;lr> Max-Forwards: 70 From: "Bob" <sip:15136857780@px3.nexvortex.com>;tag=r011rpa0Syg0S To: <sip:15136852816@px3.nexvortex.com>;tag=gK07d8165c Call-ID: dcb948b2-9ab0-1231-c297-001cc0382911 CSeq: 49400455 BYE Contact: <sip:gw+nexvortex-main@175.29.62.55:5080;transport=udp;gw=nexvortex-main> User-Agent: FreeSWITCH-mod_sofia/1.2.12+git~20130826T225725Z~4990a541bf Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, N OTIFY Supported: timer, precondition, path, replaces Proxy-Authorization: Digest username="dummy", realm="nexvortex.com", nonce="U jkXvFI5FpDt+8Hzk/viti", algorithm=MD5, uri="sip:72.15.219.140;did=27d.e851d0 a3", response="3561a42f5bfa281fad3f39077534732d" Reason: Q.850;cause=16;text="NORMAL_CLEARING" Content-Length: 0 -- Tim Bock Synacktics, LLC www.synacktics.com

1 0

inherit_codec failing with pre-media
by sangdrax8 17 Sep '13

17 Sep '13

I pulled the latest freeswitch from git this morning, and am still having issues using inherit_codec=true. It seems the only way I can get it to defer to the choice of the b-leg call is to remove the ringback, and thus the need for early media. My setup has 2 phones with the following codecs configured: phone1000: g722, ulaw phone1001: ulaw My goal is to have a call initiated by phone1000 (a-leg) to defer the codec choice until phone1001 (b-leg) chooses one. This would allow them to talk with no transcoding required by freeswitch. With the following dial plan, this fails to work. <extension name="Local_Extension"> <condition field="destination_number" expression="^(10[01][0-9])$"> <action application="export" data="dialed_extension=$1"/> <action application="set" data="ringback=${us-ring}"/> <action application="set" data="transfer_ringback=$${hold_music}"/> <action application="set" data="call_timeout=30"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="inherit_codec=true" /> <action application="bridge" data="user/${dialed_extension}@${domain_name}"/> </condition> </extension> It does log that it is going to defer: 2013-09-17 13:15:10.956535 [DEBUG] mod_sofia.c:4542 [zrtp_passthru] Setting a-leg inherit_codec=true 2013-09-17 13:15:10.956535 [DEBUG] mod_sofia.c:4545 [zrtp_passthru] Setting b-leg absolute_codec_string='G722@8000h@20i@64000b,PCMU@8000h@20i@64000b' then it tries to provide the ringback for the a-leg, and it negotiates to g722 since freeswitch supports that and it is the first match. Later when the b-leg is answered, it also negotiates, this time to ulaw as that is all b supports. My call completes, but freeswitch has to transcode between the two. In an attempt to see inherit_codec work, I then commented out the ringback line from the above dialplan. With only this one change, freeswitch now waits until the b-leg negotiation, and passes that back to the a-leg. The call completes and both handsets are using ulaw and no transcoding is required. The problem being that the calling party never gets a ring while waiting. I can't imagine that the only way to use inherit_codec=true is with all ringing turned off. Can someone tell me if there is an additional option I am missing? All documentation I read seems to indicate that just adding "inherit_codec=true" will fix things, but even the default.xml provided as an example uses ringback and therefore fails.

1 0