August 2011 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Forcing CN offer
by Alex Massover 28 Aug '11

28 Aug '11

Hello, I'm working on the following scenarios: scenario 1: A --> FS --> B scenario 2: C --> FS --> A Where A supports CN (a=rtpmap:13 CN/8000) and requires CN negotiation, and B and C do not support and aren't able to negotiate it. I successfully implemented scenario 1, CN is negotiated between A party and FS, and not negotiated between FS and B. But scenario 2 doesn't work for me! When C doesn't offer CN in INVITE towards FS, FS also doesn't offer CN in SDP in INVITE towards A. And nothing helps, tried all the combination of VAD options. Gateway A is in the same internal sip profile in both scenarios. This is the SDP in INVITE from C to FS: Media Description, name and address (m): audio 30224 RTP/AVP 0 8 18 101 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute (a): fmtp:18 annexb=no Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-16 Media Attribute (a): silenceSupp:off - - - - Media Attribute (a): ptime:20 Media Attribute (a): sendrecv And this is the SDP from FS towards A: Media Description, name and address (m): audio 23564 RTP/AVP 0 8 101 13 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-16 Media Attribute (a): ptime:20 FS even puts 13 in m= attribute, but doesn't add a= attribute for rtpmap:13. Is that a bug? -- Best Regards Alex Massover. This mail was sent via Mail-SeCure System.

2 2

odd behavior with freeswitch current
by Kevin Raison 28 Aug '11

28 Aug '11

I am running the most current version of Freeswitch from git on Ubuntu Linux 9.10 64 bit. I have a pair of these systems that are handling no more than 12 simultaneous calls each. Over time, Freeswitch begins to take up more and more CPU, and after about 2 weeks, it is using up so much CPU that call quality starts to degrade. It will be churning away even when there are no active calls. A restart of Freeswitch cures the problem for a couple of weeks. Can someone give me pointers on where to start debugging this issue? Or perhaps a better remedy than a restart? Thanks! Kevin Raison

2 4

SYSTEM_SHUTDOWN
by DJB International 27 Aug '11

27 Aug '11

I have one FS that set up similar to the others, but the weird thing about this one is that when I shutdown the FS when there are calls running, it never generated CDRs of those running calls before the system got shutdown while the other servers always generate those CDRs with hangup_cause SYSTEM_SHUTDOWN. What would be the reason for this particular server not to write the CDRs when it's shutting down like the other servers? By the way, I am using mod_cdr_csv. Thank you, Dorn B.

1 0

call_timeout
by Federico Beffa 27 Aug '11

27 Aug '11

I've just traced a call on my Asterisk system and ... well, I get exactly the same behavior. The provider must have changed settings recently without any notice. In fact my mailbox is never reached anymore since I'm waiting for 30 seconds, but they CANCEL after 20... sorry for making you loose time... In any case I've learned how to trace calls in FreeSwitch :-) Regards, Fede

1 0

call_timeout
by Federico Beffa 27 Aug '11

27 Aug '11

