July 2012 - FreeSWITCH-users - FreeSWITCH Mailing Lists

xml cdr with rc2
by Miha 23 Jul '12

23 Jul '12

HI, just one questione before I post to Jira. Is there any cdr problem with rc2. With the same dialplan that I have on FS verison 1.0.xxx from git (befor 1.2 appeared) I get on RC2 different values when 302 happens. Olso noticed that cdr for b leg are different (like on production FS with same dialplan). Is that normal or has anyone also noticed? THanks! Miha

2 4

Originate with python ESL
by James 22 Jul '12

22 Jul '12

I'm trying to do an originate command via python script and ESL. FS attempts to make this call but is rejected by my gateway with a 407. FS does not follow-up with an INVITE with the credentials. Is there a variable I need to set in order to do this? Here's the originate I'm using: e = con.api("create_uuid").getBody() res = con.bgapi("originate", "{origination_uuid=" + e + ",fax_verbose=true,ignore_early_media=true}sofia/gateway/myprovider/XXXXXXXXXX &txfax(/tmp/fax.5661.tiff)") -- James Lyons QuikVoIP, LLC. p: +1 (786) 369-5308 e: jlyons(a)quikvoip.net

2 3

Making a call from PSTN to SoftPhone
by Rajkumar Kanniappan 21 Jul '12

21 Jul '12

Hi, if I make a call from PSTN extension to a IP phone, call has to reach from Extension -> PRI card(VoIP gateway) -> Drivers -> FreeTDM, and from here what is going to be the job of FreeTDM. Is FreeTDM going to contact Sofia module, if so what is going to be the configuration changes for freetdm and sofia. Will FreeTDM module select any sofia profile(internal or external) to make calls. And how sofia profile is getting selected for this particular call. Please clarify this to me... Thanks, Rajkumar ________________________________ SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

2 5

dtmf problems
by Jason Holden 20 Jul '12

20 Jul '12

Hi, I have noticed a problem with some IP phones and am unsure how to correct this issue in fs. There are no settings on the IP phone that would correct the problem experienced. If anyone has any suggestions please let me know. Note this problem is experienced with git versions from late last year and from January this year. Vender notes The sequence of DTMF event messages we send is actually pretty logical when you look at it closely. We send three packets with 0 duration to announce the beginning of the DTMF event. This mirrors the 3 packets sent at the end with the final duration. The Polycom does the latter, but not the former. In between we send a packet with a new duration every 10ms. The "duration" in each packet increases by 80. Duration is in "samples", 80 make up 10 ms. Once the codec knows that the DTMF event has ended, it begins the sequence of 3 redundant end packets showing the final duration. So, looking at the sequence of durations, the normal last three are supplanted by the 3 redundant end packets. The Polycom does the same thing. The difference between us and the Polycom is that the PC sends exactly one packet every 20 ms in the stream, in place of the audio packet that would have been sent. We, OTOH, 1) send the DTMF event packets as soon as they are ready, 2) do not send the same number of packets as the audio codec would have. As a result, we send a different number of packets during a DTMF event than during normal audio. The Freeswitch appears to assume that all packets in an RTP stream represent the same amount of time, 20ms in this case. During our DTMF event, this is not the case. If you look at the rtp coming into the FS and going out, our first 5 DTMF packets arrive very soon after the last audio packet. The FS delays them and sent each one in a 20ms slot. But DTMF packets do not map linearly to the timeline. Therefore distorts the stream of packets. Our DTMF packets arrive spread over a much longer time than the actual duration of the DTMF event. That is almost certainly the cause of the problem. Since the Polycom sends exactly one packet in each 20 ms time slot, even during a DTMF event, that works with the FS. When you think about it, the whole reason for RTP is to handle changes in latency, missing packets and so on, it does not make sense for the FS to force every packet into a 20 ms timeslot. The answer is simply for the FS to forward DTMF packets immediately instead of delaying them for a 20 ms timeslot. IMHO, all RTP packets should be forwarded this way. I am pretty sure about what is happening in our phone that causes the timing oddities. When a DTMF event physically starts, the codec starts sending DTMF packets. However, the DTMF packets have no encoding latency, so the first packets seem to arrive immediately after the last audio packet. Then when the latency has fallen to zero, packets go out every 10 ms with corresponding increases in duration. AT the end, the encoding latency must be re-established so there is a gap in the time line after the last DTMF event is received and the first audio packet. Note the issue was noticed when the information was leaving our freeswitch and heading out to the carrier. We use bypass media and passive dtmf is set to true. Any assistance would be great. Thanks.

