May 2009 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Invite on SIP instead of TLS
by Peter P GMX 05 May '09

05 May '09

I have updated my system from SVN 10003 to 13223. I also have updated all libraries etc. Everything works fine (SIP +TLS) when calling internal numbers (conference). However calling internally registered phones does not work. Here are some facts which do not fit together - phones are sucessfully registered via TLS (ok) - debug log show that phone will be called via TLS (port 5061) (ok) - Invite message however is sent via SIP (port 5060) Please see the part of the logs below. Anybody has a clue what happened here? Best regards Peter Debug Log: ============ 2009-05-05 00:49:38 [DEBUG] sofia_glue.c:1599 sofia_glue_do_invite() sip:723329@217.xxx.xxx.186:2651 Setting proxy route to sofia/internal/sip:723329@217.xxx.xxx.186:2651;transport=TLS;rinstance=6c215161c08f55da;fs_nat=yes;fs_path=sip%3A723329%40217.xxx.xxx.186%3A2651 2009-05-05 00:49:38 [DEBUG] switch_core_state_machine.c:502 switch_core_session_run() (sofia/internal/sip:723329@217.xxx.xxx.186:2651;transport=TLS;rinstance=6c215161c08f55da;fs_nat=yes;fs_path=sip%3A723329%40217.xxx.xxx.186%3A2651) State CONSUME_MEDIA 2009-05-05 00:49:38 [DEBUG] sofia.c:2912 sofia_handle_sip_i_state() Channel sofia/internal/sip:723329@217.xxx.xxx.186:2651;transport=TLS;rinstance=6c215161c08f55da;fs_nat=yes;fs_path=sip%3A723329%40217.xxx.xxx.186%3A2651 entering state [calling][0] 2009-05-05 00:49:38 [DEBUG] sofia.c:2912 sofia_handle_sip_i_state() Channel sofia/internal/sip:723329@217.xxx.xxx.186:2651;transport=TLS;rinstance=6c215161c08f55da;fs_nat=yes;fs_path=sip%3A723329%40217.xxx.xxx.186%3A2651 entering state [terminated][503] 2009-05-05 00:49:38 [NOTICE] sofia.c:3469 sofia_handle_sip_i_state() Hangup sofia/internal/sip:723329@217.xxx.xxx.186:2651;transport=TLS;rinstance=6c215161c08f55da;fs_nat=yes;fs_path=sip%3A723329%40217.xxx.xxx.186%3A2651 [CS_CONSUME_MEDIA] [NORMAL_TEMPORARY_FAILURE] Phone is registered with TLS ============================ Call-ID: OWE1NTAyNWU0MGE2NjI1OWJhZjM1YWJiYWJjZGYzYTI. User: 723329(a)sip2.mydomain.de Contact: "723329" Agent: eyeBeam release 1102u stamp 52345 Status: Registered(TLS-NAT)(unknown) EXP(2009-05-05 00:58:03) Host: sip2.mydomain.de IP: 217.xxx.xxx.186 Port: 2651 Auth-User: 723329 Auth-Realm: sip2.mydomain.de SIP message instead of TLS message: ==================== U 217.xxx.xxx.190:5060 -> 217.xxx.xxx.186:2651 INVITE sip:723329@217.xxx.xxx.186:2651;transport=TLS;rinstance=6c215161c08f55da SIP/2.0. Via: SIP/2.0/UDP 217.xxx.xxx.190;rport;branch=z9hG4bK2tH444a02mQZc. Route: <sip:723329@217.xxx.xxx.186:2651>. Max-Forwards: 69. From: "Extension 723321" <sip:723321@217.xxx.xxx.190>;tag=HB02U2mHX28yK. To: <sip:723329@217.xxx.xxx.186:2651;transport=TLS;rinstance=6c215161c08f55da>. Call-ID: e3b50c2c-b3a0-122c-4491-001e904cc34e. CSeq: 114620396 INVITE. Contact: <sip:mod_sofia@217.xxx.xxx.190:5061;transport=tls>. User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-13223M. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO. Supported: timer, precondition, path, replaces. Allow-Events: talk, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 447. P-Key-Flags: keys="3". Remote-Party-ID: "Extension 723321" <sip:723321@217.xxx.xxx.190>;party=calling;screen=yes;privacy=off. . v=0. o=FreeSWITCH 1314931392159531063 5177685988992248857 IN IP4 217.xxx.xxx.190. s=FreeSWITCH. c=IN IP4 217.xxx.xxx.190. t=0 0. m=audio 12556 RTP/SAVP 8 9 0 98 3 101 13. a=rtpmap:8 PCMA/8000. a=rtpmap:9 G722/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:98 SPEEX/8000. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=rtpmap:13 CN/8000. a=ptime:20. a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:w/ubmPAP4I5BA1Gv1ZWZzbJkfst2e4cY7bKedcjA.