Is there a way to force the provider's proxy to wait longer with some kind of signal? I'm using "ring_ready" before transfer/bridge. Should I add or replace it with something else? On another system I have Asterisk installed (I'm planning to replace it with freeswitch) and for some reason the same provider does not drop the call for much longer. I guess I will have to trace the Asterisk call and compare... Thanks, Fede >Your provider seems to be dropping the call on you. > >see - > >recv 415 bytes from udp/[195.190.1xx.2xx]:5060 at 18:57:29.322712: > ------------------------------------------------------------------------ > CANCEL >sip:gw+ticinocom_private at 84.55.2xx.xx:5080;transport=udp;gw=ticinocom_private >SIP/2.0 > Via: SIP/2.0/UDP >195.190.1xx.2xx:5060;branch=z9hG4bK-d8754z-81e78d37b38d1735-1---d8754z-;rport > Max-Forwards: 70 > To: <sip:41916001220 at 195.190.1xx.2xx> > From: >"0765681626"<sip:0765681626 at 195.190.1xx.2xx>;tag=36agpbj7t724x3im.o > Call-ID: 7b9707bd-9e83a87-521dc9e3-3979 at 62.65.1xx.5x > CSeq: 737 CANCEL > Content-Length: 0

1 0

call_timeout
by Federico Beffa 27 Aug '11

27 Aug '11

The call monitored in the siptrace was as follows: the call originated from my mobile phone. The destination was my desk phone, a Snom 300. The Snom 300 is registered with FreeSwitch. The call from the mobile phone arrives to FreeSwitch through my provider. After ca. 19 secs the mobile phone seems to hangup and start a new call (all automatically with no manual intervention). If instead of calling from my mobile phone, I originate the call from X-lite (softphone), then, after ca. 19 secs the call is terminated. I'm trying to figure out how to prevent the call to be terminated or re-started after these 19 seconds. Hope this is clearer. Regards, Fede >Can you re-phrase your first paragraph? > >On Friday, 26 August 2011, Federico Beffa <beffa at ieee.org> wrote: >> Dear Jeff and Michael, >> >> thanks for the answer. I've put siptrace and log on pastebin: >> >> http://pastebin.freeswitch.org/17205 >> >> The case I've monitored was me calling with my mobile phone my desk phone >(Snom 300). The desk phone is registered to Freeswitch and the call goes >through my provider. Note that after ca. 19 secs my mobile phone makes a new >call, while if I try to do the same, but calling with X-lite, then X-lite >just hangs up.

2 1

call_timeout
by Federico Beffa 26 Aug '11

26 Aug '11

Dear Jeff and Michael, thanks for the answer. I've put siptrace and log on pastebin: http://pastebin.freeswitch.org/17205 The case I've monitored was me calling with my mobile phone my desk phone (Snom 300). The desk phone is registered to Freeswitch and the call goes through my provider. Note that after ca. 19 secs my mobile phone makes a new call, while if I try to do the same, but calling with X-lite, then X-lite just hangs up. The problem seems to be the CANCEL signal at line 459. Am I right in interpreting this signal as originating from my provider? If that is the case, then is there a way to tell my provider's proxy to wait longer? If my interpretation is correct, then I'm surprised that the same does not happen with Asterisk, where the call does not terminate (nor is re-started) for more than 1 minute. Thanks for any advise! Fede

2 1

Error SRTP unprotect
by Aakash 26 Aug '11

26 Aug '11

Hi Guys, I am using latest git version.Sometimes i am getting an error as below [ERR] switch_rtp.c:2559 Error: SRTP unprotect failed with code 7 (auth check failed) The calls got disconnected when this error hits. Thanks, Aakash -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Error-SRTP-unprotect-tp673023… Sent from the freeswitch-users mailing list archive at Nabble.com.

1 0

PRI to VoIP gateway devices
by Michael Collins 26 Aug '11

26 Aug '11

Hello gang, If anyone out there has a PRI to VoIP gateway device that we can borrow (or that you'd like to donate) to the FreeSWITCH project please let me know. We are looking for something like the Vegastream 400 or the Audiocodes Mediant 600. If you have anything like these that are just collecting dust on a shelf somewhere please contact me off list. Thanks! -Michael

1 0

call_timeout
by Federico Beffa 26 Aug '11

26 Aug '11

Hi, I've setup the dialplan such that when I receive a call from a provider (public context), the call get transferred to an extension in the default context (in a similar way as the default config). However, no matter what I set for call_timeout, the call is always terminated after ca. 19 seconds with a cause ORIGINATOR_CANCEL. I would like to extend the timeout period. This is my public entry for the incoming call: <include> <extension name="incoming_call"> <condition field="destination_number" expression="^XXXXX$"> <action application="set" data="domain_name=$${domain}"/> <action application="export" data="call_timeout=60"/> <action application="export" data="bridge_answer_timeout=60"/> <action application="export" data="originate_timeout=60"/> <action application="ring_ready"/> <action application="bridge" data="user/1000@${domain_name}"/>  <action application="hangup"/> </condition> </extension> </include> And this is part of the log: 2011-08-25 23:57:30.920053 [NOTICE] sofia.c:5226 Ring-Ready sofia/external/0916001220! 2011-08-25 23:57:30.920053 [NOTICE] mod_sofia.c:2366 Ring-Ready sofia/internal/1001@xxxxx! 2011-08-25 23:57:30.920053 [NOTICE] switch_ivr_originate.c:481 Ring Ready sofia/internal/1001@xxxxx! 2011-08-25 23:57:30.960053 [NOTICE] sofia.c:5226 Ring-Ready sofia/internal/ sip:1000@192.168.0.5:31148! 2011-08-25 23:57:30.960053 [NOTICE] switch_ivr_originate.c:481 Ring Ready sofia/external/0916001220(a)195.190.166.249! 2011-08-25 23:57:50.900063 [NOTICE] sofia.c:5872 Hangup sofia/external/ 0916001220(a)195.190.166.249 [CS_EXECUTE] [ORIGINATOR_CANCEL] 2011-08-25 23:57:50.900063 [NOTICE] switch_ivr_originate.c:3144 Hangup sofia/internal/sip:1000@192.168.0.5:31148 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2011-08-25 23:57:50.900063 [NOTICE] switch_ivr_originate.c:2436 Cannot create outgoing channel of type [user] cause: [ORIGINATOR_CANCEL] 2011-08-25 23:57:50.900063 [INFO] mod_dptools.c:2696 Originate Failed. Cause: ORIGINATOR_CANCEL 2011-08-25 23:57:50.900063 [NOTICE] sofia.c:5872 Hangup sofia/external/0916001220 [CS_CONSUME_MEDIA] [NORMAL_TEMPORARY_FAILURE] 2011-08-25 23:57:50.900063 [NOTICE] switch_core_session.c:1353 Session 11 (sofia/external/0916001220(a)195.190.166.249) Ended 2011-08-25 23:57:50.900063 [NOTICE] switch_core_session.c:1355 Close Channel sofia/external/0916001220(a)195.190.166.249 [CS_DESTROY] 2011-08-25 23:57:50.900063 [NOTICE] switch_core_session.c:1353 Session 12 (sofia/internal/sip:1000@192.168.0.5:31148) Ended 2011-08-25 23:57:50.900063 [NOTICE] switch_core_session.c:1355 Close Channel sofia/internal/sip:1000@192.168.0.5:31148 [CS_DESTROY] 2011-08-25 23:57:50.900063 [NOTICE] switch_core_session.c:1353 Session 10 (sofia/external/0916001220) Ended 2011-08-25 23:57:50.900063 [NOTICE] switch_core_session.c:1355 Close Channel sofia/external/0916001220 [CS_DESTROY] 2011-08-25 23:57:50.900063 [INFO] mod_dptools.c:2696 Originate Failed. Cause: NORMAL_TEMPORARY_FAILURE 2011-08-25 23:57:50.900063 [NOTICE] mod_dptools.c:2815 Hangup sofia/internal/1001@xxxxx [CS_EXECUTE] [NORMAL_TEMPORARY_FAILURE] 2011-08-25 23:57:50.900063 [NOTICE] switch_core_session.c:1353 Session 9 (sofia/internal/1001@xxxxx) Ended 2011-08-25 23:57:50.900063 [NOTICE] switch_core_session.c:1355 Close Channel sofia/internal/1001@xxxxx [CS_DESTROY] I've tryied with "transfer" and with "bridge" also setting [leg_timeout=60], but no luck. I've changed all timeout related values in default.xml as well. If the call comes from a phone registered locally, then the timeout works fine. The problem only exists with calls coming from outside (the public context). However, the timeout does seems to be related to freeswitch and not the provider as I have another system running Asterisk and there the problem (using the same provider accounts) does not exist. I would really appreciate any suggestion on how to extend calls timeout. Regards, Fede

3 2