September 2012 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Issue with play_and_get_digits
by Emrah 18 Sep '12

18 Sep '12

Just wanted to drop a quick note about an issue I just stumbled upon. When using play_and_get_digits, you are still able to input DTMFs when the invalid-entry prompt is played, but the message won't be interrupted and your DTMF input won't be executed until the prompt is fully played. Can someone look into this and confirm? Best, Emrah

4 14

directory variables not set on user channels when bridge does not succeed
by Babak Yakhchali 18 Sep '12

18 Sep '12

Hi To add some features to fs, I need to set some variables in xml directory user as: <include> <user id="1000"> <params> ... <variables> <variable name="profile_id" value="10"/> <variable name="dn_id" value="25"/> ..... <variable name="call_timeout" value="7"/> </variables> </user> </include> as documentation says these variables are set on every inbound or outbound channel for this user. when I try to call to user/1000 if call succeeds everything is ok but if call ends with results like no_answer, in xml_cdr that is sent to my cdr logger url, there is no sign of any variables set in directory as above. is this normal? because if I set these on bleg (user/1000) using export they appear in xml cdr. thanx

3 7

SBC bridged call: DTMF delay
by Alex Zarubin 17 Sep '12

17 Sep '12

Hi all, FS in SBC mode, 'external' and 'internal' sip calls are bridged. DTMF sequence '11234567890' gets passed with a delay, - 2 sec between the last digit '0' is received and sent (see log below). There is a consistent 500ms+ between 'Queue digit delay of 40ms' and 'Send start packet' for the next digit. Haven't found a way to fix it so far (wiki, user list, parameters such as auto-rtp-bugs), help will be appreciated. CentOS 6.1, Xen, rfc2833. Thank you. Alex 2012-09-17 12:52:20.714917 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 1:1120 2012-09-17 12:52:20.714917 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:20.774914 [DEBUG] switch_rtp.c:2420 Send start packet for [1] ts=325320 dur=160/160/1120 seq=6880 lw=325320 2012-09-17 12:52:20.794915 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=325320 dur=320/320/1120 seq=6881 lw=325480 2012-09-17 12:52:20.814914 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=325320 dur=480/480/1120 seq=6882 lw=325640 2012-09-17 12:52:20.834915 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=325320 dur=640/640/1120 seq=6883 lw=325800 2012-09-17 12:52:20.874917 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=325320 dur=800/800/1120 seq=6884 lw=161 2012-09-17 12:52:20.894918 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=325320 dur=960/960/1120 seq=6885 lw=321 2012-09-17 12:52:20.914916 [DEBUG] switch_rtp.c:2323 Send end packet for [1] ts=325320 dur=1120/1120/1120 seq=6886 lw=321 2012-09-17 12:52:20.914916 [DEBUG] switch_rtp.c:2323 Send end packet for [1] ts=325320 dur=1120/1120/1120 seq=6887 lw=321 2012-09-17 12:52:20.914916 [DEBUG] switch_rtp.c:2323 Send end packet for [1] ts=325320 dur=1120/1120/1120 seq=6888 lw=321 2012-09-17 12:52:20.914916 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:21.054920 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 1:960 2012-09-17 12:52:21.054920 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:21.454915 [DEBUG] switch_rtp.c:2420 Send start packet for [1] ts=331880 dur=160/160/960 seq=6907 lw=331880 2012-09-17 12:52:21.474918 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=331880 dur=320/320/960 seq=6908 lw=332040 2012-09-17 12:52:21.494916 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 2:800 2012-09-17 12:52:21.494916 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=331880 dur=480/480/960 seq=6909 lw=332200 2012-09-17 12:52:21.494916 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:21.514915 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=331880 dur=640/640/960 seq=6910 lw=332360 2012-09-17 12:52:21.534920 [DEBUG] switch_rtp.c:2323 Send middle packet for [1] ts=331880 dur=800/800/960 seq=6911 lw=332520 2012-09-17 12:52:21.554917 [DEBUG] switch_rtp.c:2323 Send end packet for [1] ts=331880 dur=960/960/960 seq=6912 lw=332520 2012-09-17 12:52:21.554917 [DEBUG] switch_rtp.c:2323 Send end packet for [1] ts=331880 dur=960/960/960 seq=6913 lw=332520 2012-09-17 12:52:21.554917 [DEBUG] switch_rtp.c:2323 Send end packet for [1] ts=331880 dur=960/960/960 seq=6914 lw=332520 2012-09-17 12:52:21.554917 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:21.934916 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 3:800 2012-09-17 12:52:21.934916 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:22.094915 [DEBUG] switch_rtp.c:2420 Send start packet for [2] ts=337000 dur=160/160/800 seq=6934 lw=337000 2012-09-17 12:52:22.114914 [DEBUG] switch_rtp.c:2323 Send middle packet for [2] ts=337000 dur=320/320/800 seq=6935 lw=337160 2012-09-17 12:52:22.134920 [DEBUG] switch_rtp.c:2323 Send middle packet for [2] ts=337000 dur=480/480/800 seq=6936 lw=337320 2012-09-17 12:52:22.154919 [DEBUG] switch_rtp.c:2323 Send middle packet for [2] ts=337000 dur=640/640/800 seq=6937 lw=337480 2012-09-17 12:52:22.174917 [DEBUG] switch_rtp.c:2323 Send end packet for [2] ts=337000 dur=800/800/800 seq=6938 lw=337480 2012-09-17 12:52:22.174917 [DEBUG] switch_rtp.c:2323 Send end packet for [2] ts=337000 dur=800/800/800 seq=6939 lw=337480 2012-09-17 12:52:22.174917 [DEBUG] switch_rtp.c:2323 Send end packet for [2] ts=337000 dur=800/800/800 seq=6940 lw=337480 2012-09-17 12:52:22.174917 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:22.554917 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 4:960 2012-09-17 12:52:22.554917 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:22.714915 [DEBUG] switch_rtp.c:2420 Send start packet for [3] ts=341960 dur=160/160/800 seq=6959 lw=341960 2012-09-17 12:52:22.734917 [DEBUG] switch_rtp.c:2323 Send middle packet for [3] ts=341960 dur=320/320/800 seq=6960 lw=342120 2012-09-17 12:52:22.754918 [DEBUG] switch_rtp.c:2323 Send middle packet for [3] ts=341960 dur=480/480/800 seq=6961 lw=342280 2012-09-17 12:52:22.774919 [DEBUG] switch_rtp.c:2323 Send middle packet for [3] ts=341960 dur=640/640/800 seq=6962 lw=342440 2012-09-17 12:52:22.794916 [DEBUG] switch_rtp.c:2323 Send end packet for [3] ts=341960 dur=800/800/800 seq=6963 lw=342440 2012-09-17 12:52:22.794916 [DEBUG] switch_rtp.c:2323 Send end packet for [3] ts=341960 dur=800/800/800 seq=6964 lw=342440 2012-09-17 12:52:22.794916 [DEBUG] switch_rtp.c:2323 Send end packet for [3] ts=341960 dur=800/800/800 seq=6965 lw=342440 2012-09-17 12:52:22.794916 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:22.994918 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 5:800 2012-09-17 12:52:22.994918 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:23.334917 [DEBUG] switch_rtp.c:2420 Send start packet for [4] ts=346920 dur=160/160/960 seq=6985 lw=346920 2012-09-17 12:52:23.354917 [DEBUG] switch_rtp.c:2323 Send middle packet for [4] ts=346920 dur=320/320/960 seq=6986 lw=347080 2012-09-17 12:52:23.374915 [DEBUG] switch_rtp.c:2323 Send middle packet for [4] ts=346920 dur=480/480/960 seq=6987 lw=347240 2012-09-17 12:52:23.394913 [DEBUG] switch_rtp.c:2323 Send middle packet for [4] ts=346920 dur=640/640/960 seq=6988 lw=347400 2012-09-17 12:52:23.414914 [DEBUG] switch_rtp.c:2323 Send middle packet for [4] ts=346920 dur=800/800/960 seq=6989 lw=347560 2012-09-17 12:52:23.434914 [DEBUG] switch_rtp.c:2323 Send end packet for [4] ts=346920 dur=960/960/960 seq=6990 lw=347560 2012-09-17 12:52:23.434914 [DEBUG] switch_rtp.c:2323 Send end packet for [4] ts=346920 dur=960/960/960 seq=6991 lw=347560 2012-09-17 12:52:23.434914 [DEBUG] switch_rtp.c:2323 Send end packet for [4] ts=346920 dur=960/960/960 seq=6992 lw=347560 2012-09-17 12:52:23.434914 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:23.474915 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 6:800 2012-09-17 12:52:23.474915 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] nta: timer J fired, terminate 200 response nta_incoming_timer: 0/0 resent, 0/0 tout, 1/1 term, 1/1 free 2012-09-17 12:52:23.974919 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 7:960 2012-09-17 12:52:23.974919 [DEBUG] switch_rtp.c:2420 Send start packet for [5] ts=351560 dur=160/160/800 seq=7012 lw=351560 2012-09-17 12:52:23.974919 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:23.994918 [DEBUG] switch_rtp.c:2323 Send middle packet for [5] ts=351560 dur=320/320/800 seq=7013 lw=351720 2012-09-17 12:52:24.014914 [DEBUG] switch_rtp.c:2323 Send middle packet for [5] ts=351560 dur=480/480/800 seq=7014 lw=351880 2012-09-17 12:52:24.034914 [DEBUG] switch_rtp.c:2323 Send middle packet for [5] ts=351560 dur=640/640/800 seq=7015 lw=352040 2012-09-17 12:52:24.054913 [DEBUG] switch_rtp.c:2323 Send end packet for [5] ts=351560 dur=800/800/800 seq=7016 lw=352040 2012-09-17 12:52:24.054913 [DEBUG] switch_rtp.c:2323 Send end packet for [5] ts=351560 dur=800/800/800 seq=7017 lw=352040 2012-09-17 12:52:24.054913 [DEBUG] switch_rtp.c:2323 Send end packet for [5] ts=351560 dur=800/800/800 seq=7018 lw=352040 2012-09-17 12:52:24.054913 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:24.394917 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 8:960 2012-09-17 12:52:24.394917 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:24.594915 [DEBUG] switch_rtp.c:2420 Send start packet for [6] ts=357000 dur=160/160/800 seq=7037 lw=357000 2012-09-17 12:52:24.614924 [DEBUG] switch_rtp.c:2323 Send middle packet for [6] ts=357000 dur=320/320/800 seq=7038 lw=357160 2012-09-17 12:52:24.634922 [DEBUG] switch_rtp.c:2323 Send middle packet for [6] ts=357000 dur=480/480/800 seq=7039 lw=357320 2012-09-17 12:52:24.654919 [DEBUG] switch_rtp.c:2323 Send middle packet for [6] ts=357000 dur=640/640/800 seq=7040 lw=357480 2012-09-17 12:52:24.674918 [DEBUG] switch_rtp.c:2323 Send end packet for [6] ts=357000 dur=800/800/800 seq=7041 lw=357480 2012-09-17 12:52:24.674918 [DEBUG] switch_rtp.c:2323 Send end packet for [6] ts=357000 dur=800/800/800 seq=7042 lw=357480 2012-09-17 12:52:24.674918 [DEBUG] switch_rtp.c:2323 Send end packet for [6] ts=357000 dur=800/800/800 seq=7043 lw=357480 2012-09-17 12:52:24.674918 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:24.814915 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 9:800 2012-09-17 12:52:24.814915 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:25.214926 [DEBUG] switch_rtp.c:2420 Send start packet for [7] ts=361960 dur=160/160/960 seq=7063 lw=361960 2012-09-17 12:52:25.234921 [DEBUG] switch_rtp.c:2323 Send middle packet for [7] ts=361960 dur=320/320/960 seq=7064 lw=362120 2012-09-17 12:52:25.254920 [DEBUG] switch_rtp.c:2323 Send middle packet for [7] ts=361960 dur=480/480/960 seq=7065 lw=362280 2012-09-17 12:52:25.274919 [DEBUG] switch_rtp.c:2323 Send middle packet for [7] ts=361960 dur=640/640/960 seq=7066 lw=362440 2012-09-17 12:52:25.294926 [DEBUG] switch_rtp.c:3410 RTP RECV DTMF 0:800 2012-09-17 12:52:25.294926 [DEBUG] switch_rtp.c:2323 Send middle packet for [7] ts=361960 dur=800/800/960 seq=7067 lw=362600 2012-09-17 12:52:25.294926 [DEBUG] switch_ivr_bridge.c:391 Send signal sofia/internal/9910@Kate-conf02-dev.webley.com:5080 [BREAK] 2012-09-17 12:52:25.314920 [DEBUG] switch_rtp.c:2323 Send end packet for [7] ts=361960 dur=960/960/960 seq=7068 lw=362600 2012-09-17 12:52:25.314920 [DEBUG] switch_rtp.c:2323 Send end packet for [7] ts=361960 dur=960/960/960 seq=7069 lw=362600 2012-09-17 12:52:25.314920 [DEBUG] switch_rtp.c:2323 Send end packet for [7] ts=361960 dur=960/960/960 seq=7070 lw=362600 2012-09-17 12:52:25.314920 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:25.874915 [DEBUG] switch_rtp.c:2420 Send start packet for [8] ts=161 dur=160/160/960 seq=7096 lw=161 2012-09-17 12:52:25.894918 [DEBUG] switch_rtp.c:2323 Send middle packet for [8] ts=161 dur=320/320/960 seq=7097 lw=321 2012-09-17 12:52:25.914916 [DEBUG] switch_rtp.c:2323 Send middle packet for [8] ts=161 dur=480/480/960 seq=7098 lw=481 2012-09-17 12:52:25.934917 [DEBUG] switch_rtp.c:2323 Send middle packet for [8] ts=161 dur=640/640/960 seq=7099 lw=641 2012-09-17 12:52:25.954921 [DEBUG] switch_rtp.c:2323 Send middle packet for [8] ts=161 dur=800/800/960 seq=7100 lw=801 2012-09-17 12:52:25.974930 [DEBUG] switch_rtp.c:2323 Send end packet for [8] ts=161 dur=960/960/960 seq=7101 lw=801 2012-09-17 12:52:25.974930 [DEBUG] switch_rtp.c:2323 Send end packet for [8] ts=161 dur=960/960/960 seq=7102 lw=801 2012-09-17 12:52:25.974930 [DEBUG] switch_rtp.c:2323 Send end packet for [8] ts=161 dur=960/960/960 seq=7103 lw=801 2012-09-17 12:52:25.974930 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:26.514917 [DEBUG] switch_rtp.c:2420 Send start packet for [9] ts=372360 dur=160/160/800 seq=7128 lw=372360 2012-09-17 12:52:26.534917 [DEBUG] switch_rtp.c:2323 Send middle packet for [9] ts=372360 dur=320/320/800 seq=7129 lw=372520 2012-09-17 12:52:26.554924 [DEBUG] switch_rtp.c:2323 Send middle packet for [9] ts=372360 dur=480/480/800 seq=7130 lw=372680 2012-09-17 12:52:26.574918 [DEBUG] switch_rtp.c:2323 Send middle packet for [9] ts=372360 dur=640/640/800 seq=7131 lw=372840 2012-09-17 12:52:26.594915 [DEBUG] switch_rtp.c:2323 Send end packet for [9] ts=372360 dur=800/800/800 seq=7132 lw=372840 2012-09-17 12:52:26.594915 [DEBUG] switch_rtp.c:2323 Send end packet for [9] ts=372360 dur=800/800/800 seq=7133 lw=372840 2012-09-17 12:52:26.594915 [DEBUG] switch_rtp.c:2323 Send end packet for [9] ts=372360 dur=800/800/800 seq=7134 lw=372840 2012-09-17 12:52:26.594915 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-09-17 12:52:27.134920 [DEBUG] switch_rtp.c:2420 Send start packet for [0] ts=377480 dur=160/160/800 seq=7160 lw=377480 2012-09-17 12:52:27.154916 [DEBUG] switch_rtp.c:2323 Send middle packet for [0] ts=377480 dur=320/320/800 seq=7161 lw=377640 2012-09-17 12:52:27.174916 [DEBUG] switch_rtp.c:2323 Send middle packet for [0] ts=377480 dur=480/480/800 seq=7162 lw=377800 2012-09-17 12:52:27.194919 [DEBUG] switch_rtp.c:2323 Send middle packet for [0] ts=377480 dur=640/640/800 seq=7163 lw=377960 2012-09-17 12:52:27.214916 [DEBUG] switch_rtp.c:2323 Send end packet for [0] ts=377480 dur=800/800/800 seq=7164 lw=377960 2012-09-17 12:52:27.214916 [DEBUG] switch_rtp.c:2323 Send end packet for [0] ts=377480 dur=800/800/800 seq=7165 lw=377960 2012-09-17 12:52:27.214916 [DEBUG] switch_rtp.c:2323 Send end packet for [0] ts=377480 dur=800/800/800 seq=7166 lw=377960 2012-09-17 12:52:27.214916 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms This message and any attachments to it are intended only for the addressee(s) identified above and may contain CONFIDENTIAL information. It is not intended for transmission to, or receipt by, any unauthorized persons. If you are not an intended recipient or an agent responsible for delivering it to an intended recipient, you have received this e-mail in error and any dissemination, distribution, or copying of this message or any attachment to it is strictly prohibited. If you have received this email in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the message from your system.

