November 2009 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Call Transfer Help Please
by Dave Stevenson 25 Nov '09

25 Nov '09

Hi, I'm trying to setup call transfer for a phone without a transfer button. I was on IRC last night and got some pointers to how this is setup in dialplan.xml and features.xml and what "bind meta app" does. Once it became clear how the transfer is initiated and that the transfer, in the default config, can only be initiated by the "b" leg of the call, I was able to make this work as configured in the defaults, i.e, to initiate a transfer (for an internal call) from the dialled extension to a new extension. Now the problem . . . I have an incoming PSTN line that rings a group of extensions, what I want to be able to do is to give whoever answers the PSTN call ability to transfer the call on to another extension. There is an ATA (Linksys SPA3101) set up on the PSTN line with a FreeSwitch extension of 1000, it rings the extension phones in the group. I'd hoped that the default transfer setup would handle this without modification - the incoming call on extension 1000 would be the "a" leg, the answering extension would be the "b" leg and a transfer from "b" would work as per the default config. This does not work for me though. I'm struggling a bit with the "bind meta app" options and can't seem to make it do what I want. Could someone please confirm that what I'm trying to do is feasible and perhaps suggest the right parameters to use in dialplan.xml and features.xml please ? Relevant section in the "is_transfer" section in features.xml <action application="transfer" data="-bleg ${digits} XML default"/> And in default.xml from <action application="bind_meta_app" data="1 b s execute_extension::dx XML features"/> to I've tried posting a call log to the Pastebin (11252/3) but there was an error - it looks like the dump was too big. Not sure what the maximum size on pastebin dumps is ? My understanding (or lack of) of "a" and "b" are in the scenario described is not helping ... Is the "a" leg the call coming in on the PSTN line (on Ext 1000) ? Is the answering extension the "b" leg ? What are the correct LISTEN_TO and RESPOND_ON entries in dialplan.xml ? What is the correct "transfer" data string in features.xml ? Or am I totally on the wrong track here ? If it is possible to do what I want, and changes are required to the dialplan.xml and/or features.xml files, is it possible to have different logic in there such that the actions are different whether it is the "a" leg or "b" leg that's requesting the transfer ? regards Dave FreeSwitch Version 1.0.4 (14460)

3 5

How Register soft sip phones to FreeSWITCH with extension number.
by ovvenkat 25 Nov '09

25 Nov '09

Hi to All, Any one please tell me , How to configure soft sip phone to freeswitch with extension number. -- If you have come to help me, you are wasting your time. If you have come to because your liberation is bound up in mine, we can work together. Regards Venkatesan OV.

2 1

How to connect SIP phone to freeswitch
by ovvenkat 25 Nov '09

25 Nov '09

Hi . Could you please tell me, How to connect sip phone (which one is more friendly with freeswitch) to freeswitch. How I can check whether connection is properly established or not? -- If you have come to help me, you are wasting your time. If you have come to because your liberation is bound up in mine, we can work together. Regards Venkatesan OV.

2 1

register timeout / cisco 7960
by Phillip Jones 25 Nov '09

25 Nov '09

hi there, I have set up some cisco 7960 up with fs. They work fine - but the only way I can keep them registered is to set the "timer_register_expires" in the Cisco cfg file to something really short like 10s. Does anyone know the default register timeout for fs? And where I might change this in fs? Thanks! Phil

2 1

Call forwarding problem
by John Platts 24 Nov '09

24 Nov '09