1 0

Passing Caller id from ata to phone
by Todd Bailey 20 Jul '12

20 Jul '12

Hi all, Using a spa3102 ata, Frees switch and a Polycom ip501, I'm not getting caller id to display on the phone. Is there some 'magical' setting that I need to address, somewhere ? Note: when an internal softphone extension calls the ip501, I see the caller id. This implies the phone and FS are working.

2 4

Skype use with mod_skypopen
by Todd Bailey 20 Jul '12

20 Jul '12

2 Easy question for Skype users, 1: Do I need a special or business account to use with mod_skypopen or will any account type work? Reason: I'd like to create a dial plan that when I dial 9+ number etc it will connect to skype account, for uses for long distance calls. I want to be able to dial 1+ number for ld through pstn carrier. 2: Do I need to install any special skype applications or does mod_skypopen handle all aspects of Fs to Skype connections? reason: Skype applications and support for linix is basically nill.

3 2

ACK to 200 OK in a Bridge
by Stephen Wilde 20 Jul '12

20 Jul '12

I have the following issue: if I do a bridge of an inbound call to an outbound call, when the called number answer the call with a 200 OK, FreeSwitch sends the ACK instantely, without wait the ACK of the calling. The message flow (as shown in the attached .png) is: CALLING FS CALLED INVITE ---------> 100 Trying <--------- -------------> INVITE <--------- 100 Trying <--------- 200 OK -------------> ACK <--------- 200 OK -------------> ACK When I expected that the ACK to called is related to ACK from the calling: CALLING FS CALLED INVITE ---------> 100 Trying <--------- -------------> INVITE <--------- 100 Trying <--------- 200 OK <--------- 200 OK -------------> ACK -------------> ACK For this reason, if sometimes the Calling doesn't send the ACK (because it reject the 200 OK), the call is considered connected (and billed) by Freeswitch (30s, probably due to a timeout waiting ack) and not by Calling (0s). There is a way (config?) to send ACK to called only when is received the ACK from calling? Stephen

3 4

Re: [Freeswitch-users] hunting in failover mode
by Mi Ke 20 Jul '12

20 Jul '12

Michael, thanks for answering - I already tried this but I need to set continue_on_fail to TRUE because that seems to be the only way to pass original hangup code from leg B to A when bridge completes. And when COF is set to TRUE it behaves like it's related to the "whole" bridge i.e. until all 3 endpoints are tried entire bridge is not considered as failed of succeded. Re separate approach - I'm not sure how can I do that as the number of EPs in my case is dynamic, bridge app receives them as a 1|2|3 dialstring from rouing lua app. Thanks / Mike ----- Original Message ----- From: Michael Collins Sent: 07/20/12 08:39 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] hunting in failover mode Perhaps you could use this? http://wiki.freeswitch.org/wiki/Channel_Variables#continue_on_fail Specify the conditions on which the bridge should keep going. Note: you may need to separate these out into individual bridge apps with a single endpoint. I haven't tried it lately, so be sure to report back what you find out. -MC On Fri, Jul 20, 2012 at 10:30 AM, Mi Ke < mi.ke(a)null.net > wrote: Hi All, When I do a failover using bridge app and ep1|ep2|ep3 construstion - how do I stop further hunting if any of already hunted endpoints returned e.g. USER_BUSY ? Thanks / Mike _________________________________________________________________________ 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 Join Us At ClueCon - Aug 7-9, 2012 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 -- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org

1 0

hunting in failover mode
by Mi Ke 20 Jul '12

20 Jul '12

Hi All, When I do a failover using bridge app and ep1|ep2|ep3 construstion - how do I stop further hunting if any of already hunted endpoints returned e.g. USER_BUSY ? Thanks / Mike

