July 2014 - FreeSWITCH-users - FreeSWITCH Mailing Lists

wss conection closed
by Javier Menendez 16 Jul '14

16 Jul '14

Hi, I am trying to get the wss connection work, tried everything and still doesn't work, I don't think it is a certificate problem because if I try this manually: curl -v https://myhost.com:10081/ -H "Upgrade: WebSocket" -H "Connection: Upgrade" -H "Sec-WebSocket-Protocol: sip" -H "Sec-WebSocket-Key: +LLGYSDSKelND6UVF9z71w==" -H "Sec-WebSocket-Version: 13" * About to connect() to myhost.com port 10081 (#0) * Trying X.X.X.X... connected * Connected to myhost.com (X.X.X.X) port 10081 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using AES256-SHA * Server certificate: * subject: OU=Domain Control Validated; CN=myhost.com * start date: 2014-06-16 10:09:42 GMT * expire date: 2016-06-07 11:02:46 GMT * subjectAltName: myhost.com matched * issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU= http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2 * SSL certificate verify ok. > GET / HTTP/1.1 > User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8o zlib/1.2.3.3 libidn/1.15 > Host: myhost.com:10081 > Accept: */* > Upgrade: WebSocket > Connection: Upgrade > Sec-WebSocket-Protocol: sip > Sec-WebSocket-Key: +LLGYSDSKelND6UVF9z71w== > Sec-WebSocket-Version: 13 > < HTTP/1.1 101 Switching Protocols < Upgrade: websocket < Connection: Upgrade < Sec-WebSocket-Accept: CQsVOMdurBA so it seems to work, but if I try with jssip or sipml5 library I got this trace log and the socket gets disconnected within half second freeswitch@internal> tport.c:2749 tport_wakeup_pri() tport_wakeup_pri(0x7f2198004f20): events IN tport.c:862 tport_alloc_secondary() tport_alloc_secondary(0x7f2198004f20): new secondary tport 0x7f21980afb20 tport.c:2640 tport_accept() tport_accept(0x7f21980afb20): new connection from wss/130.117.88.33:62056/sips tport.c:2773 tport_wakeup() tport_wakeup(0x7f21980afb20): events IN tport.c:2864 tport_recv_event() tport_recv_event(0x7f21980afb20) tport.c:2296 tport_set_secondary_timer() tport(0x7f21980afb20): reset timer tport.c:2773 tport_wakeup() tport_wakeup(0x7f21980afb20): events IN HUP ERR nta.c:2719 agent_tp_error() nta_agent: tport: Conexión reinicializada por la máquina remota tport.c:2090 tport_close() tport_close(0x7f21980afb20): wss/ 130.117.88.33:62056/sips I am using last version from git and I also tried with 1.4 versions. I have accept-blind-auth and accept-blind-reg to true, any clue?

3 9

confirmation for group_confirm
by Grant Bagdasarian 16 Jul '14

16 Jul '14

Hello, Is there a way to know in the incoming channel (A) if one of the destinations has pressed the group_confirm_key? Something like a "Answer Confirmation" confirmation. I'm bridging the incoming leg to multiple destinations simultaneously and on answer they have to press the confirm key in order to accept the call. When no one has answered or pressed the key, the incoming channel should be bridged to a final destination. I have no idea how to do the final bridge if the above condition is met. Simultaneous bridging and configuring the group_confirm is no problem. I'd like to this all of this in XML dialplan if possible. Other suggestions are welcome as well. Any ideas? Regards, Grant

2 4

Freeswitch Week in Review(Master Branch) July 6th-12th
by Kathleen King 15 Jul '14

15 Jul '14