I was having trouble doing call forwarding from my SIP phone that is connected to FreeSWITCH. It turns out that my SIP phone is actually sending 302 Moved Temporarily responses, but my SIP gateway does not support 302 Moved Temporarily or SIP REFER messages. How do I get FreeSWITCH to forward calls without sending 302 Moved Temporarily or SIP REFER messages? Here is the SIP debug from our gateway: Received: INVITE sip:+19725357722@ipipgw.ipdimensions.com:5060;user=phone;transport=UDP;maddr=168.75.202.246 SIP/2.0 v: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bKe19865e46222056ca70435e66fde4127.19be3eb0 Record-Route: <sip:65.243.172.245:5060;lr> v: SIP/2.0/UDP 63.77.76.236:5060;branch=z9hG4bK3f49bc4eb4ac163ffa354de0e6384d30.12e7ffbd;received=63.77.76.236 record-route: <sip:63.77.76.236;lr> f: <sip:+19729555871@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3ec95a-3ad03068-3ec95a t: <sip:+19725357722@63.77.76.236:5060;user=phone> i: a1f37fb0d065adc713c43ec95af54289baa8ec2034c293850-0569-7989 CSeq: 1 INVITE Max-Forwards: 18 k: 100rel, replaces allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK v: SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3ec95a-f54289ba-139ab2d1;received=199.173.101.208 m: <sip:199.173.101.208:5060;transport=UDP> c: application/SDP l: 210 P-Asserted-Identity: <sip:9729555871@63.77.76.236;user=phone> Privacy: none v=0 o=- 540754816 540754816 IN IP4 199.173.111.141 s=- c=IN IP4 199.173.111.141 t=0 0 m=audio 30056 RTP/AVP 18 0 8 101 a=ptime:20 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Nov 24 15:08:00.367 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 100 Trying Via: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bKe19865e46222056ca70435e66fde4127.19be3eb0,SIP/2.0/UDP 63.77.76.236:5060;branch=z9hG4bK3f49bc4eb4ac163ffa354de0e6384d30.12e7ffbd;received=63.77.76.236,SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3ec95a-f54289ba-139ab2d1;received=199.173.101.208 From: <sip:+19729555871@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3ec95a-3ad03068-3ec95a To: <sip:+19725357722@63.77.76.236:5060;user=phone> Date: Tue, 24 Nov 2009 21:08:00 GMT Call-ID: a1f37fb0d065adc713c43ec95af54289baa8ec2034c293850-0569-7989 CSeq: 1 INVITE Allow-Events: telephone-event Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Nov 24 15:08:00.367 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:19725357722@168.75.202.212:5062 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK6821870 From: <sip:19729555871@168.75.202.246>;tag=14E93594-2488 To: <sip:19725357722@168.75.202.212> Date: Tue, 24 Nov 2009 21:08:00 GMT Call-ID: 4802BACC-D87411DE-AC70D9DF-3419A306(a)168.75.202.246 Supported: timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 1208058493-3631485406-2892683743-874095366 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1259096880 Contact: <sip:19729555871@168.75.202.246:5060> Expires: 180 Allow-Events: telephone-event Max-Forwards: 17 P-Asserted-Identity: <sip:19729555871@168.75.202.246> Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 314 v=0 o=CiscoSystemsSIP-GW-UserAgent 2925 1780 IN IP4 168.75.202.246 s=SIP Call c=IN IP4 199.173.111.141 t=0 0 m=audio 30056 RTP/AVP 18 0 8 101 c=IN IP4 199.173.111.141 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Nov 24 15:08:00.367 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK6821870 From: <sip:19729555871@168.75.202.246>;tag=14E93594-2488 To: <sip:19725357722@168.75.202.212> Call-ID: 4802BACC-D87411DE-AC70D9DF-3419A306(a)168.75.202.246 CSeq: 101 INVITE Timestamp: 1259096880 0.000342 User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15654M Content-Length: 0 Nov 24 15:08:00.419 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK6821870 From: <sip:19729555871@168.75.202.246>;tag=14E93594-2488 To: <sip:19725357722@168.75.202.212>;tag=49aF8vtgHme2c Call-ID: 4802BACC-D87411DE-AC70D9DF-3419A306(a)168.75.202.246 CSeq: 101 INVITE User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15654M Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, refer Reason: Q.850;cause=16;text="NORMAL_CLEARING" Content-Length: 0 P-Asserted-Identity: "19725357722" <sip:19725357722@168.75.202.212> Nov 24 15:08:00.427 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:19725357722@168.75.202.212:5062 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK6821870 From: <sip:19729555871@168.75.202.246>;tag=14E93594-2488 To: <sip:19725357722@168.75.202.212>;tag=49aF8vtgHme2c Date: Tue, 24 Nov 2009 21:08:00 GMT Call-ID: 4802BACC-D87411DE-AC70D9DF-3419A306(a)168.75.202.246 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: telephone-event Content-Length: 0 _________________________________________________________________ Windows 7: I wanted simpler, now it's simpler. I'm a rock star. http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PID24…