2 3

Got more 404s than should.
by seven 05 May '09

05 May '09

Hi, Please help me take a look into this: http://pastebin.freeswitch.org/8816 My problem is why the first one keep sending 404s even got the ACK? It seems that in the first test the ACK is not recognized by FS so it keep sending 404. The only difference I can see of the two ACK-404 is the first one missing a tag of TO, is that related? Shouldn't the tag optional? PS: it works OK if I dial an exists number and get answered. It only happens on unanswered messages like 404 or 503 etc. Thank you.

3 2

any way ring fifo members one by one?
by seven 05 May '09

05 May '09

Hi, I'm on trunk 13174, and route a call to fifo, but two members ring at the same time. I want it ring one by one in a round robin manner, what's wrong with me? here is fifo.xml <fifo name="sales_fifo@$${domain}" importance="0"> <member timeout="60" simo="1" lag="20">{fifo_member_wait=wait}user/1009@$${domain}</member> <member timeout="60" simo="1" lag="20">{fifo_member_wait=wait}user/1001@$${domain}</member> </fifo> We want to implement a call center where agents register to waiting customers, when a customer calls in, it will drop in a queue and search one available agent(in round robin manner). Most fifo functions seems implemented for scenarios where agents dial in and waiting callers, which is unnecessary on our condition. Thanks.

5 16

ANNOUNCEMENT: FreeSWITCH mod_opal Now Officially In Beta
by Michael Collins 04 May '09

04 May '09

The FreeSWITCH team would like everyone to know that the mod_opal module is now officially in beta. Please read this article for more information: http://www.freeswitch.org/node/179 Many thanks to Robert Jongbloed and Craig Southeren of the OPAL project for their many years of support for open source VoIP. -Michael S Collins http://www.cluecon.com

1 0

XML editors and freeswitch XML spec compliance?
by Jay Austad 04 May '09

04 May '09

Has anyone found a decent XML editor for the XML files? I loaded the files up in OrangeVolt under Eclipse, but didn't have much time to play around with it. Also, I tried opening them with an XML plugin for TextMate, and it says the files are not compliant. The reason is that the first line of each files is a comment describing the file, followed by the <xml> tag. Apparently, the <xml> tag needs to be the first line in the file for compliance to the spec. -- jay austad | 612.423.1433 | austad(a)signal15.com

3 2

Ways of Integrating Sphinx...
by Moiz Chinoy 04 May '09

04 May '09

Hi, I know only two ways of Sphinx - FS integration and its through mod_pocketsphinx and ESL. Performance with mod_pocketsphinx was not very good especially prompts were not playing properly. I haven't tried ESL. Can anyone guide what are other possibilities and which one is best in stability and can any one be deployed in live environment. -- Regards, Moiz Chinoy.

4 10

Registration problem with multiple IP phones behind Linux NAT firewall router
by wchao＠yahoo.com 04 May '09

04 May '09