Hello, again. This week in the FreeSWITCH master branch we had 40 commits. We had quite a few new features this week such as work in mod_LDAP to allow for authenticating from LDAP instead of the XML directory, added a new option to request TEP to be used for an outbound fax call in spandsp, added additional warnings to remind users to change the default password in the default dialplan, support for hardware DTMF in ftmod_gsm, and added clear channel for mono participants while in a conference with 3D callers. These are just a few of the commits for this week and more miscellaneous commits can be found in the attached text document. The following bugs were squashed: ba067f3 Fix for failing rpm build in mod_spidermonkey. Jira: http://jira.freeswitch.org/browse/FS-6563 e1d814b Fix for CDR insert fail in mod_cdr_pg_csv when variable with quote="false" attribute is not defined in mod_cdr_pg_csv. Jira: http://jira.freeswitch.org/browse/FS-6565 8951d26 Fixed a strepoch daylight saving time bug in FS core. Jira: http://jira.freeswitch.org/browse/FS-6626 8ec7b25 Enabled fscore_pb to work on OS X. Jira: http://jira.freeswitch.org/browse/FS-4939 21ae587 Removed disabling of require timer for T.38 re-invites in mod_sofia. New features that were added: 9a4e29d Authenticate users from LDAP instead of XML directory. Jira: http://jira.freeswitch.org/browse/FS-4870 a79a9ea Set total detect time variable in mod_avmd. Jira: http://jira.freeswitch.org/browse/FS-6373 ec00823 FS-5516 allow get params in URL in mod_xml_cdr. Jira: http://jira.freeswitch.org/browse/FS-5516 28e90ad FS-5501 fire event on profile start in mod_sofia Jira: http://jira.freeswitch.org/browse/FS-5501 a03963f Fold livetables into verto obj and expose moderator mode in mod_verto. 0fb179a Add new option to request TEP to be used for an outbound fax call in mod_spandsp a99df48 FS-4861 improve logging when using c++ wrapper in FS core. Jira: http://jira.freeswitch.org/browse/FS-4861 e79f872 Additional fields can now be specified by adding LOG_FIELDS[name=string_value,@#name=number_value] to beginning of log. Added _microtimestamp additional field since graylog2 only has millisecond timestamp precision in mod_graylog2. 07f4c62 Added ORDER BY score to select statement for 'callcenter_config queue list members QUEUE' in mod_conference. Jira: http://jira.freeswitch.org/browse/FS-6646 ebe4238 Added additional alerting if default directory password is not changed in default dialplan configs. 4bc1b73 Allow hwdtmf parameter to accept detect or generate in ftdmod_gsm. eae1c44 Additional input checks on LOG_FIELDS[] in mod_graylog2. 4021482 Added additional checks that HDLC frames arriving at the T.38 gateway engine begin with the correct 2 bytes in spandsp. 0b6f10a Added support for hardware DTMF in ftmod_gsm. a0a8a66 Increased expires from integer to bigint in mod_sofia. Jira: http://jira.freeswitch.org/browse/FS-6420 64489c5 Added support for DTMF generation to be performed in the signaling modules (currently only used by the gsm signaling driver) in freetdm fd9d77f Add clear channel for mono participants while in a conference with 3d callers in mod_conference. 88940d3 Log websocket write failures in mod_verto. Improvements in cross platform build supports: 99d0f13 Attempt to fix build of mod_cdr_pg_csv Jira: http://jira.freeswitch.org/browse/FS-6566 In terms of stability these were the use cases that were fixed: e742522 Fix several leaks on module shutdown in mod_freetdm. Feedback is welcome at kathleen.king(a)quentustech.com and the commits for this week are in the attached file along with the corresponding Jira links. -- Kathleen King Quentus Technologies, INC 1037 NE 65th St Suite 273 Seattle, WA 98115 Main: (253) 617-3210 Cell: (703) 859-3757 kathleen.king(a)quentustech.com

1 0

Re: [Freeswitch-users] Error in codec negotiation: What are all the places that specify accepted codecs for outgoing calls?
by Mark Boots 15 Jul '14

15 Jul '14

