- FreeSWITCH-users - FreeSWITCH Mailing Lists

DTMF rfc2833 hanging up the calls
by Mino Haluz 10 Jun '13

10 Jun '13

Hi, if I use SIP INFO on leg A, FS detects everything fine, but in case I use rfc2833, after pressing number, it instantly hangs up the call. n2013-06-06 17:13:16.319289 [NOTICE] mod_sofia.c:1137 Hangup sofia/myprofile/sip:200@x.x.x.x:45703 [CS_EXCHANGE_MEDIA] [MEDIA_TIMEOUT] 2013-06-06 17:13:16.319289 [DEBUG] switch_channel.c:3096 Send signal sofia/myprofile/sip:200@x.x.x.x:45703 [KILL] 2013-06-06 17:13:16.319289 [DEBUG] switch_core_session.c:1333 Send signal sofia/myprofile/sip:200@x.x.x.x:45703 [BREAK] 2013-06-06 17:13:16.319289 [DEBUG] switch_ivr_bridge.c:533 sofia/myprofile/sip:200@x.x.x.x:45703 ending bridge by request from read function I do not use any ivr module, or start_dtmf, or whatsoever setting related to dtmf. Any hint? Thanks, Mino

5 10

2013-02-15 05:30:00.934663 [DEBUG] mod_skypopen.c:1056 [e5e3e4b|3d6ed64] [DEBUG_SKYPE 1056 ][gplhost_skype1 ][DIALING, INC_HNG] NO SPACE in WRITE BUFFER: there was no space for 640
by Shawndell Harris 10 Jun '13

10 Jun '13

Placing a call out through skype i receive this error 2013-02-15 05:30:00.934663 [DEBUG] mod_skypopen.c:1056 [e5e3e4b|3d6ed64] [DEBUG_SKYPE 1056 ][gplhost_skype1 ][DIALING,INC_HNG] NO SPACE in WRITE BUFFER: there was no space for 640 -- Shawndell Harris

1 0

Ticket triage - everyone can do their bit!
by Cal Leeming [Simplicity Media Ltd] 10 Jun '13

10 Jun '13

Hello all, I've done triage on the following tickets, needs someone with higher JIRA privs to sign off; http://jira.freeswitch.org/browse/FS-5495 (needs input from core dev) http://jira.freeswitch.org/browse/FS-5497 (suggested wontfix - needs waiting on reporter) http://jira.freeswitch.org/browse/FS-5482 (needs clean patch - waiting on reporter) http://jira.freeswitch.org/browse/FS-5478 (waiting on reporter) http://jira.freeswitch.org/browse/FS-5427 (waiting on reporter) For anyone who's reading, this triage took about 25 minutes which I did when I needed a change of focus - if everyone did this, we would be able to clear down the ticket queue much faster. If you want a good place to start; http://jira.freeswitch.org/issues/?jql=project%20%3D%20FS%20AND%20status%20… That above link will give you new tickets in the order they were created.. aim for tickets which don't yet have a reply, you can either offer assistance on the problem, or give your thoughts on what the appropriate action should be. Make sure you clearly state what your thoughts are, so that when core dev or triage admin comes along, they can get the ticket resolved much quicker. Usually I tend to aim for 5 tickets, or a maximum of 30 minutes - which ever comes first. And remember, this is a great way to claim your 5-for-1 token too! (for every 5 tickets you triage, you can ask for a core dev to give eyes on any ticket of your choice). Cal

1 0

G729 ptime mismatch on ingress and egress legs
by Ashwin Rath 10 Jun '13

10 Jun '13

Hi I am trying to configure FS as a B2BUA which can do ptime conversions between the ingress and egress leg. The question is, if both legs have G729 as the codec but ptime 20 on one and 30 on another, would i still need to get the licensed mod_com_g729 or can it work with the passthrough mod_g729. I already tried it out, but it doesnt seem to work. Is there some configuration needed for this ? -- Thegrid

4 7

Re: [Freeswitch-users] NAT problem: Use local IPv4 for specific LAN IP address range
by Ben 10 Jun '13

10 Jun '13