I am having a problem with getting multiple Polycom IP phones to register to my Freeswitch server. Here is my setup (IP addresses are not actual ones, but are consistent throughout): Freeswitch server in colo facility IP addr: 1.1.1.1 (publicly routable) Linux NAT firewall router with iptables in office building external IP: 2.2.2.2 (publicly routable) internal IP: 192.168.1.1 (internal only, not publicly routable) Polycom IP301 phone A extension: 1001 IP addr: 192.168.1.2 Polycom IP301 phone B extension: 1002 IP addr: 192.168.1.3 snom 320 phone C extension: 1003 IP addr: 192.168.1.4 The Freeswitch server configuration has not changed much from the default installation. I tried changing NDLB-received-in-nat-reg-contact and it doesn't make a difference (although the register line adds a ";received=<ip>:<port>" tag). Here is what happens: Polycom phone A registers successfully. If I execute "sofia status profile internal", I see this: Call-ID: f905cac7-125f0b1d-87aff436(a)192.168.1.2 User: 1001(a)1.1.1.1 Contact: "user" <sip:1001@2.2.2.2:5060;received=2.2.2.2:5060;fs_nat=yes> Agent: PolycomSoundPointIP-SPIP_301-UA/2.1.0.2708 Status: Registered(UDP-NAT)(unknown) EXP(2009-05-04 13:06:47) Host: 1.1.1.1 IP: 2.2.2.2 Port: 5060 Auth-User: 1001 Auth-Realm: 1.1.1.1 When Polycom phone B attempts to register, it cannot and I get the hollowed out phone icon on the phone display. I took a Wireshark capture and discovered that phone B does communicate with Freeswitch, but it is getting denied access. First phone B sends a REGISTER request: No. Time Source Destination Protocol Info 15114 117.617280 2.2.2.2 1.1.1.1 SIP Request: REGISTER sip:1.1.1.1:5060 Frame 15114 (561 bytes on wire, 561 bytes captured) Arrival Time: May 3, 2009 16:46:45.728592000 [Time delta from previous captured frame: 0.007070000 seconds] [Time delta from previous displayed frame: 10.505373000 seconds] [Time since reference or first frame: 117.617280000 seconds] Frame Number: 15114 Frame Length: 561 bytes Capture Length: 561 bytes [Frame is marked: False] [Protocols in frame: eth:ip:udp:sip] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Xensourc_55:2a:dd (00:16:3e:55:2a:dd), Dst: D-Link_61:f2:9a (00:11:95:61:f2:9a) Destination: D-Link_61:f2:9a (00:11:95:61:f2:9a) Address: D-Link_61:f2:9a (00:11:95:61:f2:9a) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Xensourc_55:2a:dd (00:16:3e:55:2a:dd) Address: Xensourc_55:2a:dd (00:16:3e:55:2a:dd) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 2.2.2.2 (2.2.2.2), Dst: 1.1.1.1 (1.1.1.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0xb0 (DSCP 0x2c: Unknown DSCP; ECN: 0x00) 1011 00.. = Differentiated Services Codepoint: Unknown (0x2c) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 547 Identification: 0x02ae (686) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x3ff3 [correct] [Good: True] [Bad : False] Source: 2.2.2.2 (2.2.2.2) Destination: 1.1.1.1 (1.1.1.1) User Datagram Protocol, Src Port: qsm-proxy (1164), Dst Port: sip (5060) Source port: qsm-proxy (1164) Destination port: sip (5060) Length: 527 Checksum: 0xdb1b [correct] [Good Checksum: True] [Bad Checksum: False] Session Initiation Protocol Request-Line: REGISTER sip:1.1.1.1:5060 SIP/2.0 Method: REGISTER [Resent Packet: False] Message Header Via: SIP/2.0/UDP 192.168.1.3;branch=z9hG4bK73c1d1c2BF65B36B Transport: UDP Sent-by Address: 192.168.1.3 Branch: z9hG4bK73c1d1c2BF65B36B From: "Rahim Orazkuliyev" <sip:1002@1.1.1.1>;tag=807917B4-BA73B497 SIP Display info: "Rahim Orazkuliyev" SIP from address: sip:1002@1.1.1.1 SIP tag: 807917B4-BA73B497 To: <sip:1002@1.1.1.1> SIP to address: sip:1002@1.1.1.1 CSeq: 1 REGISTER Sequence Number: 1 Method: REGISTER Call-ID: 76909a58-dd169e7e-a7c5da19(a)192.168.1.3 Contact: <sip:1002@192.168.1.3>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER" Contact Binding: <sip:1002@192.168.1.3>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER" URI: <sip:1002@192.168.1.3> SIP contact address: sip:1002@192.168.1.3 User-Agent: PolycomSoundPointIP-SPIP_301-UA/2.1.0.2708 Max-Forwards: 70 Expires: 3600 Content-Length: 0 The Freeswitch server responds as follows: No. Time Source Destination Protocol Info 15117 117.655406 1.1.1.1 2.2.2.2 SIP Status: 401 Unauthorized (0 bindings) Frame 15117 (698 bytes on wire, 698 bytes captured) Arrival Time: May 3, 2009 16:46:45.766718000 [Time delta from previous captured frame: 0.023210000 seconds] [Time delta from previous displayed frame: 0.038126000 seconds] [Time since reference or first frame: 117.655406000 seconds] Frame Number: 15117 Frame Length: 698 bytes Capture Length: 698 bytes [Frame is marked: False] [Protocols in frame: eth:ip:udp:sip] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: D-Link_61:f2:9a (00:11:95:61:f2:9a), Dst: Xensourc_55:2a:dd (00:16:3e:55:2a:dd) Destination: Xensourc_55:2a:dd (00:16:3e:55:2a:dd) Address: Xensourc_55:2a:dd (00:16:3e:55:2a:dd) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: D-Link_61:f2:9a (00:11:95:61:f2:9a) Address: D-Link_61:f2:9a (00:11:95:61:f2:9a) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2) Version: 4 Header length: 20 bytes Differentiated Services Field: 0xb8 (DSCP 0x2e: Expedited Forwarding; ECN: 0x00) 1011 10.. = Differentiated Services Codepoint: Expedited Forwarding (0x2e) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 684 Identification: 0xd2e8 (53992) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 56 Protocol: UDP (0x11) Header checksum: 0x7627 [correct] [Good: True] [Bad : False] Source: 1.1.1.1 (1.1.1.1) Destination: 2.2.2.2 (2.2.2.2) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Source port: sip (5060) Destination port: sip (5060) Length: 664 Checksum: 0x1fb5 [correct] [Good Checksum: True] [Bad Checksum: False] Session Initiation Protocol Status-Line: SIP/2.0 401 Unauthorized Status-Code: 401 [Resent Packet: False] Message Header Via: SIP/2.0/UDP 192.168.1.3;branch=z9hG4bK73c1d1c2BF65B36B;received=2.2.2.2 Transport: UDP Sent-by Address: 192.168.1.3 Branch: z9hG4bK73c1d1c2BF65B36B Received: 2.2.2.2 From: "Rahim Orazkuliyev" <sip:1002@1.1.1.1>;tag=807917B4-BA73B497 SIP Display info: "Rahim Orazkuliyev" SIP from address: sip:1002@1.1.1.1 SIP tag: 807917B4-BA73B497 To: <sip:1002@1.1.1.1>;tag=FXNpXtFFBBSpF SIP to address: sip:1002@1.1.1.1 SIP tag: FXNpXtFFBBSpF Call-ID: 76909a58-dd169e7e-a7c5da19(a)192.168.1.3 CSeq: 1 REGISTER Sequence Number: 1 Method: REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.4pre4-hacked Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: timer, precondition, path, replaces WWW-Authenticate: Digest realm="1.1.1.1", nonce="066baa69-aebb-4a39-a972-6d20625a79e0", algorithm=MD5, qop="auth" Authentication Scheme: Digest Realm: "1.1.1.1" Nonce Value: "066baa69-aebb-4a39-a972-6d20625a79e0" Algorithm: MD5 QOP: "auth" Content-Length: 0 Interestingly, the snom 320 phone registers fine: Call-ID: 3c26702fbd8b-3wozzv3bd908 User: 1003(a)1.1.1.1 Contact: "Wellie Chao" <sip:1003@2.2.2.2:2058;line=5gjot59h;received=2.2.2.2:2058;fs_nat=yes> Agent: snom320/7.3.14 Status: Registered(UDP-NAT)(unknown) EXP(2009-05-04 14:32:50) Host: 1.1.1.1 IP: 2.2.2.2 Port: 2058 Auth-User: 1003 Auth-Realm: 1.1.1.1 I suspect that the snom 320 phone is working fine because the port is not 5060. The first Polycom (phone A) registered from port 5060. It appears that Freeswitch thinks the second Polycom (phone B) also is coming from port 5060 and is getting confused, thinking that phone B is trying to hijack phone A's registration. The packet capture was taken when running Freeswitch 1.0.4pre4, but I subsequently upgraded to 1.0.4pre6 and it didn't make a difference. The Linux NAT firewall router is running CentOS 5.3 with the most recent updates, and I have tried with ip_nat_sip and ip_conntrack_sip turned on and turned off. When ip_nat_sip and ip_conntrack_sip are turned on, I have included the 4 iptables rules needed: iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 2.2.2.2 iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p udp --dport 5060 -j ACCEPT iptables -A FORWARD -o eth0 -p udp --dport 5060 -j ACCEPT It didn't make a difference no matter what I did. I am not sure why Freeswitch thinks that the source port is 5060 when it appears from the packet capture that the source port is 1164. Does anyone have any insights into why this is happening and what I can try to fix the problem? Regards, Wellie