2 2

FreeSWITCH Weekly News and Notes
by Michael Collins 17 Sep '12

17 Sep '12

Hello all, It's been another productive week on the FreeSWITCH team. We are pleased to let you know that we have officially tagged <http://freeswitch.org/node/418>FreeSWITCH version 1.2.2 in the git repo. Source tarballs are available in the usual location <http://files.freeswitch.org>. Thanks to all those whose efforts make more frequent releases a reality. It is much appreciated. On last Wednesday's conference call<http://wiki.freeswitch.org/wiki/FS_weekly_2012_09_12>we enjoyed a nice Adhearsion <http://adhearsion.com/> presentation by Ben Langfeld and Ben Klang. Adhearsion is a Ruby-based framework for developing telephony applications. Ben and Ben discuss how Adhearsion works, why Ruby is cool for building telephony apps, and why the Adhearsion guys love FreeSWITCH. FreeSWITCH community members are invited to join the Adhearsion team at AdhearsionConf <http://adhearsionconf.com> in Palo Alto, CA on October 20-21, 2012. Community members receive a special rate by using discount code AHNLOVESFREESWITCH. Thanks to Ben and Ben for a great presentation with cool slides<http://wiki.freeswitch.org/images/8/8e/FreeSWITCH_Weekly_CC_2012-09-12.pdf> . For the next few weeks we look forward to hearing from Daniel Pocock and Scott Godin who will be telling us more about the Repro<http://www.resiprocate.org/About_Repro>SIP proxy and the ReSIProcate <http://www.resiprocate.org/Resip_Overview> SIP stack. For many of us it will be our first look at a SIP proxy that does not have its roots in the OpenSER project. We look forward to learning more on this Wednesday's conference call<http://wiki.freeswitch.org/wiki/FS_weekly_2012_09_19> . Have a great week! -- Michael S Collins ClueCon Team http://www.cluecon.com 877-7-4ACLUE

