Stutter on ringtone - incoming calls only
When people call in (via callcentric) - they hear a stutter in the ringtone. My understanding is that the ringtone is generated by freeswitch - looks like here: <action application="set" data="transfer_ringback=${us-ring}"/> We are running the Debian release - 1.4.26~37-1~jessie+1 Could be this is a new 'feature'? Never sure. Anyone else seeing this? I'm thinking the ringtone might be using a different CODEX? -- -------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB https://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-3089 Teaching people to think of themselves as victims is close to pure evil. kps --------------------------------------------------------------------------------
On Fri, Mar 4, 2016 at 3:56 PM, Karl Schmidt <karl@xtronics.com> wrote:
When people call in (via callcentric) - they hear a stutter in the ringtone.
My understanding is that the ringtone is generated by freeswitch - looks like here:
<action application="set" data="transfer_ringback=${us-ring}"/>
We are running the Debian release - 1.4.26~37-1~jessie+1
Could be this is a new 'feature'? Never sure.
Anyone else seeing this?
I'm thinking the ringtone might be using a different CODEX?
You can be absolutely certain of what's happening by taking a pcap of the SIP and RTP that are leaving the box when the call comes in from Callcentric. Verify that you're sending a 183 w/SDP and that there's actual early media leaving your system. If there is, analyze the RTP and see if the stutter can be heard there. If it's PCMU then Wireshark is great for this kind of thing. (Lots of info in Confluence on packet captures <https://freeswitch.org/confluence/display/FREESWITCH/Packet+Capture> and analysis <https://freeswitch.org/confluence/display/FREESWITCH/Wireshark+How+To> if you need a reference.) The pcap analysis should at the very least help you narrow down where the stutter is coming in to play and where to go next. -MC
--
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB https://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 <dial://%28785%29%20841-3089> Lawrence, KS 66049 FAX (785) 841-3089 <dial://%28785%29%20841-3089>
Teaching people to think of themselves as victims is close to pure evil. kps
--------------------------------------------------------------------------------
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
OK - this bit seems likely: 2016-03-06 14:48:04.240958 [WARNING] switch_core_media.c:2042 Asynchronous PTIME not supported, changing our end from 30 to 20 2016-03-06 14:48:04.260851 [DEBUG] switch_core_media.c:2414 Changing Codec from PCMU@30ms@8000hz to PCMU@20ms@8000hz earlier in the log: Local SDP: v=0 o=FreeSWITCH 1457269929 1457269930 IN IP4 192.168.1.200 s=FreeSWITCH c=IN IP4 192.168.1.200 t=0 0 m=audio 27354 RTP/AVP 0 13 a=rtpmap:0 PCMU/8000 a=ptime:30 a=sendrecv m=audio 27354 RTP/AVP 0 8 9 3 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:3 GSM/8000 a=ptime:20 a=sendrecv So I'm guessing that the PTIME bit is the cause - I found some earlier threads and tried un-commenting : rtp-autofix-timing=false in sip_profiles/internal.xml But no joy. Shouldn't the Asynchronous PTIME be negotiated before the ringing is set up? ( Call audio is fine - just this ringtone phase on incoming calls ) On 03/05/2016 03:04 PM, Michael Collins wrote:
On Fri, Mar 4, 2016 at 3:56 PM, Karl Schmidt <karl@xtronics.com <mailto:karl@xtronics.com>> wrote:
When people call in (via callcentric) - they hear a stutter in the ringtone.
My understanding is that the ringtone is generated by freeswitch - looks like here:
<action application="set" data="transfer_ringback=${us-ring}"/>
We are running the Debian release - 1.4.26~37-1~jessie+1
Could be this is a new 'feature'? Never sure.
Anyone else seeing this?
I'm thinking the ringtone might be using a different CODEX?
You can be absolutely certain of what's happening by taking a pcap of the SIP and RTP that are leaving the box when the call comes in from Callcentric. Verify that you're sending a 183 w/SDP and that there's actual early media leaving your system. If there is, analyze the RTP and see if the stutter can be heard there. If it's PCMU then Wireshark is great for this kind of thing. (Lots of info in Confluence on packet captures <https://freeswitch.org/confluence/display/FREESWITCH/Packet+Capture> and analysis <https://freeswitch.org/confluence/display/FREESWITCH/Wireshark+How+To> if you need a reference.)
The pcap analysis should at the very least help you narrow down where the stutter is coming in to play and where to go next.
-MC
-- -------------------------------------------------------------------------------- Link to our website and get free US-48 shipping on your next order. Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB https://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-3089 As a bright friend explained as to why he doesn't watch any TV; All we have is time - best not to waste it. kps --------------------------------------------------------------------------------
https://wiki.freeswitch.org/wiki/Provider_Configuration:_Callcentric The last bit is what you need. <!-- There are two other options such as generous, greedy, but scrooge seems to work with CallCentric --> <param name="inbound-codec-negotiation" value="scrooge"/> On Sun, Mar 6, 2016 at 7:57 PM, Karl Schmidt <karl@xtronics.com> wrote:
OK - this bit seems likely:
2016-03-06 14:48:04.240958 [WARNING] switch_core_media.c:2042 Asynchronous PTIME not supported, changing our end from 30 to 20 2016-03-06 14:48:04.260851 [DEBUG] switch_core_media.c:2414 Changing Codec from PCMU@30ms@8000hz to PCMU@20ms@8000hz
earlier in the log: Local SDP: v=0 o=FreeSWITCH 1457269929 1457269930 IN IP4 192.168.1.200 s=FreeSWITCH c=IN IP4 192.168.1.200 t=0 0 m=audio 27354 RTP/AVP 0 13 a=rtpmap:0 PCMU/8000 a=ptime:30 a=sendrecv m=audio 27354 RTP/AVP 0 8 9 3 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:3 GSM/8000 a=ptime:20 a=sendrecv
So I'm guessing that the PTIME bit is the cause - I found some earlier threads and tried un-commenting : rtp-autofix-timing=false in sip_profiles/internal.xml
But no joy.
Shouldn't the Asynchronous PTIME be negotiated before the ringing is set up?
( Call audio is fine - just this ringtone phase on incoming calls )
On 03/05/2016 03:04 PM, Michael Collins wrote:
On Fri, Mar 4, 2016 at 3:56 PM, Karl Schmidt <karl@xtronics.com <mailto:
karl@xtronics.com>> wrote:
When people call in (via callcentric) - they hear a stutter in the
ringtone.
My understanding is that the ringtone is generated by freeswitch -
looks like here:
<action application="set" data="transfer_ringback=${us-ring}"/>
We are running the Debian release - 1.4.26~37-1~jessie+1
Could be this is a new 'feature'? Never sure.
Anyone else seeing this?
I'm thinking the ringtone might be using a different CODEX?
You can be absolutely certain of what's happening by taking a pcap of
the SIP and RTP that are
leaving the box when the call comes in from Callcentric. Verify that you're sending a 183 w/SDP and that there's actual early media leaving your system. If there is, analyze the RTP and see if the stutter can be heard there. If it's PCMU then Wireshark is great for this kind of thing. (Lots of info in Confluence on packet captures <https://freeswitch.org/confluence/display/FREESWITCH/Packet+Capture> and analysis <https://freeswitch.org/confluence/display/FREESWITCH/Wireshark+How+To> if you need a reference.)
The pcap analysis should at the very least help you narrow down where the stutter is coming in to play and where to go next.
-MC
--
-------------------------------------------------------------------------------- Link to our website and get free US-48 shipping on your next order.
Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB https://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-3089
As a bright friend explained as to why he doesn't watch any TV; All we have is time - best not to waste it. kps
--------------------------------------------------------------------------------
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com https://www.gofundme.com/freeswitch_ubuntu Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
participants (3)
-
Brian West
-
Karl Schmidt
-
Michael Collins