Freeswitch Asynchronus Ptime and Executing Playback of prompts

972 views
Skip to first unread message

Mike Dunton

unread,
Apr 15, 2016, 6:28:30 PM4/15/16
to 2600hz-dev
I am seeing an issue when using freeswitch and mod_kazoo where if if I send a command to play a prompt eg cf_menu greeting and that command executes on the freeswitch server before I see 

2016-04-15 21:36:13.450200 [WARNING] switch_core_media.c:2042 Asynchronous PTIME not supported, changing our end from 30 to 20

The audio gets all choppy/speed up/missing audio. 

However if the switch_core_media happens BEFORE the execute the audio sounds fine.


I am on FreeSWITCH version: 1.4.26

here are two calls from the fs_cli log. The first call sounds great. The 2nd call sounds chopped. 

2016-04-15 21:36:10.130115 [INFO] kazoo_node.c:625 exec: uuid_setvar_multi(855940302...@sc.ru.be.ed effective_caller_id_name=scrubeed;effective_caller_id_number=+scrubeed;ecallmgr_Fetch-ID=1197ea0c-0352-11e6-84b2-97d967d5b2ec;ecallmgr_Account-ID=994149da43a135062a3f975400aaa7de;ignore_display_updates=true;ecallmgr_Inception=+18005...@bandwidth.com;ecallmgr_Resource-ID=bandwidth)
2016-04-15 21:36:10.330139 [NOTICE] kazoo_node.c:285 log|855940302...@sc.ru.be.ed|executing answer  
2016-04-15 21:36:10.330139 [NOTICE] sofia_media.c:92 Pre-Answer sofia/sipinterface_1/+scr...@sc.ru.be.ed!
2016-04-15 21:36:10.330139 [NOTICE] mod_dptools.c:1300 Channel [sofia/sipinterface_1/+scr...@sc.ru.be.ed] has been answered
2016-04-15 21:36:10.530128 [INFO] kazoo_node.c:625 exec: uuid_setvar(855940302...@sc.ru.be.ed playback_terminators #*0123456789)\
2016-04-15 21:36:10.590129 [WARNING] switch_core_media.c:2042 Asynchronous PTIME not supported, changing our end from 30 to 20
2016-04-15 21:36:10.730147 [NOTICE] kazoo_node.c:285 log|855940302...@sc.ru.be.ed|executing playback http_cache://http://scru...@scrubeed.scrub.com:24517/single/account%2F99%2F41%AccountNumber2234234/f6634ab08ab74094b42cdeb7c4d22af3/dummy.wav 
2016-04-15 21:36:11.710138 [NOTICE] sofia.c:952 Hangup sofia/sipinterface_1/+scr...@sc.ru.be.ed [CS_EXECUTE] [NORMAL_CLEARING]
2016-04-15 21:36:11.710138 [NOTICE] switch_core_session.c:1642 Session 971 (sofia/sipinterface_1/+scr...@sc.ru.be.ed) Ended
2016-04-15 21:36:11.710138 [NOTICE] kazoo_node.c:285 log|855940302...@sc.ru.be.ed|executing event Event-Subclass=whistle::noop,Event-Name=CUSTOM,whistle_event_name=CHANNEL_EXECUTE_COMPLETE,whistle_application_name=noop,whistle_application_response=8aa7fd2c0720da3be6a1a9f1090fd1ce 
2016-04-15 21:36:11.710138 [NOTICE] switch_core_session.c:1646 Close Channel sofia/sipinterface_1/+scr...@sc.ru.be.ed [CS_DESTROY]


2016-04-15 21:36:12.490144 [NOTICE] switch_channel.c:1077 New Channel sofia/sipinterface_1/+scrubeed@scrubedIP [204244713_132006858@scrubedIP]
2016-04-15 21:36:12.490144 [INFO] sofia.c:9175 169.54.250.5 is a proxy according to the authoritative acl
2016-04-15 21:36:12.490144 [INFO] mod_dialplan_xml.c:635 Processing +scrubeed <+scrubeed>->+18005555555 in context context_2
2016-04-15 21:36:12.530174 [NOTICE] mod_dptools.c:1670 log|204244713_132006858@scrubedIP|ecal...@callmedia01.nope.nope.nope.com won call control
2016-04-15 21:36:12.530174 [NOTICE] mod_sofia.c:2104 Ring-Ready sofia/sipinterface_1/+scrubeed@scrubedIP!
2016-04-15 21:36:12.530174 [NOTICE] mod_dptools.c:1016 Ring Ready sofia/sipinterface_1/+scrubeed@scrubedIP!
2016-04-15 21:36:12.750130 [INFO] kazoo_node.c:625 exec: uuid_setvar_multi(204244713_132006858@scrubedIP effective_caller_id_name=scrubeed;effective_caller_id_number=+scrubeed;ecallmgr_Fetch-ID=1329c2dc-0352-11e6-84bd-97d967d5b2ec;ecallmgr_Account-ID=994149da43a135062a3f975400aaa7de;ignore_display_updates=true;ecallmgr_Inception=+18005...@bandwidth.com;ecallmgr_Resource-ID=bandwidth)
2016-04-15 21:36:12.950187 [NOTICE] kazoo_node.c:285 log|204244713_132006858@scrubedIP|executing answer  
2016-04-15 21:36:12.970130 [NOTICE] sofia_media.c:92 Pre-Answer sofia/sipinterface_1/+scrubeed@scrubedIP!
2016-04-15 21:36:12.970130 [NOTICE] mod_dptools.c:1300 Channel [sofia/sipinterface_1/+scrubeed@scrubedIP] has been answered
2016-04-15 21:36:13.172118 [INFO] kazoo_node.c:625 exec: uuid_setvar(204244713_132006858@scrubedIP playback_terminators #*0123456789)
2016-04-15 21:36:13.370228 [NOTICE] kazoo_node.c:285 log|204244713_132006858@scrubedIP|executing playback http_cache://http://scru...@scrubeed.scrub.com:24517/single/account%2F99%2F41%AccountNumber2234234/f6634ab08ab74094b42cdeb7c4d22af3/dummy.wav 
2016-04-15 21:36:13.450200 [WARNING] switch_core_media.c:2042 Asynchronous PTIME not supported, changing our end from 30 to 20
2016-04-15 21:36:15.670135 [NOTICE] sofia.c:952 Hangup sofia/sipinterface_1/+scrubeed@scrubedIP [CS_EXECUTE] [NORMAL_CLEARING]


Any ideas or solutions? 

Darren Schreiber

unread,
Apr 15, 2016, 6:32:11 PM4/15/16
to 2600h...@googlegroups.com
Please use FS v1.4.23, 1.4.26 has some issues with it and has since been removed from our repo

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mike Dunton

unread,
Apr 16, 2016, 11:10:03 AM4/16/16
to 2600hz-dev
Thanks we will try this.

Mike Dunton

unread,
Apr 18, 2016, 1:35:13 PM4/18/16
to 2600hz-dev
I thought I would give an update on this. 

After speaking with bandwidth about this issue they made a change to the PSP packet profile to no longer offer the iLBC codec. This resolved the issues we were having of getting a ptime = 30 in the invite but actually receiving ptime = 20 sized RTP packets. 

Does anyone know of any issues with iLBC and kamailio or freeswitch?

Darren Schreiber

unread,
Apr 18, 2016, 1:35:57 PM4/18/16
to 2600h...@googlegroups.com
No, but Sonus has been known to do this non-sense

--

Humberto P.

unread,
Apr 25, 2016, 11:30:41 PM4/25/16
to 2600hz-dev, dschr...@2600hz.com
hello,

try changing codec negotiation to scrooge  in the file sipinterface_1.xml

<param name="inbound-codec-negotiation" value="scrooge"/>



inbound-codec-negotiation 

set to 'greedy' if you want your codec list to take precedence

 <param name="inbound-codec-negotiation" value="generous"/>

if 'greedy' doesn't work for you, try 'scrooge' which has been known to fix misreported ptime issues with DID providers such as CallCentric.

A rule of thumb is:

  • 'generous' permits the remote codec list have precedence and 'win' the codec negotiation and selection process
  • 'greedy' forces a win by the local FreeSWITCH preference list
  • 'scrooge' takes 'greedy' a step further, so that the FreeSWITCH wins even when the far side lies about capabilities during the negotiation process
Reply all
Reply to author
Forward
0 new messages