2 2

Noise with openzap
by Steven Brown 24 Nov '09

24 Nov '09

Hi, I have an Ubuntu box running FS1.0.4 which has been processing a good volume of calls between local users with soft phones (Xlite) and GSM handsets via a number or Portech gateways, this has worked very well for some time and audio quality is very good. I've now added a Sangoma A200 with 4 ports hooked up to 4 PSTN lines, configured openzap and I can originate and answer calls on the the openzap lines fine, however these calls via opezap all seem to suffer from significant noise, the audio path works fine in both directions but noise seems particularly bad at the local soft phone end. Quality of all other calls through the box is fine though, any ideas appreciated ?, NB A regular handset plugged directly into the PSTN lines has no problems though Thanks Steve

2 1

Problems with proxy media and bypass media in FreeSWITCH
by John Platts 24 Nov '09

24 Nov '09

I actually checked out the latest version of FreeSWITCH in the SVN repository. I have the following configured in /usr/local/freeswitch/conf/dialplan/default.xml: <extension name="setup_media" continue="true"> <condition field="${sip_nat_detected}" expression="true"> <action application="set" data="proxy_media=true" /> <action application="set" data="bypass_media=false" /> <anti-action application="set" data="proxy_media=false" /> <anti-action application="set" data="bypass_media=true" /> </condition> </extension> I have the following configured in /usr/local/freeswitch/conf/vars.xml: <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G729,iLBC@20i,G722,PCMU,PCMA"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=G729,iLBC@20i,G722,PCMU,PCMA"/> Here is the SIP trace for the failing call: Nov 23 17:55:05.245 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:+19725357722@ipipgw.ipdimensions.com:5060;user=phone;transport=UDP;maddr=168.75.202.246 SIP/2.0 v: SIP/2.0/UDP 65.211.120.237:5060;branch=z9hG4bKec920f9119165c414d2f6229bb6a76ac.8e1ce24 Record-Route: <sip:65.211.120.237:5060;lr> v: SIP/2.0/UDP 63.77.76.236:5060;branch=z9hG4bK19a30c0f46372620ff158f019d0ce5df.24ee0396;received=63.77.76.236 record-route: <sip:63.77.76.236;lr> f: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3d9f0a-5460a3be-3d9f0a t: <sip:+19725357722@63.77.76.236:5060;user=phone> i: a14d9878d065adc713c43d9f0af0b542beb67295e9c2c7438-0569-6585 CSeq: 1 INVITE Max-Forwards: 16 k: 100rel, replaces allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK v: SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3d9f0a-f0b542be-62e0db38;received=199.173.101.208 m: <sip:199.173.101.208:5060;transport=UDP> c: application/SDP l: 210 P-Asserted-Identity: <sip:9729831777@63.77.76.236;user=phone> Privacy: none v=0 o=- 641026559 641026559 IN IP4 199.173.111.147 s=- c=IN IP4 199.173.111.147 t=0 0 m=audio 33344 RTP/AVP 18 0 8 101 a=ptime:20 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Nov 23 17:55:05.257 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 100 Trying Via: SIP/2.0/UDP 65.211.120.237:5060;branch=z9hG4bKec920f9119165c414d2f6229bb6a76ac.8e1ce24,SIP/2.0/UDP 63.77.76.236:5060;branch=z9hG4bK19a30c0f46372620ff158f019d0ce5df.24ee0396;received=63.77.76.236,SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3d9f0a-f0b542be-62e0db38;received=199.173.101.208 From: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3d9f0a-5460a3be-3d9f0a To: <sip:+19725357722@63.77.76.236:5060;user=phone> Date: Mon, 23 Nov 2009 23:55:05 GMT Call-ID: a14d9878d065adc713c43d9f0af0b542beb67295e9c2c7438-0569-6585 CSeq: 1 INVITE Allow-Events: telephone-event Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Nov 23 17:55:05.257 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:19725357722@168.75.202.212:5062 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK659A1F3 From: <sip:19729831777@168.75.202.246>;tag=105BD148-201C To: <sip:19725357722@168.75.202.212> Date: Mon, 23 Nov 2009 23:55:05 GMT Call-ID: 74E5B003-D7C211DE-A29AD9DF-3419A306(a)168.75.202.246 Supported: timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 1961129755-3619819998-2727664095-874095366 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1259020505 Contact: <sip:19729831777@168.75.202.246:5060> Expires: 180 Allow-Events: telephone-event Max-Forwards: 15 P-Asserted-Identity: <sip:19729831777@168.75.202.246> Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 314 v=0 o=CiscoSystemsSIP-GW-UserAgent 5041 5861 IN IP4 168.75.202.246 s=SIP Call c=IN IP4 199.173.111.147 t=0 0 m=audio 33344 RTP/AVP 18 0 8 101 c=IN IP4 199.173.111.147 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Nov 23 17:55:05.261 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK659A1F3 From: <sip:19729831777@168.75.202.246>;tag=105BD148-201C To: <sip:19725357722@168.75.202.212> Call-ID: 74E5B003-D7C211DE-A29AD9DF-3419A306(a)168.75.202.246 CSeq: 101 INVITE Timestamp: 1259020505 0.000345 User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Content-Length: 0 Nov 23 17:55:05.309 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK659A1F3 From: <sip:19729831777@168.75.202.246>;tag=105BD148-201C To: <sip:19725357722@168.75.202.212>;tag=DFKSy9Q5DK1Na Call-ID: 74E5B003-D7C211DE-A29AD9DF-3419A306(a)168.75.202.246 CSeq: 101 INVITE Contact: <sip:19725357722@168.75.202.212:5062;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, refer Content-Length: 0 P-Asserted-Identity: "19725357722" <sip:19725357722@168.75.202.212> Nov 23 17:55:05.309 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 65.211.120.237:5060;branch=z9hG4bKec920f9119165c414d2f6229bb6a76ac.8e1ce24,SIP/2.0/UDP 63.77.76.236:5060;branch=z9hG4bK19a30c0f46372620ff158f019d0ce5df.24ee0396;received=63.77.76.236,SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3d9f0a-f0b542be-62e0db38;received=199.173.101.208 From: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3d9f0a-5460a3be-3d9f0a To: <sip:+19725357722@63.77.76.236:5060;user=phone>;tag=105BD180-BD7 Date: Mon, 23 Nov 2009 23:55:05 GMT Call-ID: a14d9878d065adc713c43d9f0af0b542beb67295e9c2c7438-0569-6585 CSeq: 1 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Contact: <sip:19725357722@168.75.202.246:5060> Record-Route: <sip:65.211.120.237:5060;lr>,<sip:63.77.76.236;lr> Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Nov 23 17:55:08.397 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK659A1F3 From: <sip:19729831777@168.75.202.246>;tag=105BD148-201C To: <sip:19725357722@168.75.202.212>;tag=DFKSy9Q5DK1Na Call-ID: 74E5B003-D7C211DE-A29AD9DF-3419A306(a)168.75.202.246 CSeq: 101 INVITE Contact: <sip:19725357722@168.75.202.212:5062;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, refer Min-SE: 1800 Content-Type: application/sdp Content-Disposition: session Content-Length: 202 P-Asserted-Identity: "19725357722" <sip:19725357722@168.75.202.212> v=0 o=- 211627 211627 IN IP4 192.168.1.4 s=- c=IN IP4 173.57.44.212 t=0 0 m=audio 0 RTP/AVP 96 101 a=rtpmap:96 G729a/8000 a=fmtp:96 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Nov 23 17:55:08.397 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:19725357722@168.75.202.212:5062;transport=udp SIP/2.0 Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK659B6A From: <sip:19729831777@168.75.202.246>;tag=105BD148-201C To: <sip:19725357722@168.75.202.212>;tag=DFKSy9Q5DK1Na Date: Mon, 23 Nov 2009 23:55:05 GMT Call-ID: 74E5B003-D7C211DE-A29AD9DF-3419A306(a)168.75.202.246 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: telephone-event Content-Length: 0 Nov 23 17:55:08.397 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: BYE sip:19725357722@168.75.202.212:5062;transport=udp SIP/2.0 Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK659C1B3D From: <sip:19729831777@168.75.202.246>;tag=105BD148-201C To: <sip:19725357722@168.75.202.212>;tag=DFKSy9Q5DK1Na Date: Mon, 23 Nov 2009 23:55:05 GMT Call-ID: 74E5B003-D7C211DE-A29AD9DF-3419A306(a)168.75.202.246 User-Agent: Cisco-SIPGateway/IOS-12.x Max-Forwards: 70 P-Asserted-Identity: <sip:19729831777@168.75.202.246> Timestamp: 1259020508 CSeq: 102 BYE Reason: Q.850;cause=65 Content-Length: 0 Nov 23 17:55:08.401 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK659C1B3D From: <sip:19729831777@168.75.202.246>;tag=105BD148-201C To: <sip:19725357722@168.75.202.212>;tag=DFKSy9Q5DK1Na Call-ID: 74E5B003-D7C211DE-A29AD9DF-3419A306(a)168.75.202.246 CSeq: 102 BYE Timestamp: 1259020508 0.000093 User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Content-Length: 0 Nov 23 17:55:08.401 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK659C1B3D From: <sip:19729831777@168.75.202.246>;tag=105BD148-201C To: <sip:19725357722@168.75.202.212>;tag=DFKSy9Q5DK1Na Call-ID: 74E5B003-D7C211DE-A29AD9DF-3419A306(a)168.75.202.246 CSeq: 102 BYE User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Length: 0 The SIP call actually fails. If I remove the following from /usr/local/freeswitch/conf/dialplan/default.xml: <extension name="setup_media" continue="true"> <condition field="${sip_nat_detected}" expression="true"> <action application="set" data="proxy_media=true" /> <action application="set" data="bypass_media=false" /> <anti-action application="set" data="proxy_media=false" /> <anti-action application="set" data="bypass_media=true" /> </condition> </extension> And I change this line in /usr/local/freeswitch/conf/vars.xml from <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G729,iLBC@20i,G722,PCMU,PCMA"/> to <X-PRE-PROCESS cmd="set" data="global_codec_prefs=iLBC@20i,G722,PCMU,PCMA"/> And I change this line in /usr/local/freeswitch/conf/vars.xml from <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=G729,iLBC@20i,G722,PCMU,PCMA"/> to <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=iLBC@20i,G722,PCMU,PCMA"/> both inbound and outbound calls succeed. Here is a SIP trace of a successful call after I apply the above changes: Nov 23 18:16:51.844 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:+19725357722@ipipgw.ipdimensions.com:5060;user=phone;transport=UDP;maddr=168.75.202.246 SIP/2.0 v: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bK1d6dd953ef66469db06038ec3bd2ec49.6fb41dbb Record-Route: <sip:65.243.172.245:5060;lr> v: SIP/2.0/UDP 65.217.40.205:5060;branch=z9hG4bK74e3354e4bab8f6d8afec83d314c15b8.6f41c9d4;received=65.217.40.205 record-route: <sip:65.217.40.205;lr> f: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3da425-183eff65-3da425 t: <sip:+19725357722@65.217.40.205:5060;user=phone> i: 9fffb808d065adc713c43da425f0c931a91220c864c201e88-0568-4457 CSeq: 1 INVITE Max-Forwards: 16 k: 100rel, replaces allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK v: SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3da425-f0c931a9-52a4c353;received=199.173.101.208 m: <sip:199.173.101.208:5060;transport=UDP> c: application/SDP l: 210 P-Asserted-Identity: <sip:9729831777@65.217.40.205;user=phone> Privacy: none v=0 o=- 654094598 654094598 IN IP4 199.173.111.138 s=- c=IN IP4 199.173.111.138 t=0 0 m=audio 31456 RTP/AVP 18 0 8 101 a=ptime:20 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Nov 23 18:16:51.852 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 100 Trying Via: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bK1d6dd953ef66469db06038ec3bd2ec49.6fb41dbb,SIP/2.0/UDP 65.217.40.205:5060;branch=z9hG4bK74e3354e4bab8f6d8afec83d314c15b8.6f41c9d4;received=65.217.40.205,SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3da425-f0c931a9-52a4c353;received=199.173.101.208 From: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3da425-183eff65-3da425 To: <sip:+19725357722@65.217.40.205:5060;user=phone> Date: Tue, 24 Nov 2009 00:16:51 GMT Call-ID: 9fffb808d065adc713c43da425f0c931a91220c864c201e88-0568-4457 CSeq: 1 INVITE Allow-Events: telephone-event Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Nov 23 18:16:51.856 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:19725357722@168.75.202.212:5062 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK65AD9D0 From: <sip:19729831777@168.75.202.246>;tag=106FC130-1578 To: <sip:19725357722@168.75.202.212> Date: Tue, 24 Nov 2009 00:16:51 GMT Call-ID: 7FB1015E-D7C511DE-A2CCD9DF-3419A306(a)168.75.202.246 Supported: timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 2142226702-3620016606-2730940895-874095366 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1259021811 Contact: <sip:19729831777@168.75.202.246:5060> Expires: 180 Allow-Events: telephone-event Max-Forwards: 15 P-Asserted-Identity: <sip:19729831777@168.75.202.246> Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 314 v=0 o=CiscoSystemsSIP-GW-UserAgent 9668 3852 IN IP4 168.75.202.246 s=SIP Call c=IN IP4 199.173.111.138 t=0 0 m=audio 31456 RTP/AVP 18 0 8 101 c=IN IP4 199.173.111.138 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Nov 23 18:16:51.856 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK65AD9D0 From: <sip:19729831777@168.75.202.246>;tag=106FC130-1578 To: <sip:19725357722@168.75.202.212> Call-ID: 7FB1015E-D7C511DE-A2CCD9DF-3419A306(a)168.75.202.246 CSeq: 101 INVITE Timestamp: 1259021811 0.000356 User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Content-Length: 0 Nov 23 18:16:51.908 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK65AD9D0 From: <sip:19729831777@168.75.202.246>;tag=106FC130-1578 To: <sip:19725357722@168.75.202.212>;tag=mXNXUN859rKBa Call-ID: 7FB1015E-D7C511DE-A2CCD9DF-3419A306(a)168.75.202.246 CSeq: 101 INVITE Contact: <sip:19725357722@168.75.202.212:5062;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, refer Content-Length: 0 P-Asserted-Identity: "19725357722" <sip:19725357722@168.75.202.212> Nov 23 18:16:51.908 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bK1d6dd953ef66469db06038ec3bd2ec49.6fb41dbb,SIP/2.0/UDP 65.217.40.205:5060;branch=z9hG4bK74e3354e4bab8f6d8afec83d314c15b8.6f41c9d4;received=65.217.40.205,SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3da425-f0c931a9-52a4c353;received=199.173.101.208 From: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3da425-183eff65-3da425 To: <sip:+19725357722@65.217.40.205:5060;user=phone>;tag=106FC168-50D Date: Tue, 24 Nov 2009 00:16:51 GMT Call-ID: 9fffb808d065adc713c43da425f0c931a91220c864c201e88-0568-4457 CSeq: 1 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Contact: <sip:19725357722@168.75.202.246:5060> Record-Route: <sip:65.243.172.245:5060;lr>,<sip:65.217.40.205;lr> Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Nov 23 18:16:54.408 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK65AD9D0 From: <sip:19729831777@168.75.202.246>;tag=106FC130-1578 To: <sip:19725357722@168.75.202.212>;tag=mXNXUN859rKBa Call-ID: 7FB1015E-D7C511DE-A2CCD9DF-3419A306(a)168.75.202.246 CSeq: 101 INVITE Contact: <sip:19725357722@168.75.202.212:5062;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, refer Min-SE: 1800 Content-Type: application/sdp Content-Disposition: session Content-Length: 251 P-Asserted-Identity: "19725357722" <sip:19725357722@168.75.202.212> v=0 o=FreeSWITCH 1259003870 1259003871 IN IP4 168.75.202.212 s=FreeSWITCH c=IN IP4 168.75.202.212 t=0 0 m=audio 17544 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 Nov 23 18:16:54.412 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:19725357722@168.75.202.212:5062;transport=udp SIP/2.0 Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK65AE109A From: <sip:19729831777@168.75.202.246>;tag=106FC130-1578 To: <sip:19725357722@168.75.202.212>;tag=mXNXUN859rKBa Date: Tue, 24 Nov 2009 00:16:51 GMT Call-ID: 7FB1015E-D7C511DE-A2CCD9DF-3419A306(a)168.75.202.246 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: telephone-event Content-Length: 0 Nov 23 18:16:54.412 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bK1d6dd953ef66469db06038ec3bd2ec49.6fb41dbb,SIP/2.0/UDP 65.217.40.205:5060;branch=z9hG4bK74e3354e4bab8f6d8afec83d314c15b8.6f41c9d4;received=65.217.40.205,SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3da425-f0c931a9-52a4c353;received=199.173.101.208 From: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3da425-183eff65-3da425 To: <sip:+19725357722@65.217.40.205:5060;user=phone>;tag=106FC168-50D Date: Tue, 24 Nov 2009 00:16:51 GMT Call-ID: 9fffb808d065adc713c43da425f0c931a91220c864c201e88-0568-4457 CSeq: 1 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Contact: <sip:19725357722@168.75.202.246:5060> Record-Route: <sip:65.243.172.245:5060;lr>,<sip:65.217.40.205;lr> Supported: replaces Server: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 253 v=0 o=CiscoSystemsSIP-GW-UserAgent 7353 3710 IN IP4 168.75.202.246 s=SIP Call c=IN IP4 168.75.202.212 t=0 0 m=audio 17544 RTP/AVP 0 101 c=IN IP4 168.75.202.212 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 Nov 23 18:16:54.492 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: ACK sip:19725357722@168.75.202.246:5060 SIP/2.0 v: SIP/2.0/UDP 65.243.172.245:5060;branch=z9hG4bKb17fac77c446113b9154e16639d30287.6be1820d v: SIP/2.0/UDP 65.217.40.205:5060;branch=z9hG4bK99af095cadf31f4291c6a809ef6a6e03.7c44d9fc;received=65.217.40.205 f: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3da425-183eff65-3da425 t: <sip:+19725357722@65.217.40.205:5060;user=phone>;tag=106FC168-50D i: 9fffb808d065adc713c43da425f0c931a91220c864c201e88-0568-4457 CSeq: 1 ACK user-agent: CS2000_NGSS/9.0 Max-Forwards: 68 k: 100rel,replaces allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK v: SIP/2.0/UDP DAL4:5060;maddr=199.173.101.208;branch=z9hG4bK-3da428-f0c93cc6-61239372;received=199.173.101.208 m: <sip:199.173.101.208:5060;transport=UDP> l: 0 Nov 23 18:17:00.636 CST: %FAN-3-FAN_FAILED: Fan 1 had a rotation error reported. Nov 23 18:17:06.748 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: BYE sip:19729831777@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKmNaaUQK5vrpXQ Max-Forwards: 70 From: <sip:19725357722@168.75.202.212>;tag=mXNXUN859rKBa To: <sip:19729831777@168.75.202.246>;tag=106FC130-1578 Call-ID: 7FB1015E-D7C511DE-A2CCD9DF-3419A306(a)168.75.202.246 CSeq: 123392377 BYE Contact: <sip:19725357722@168.75.202.212:5062;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15586M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Reason: Q.850;cause=16;text="NORMAL_CLEARING" Content-Length: 0 Nov 23 18:17:06.748 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKmNaaUQK5vrpXQ From: <sip:19725357722@168.75.202.212>;tag=mXNXUN859rKBa To: <sip:19729831777@168.75.202.246>;tag=106FC130-1578 Date: Tue, 24 Nov 2009 00:17:06 GMT Call-ID: 7FB1015E-D7C511DE-A2CCD9DF-3419A306(a)168.75.202.246 Server: Cisco-SIPGateway/IOS-12.x CSeq: 123392377 BYE Reason: Q.850;cause=16 Content-Length: 0 Nov 23 18:17:06.752 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: BYE sip:199.173.101.208:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 168.75.202.246:5060;branch=z9hG4bK65AF4FA From: <sip:+19725357722@65.217.40.205:5060;user=phone>;tag=106FC168-50D To: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3da425-183eff65-3da425 Date: Tue, 24 Nov 2009 00:16:54 GMT Call-ID: 9fffb808d065adc713c43da425f0c931a91220c864c201e88-0568-4457 User-Agent: Cisco-SIPGateway/IOS-12.x Max-Forwards: 70 Route: <sip:65.243.172.245:5060;lr>,<sip:65.217.40.205;lr> Timestamp: 1259021826 CSeq: 101 BYE Reason: Q.850;cause=16 Content-Length: 0 Nov 23 18:17:06.824 CST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK f: <sip:+19725357722@65.217.40.205:5060;user=phone>;tag=106FC168-50D t: <sip:+19729831777@199.173.101.208:5060;user=phone>;tag=dc7-13c4-3da425-183eff65-3da425 i: 9fffb808d065adc713c43da425f0c931a91220c864c201e88-0568-4457 CSeq: 101 BYE server: CS2000_NGSS/9.0 allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK v: SIP/2.0/UDP 168.75.202.246:5060;received=168.75.202.246;branch=z9hG4bK65AF4FA l: 0 I compared the SIP messaging from the failed call to the SIP messaging from the good call. Both calls are inbound calls. Here is the session description for the failed inbound call: v=0 o=- 211627 211627 IN IP4 192.168.1.4 s=- c=IN IP4 173.57.44.212 t=0 0 m=audio 0 RTP/AVP 96 101 a=rtpmap:96 G729a/8000 a=fmtp:96 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Here is the session description for the good outbound call: v=0 o=FreeSWITCH 1259003870 1259003871 IN IP4 168.75.202.212 s=FreeSWITCH c=IN IP4 168.75.202.212 t=0 0 m=audio 17544 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 Here are the differences between the session descriptors of the failed call and the good call: - The c= line has the correct IP address for the failed call, which was using media bypass - The c= line has the correct IP address for the good call, because the media is being processed by FreeSWITCH in the good call - The m= line does not have the correct RTP port in the failed call - The m= line has the correct RTP port in the good call I noticed that the SDP media descriptor is incorrect in the failed call. Has this problem been fixed? I am running revision 15586 from the FreeSWITCH SVN trunk. _________________________________________________________________ Hotmail: Trusted email with Microsoft's powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141664/direct/01/ http://clk.atdmt.com/GBL/go/177141664/direct/01/