Hi Kristian, Sorry for the delay. Just to finally close off this thread, I tested with the 1.4 branch and that solved it. I haven’t seen any more of these INCOMPATIBLE_DESTINATION errors after the proxy fork and renegotiation. 100rel didn’t turn out to be necessary. Thanks for the help and guidance! +Mark On Jun 10, 2014, at 2:34 PM, freeswitch-users-request(a)lists.freeswitch.org wrote: > Send FreeSWITCH-users mailing list submissions to > freeswitch-users(a)lists.freeswitch.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > or, via email, send a message with subject or body 'help' to > freeswitch-users-request(a)lists.freeswitch.org > > You can reach the person managing the list at > freeswitch-users-owner(a)lists.freeswitch.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of FreeSWITCH-users digest..." > Today's Topics: > > 1. Re: Error in codec negotiation: What are all the places that > specify accepted codecs for outgoing calls? (Kristian Kielhofner) > 2. Re: STUN Binding request times out after 200 OK received on > client (Michael Jerris) > > From: Kristian Kielhofner <kris(a)kriskinc.com> > Subject: Re: [Freeswitch-users] Error in codec negotiation: What are all the places that specify accepted codecs for outgoing calls? > Date: June 10, 2014 at 2:28:27 PM CST > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > > > Mark, > > Have you tried any of my original suggestions? > > You have a good point on the behavior of FreeSWITCH for codec > negotiation in this specific scenario and although I can't point to a > commit I seem to recall that 1.4/master tweaked this behavior > significantly; it may "just work" for you. 100rel might be a good > option too but that could come with some other unintended effects. > > On Tue, Jun 10, 2014 at 11:12 AM, Mark Boots <mark(a)votomobile.org> wrote: >> Given that our provider does this 40% of the time in multiple countries, is >> there anything we can do to get this working with Freeswitch? >> >> It seems logical for this to work: we offered a range of codecs, the other >> end chose one, then for another part of the call chose another. Both codecs >> are supported by our end, so why should we reject the second just because >> another was used first? >> >> According to the console, Freeswitch is doing a codec renegotiation >> process... It's just not accepting anything other than 1 codec at this >> point. >> >> +Mark >> >> From: Michael Jerris <mike(a)jerris.com> >> Subject: Re: [Freeswitch-users] Error in codec negotiation: What are all the >> places that specify accepted codecs for outgoing calls? >> Date: 10 June 2014 12:42:31 GMT >> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> >> Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> >> >> >> Hmm, not sure thats true. You are not supposed to change codecs before the >> dialog is complete like this, its a violation of sdp o/a. >> >> On Jun 10, 2014, at 4:50 AM, Kristian Kielhofner <kris(a)kriskinc.com> wrote: >> >> Hi Mark, >> >> Thanks for providing the full log. >> >> While goofy this is perfectly valid behavior. Because your instance of >> Freeswitch offers pcma and pcmu it's ok for the other side to switch between >> the two in 183. >> >> A few things to try: >> >> - Limit your outbound offers to pcma or pcmu only (one codec). >> >> - The remote side appears to support 100rel (PRACK). Try enabling it in >> Freeswitch. While a long shot it's possible that PRACK'ing the initial >> received 183 might change the codec swap behavior of the remote end. >> >> - Try Freeswitch 1.4 or master. There's been some significant changes in >> media/SDP behavior, particularly when the remote end does technically >> standards compliant but goofy things with multiple codec offers. >> >> If none of these works you're only option may be to have the carrier take >> some action. >> >> On Monday, June 9, 2014, Mark Boots <mark(a)votomobile.org> wrote: >>> >>> Hi Kristian, >>> >>> I've narrowed this INCOMPATIBLE_DESTINATION error down to a specific case: >>> >>> 1 - Freeswitch sends the outgoing call, and offers PCMU/PCMA/GSM >>> 2 - Other end accepts only PCMU >>> 3 - At some point after Pre-answer, the other end issues a 183 Session >>> Progress, changing to only accept PCMA. >>> 4 - Freeswitch attempts to select new codecs but only looks at PCMU, and >>> cancels the call with INCOMPATIBLE_DESTINATION. >>> >>> >>> Here is the console log and sip trace... Hope it helps! >>> >>> +Mark >>> >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_ivr_originate.c:2069 Parsing >>> global variables >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [plivo_request_uuid]=[004fd8a2-f01e-11e3-844d-22000ad937f0] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [plivo_answer_url]=[http://10.8.0.1/deliverylogs/answer/752471] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [plivo_ring_url]=[http://127.0.0.1/callqueue/ring.php] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [plivo_hangup_url]=[http://127.0.0.1/callqueue/hangup.php] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [origination_caller_id_number]=[12026004299] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [plivo_from]=[12026004299] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [plivo_to]=[0011104555592211972] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [plivo_app]=[true] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [originate_timeout]=[60] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_event.c:1661 Parsing variable >>> [ignore_early_media]=[true] >>> 2014-06-09 21:35:39.615207 [NOTICE] switch_channel.c:1049 New Channel >>> sofia/external/0011104555592211972 [005052e6-f01e-11e3-bbae-cbf0f4eac998] >>> 2014-06-09 21:35:39.615207 [DEBUG] mod_sofia.c:5237 >>> (sofia/external/0011104555592211972) State Change CS_NEW -> CS_INIT >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_session.c:1351 Send signal >>> sofia/external/0011104555592211972 [BREAK] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:418 >>> (sofia/external/0011104555592211972) Running State Change CS_INIT >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:458 >>> (sofia/external/0011104555592211972) State INIT >>> 2014-06-09 21:35:39.615207 [DEBUG] mod_sofia.c:87 >>> sofia/external/0011104555592211972 SOFIA INIT >>> 2014-06-09 21:35:39.615207 [DEBUG] sofia_glue.c:2746 >>> sofia/external/0011104555592211972 sending invite version: 1.2.24 git >>> 7b74ee3 2014-06-03 00:26:24Z 32bit >>> Local SDP: >>> v=0 >>> o=FreeSWITCH 1402325141 1402325142 IN IP4 54.203.245.50 >>> s=FreeSWITCH >>> c=IN IP4 54.203.245.50 >>> t=0 0 >>> m=audio 24598 RTP/AVP 0 8 3 101 13 >>> a=rtpmap:101 telephone-event/8000 >>> a=fmtp:101 0-16 >>> a=ptime:20 >>> a=sendrecv >>> >>> 2014-06-09 21:35:39.615207 [DEBUG] mod_sofia.c:127 >>> (sofia/external/0011104555592211972) State Change CS_INIT -> CS_ROUTING >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_session.c:1351 Send signal >>> sofia/external/0011104555592211972 [BREAK] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:458 >>> (sofia/external/0011104555592211972) State INIT going to sleep >>> send 1071 bytes to udp/[108.59.2.133]:5060 at 21:35:39.620673: >>> >>> ------------------------------------------------------------------------ >>> INVITE sip:0011104555592211972@108.59.2.133 SIP/2.0 >>> Via: SIP/2.0/UDP 54.203.245.50:5080;rport;branch=z9hG4bKUNeNtZcZp5ZmB >>> Max-Forwards: 70 >>> From: "" <sip:12026004299@54.203.245.50>;tag=9Z1HtD145Qv3K >>> To: <sip:0011104555592211972@108.59.2.133> >>> Call-ID: d7aeb7a1-6ac0-1232-718c-22000ad937f0 >>> CSeq: 60838805 INVITE >>> Contact: >>> <sip:gw+voxbeam_outbound@54.203.245.50:5080;transport=udp;gw=voxbeam_outbound> >>> User-Agent: >>> FreeSWITCH-mod_sofia/1.2.24+git~20140603T002624Z~7b74ee3955~32bit >>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, >>> REGISTER, REFER, NOTIFY >>> Supported: timer, path, replaces >>> Allow-Events: talk, hold, conference, refer >>> Content-Type: application/sdp >>> Content-Disposition: session >>> Content-Length: 207 >>> X-FS-Support: update_display,send_info >>> Remote-Party-ID: >>> <sip:12026004299@54.203.245.50>;party=calling;screen=yes;privacy=off >>> >>> v=0 >>> o=FreeSWITCH 1402325141 1402325142 IN IP4 54.203.245.50 >>> s=FreeSWITCH >>> c=IN IP4 54.203.245.50 >>> t=0 0 >>> m=audio 24598 RTP/AVP 0 8 3 101 13 >>> a=rtpmap:101 telephone-event/8000 >>> a=fmtp:101 0-16 >>> a=ptime:20 >>> >>> ------------------------------------------------------------------------ >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_session.c:1016 Send signal >>> sofia/external/0011104555592211972 [BREAK] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:418 >>> (sofia/external/0011104555592211972) Running State Change CS_ROUTING >>> 2014-06-09 21:35:39.615207 [DEBUG] sofia.c:5845 Channel >>> sofia/external/0011104555592211972 entering state [calling][0] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:474 >>> (sofia/external/0011104555592211972) State ROUTING >>> 2014-06-09 21:35:39.615207 [DEBUG] mod_sofia.c:150 >>> sofia/external/0011104555592211972 SOFIA ROUTING >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_ivr_originate.c:67 >>> (sofia/external/0011104555592211972) State Change CS_ROUTING -> >>> CS_CONSUME_MEDIA >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_session.c:1351 Send signal >>> sofia/external/0011104555592211972 [BREAK] >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:474 >>> (sofia/external/0011104555592211972) State ROUTING going to sleep >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:418 >>> (sofia/external/0011104555592211972) Running State Change CS_CONSUME_MEDIA >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:493 >>> (sofia/external/0011104555592211972) State CONSUME_MEDIA >>> 2014-06-09 21:35:39.615207 [DEBUG] switch_core_state_machine.c:493 >>> (sofia/external/0011104555592211972) State CONSUME_MEDIA going to sleep >>> recv 367 bytes from udp/[108.59.2.133]:5060 at 21:35:39.725204: >>> >>> ------------------------------------------------------------------------ >>> SIP/2.0 100 Giving a try >>> Via: SIP/2.0/UDP >>> 54.203.245.50:5080;received=54.203.245.50;rport=5080;branch=z9hG4bKUNeNtZcZp5ZmB >>> From: "" <sip:12026004299@54.203.245.50>;tag=9Z1HtD145Qv3K >>> To: <sip:0011104555592211972@108.59.2.133> >>> Call-ID: d7aeb7a1-6ac0-1232-718c-22000ad937f0 >>> CSeq: 60838805 INVITE >>> Server: OpenSIPS (1.8.2-notls (x86_64/linux)) >>> Content-Length: 0 >>> >>> >>> ------------------------------------------------------------------------ >>> recv 657 bytes from udp/[108.59.2.133]:5060 at 21:35:41.191275: >>> >>> ------------------------------------------------------------------------ >>> SIP/2.0 183 Session Progress >>> Via: SIP/2.0/UDP 54.203.245.50:5080;rport;branch=z9hG4bKUNeNtZcZp5ZmB >>> From: "" <sip:12026004299@54.203.245.50>;tag=9Z1HtD145Qv3K >>> To: <sip:0011104555592211972@108.59.2.133>;tag=9312047651043624688 >>> Call-ID: d7aeb7a1-6ac0-1232-718c-22000ad937f0 >>> CSeq: 60838805 INVITE >>> Content-Type: application/sdp >>> Contact: <sip:callee@108.59.2.133;did=795.65454242> >>> Supported: timer,100rel >>> Content-Length: 226 >>> >>> v=0 >>> o=RISNEXT02 869 1999 IN IP4 80.84.30.41 >>> s=sip call >>> c=IN IP4 80.84.30.41 >>> t=0 0 >>> m=audio 42108 RTP/AVP 0 13 101 >>> a=rtpmap:0 PCMU/8000 >>> a=rtpmap:13 CN/8000 >>> a=rtpmap:101 telephone-event/8000 >>> a=fmtp:101 0-16 >>> a=ptime:20 >>> >>> ------------------------------------------------------------------------ >>> 2014-06-09 21:35:41.175213 [DEBUG] switch_core_session.c:1016 Send signal >>> sofia/external/0011104555592211972 [BREAK] >>> 2014-06-09 21:35:41.175213 [DEBUG] switch_core_session.c:1016 Send signal >>> sofia/external/0011104555592211972 [BREAK] >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia.c:5845 Channel >>> sofia/external/0011104555592211972 entering state [proceeding][183] >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia.c:5858 Remote SDP: >>> v=0 >>> o=RISNEXT02 869 1999 IN IP4 80.84.30.41 >>> s=sip call >>> c=IN IP4 80.84.30.41 >>> t=0 0 >>> m=audio 42108 RTP/AVP 0 13 101 >>> a=rtpmap:0 PCMU/8000 >>> a=rtpmap:13 CN/8000 >>> a=rtpmap:101 telephone-event/8000 >>> a=fmtp:101 0-16 >>> a=ptime:20 >>> >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:5284 Audio Codec Compare >>> [PCMU:0:8000:20:64000]/[PCMU:0:8000:20:64000] >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3192 Set Codec >>> sofia/external/0011104555592211972 PCMU/8000 20 ms 160 samples 64000 bits >>> 2014-06-09 21:35:41.175213 [DEBUG] switch_core_codec.c:111 >>> sofia/external/0011104555592211972 Original read codec set to PCMU:0 >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:5444 Set 2833 dtmf send >>> payload to 101 >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3451 AUDIO RTP >>> [sofia/external/0011104555592211972] 10.217.55.240 port 24598 -> 80.84.30.41 >>> port 42108 codec: 0 ms: 20 >>> 2014-06-09 21:35:41.175213 [DEBUG] switch_rtp.c:2040 Starting timer [soft] >>> 160 bytes per 20ms >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3718 Set 2833 dtmf send >>> payload to 101 >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3724 Set 2833 dtmf receive >>> payload to 101 >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3751 >>> sofia/external/0011104555592211972 Set rtp dtmf delay to 40 >>> 2014-06-09 21:35:41.175213 [DEBUG] sofia_glue.c:3757 Set comfort noise >>> payload to 13 >>> 2014-06-09 21:35:41.175213 [NOTICE] sofia_glue.c:4362 Pre-Answer >>> sofia/external/0011104555592211972! >> >> >> >> >> >> _______________________________________________ >> FreeSWITCH-users mailing list >> FreeSWITCH-users(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting(a)freeswitch.org >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> FreeSWITCH-users mailing list >> FreeSWITCH-users(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org >> > > > > -- > Kristian Kielhofner > > > > > > From: Michael Jerris <mike(a)jerris.com> > Subject: Re: [Freeswitch-users] STUN Binding request times out after 200 OK received on client > Date: June 10, 2014 at 2:33:30 PM CST > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > > > so that for sure doesn't have the fix i'm thinking in it. Can you try git master on freeswitch and see if that works any better? > > On Jun 10, 2014, at 8:25 PM, Peter Villeneuve <petervnv1(a)gmail.com> wrote: > >> I'm using FreeSWITCH Version 1.5.13b+git~20140515T183425Z~ebc0a99f1c~64bit. >> Server is on a public IP. What version of CSipSimple did Tony use to test? >> >> There have been some changes recently to ICE in CSip. I'm using latest nightly release (2414) http://nightlies.csipsimple.com/trunk/ with ICE set to aggressive mode. >> >> Also, I have Kamailio in front of FS on the same server, but that shouldn't really be an issue, no? >> >> Anyway, I have some FS logs posted here if you want to take a closer look http://pastebin.com/WNGcpTqB >> >> But I did just confirm that all works as expected with ICE turned off in CSip. >> >> >> On Tue, Jun 10, 2014 at 9:13 PM, Michael Jerris <mike(a)jerris.com> wrote: >> Tony just tested this and it worked with csipsimple. Can you confirm if you are testing with freeswitch from latest git master? is the server side on a public ip or behind nat? >> >> Mike >> >> On Jun 10, 2014, at 5:43 PM, Peter Villeneuve <petervnv1(a)gmail.com> wrote: >> >>> I think Michael's insight appears to be correct. >>> I say this because I also can't seem to get ICE to work correctly with FS when using the CSipSimple client with ICE support. >>> >>> As you can see in the CSipSimple logs here, it seems that FS fails to correctly respond to the STUN binding request, and thus ICE negotiation fails: >>> >>> 17:17:58.927 icetp00 ..Triggered check for check 1 not performed because it's in progress. Retransmitting >>> 17:17:58.927 utsx0x5dee930c ...STUN sending message (transmit count=7) >>> 17:17:59.040 timer_android. !FIRE timer 26 of heap 16 >>> 17:17:59.040 utsx0x5f6e659c STUN timeout waiting for response >>> 17:17:59.040 icetp00 .Check 2: [2] 192.168.1.4:4037-->79.my.serverIP:62203 (nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT) >>> 17:17:59.040 icetp00 ..Check 2: [2] 192.168.1.4:4037-->79.my.serverIP:62203: state changed from In Progress to Failed >>> 17:17:59.040 stun_session.c .tdata 0x5f6e6484 destroy request, force=1, tsx=0x5f6e659c >>> 17:17:59.040 timer_android. .Ask to cancel something already fired or cancelled : -1 @ 0x5f6e65dc >>> 17:17:59.040 utsx0x5f6e659c .STUN client transaction 0x5f6e659c stopped, ref_cnt=46 >>> 17:17:59.041 timer_android. FIRE done and released >>> 17:17:59.238 timer_android. FIRE timer 27 of heap 16 >>> 17:17:59.238 utsx0x5d9a080c STUN timeout waiting for response >>> 17:17:59.238 icetp00 .Check 0: [1] 192.168.1.4:4001-->79.my.serverIP:62202 (nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT) >>> 17:17:59.239 icetp00 ..Check 0: [1] 192.168.1.4:4001-->79.my.serverIP:62202: state changed from In Progress to Failed >>> 17:17:59.239 stun_session.c .tdata 0x5d9a06f4 destroy request, force=1, tsx=0x5d9a080c >>> 17:17:59.239 timer_android. .Ask to cancel something already fired or cancelled : -1 @ 0x5d9a084c >>> 17:17:59.239 utsx0x5d9a080c .STUN client transaction 0x5d9a080c stopped, ref_cnt=45 >>> 17:17:59.239 timer_android. FIRE done and released >>> 17:17:59.257 timer_android. FIRE timer 28 of heap 16 >>> 17:17:59.257 utsx0x5dee930c STUN timeout waiting for response >>> 17:17:59.257 icetp00 .Check 1: [1] 79.my.serverIP:56378-->79.my.serverIP:62202 (nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT) >>> 17:17:59.257 icetp00 ..Check 1: [1] 79.my.serverIP:56378-->79.my.serverIP:62202: state changed from In Progress to Failed >>> 17:17:59.258 stun_session.c .tdata 0x5dee91f4 destroy request, force=1, tsx=0x5dee930c >>> 17:17:59.258 timer_android. .Ask to cancel something already fired or cancelled : -1 @ 0x5dee934c >>> 17:17:59.258 utsx0x5dee930c .STUN client transaction 0x5dee930c stopped, ref_cnt=44 >>> 17:17:59.258 timer_android. FIRE done and released >>> 17:17:59.273 timer_android. FIRE timer 34 of heap 16 >>> 17:17:59.274 utsx0x5da8db64 STUN timeout waiting for response >>> 17:17:59.274 icetp00 .Check 3: [2] 79.my.serverIP2:54506-->79.my.serverIP:62203 (nominated): connectivity check FAILED: STUN transaction has timed out (PJNATH_ESTUNTIMEDOUT) >>> 17:17:59.274 icetp00 ..Check 3: [2] 79.my.serverIP2:54506-->79.my.serverIP:62203: state changed from In Progress to Failed >>> 17:17:59.274 timer_android. ..Ask to cancel something already fired or cancelled : -1 @ 0x5dc0b400 >>> 17:17:59.274 icetp00 ..ICE process complete, status=All ICE checklists failed (PJNATH_EICEFAILED) >>> 17:17:59.274 icetp00 ..Valid list >>> 17:17:59.274 timer_android. ..Scheduling timer 30 of 16 in 0 ms @ 0x5dc0b400 >>> 17:17:59.278 stun_session.c .tdata 0x5da8da4c destroy request, force=1, tsx=0x5da8db64 >>> 17:17:59.278 timer_android. .Ask to cancel something already fired or cancelled : -1 @ 0x5da8dba4 >>> 17:17:59.278 utsx0x5da8db64 .STUN client transaction 0x5da8db64 stopped, ref_cnt=45 >>> 17:17:59.278 timer_android. FIRE done and released >>> 17:17:59.289 timer_android. FIRE timer 30 of heap 16 >>> 17:17:59.289 icetp00 ICE negotiation failed after 8s:424: All ICE checklists failed (PJNATH_EICEFAILED) >>> >>> >>> On Tue, Jun 10, 2014 at 3:27 PM, Michael Jerris <mike(a)jerris.com> wrote: >>> Its possible that we have some conditions wrong for non-webrtc ice. You are going to need to trace the switch_core_media code a bit and see how we parse the sdp, what we are expecting, and how we turn on ice. I suspect we have conditions that tie some of the ice functionality incorrectly to other things required for webrtc. >>> >>> >>> On Jun 10, 2014, at 2:09 PM, Jayesh Nambiar <jayesh1017(a)gmail.com> wrote: >>> >>> > Hi, >>> > I am developing an iOS calling App with libnice for ICE capabilities. The calls go through freeswitch and since freeswitch supports ICE, I expected it to work out of the box. But I have a problem. The way libnice works is as follows: >>> > 1) The client sends INVITE with his candidates. >>> > 2) Freeswitch parses the candidates. >>> > 3) Immediately after 200 OK is received, I can see FreeSWITCH choosing an ICE candidate and logging "Activating Audio ICE" indicating the IP and Port and it sends media/RTP to. >>> > 4) But the libnice agent tries to look at the candidates received in 200 OK and tries to send a STUN binding request to FreeSWITCH IP as that IP is mentioned as ICE candidate in the 200 OK coming from freeswitch. >>> > 5) The FreeSWITCH doesn't respond to that STUN binding request and libnice agent times out. >>> > 6) Ideally, if libnice gets back a response from the freeswitch, it should initiate a Re-INVITE with the candidate pair selected. >>> > >>> > Now here, the freeswitch starts sending RTP to client's candidate, but the client gets stuck because the candidate pair is not formed as the libnice agent keeps waiting for a response for the STUN Binding Request. >>> > Is there anything that I am missing here. Any help is highly appreciated. >>> >>> >>> _________________________________________________________________________ >>> Professional FreeSWITCH Consulting Services: >>> consulting(a)freeswitch.org >>> http://www.freeswitchsolutions.com >>> >>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >>> http://www.cudatel.com >>> >>> Official FreeSWITCH Sites >>> http://www.freeswitch.org >>> http://wiki.freeswitch.org >>> http://www.cluecon.com >>> >>> FreeSWITCH-users mailing list >>> FreeSWITCH-users(a)lists.freeswitch.org >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>> http://www.freeswitch.org >>> >>> _________________________________________________________________________ >>> Professional FreeSWITCH Consulting Services: >>> consulting(a)freeswitch.org >>> http://www.freeswitchsolutions.com >>> >>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >>> http://www.cudatel.com >>> >>> Official FreeSWITCH Sites >>> http://www.freeswitch.org >>> http://wiki.freeswitch.org >>> http://www.cluecon.com >>> >>> FreeSWITCH-users mailing list >>> FreeSWITCH-users(a)lists.freeswitch.org >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>> http://www.freeswitch.org >> >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting(a)freeswitch.org >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> FreeSWITCH-users mailing list >> FreeSWITCH-users(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org >> >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting(a)freeswitch.org >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> FreeSWITCH-users mailing list >> FreeSWITCH-users(a)lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org > > > > _______________________________________________ > 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