1 0

Require Timer on re-invite from FS to A-LEG
by Mike Burlingame 17 Sep '12

17 Sep '12

it seems if I get an re-invite from the B-Leg FS add's requires timer and changes the session timer to a high value to the re-invite going to the A-Leg come to find out Acme Packets at our ULC's do not like this and send us back a 420 Bad Extension and the call is disconnected with Reason: Q.850;cause=127;text="INTERWORKING" The ULC are stating we need to only have it in our supported and do not pass them a require. Re-Invite from B-Leg to FS ------------------------------------------------------------------------ INVITE sip:16025551212;phone-context=+1@FS_SERVER:5070 SIP/2.0 Via: SIP/2.0/UDP OpenSIPs_DID_Proxy;branch=z9hG4bK8288.10e55fe5.0 Via: SIP/2.0/UDP B-LEG_IP:5060;branch=z9hG4bKve7vp6002gr1gfsh72k0sb1gv1ek1.1 Call-Id: f8330599-d298-4233-92bb-5d622e85aa6d Contact: <sip:18475551212@B-LEG_IP:5060;transport=udp> Content-Length: 217 Content-Type: application/sdp CSeq: 33480808 INVITE From: <sip:18475551212@B-LEG_IP>;tag=100052073 Max-Forwards: 92 Session-Expires: 3600;refresher=uas Supported: timer To: <sip:116025551212@OpenSIPs_DID_Proxy>;tag=Dj92X5t8065FQ User-Agent: FreeSwitch v=0 o=- 3308986892 0 IN IP4 B-LEG_IP s=Media Server c=IN IP4 B-LEG_IP t=0 0 m=audio 51246 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 ------------------------------------------------------------------------ Re-Invite from FS to A-Leg ------------------------------------------------------------------------ INVITE sip:16025551212@DID_CARRIER:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP FS_SERVER:5070;rport;branch=z9hG4bKj8yevKKS0X0mK Route: <sip:OpenSIPS_DID_CARRIER_Proxy;lr=on> Max-Forwards: 97 From: <sip:18475551212;phone-context=+1@OpenSIPS_DID_CARRIER_Proxy:5060;user=phone>;tag=c9Favaa53XFXB To: <sip:16025551212;phone-context=+1@DID_CARRIER:5060;user=phone>;tag=SDd626401-gK095bbb72 Call-ID: SDd626401-b06f59c4aa359462042e25890d7b5bfd-v3000i1 CSeq: 33480811 INVITE Contact: <sip:18475551212;phone-context=+1@FS_SERVER:5070;transport=udp> User-Agent: FreeSwitch Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, NOTIFY Require: timer Supported: timer, precondition, path, replaces Session-Expires: 64800;refresher=uas Min-SE: 64800 Content-Type: application/sdp Content-Disposition: session Content-Length: 235 X-FS-Support: update_display,send_info v=0 o=- 3308979701 3213293310682935904 IN IP4 B-LEG_IP s=Media Server c=IN IP4 B-LEG_IP t=0 0 m=audio 51246 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 ------------------------------------------------------------------------