3 5

DTMF Event is not coming while using playback terminators.
by velusamy velu 24 Nov '09

24 Nov '09

Dear All, I am using Perl ESL::IVR module to develop a simple IVR. I have filtered DTMF events. I have also set playback_terminators to cut the playback when giving the digits. I have faced problem that DTMF event has not come if DTMF given while playing voice files. I have received 'COMMAND' event. I have the following questions. Why the 'COMMAND' event came event filter is on? How to avoid this event in ESL? Thanks, Velusamy

2 3

Patch to allow gateways to be defined without the password parameter set
by John Platts 24 Nov '09

24 Nov '09

I have modified sofia.c in mod_sofia so that I can define gateways without having to specify the password parameter. This is because I am using a SIP gateway that does not require SIP registration. The modified version still requires the password to be set on any gateway for which register is set to true. Attached is the diff file for these changes. _________________________________________________________________ Bing brings you maps, menus, and reviews organized in one place. http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT…

2 1

Re: [Freeswitch-users] need help !! Problem with freeswitch & uniMRCP
by Jeff Lenk 24 Nov '09

24 Nov '09

That module is not currently being built for Windows. Also the library unimrcp needs build integration work with FS to make that happen under windows. ss1 wrote: > > Hi Everyone, > > Please help freeswitch experts... !!! > > i have been working on freeswitch from last 2 days. i have downloaded > freeswitch and unimrcp (server + client) for windows. > I tested the unimrcp client and server, which is running fine with the > command: run synth and run recog. I got both synth.pcm & recog.pcm files. > > But my objective is to call Freeswitch through x-lite, where freeswitch > should call unimrcp client and return the PCM files. > > I tried it alot, but unable to do it. after lots of reading i found that i > do not have mod_unimrcp. i do not know from where to download it and how > to merge it into freeswitch. > > I would be very thankful if you may help. > > Thanks, > ss > > -- View this message in context: http://n2.nabble.com/need-help-Problem-with-freeswitch-uniMRCP-tp4031590p40… Sent from the freeswitch-users mailing list archive at Nabble.com.

4 10