Pausing dialplan execution
by Oleg Stolyar 15 Jul '14

15 Jul '14

Guys, is there a way to pause the execution of a dialplan? The sleep and answer_delay commands only pause the media but the rest of the dialplan still executes right away. The use case I have is this: 1. Dial FS from a WebRTC client. 2. Answer the call to start the handshake 3. Sleep for 2.5 sec to handle the handshake delay. 4. After that make a curl call to tell another system that the call is connected.

3 3

FYI, wiki.freeswitch.org is READ ONLY
by Brian West 15 Jul '14

15 Jul '14

We all know that wiki.freeswitch.org is a great resource and currently its not able to be updated because its read only while the docs are transitioning to https://confluence.freeswitch.org, If you find something that is out of place or wrong by all means please join the freeswitch-docs mailing list at http://lists.freeswitch.org, Then post a message, We will be having our weekly call at 2PM Central today, so aprox. 1.5 hours from now. sip:888@conference.freeswitch.org Or you can use Chrome/FireFox/Opera at: httsp://conference.freeswitch.org/verto/ Please join in, help us make the docs better. Thanks, -- *Brian West* brian(a)freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest

5 5

New warning message: sofia_dialog_probe_callback: not enough info to generate a dialog entry
by Sean Devoy 15 Jul '14