3 13

Altering From Header in SIP Invite
by Rob Moore 17 Sep '12

17 Sep '12

Hi All, I'm having a little trouble with 'presentation numbers' with a new provider I'm in IOT with this week. I'm trying to recreate the following Invite as the calls pass through our dialplan to this provider but there are issues with trying to get a different CLI into the From and P-Asserted-Identity headers. When presenting a Freephone number (for example) we need to still present the regular number that would be used by this extension in the P-Asserted-Identity whilst passing the number we wish to have presented in the From header. Currently we are not using Gateways so we cannot resort to using <param name="caller-id-in-from" value="true"/> (although I expect this won't do what we need in this case) so I've looked at altering the channel variables sip_from_user,sip_full_from and sip_full_uri using set and export dial plan apps but none of these seem to have any effect so I guess these variables must be read only. I'm sure this must be simple, but can't for the life of me work out what I need to do. Below is an extract from an example header from the provider I am trying to recreate, I've also added a copy of the Dialplan extension I am using to test. If someone can tell me what I'm getting wrong I would really appreciate it. Thanks Rob INVITE sip:+445600005262@primarysip.barfoo.com;user=phone SIP/2.0 Max-Forwards: 69 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: timer, 100rel To: +445600000262 <sip:+445600005262@primarysip.barfoo.com;user=phone> From: <sip:+448000655262@uk.foo.bar.2.net;user=phone>;tag=12544 P-Asserted-Identity: <sip:+445600655262@uk.sdin.bt.net> Call-ID: 1347372978-13100(a)mgc-uk-998.n2<mailto:1347372978-13100@mgc-uk-998.n2> CSeq: 1 INVITE Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, INFO, PRACK, UPDATE DIAL Plan: (attempting +445600655262 in P Asserted-Id and +448000655262 in from) have commented out some things that I have tried.) If you are worried about [sip_h_X-Gateway=4003:4] this is added to help our SBC forward calls to our different providers. <extension name="TC 25"> <condition field="destination_number" expression="^10125$"> <action application="set" data="effective_caller_id_name=_undef_"/> <action application="set" data="effective_caller_id_number=+445600005262 "/> <action application="set" data="dtmf_type=rfc2833"/> <action application="set" data="sip_cid_type=pid"/>    <action application="info"/> <action application="bridge" data="[sip_h_X-Gateway=4003:4]sofia/internal/+442920001199@pstn.tel" /> </condition> </extension> Rob Moore Telephony Systems Infrastructure Manager Aeriandi Aeriandi Ltd, Prama House, Banbury Road, Oxford, OX27HT E: rob.moore(a)aeriandi.com<mailto:rob.moore@aeriandi.com> W: www.aeriandi.com<http://www.aeriandi.com/> M: +44 (0)7766 838040 T: +44 (0) 845 108 0308 [Description: Description: Description: Description: Description: Description: Description: Description: cid:image002.png@01CC9E0C.20153A40]