Steve, Sorry for the late reply (4 months!!!), the immediate need for a fix went away, until now. The problem with setting up an additional profile would be that the end user would have to change port numbers when moving from the internal network to an external network. Unfortunately the end user does not have access to these sorts of settings with the app we're using, and more importantly, I need this to be seamless between networks. Does anyone else have any ideas? I'm starting to think this problem is unsolvable with the current functionality. Implementing an equivalent of the Asterisk "nat.conf" with a "localnet=" line, which will force the Freeswitches local IPv4 address as the SDP for any requests originating from one of these "localnets" would hopefully resolve the issue. Thanks, Ben From: freeswitch-users-bounces(a)lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steven Ayre Sent: 07 February 2013 13:07 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Use local IPv4 for specific LAN IP address range One simple option would be to have a 2nd profile listening on another port (eg 5080) that does not use ext-*-ip and connect to that internally. -Steve On 7 February 2013 11:44, Ben <ben122uk(a)gmail.com> wrote: Greetings all, A question on NATing in Freeswitch - I have my internal SIP profile to use a static public IP for the ext-sip-ip and ext-rtp-ip. The Freeswitch server is on a local LAN IP, for example 192.168.0.10. External SIP clients can access the server via the external IP, as there's a static NAT on the router to map the public IP to the private IP. I have another SIP client on a different LAN, but behind the same firewall, for example, 10.0.0.10. This client is allowed to talk to the server on its private ip of 192.168.0.10, by allowing inter-vlan traffic to pass through. My challenge is, how do I get Freeswitch to recognise this internal SIP client as being allowed to use the internal IP for SIP/RTP communications, and therefore present the client with internal addresses in the SIP header for SIP/RTP? Due to statically setting ext-sip-ip and ext-rtp-ip, Freeswitch tells the client to go via the public IP. The firewall has a policy to not accept traffic to the public IP if sourced from an internal device. I have explored the NATing options in Freeswitch, but can't find anything that fits my scenario. It seems to be more towards how to enable NAT in certain situations, not disable it. I have also looked at re-writing the SDP, but this re-writes the incoming SDP from the clients. My intention was to re-write the outgoing SDP from the Freeswitch to include the internal IP address as the RTP connect in address. I don't have much Asterisk experience, but I seem to remember a nat.conf file where you could specify subnets that were treated differently. These could be classed as internal subnets, and would be given the private IP in the SDP from asterisk, everything got the public IP. I'm also aware that I could create another SIP profile easily with different NATing/IP options, but I want to find out if there's anything I can do with the above first. Many thanks for the help! _________________________________________________________________________ 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

1 0

JIRA contributions - 15/05/2013
by Cal Leeming [Simplicity Media Ltd] 10 Jun '13

10 Jun '13

Hello all, Last week I made some contributions on JIRA by triaging some tickets. FS-3964 - requested larger bounty offer, if no bite then reclassify as nice to have FS-4211 - requested further info, close after 2 weeks if no response. FS-4281 - requested more info, waiting on core devs FS-4891 - requested more info, updated wiki docs, close after 2 weeks if no response FS-5154 - requested OP create new ticket for seperate issues, close after 2 weeks if no response However, I was unable to action them due to lack of access on JIRA. I sent an email to Ken/Michael requesting access to close tickets and mark as resolved etc, but realised this was not the appropriate way as you shouldn't need to have extra privileges in order to do ticket triage. Therefore, I'd like to open up discussion about how we can improve JIRA to allow for public contributions and make ticket triaging easier. My suggestions are; * Add a new step in the workflow that switches it into "needs more client info", so it automatically closes the ticket after X days if no extra info is received. * Have a "maybe one day/needs contributions" status in the workflow, rather than leaving the ticket as open.. that way we can see really how many are waiting, and how many are waiting on contributions. * Have a "needs design decision" status in the workflow, indicating that a core dev needs to make the final call * Introduce an official 5-for-1 ticket system where users can triage 5 tickets and request that a core dev look at any ticket of their choice in return. I think we stand a much better chance of getting a lot more public contributions if we implement these changes. Probably a bit too short notice to discuss on todays conf call, but it would be good to get some ideas/feedback in time for next weeks call. Modifying JIRA and making workflow changes is no easy task, so it would need to be thoroughly discussed and understood. I'll be on the call today 20 minutes early today if anyone wants to discuss. Any thoughts/ideas? Thanks Cal