15 Jul '14

Hi, This is new to me, can anyone point me where I might find more information or what this means? I have not found any telephony event to correlate the messages to: 2014-07-11 19:45:02.938843 [WARNING] sofia_presence.c:1967 sofia_dialog_probe_callback: not enough info to generate a dialog entry 2014-07-11 20:04:15.449079 [WARNING] sofia_presence.c:1967 sofia_dialog_probe_callback: not enough info to generate a dialog entry 2014-07-11 20:04:34.479535 [WARNING] sofia_presence.c:1967 sofia_dialog_probe_callback: not enough info to generate a dialog entry 2014-07-11 20:14:46.999121 [WARNING] sofia_presence.c:1967 sofia_dialog_probe_callback: not enough info to generate a dialog entry Thanks, Sean

2 2

Aastra 673Xi and 675Xi Presence/BLF
by Chris Tunbridge 15 Jul '14

15 Jul '14

I'm currently experiencing presence/blf sticking either in the "Idle" or "Busy" states on the Aastra Phone's occasionally, I've seen (and tried) the recommendations found here https://confluence.freeswitch.org/display/FREESWITCH/Aastra when setting the mode to TCP, the phones intermittently go offline, I'll be trying a different firmware to confirm, but so far its not been a great experience. Currently running 3.3.1.2235 Just wondering if anyone else on the mailing list has experience with Aastra's, as my past experience with them in closed environments was great, but not so much with a hosted setup.

2 3

Changing hangup cause of b-leg when a-leg is parked
by Siri MM 15 Jul '14

15 Jul '14

Hi, Once two legs are connected, if I park the a-leg using uuid_park, b-leg gets automatically disconnected with hangup cause as Normal Clearing. Is there any way I could change this hangup cause?

3 2

Re: [Freeswitch-users] Freeswitch sending NOTIFY & OPTIONS to UAC directly bypassing proxy
by Luis Azedo 15 Jul '14

15 Jul '14

in kamailio you need to change the contact header by adding fs_path=sip:your.kamailio.ip.address:your_kamailio_port

1 0