3 4

Phones lossing connection
by Miha 17 Sep '12

17 Sep '12

Hi, my Fs version is 1.2 rc2. I have about 820 phones registered on it. I noticed that after one mounth of production 20 phones behind nat lost connection and I needed to restart all 20 phones (I was unable to get them from outside, also calls from inside FS were not working). On think is that the Switch could be causing problems but I did not have to restart switch, I just restarted phones... What do you thing, could this be FS problem? p.s.: other phones, which are not behind nat are working as they should. Regards, MIha

1 0

481 Call Leg/Transaction Does Not Exist
by Emrah 16 Sep '12

16 Sep '12

Hi all, I seem to be encountering the strangest problems. I have been doing some more testing with my transfers and here is a recurring issue. I have 2 phones behind the same router. 1 Polycom VVX 1500 and 1 Yealink SIP-T38g They are both registering on the same FS server which is on a remote public IP. The Polycom has extension 20 and the yealink uses 21. When I call the Polycom from the Yealink and perform a blind transfer from the Yealink, it fails with: 481 Call Leg/Transaction Does Not Exist. If I transfer from the Polycom though, it seems to work. In resume: I cannot transfer from A leg. B leg doesn't seem to know its way around and looses it. To demonstrate, I transfer B leg from A leg to extension 5000. http://pastebin.freeswitch.org/19893 I tried Googleing the error code and didn't find anything particularly related to my issue. Any hint would be greatly appreciated. To make sure, I downgraded to the stable version. Thanks a bunch, as always. Emrah