3 4

Bazzare Duplicated UUID Error Issue
by David Allen 10 Jun '13

10 Jun '13

Hi, I recently upgraded from the 1.0 GIT Head to 1.2.10+git~20130607T172913Z~658c4d732d (git 658c4d7 2013-06-07 17:29:13Z) and have encounted a weird problem on inbound calls from a SIP UA (Eg. Asterisk) to be bridged and sent out to an up stream sip peer are being rejected due to a Duplicate UUID and Freeswitch responses with 503 Maximum Calls in Progress. The problem appears to happen after the digest authentication takes place as below: ------------------------------------------------------------------------ recv 769 bytes from udp/[10.20.10.90]:5060 at 06:37:37.298978: ------------------------------------------------------------------------ INVITE sip:99992912@10.20.10.10 SIP/2.0 Via: SIP/2.0/UDP 10.20.10.90:5060;branch=z9hG4bK0e4d9102;rport From: "1677288" <sip:1677288@10.20.10.10>;tag=as753afbc5 To: <sip:99992912@10.20.10.10> Contact: <sip:1677288@10.20.10.90:5060> Call-ID: 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10 CSeq: 102 INVITE User-Agent: Asterisk PBX (digium) Max-Forwards: 70 Date: Mon, 10 Jun 2013 06:38:34 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Content-Type: application/sdp Content-Length: 213 v=0 o=root 3216 3216 IN IP4 10.20.10.90 s=session c=IN IP4 10.20.10.90 t=0 0 m=audio 10000 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv ------------------------------------------------------------------------ send 311 bytes to udp/[10.20.10.90]:5060 at 06:37:37.299263: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.20.10.90:5060;branch=z9hG4bK0e4d9102;rport=5060 From: "1677288" <sip:1677288@10.20.10.10>;tag=as753afbc5 To: <sip:99992912@10.20.10.10> Call-ID: 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10 CSeq: 102 INVITE User-Agent: SipTesting Content-Length: 0 ------------------------------------------------------------------------ 2013-06-10 16:37:37.296945 [NOTICE] switch_channel.c:1027 New Channel sofia/external/1677288(a)10.20.10.10 [ 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10] 2013-06-10 16:37:37.296945 [DEBUG] switch_core_session.c:999 Send signal sofia/external/1677288(a)10.20.10.10 [BREAK] 2013-06-10 16:37:37.296945 [DEBUG] switch_core_session.c:999 Send signal sofia/external/1677288(a)10.20.10.10 [BREAK] 2013-06-10 16:37:37.296945 [DEBUG] switch_core_state_machine.c:415 (sofia/external/1677288(a)10.20.10.10) Running State Change CS_NEW 2013-06-10 16:37:37.296945 [DEBUG] switch_core_state_machine.c:433 (sofia/external/1677288(a)10.20.10.10) State NEW 2013-06-10 16:37:37.316945 [DEBUG] sofia.c:5689 Channel sofia/external/ 1677288(a)10.20.10.10 entering state [received][100] 2013-06-10 16:37:37.316945 [DEBUG] sofia.c:5700 Remote SDP: v=0 o=root 3216 3216 IN IP4 10.20.10.90 s=session c=IN IP4 10.20.10.90 t=0 0 m=audio 10000 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 2013-06-10 16:37:37.316945 [DEBUG] sofia_glue.c:5176 Audio Codec Compare [PCMA:8:8000:20:64000]/[G729:18:8000:20:8000] 2013-06-10 16:37:37.316945 [DEBUG] sofia_glue.c:5176 Audio Codec Compare [PCMA:8:8000:20:64000]/[G729:18:8000:30:8000] 2013-06-10 16:37:37.316945 [DEBUG] sofia_glue.c:5176 Audio Codec Compare [PCMA:8:8000:20:64000]/[G729:18:8000:40:8000] 2013-06-10 16:37:37.316945 [DEBUG] sofia_glue.c:5176 Audio Codec Compare [PCMA:8:8000:20:64000]/[G729:18:8000:60:8000] 2013-06-10 16:37:37.316945 [DEBUG] sofia_glue.c:5176 Audio Codec Compare [PCMA:8:8000:20:64000]/[GSM:3:8000:20:13200] 2013-06-10 16:37:37.316945 [DEBUG] sofia_glue.c:5176 Audio Codec Compare [PCMA:8:8000:20:64000]/[PCMA:8:8000:20:64000] 2013-06-10 16:37:37.316945 [DEBUG] sofia_glue.c:3119 Set Codec sofia/external/1677288(a)10.20.10.10 PCMA/8000 20 ms 160 samples 64000 bits 2013-06-10 16:37:37.316945 [DEBUG] switch_core_codec.c:111 sofia/external/ 1677288(a)10.20.10.10 Original read codec set to PCMA:8 2013-06-10 16:37:37.316945 [DEBUG] sofia_glue.c:5307 Set 2833 dtmf send/recv payload to 101 2013-06-10 16:37:37.316945 [DEBUG] sofia.c:5934 (sofia/external/ 1677288(a)10.20.10.10) State Change CS_NEW -> CS_INIT 2013-06-10 16:37:37.316945 [DEBUG] switch_core_session.c:1334 Send signal sofia/external/1677288(a)10.20.10.10 [BREAK] 2013-06-10 16:37:37.316945 [DEBUG] switch_core_state_machine.c:415 (sofia/external/1677288(a)10.20.10.10) Running State Change CS_INIT 2013-06-10 16:37:37.316945 [DEBUG] switch_core_state_machine.c:454 (sofia/external/1677288(a)10.20.10.10) State INIT 2013-06-10 16:37:37.316945 [DEBUG] mod_sofia.c:87 sofia/external/ 1677288(a)10.20.10.10 SOFIA INIT 2013-06-10 16:37:37.316945 [DEBUG] mod_sofia.c:127 (sofia/external/ 1677288(a)10.20.10.10) State Change CS_INIT -> CS_ROUTING 2013-06-10 16:37:37.316945 [DEBUG] switch_core_session.c:1334 Send signal sofia/external/1677288(a)10.20.10.10 [BREAK] 2013-06-10 16:37:37.316945 [DEBUG] switch_core_state_machine.c:454 (sofia/external/1677288(a)10.20.10.10) State INIT going to sleep 2013-06-10 16:37:37.316945 [DEBUG] switch_core_state_machine.c:415 (sofia/external/1677288(a)10.20.10.10) Running State Change CS_ROUTING 2013-06-10 16:37:37.316945 [DEBUG] switch_channel.c:2110 (sofia/external/ 1677288(a)10.20.10.10) Callstate Change DOWN -> RINGING 2013-06-10 16:37:37.316945 [DEBUG] switch_core_state_machine.c:470 (sofia/external/1677288(a)10.20.10.10) State ROUTING 2013-06-10 16:37:37.316945 [DEBUG] mod_sofia.c:150 sofia/external/ 1677288(a)10.20.10.10 SOFIA ROUTING 2013-06-10 16:37:37.316945 [DEBUG] switch_core_state_machine.c:117 sofia/external/1677288(a)10.20.10.10 Standard ROUTING 2013-06-10 16:37:37.316945 [INFO] mod_dialplan_xml.c:558 Processing 1677288 <1677288>->99992912 in context public Dialplan: sofia/external/1677288(a)10.20.10.10 parsing [public->unloop] continue=false Dialplan: sofia/external/1677288(a)10.20.10.10 Regex (PASS) [unloop] ${unroll_loops}(true) =~ /^true$/ break=on-false Dialplan: sofia/external/1677288(a)10.20.10.10 Regex (FAIL) [unloop] ${sip_looped_call}() =~ /^true$/ break=on-false Dialplan: sofia/external/1677288(a)10.20.10.10 parsing [public->check_auth] continue=true Dialplan: sofia/external/1677288(a)10.20.10.10 Regex (FAIL) [check_auth] ${sip_authorized}() =~ /^true$/ break=never Dialplan: sofia/external/1677288(a)10.20.10.10 ANTI-Action respond(407) Dialplan: sofia/external/1677288(a)10.20.10.10 parsing [public->transfer_to_default] continue=false Dialplan: sofia/external/1677288(a)10.20.10.10 Absolute Condition [transfer_to_default] Dialplan: sofia/external/1677288(a)10.20.10.10 Action transfer(${destination_number} XML default) 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:167 (sofia/external/1677288(a)10.20.10.10) State Change CS_ROUTING -> CS_EXECUTE 2013-06-10 16:37:37.326961 [DEBUG] switch_core_session.c:1334 Send signal sofia/external/1677288(a)10.20.10.10 [BREAK] 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:470 (sofia/external/1677288(a)10.20.10.10) State ROUTING going to sleep 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:415 (sofia/external/1677288(a)10.20.10.10) Running State Change CS_EXECUTE 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:477 (sofia/external/1677288(a)10.20.10.10) State EXECUTE 2013-06-10 16:37:37.326961 [DEBUG] mod_sofia.c:243 sofia/external/ 1677288(a)10.20.10.10 SOFIA EXECUTE 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:209 sofia/external/1677288(a)10.20.10.10 Standard EXECUTE EXECUTE sofia/external/1677288(a)10.20.10.10 respond(407) 2013-06-10 16:37:37.326961 [DEBUG] mod_sofia.c:2666 Responding with 407 [(null)] 2013-06-10 16:37:37.326961 [NOTICE] mod_sofia.c:2725 Hangup sofia/external/ 1677288(a)10.20.10.10 [CS_EXECUTE] [CALL_REJECTED] 2013-06-10 16:37:37.326961 [DEBUG] switch_channel.c:3129 Send signal sofia/external/1677288(a)10.20.10.10 [KILL] 2013-06-10 16:37:37.326961 [DEBUG] switch_core_session.c:1334 Send signal sofia/external/1677288(a)10.20.10.10 [BREAK] 2013-06-10 16:37:37.326961 [DEBUG] switch_core_session.c:2732 sofia/external/1677288(a)10.20.10.10 skip receive message [APPLICATION_EXEC_COMPLETE] (channel is hungup already) 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:477 (sofia/external/1677288(a)10.20.10.10) State EXECUTE going to sleep 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:415 (sofia/external/1677288(a)10.20.10.10) Running State Change CS_HANGUP 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:678 (sofia/external/1677288(a)10.20.10.10) State HANGUP 2013-06-10 16:37:37.326961 [DEBUG] mod_sofia.c:504 Channel sofia/external/ 1677288(a)10.20.10.10 hanging up, cause: CALL_REJECTED 2013-06-10 16:37:37.326961 [DEBUG] mod_sofia.c:600 Challenging call 2013-06-10 16:37:37.326961 [DEBUG] mod_sofia.c:638 Responding to INVITE with: 407 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:48 sofia/external/1677288(a)10.20.10.10 Standard HANGUP, cause: CALL_REJECTED 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:678 (sofia/external/1677288(a)10.20.10.10) State HANGUP going to sleep 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:689 (sofia/external/1677288(a)10.20.10.10) Callstate Change RINGING -> HANGUP 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:446 (sofia/external/1677288(a)10.20.10.10) State Change CS_HANGUP -> CS_REPORTING 2013-06-10 16:37:37.326961 [DEBUG] switch_core_session.c:1334 Send signal sofia/external/1677288(a)10.20.10.10 [BREAK] send 803 bytes to udp/[10.20.10.90]:5060 at 06:37:37.331025: ------------------------------------------------------------------------ SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 10.20.10.90:5060;branch=z9hG4bK0e4d9102;rport=5060 From: "1677288" <sip:1677288@10.20.10.10>;tag=as753afbc5 To: <sip:99992912@10.20.10.10>;tag=ge05D2HSyNegQ Call-ID: 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10 CSeq: 102 INVITE User-Agent: SipTesting Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Proxy-Authenticate: Digest realm="10.20.10.10", nonce="3d9a75c8-d198-11e2-a1fd-9f60ee575d4e", algorithm=MD5, qop="auth" Content-Length: 0 ------------------------------------------------------------------------ 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:415 (sofia/external/1677288(a)10.20.10.10) Running State Change CS_REPORTING 2013-06-10 16:37:37.326961 [DEBUG] switch_core_state_machine.c:761 (sofia/external/1677288(a)10.20.10.10) State REPORTING recv 403 bytes from udp/[10.20.10.90]:5060 at 06:37:37.333826: ------------------------------------------------------------------------ ACK sip:99992912@10.20.10.10 SIP/2.0 Via: SIP/2.0/UDP 10.20.10.90:5060;branch=z9hG4bK0e4d9102;rport From: "1677288" <sip:1677288@10.20.10.10>;tag=as753afbc5 To: <sip:99992912@10.20.10.10>;tag=ge05D2HSyNegQ Contact: <sip:1677288@10.20.10.90:5060> Call-ID: 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10 CSeq: 102 ACK User-Agent: Asterisk PBX (digium) Max-Forwards: 70 Content-Length: 0 ------------------------------------------------------------------------ recv 1020 bytes from udp/[10.20.10.90]:5060 at 06:37:37.334446: ------------------------------------------------------------------------ INVITE sip:99992912@10.20.10.10 SIP/2.0 Via: SIP/2.0/UDP 10.20.10.90:5060;branch=z9hG4bK2bcc3b6b;rport From: "1677288" <sip:1677288@10.20.10.10>;tag=as753afbc5 To: <sip:99992912@10.20.10.10> Contact: <sip:1677288@10.20.10.90:5060> Call-ID: 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10 CSeq: 103 INVITE User-Agent: Asterisk PBX (digium) Max-Forwards: 70 Proxy-Authorization: Digest username="1677288", realm="10.20.10.10", algorithm=MD5, uri="sip:99992912@10.20.10.10", nonce="3d9a75c8-d198-11e2-a1fd-9f60ee575d4e", response="5c9facef9ebcc380f74ec52816892694", qop=auth, cnonce="1930827a", nc=00000001 Date: Mon, 10 Jun 2013 06:38:34 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Content-Type: application/sdp Content-Length: 213 v=0 o=root 3216 3217 IN IP4 10.20.10.90 s=session c=IN IP4 10.20.10.90 t=0 0 m=audio 10000 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv ------------------------------------------------------------------------ send 311 bytes to udp/[10.20.10.90]:5060 at 06:37:37.334699: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.20.10.90:5060;branch=z9hG4bK2bcc3b6b;rport=5060 From: "1677288" <sip:1677288@10.20.10.10>;tag=as753afbc5 To: <sip:99992912@10.20.10.10> Call-ID: 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10 CSeq: 103 INVITE User-Agent: SipTesting Content-Length: 0 ------------------------------------------------------------------------ 2013-06-10 16:37:37.326961 [CRIT] switch_core_session.c:2185 Duplicate UUID! send 695 bytes to udp/[10.20.10.90]:5060 at 06:37:37.334857: ------------------------------------------------------------------------ SIP/2.0 503 Maximum Calls In Progress Via: SIP/2.0/UDP 10.20.10.90:5060;branch=z9hG4bK2bcc3b6b;rport=5060 From: "1677288" <sip:1677288@10.20.10.10>;tag=as753afbc5 To: <sip:99992912@10.20.10.10>;tag=HQSyFX2vUy42j Call-ID: 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10 CSeq: 103 INVITE Retry-After: 300 User-Agent: SipTesting Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Length: 0 ------------------------------------------------------------------------ recv 403 bytes from udp/[10.20.10.90]:5060 at 06:37:37.337584: ------------------------------------------------------------------------ ACK sip:99992912@10.20.10.10 SIP/2.0 Via: SIP/2.0/UDP 10.20.10.90:5060;branch=z9hG4bK2bcc3b6b;rport From: "1677288" <sip:1677288@10.20.10.10>;tag=as753afbc5 To: <sip:99992912@10.20.10.10>;tag=HQSyFX2vUy42j Contact: <sip:1677288@10.20.10.90:5060> Call-ID: 23dbb80216dc65a178bef5315cbc687d(a)10.20.10.10 CSeq: 103 ACK User-Agent: Asterisk PBX (digium) Max-Forwards: 70 Content-Length: 0 ------------------------------------------------------------------------ 2013-06-10 16:37:37.336949 [DEBUG] switch_core_state_machine.c:92 sofia/external/1677288(a)10.20.10.10 Standard REPORTING, cause: CALL_REJECTED 2013-06-10 16:37:37.336949 [DEBUG] switch_core_state_machine.c:761 (sofia/external/1677288(a)10.20.10.10) State REPORTING going to sleep 2013-06-10 16:37:37.336949 [DEBUG] switch_core_state_machine.c:440 (sofia/external/1677288(a)10.20.10.10) State Change CS_REPORTING -> CS_DESTROY 2013-06-10 16:37:37.336949 [DEBUG] switch_core_session.c:1334 Send signal sofia/external/1677288(a)10.20.10.10 [BREAK] 2013-06-10 16:37:37.336949 [DEBUG] switch_core_session.c:1542 Session 546 (sofia/external/1677288(a)10.20.10.10) Locked, Waiting on external entities 2013-06-10 16:37:37.336949 [NOTICE] switch_core_session.c:1560 Session 546 (sofia/external/1677288(a)10.20.10.10) Ended 2013-06-10 16:37:37.336949 [NOTICE] switch_core_session.c:1564 Close Channel sofia/external/1677288(a)10.20.10.10 [CS_DESTROY] 2013-06-10 16:37:37.336949 [DEBUG] switch_core_state_machine.c:565 (sofia/external/1677288(a)10.20.10.10) Callstate Change HANGUP -> DOWN 2013-06-10 16:37:37.336949 [DEBUG] switch_core_state_machine.c:568 (sofia/external/1677288(a)10.20.10.10) Running State Change CS_DESTROY 2013-06-10 16:37:37.336949 [DEBUG] switch_core_state_machine.c:578 (sofia/external/1677288(a)10.20.10.10) State DESTROY 2013-06-10 16:37:37.336949 [DEBUG] mod_sofia.c:397 sofia/external/ 1677288(a)10.20.10.10 SOFIA DESTROY 2013-06-10 16:37:37.336949 [DEBUG] switch_core_state_machine.c:99 sofia/external/1677288(a)10.20.10.10 Standard DESTROY 2013-06-10 16:37:37.336949 [DEBUG] switch_core_state_machine.c:578 (sofia/external/1677288(a)10.20.10.10) State DESTROY going to sleep The only thing that I do is that I do bridge the incoming and outgoing on the same channel. I have made sure that the maximum amount of sessions has been increased and I can see any reason why the UUID would be duplicated as I have been able to replicate the same call from a SPA504G and the call has progressed without any issues. If any one has any ideas on what may be causing this it would be appreciated. Thanks David