1 0

FS & Outbound proxy
by kokoska rokoska 03 May '09

03 May '09

Hi all, while I read some threads about Outbound Proxy, I'm still not sure how to use it :-) Well, what's going on: I want to send and receive calls from/to my TSP which uses outbound proxy. For that, I have to register with providers registrar (R1), receive calls from outbound proxy (O1) and send calls (D-URI) to outbound proxy (O1), but with R-URI pointing to real proxy (P1). BTW: registar and proxy challenge me for credentials... Registering with R1, receiving calls from O1 is simple and works fine. But I still cant successfuly send calls to O1 with R-URI of P1. When I try to add fs_path to "dialing" thru gateway, it is silently ignored... Any hint is really welcome :-) Best regards, kokoska.rokoska

2 2

Segfaults with core dump, how to handle
by paul.degt 03 May '09

03 May '09

We experience sporadic seg faults in our production FS, version 1.0.3, load is very low, 10-15 users, runs under Centos 5.2 2.6.18-92.1.22.el5 SMP 64-bit. This is what I get in system log: May 3 10:39:01 hostname kernel: freeswitch[7578]: segfault at 0000000000000000 rip 00002aaab098e236 rsp 0000000040cdde50 error 4 Need advice on the best way to handle the situation, since it's our production switch I hesitate to use trunk version, we may hit some other unknown bugs. Which version is considered currently stable enough for production use? Thanks.

2 1

Ruby and ESL help
by Diego Viola 03 May '09

03 May '09

Hello everyone, I was trying to test ESL with Ruby, and I made this: " require 'socket' require 'ESL' TCPServer.new('127.0.0.1', '8084') con = ESL::ESLconnection.new('127.0.0.1', '8084', '') con.execute('answer') con.execute('playback', '/usr/local/freeswitch/sounds/music/8000/suite-espanola-op-47-leyenda.wav') " I can connect from freeswitch with sync and async mode, but it doesn't do anything more than that, it doesn't execute my answer or playback, anyone knows what's wrong with it? I use the freeswitcher lib and it works great, but I also want to try ESL. Thanks, Diego

1 1