2 1

a=crypto in RTP/AVP, refer to rfc3711
by Anita Hall 20 Jul '12

20 Jul '12

Hi I am getting an error a=crypto in RTP/AVP, refer to rfc3711 when using sipml5 client with FS. There is some info on this thread, which I am currently experimenting with. https://groups.google.com/forum/#!msg/doubango/m7FCqYxRcQc/-ThdAwWJxP8J Is there any change in setting on FS side that can deal with this ? Complete SIP Log v=0 o=- 2834273280 1 IN IP4 127.0.0.1 s=webrtc (chrome 20.0.1127.0) - Doubango Telecom (sipML5 r000) t=0 0 a=group:BUNDLE audio video m=audio 51704 RTP/SAVPF 103 104 0 8 106 105 13 126 c=IN IP4 182.68.141.91 a=rtcp:51704 IN IP4 182.68.141.91 a=candidate:829852397 1 udp 2130714367 192.168.1.31 51703 typ host generation 0 a=candidate:829852397 2 udp 2130714367 192.168.1.31 51703 typ host generation 0 a=candidate:3345412921 1 udp 1912610559 182.68.141.91 51704 typ srflx generation 0 a=candidate:3345412921 2 udp 1912610559 182.68.141.91 51704 typ srflx generation 0 a=candidate:2146792989 1 tcp 1694506751 192.168.1.31 50295 typ host generation 0 a=candidate:2146792989 2 tcp 1694506751 192.168.1.31 50295 typ host generation 0 a=ice-ufrag:Jz1C79lLNJodMTz2 a=ice-pwd:UsowydSx3Uy9ehq8lKyR+JmJ a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ccVX0xSFpsuRG8lnNQgnSiMdckCgtHs5SET8r9Jt a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=ssrc:862982555 cname:QP1jAi3c1C/sIjMM a=ssrc:862982555 mslabel:JTCmb2lovY15B6rH1xoGTpSOwige5Py22GgE a=ssrc:862982555 label:JTCmb2lovY15B6rH1xoGTpSOwige5Py22GgE00 m=video 51704 RTP/SAVPF 100 101 102 c=IN IP4 182.68.141.91 a=rtcp:51704 IN IP4 182.68.141.91 a=candidate:829852397 1 udp 2130714367 192.168.1.31 51703 typ host generation 0 a=candidate:829852397 2 udp 2130714367 192.168.1.31 51703 typ host generation 0 a=candidate:3345412921 1 udp 1912610559 182.68.141.91 51704 typ srflx generation 0 a=candidate:3345412921 2 udp 1912610559 182.68.141.91 51704 typ srflx generation 0 a=candidate:2146792989 1 tcp 1694506751 192.168.1.31 50295 typ host generation 0 a=candidate:2146792989 2 tcp 1694506751 192.168.1.31 50295 typ host generation 0 a=ice-ufrag:Jz1C79lLNJodMTz2 a=ice-pwd:UsowydSx3Uy9ehq8lKyR+JmJ a=mid:video a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ccVX0xSFpsuRG8lnNQgnSiMdckCgtHs5SET8r9Jt a=rtpmap:100 VP8/90000 a=rtpmap:101 red/90000 a=rtpmap:102 ulpfec/90000 a=ssrc:1143670773 cname:QP1jAi3c1C/sIjMM a=ssrc:1143670773 mslabel:JTCmb2lovY15B6rH1xoGTpSOwige5Py22GgE a=ssrc:1143670773 label:JTCmb2lovY15B6rH1xoGTpSOwige5Py22GgE10 2012-07-17 14:48:02.285368 [ERR] sofia_glue.c:4673 a=crypto in RTP/AVP, refer to rfc3711 2012-07-17 14:48:02.285368 [DEBUG] switch_channel.c:2848 (sofia/internal/ 1015(a)122.180.97.198) Callstate Change DOWN -> HANGUP 2012-07-17 14:48:02.285368 [NOTICE] sofia.c:5813 Hangup sofia/internal/ 1015(a)122.180.97.198 [CS_NEW] [INCOMPATIBLE_DESTINATION] regards, Anita

2 1