2 1

Israel SIP provider
by Moishe Grunstein 10 Jun '13

10 Jun '13

Can someone please recommend a reliable Israeli SIP provider? Thanks, Moishe Grunstein Tornado Computer Systems, Inc. 212.400.7650 888.IPPBX.US Service Request Email: support(a)nysolutions.com<mailto:support@nysolutions.com> Polycom Certified VAR Microsoft Small Business Specialist, Cisco SMB Select Certified [cid:image001.jpg@01C72F94.9EE45D60]<http://www.nysolutions.com/> Computer Networking * Managed Services * IP Video Surveillance * Network Assessments * Web Solutions * Voice over IP * Disaster Recovery * Network Security * Site Surveys * CMS

4 6

LUA script has problem with bridge action?
by Vincent Xia 10 Jun '13

10 Jun '13

i set the dialplan to call test.lua by adding <action application="lua" data="test.lua"/> it works fine when placing it before a "bridge" action, like <action application="lua" data="test.lua"/> <action application="bridge" data="user/${dialed_extension}"/> but if i put "lua" after "bridge" <action application="bridge" data="user/${dialed_extension}"/> <action application="lua" data="test.lua"/> then test.lua is not executed, no matter the dialed_extension answered the call or not, my question is: 1. why is this happening? 2. how can i get test.lua get executed after "bridge"?

4 6

DAHDI_SPANCONFIG failed on span 1: Invalid argument (22)
by Ashish gautam 10 Jun '13

10 Jun '13

Hi, I am getting this error while configuring Digium 8 span PRI card. I am attaching system.conf, freetdm.conf,and freetdm.conf.xml here. Please help. -- Ashish Gautam Nucleus Microsystems (Pvt.) Ltd. Ph. 011 47574758

2 3