2 4

mod_snom + mod_fifo: Turning the light off
by georg＠riseup.net 16 Sep '12

16 Sep '12

Hi all, I'm using FS in a small office. I've setup a small queue with mod_fifo. Now I woud like let my users know, when someone enters the queue and they're still talking. I've used mod_snom for this, which works great. Hoever, I'm not able to turn the light off after the call is completed. <extension name="kunden-queue"> <condition field="destination_number" expression="^(666)$">  <action application="eval" data="${snom_bind_key(2 on x kunden-1 192.168.1.93 internal x x)}"/> <action application="fifo" data="fifo_kunden(a)192.168.1.93 in undef /data/usr/local/freeswitch/sounds/kunden-queue.raw" /> <action application="transfer" data="6666 XML public" /> <action application="eval" data="${snom_bind_key(2 off x kunden-1 192.168.1.93 internal x x)}"/> </condition> </extension> It seems, that the dialplan is not processed anymore, after the caller gets into the queue. Any hints for this? Thanks, Georg

1 0

Kazoo Review
by TamurlangClan 16 Sep '12

16 Sep '12

Hi, I'm thinking to use Kazoo by 2600HZ for effectively mainting PBX and other services. Has anyone used it? Anyone willing to give feedback on how effective it is? Thanks. -- View this message in context: http://old.nabble.com/Kazoo-Review-tp34429093p34429093.html Sent from the Freeswitch-users mailing list archive at Nabble.com.

4 3