Re: [Freeswitch-users] Doubts over G729 passthru for 50ms ptimes
I tried setting the {passthru_ptime_mismatch=true} variable in the dialplan, but no joy unfortunately. I'm also fairly sure that the codecs are matched on both call legs, so shouldn't be having that sort of issue. I'm going to gather up some evidence and console logs/traces etc so that I can put something together for a bug report on Jira. Is there anything else that someone can suggest I try before it goes on Jira? Is anyone able to re-produce the same problem? Admittedly, I'm not on the latest GIT, but I'm on a recent (last couple of months) stable release. Thanks in advance for any assistance! Regards, Ben From: Ben N [mailto:ben122uk@gmail.com] Sent: 29 November 2012 09:58 To: clive engelberg Subject: Re: [Freeswitch-users] Doubts over G729 passthru for 50ms ptimes Hi Brian, yes I've set G729@50i on both the external and internal sofia profiles statically, and confirmed the allowed codecs by running "sofia status profile profilename". I can also confirm in the FS console that codec comparisons for both the a-leg, and b-leg match instantly to G729@50i. Clive, thanks for the pointer, although in my case I don't think there's a mis-match as each side of the call supports sending/receiving G729 50ms ptimes, and is negotiated correctly in the SDP. However I'm still willing to give it a try as I need to try everything! I'll let you know what happens. Cheers, Ben On Thu, Nov 29, 2012 at 8:08 AM, clive engelberg <clive18@webmail.co.za> wrote: Hi I have had limited success with : <action application="bridge" data="{passthru_ptime_mismatch=true}sofia/gateway/icall/$1@1.2.3.4"/> Sometimes the sound was garbled, sometimes worked fine, not sure why it was sometimes garbled, so I dont use it anymore, as complaints are not what I want :) Hope this helps. regards Clive On Tue, 27 Nov 2012 11:06:18 +0000 Ben N wrote Hi All, I'm wondering if anyone out there is using G729 with 50ms ptime through Freeswitch, without proxy media? I am unable to get this to work, even in a very basic lab with just two clients and an up to date FS server on the same LAN. I can get G729 with 20ms working, but 50ms causes Freeswitch to hang the call. It might be that mod_g729 and mod_com_g729 simply don't support it, so if anyone in the know can tell me that would be great! Further info can be supplied, I believe I have tried pretty much all options.... Cheers, Ben _____ South Africa premier free email service - webmail.co.za <http://www.webmail.co.za/> <http://b.wm.co.za/click.pwm?cid=20053491&loc=N-MT&seq=50b717ec> <http://b.wm.co.za/click.pwm?cid=20053491&loc=N-MT&seq=50b717ec>
PCAP's will show you.... I suspect something is telling a lie about the timestamps. Very common. -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH_Wire T: +1.918.420.9266 | F: +1.918.420.9267 | M: +1.918.424.WEST iNUM: +883 5100 1420 9266 UK: +44 20 3298 4900 ISN: 410*543 On Dec 3, 2012, at 9:31 AM, Ben <ben122uk@gmail.com> wrote:
I tried setting the {passthru_ptime_mismatch=true} variable in the dialplan, but no joy unfortunately. I’m also fairly sure that the codecs are matched on both call legs, so shouldn’t be having that sort of issue.
I’m going to gather up some evidence and console logs/traces etc so that I can put something together for a bug report on Jira. Is there anything else that someone can suggest I try before it goes on Jira? Is anyone able to re-produce the same problem? Admittedly, I’m not on the latest GIT, but I’m on a recent (last couple of months) stable release.
Thanks in advance for any assistance!
Regards,
Ben
Hi Brian, I looked at the timestamps for both RTP streams that are being sent by each client, it appears that the timestamp increments by a value of 400 for each packet, for both streams. I can also see this in FS for each stream - 2012-12-03 15:51:03.374955 [DEBUG] sofia_glue.c:5094 Audio Codec Compare [G729:18:8000:50:8000]/[G729:18:8000:50:8000] 2012-12-03 15:51:03.374955 [DEBUG] sofia_glue.c:3077 Set Codec sofia/internal/1002@192.168.17.154 G729/8000 50 ms 400 samples 8000 bits Looking at the Freeswitch log, I'm guessing that the timestamps set by the client correlate to the sample rate set by Freeswitch? Or am I not on the right track with what you were suggesting? I've also noticed that when using 50ms ptimes, one of the RTP streams from a client is not very 'steady'. One stream seems acceptable, with only one or two packets straying to 60ms, and jitter hovers around 2-3ms. However the other stream really struggles, the delta(ms) values in wireshark are all over the place. This is the summary of a 20 second RTP stream in wireshark - Max delta = 120.95 ms at packet no. 1250 Max jitter = 22.00 ms. Mean jitter = 18.12 ms. Max skew = 65.24 ms. This seems odd since the test I did was all internal on the same LAN. I'll try and track down the cause tomorrow by switching around some kit so that it cuts out any potential problems. Are there tolerance levels in Freeswitch for RTP streams that are affected during transit? If so, how does Freeswitch react when one of these tolerance levels is exceeded? My FS server seems to just hang during call setup, and no RTP stream is sent out the server to the clients. Thanks for the help, I'll let you know how I get on tomorrow with some further tests. Regards, Ben -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: 04 December 2012 15:11 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Doubts over G729 passthru for 50ms ptimes PCAP's will show you.... I suspect something is telling a lie about the timestamps. Very common. -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH_Wire T: +1.918.420.9266 | F: +1.918.420.9267 | M: +1.918.424.WEST iNUM: +883 5100 1420 9266 UK: +44 20 3298 4900 ISN: 410*543 On Dec 3, 2012, at 9:31 AM, Ben <ben122uk@gmail.com> wrote:
I tried setting the {passthru_ptime_mismatch=true} variable in the dialplan, but no joy unfortunately. I'm also fairly sure that the codecs are matched on both call legs, so shouldn't be having that sort of issue.
I'm going to gather up some evidence and console logs/traces etc so that I can put something together for a bug report on Jira. Is there anything else that someone can suggest I try before it goes on Jira? Is anyone able to re-produce the same problem? Admittedly, I'm not on the latest GIT, but I'm on a recent (last couple of months) stable release.
Thanks in advance for any assistance!
Regards,
Ben
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
RTP timestamps = ptime x 8, so: PTIME:timestamp increment 10:80 20:160 30:240 40:320 50:400 Your endpoints seem to be writing their RTP timestamps correctly. For the endpoint that's all over the place, check the hardware. I've seen bad DSPs, etc cause strange RTP skew before. On Tue, Dec 4, 2012 at 3:40 PM, Ben <ben122uk@gmail.com> wrote:
Hi Brian,
I looked at the timestamps for both RTP streams that are being sent by each client, it appears that the timestamp increments by a value of 400 for each packet, for both streams. I can also see this in FS for each stream -
2012-12-03 15:51:03.374955 [DEBUG] sofia_glue.c:5094 Audio Codec Compare [G729:18:8000:50:8000]/[G729:18:8000:50:8000] 2012-12-03 15:51:03.374955 [DEBUG] sofia_glue.c:3077 Set Codec sofia/internal/1002@192.168.17.154 G729/8000 50 ms 400 samples 8000 bits
Looking at the Freeswitch log, I'm guessing that the timestamps set by the client correlate to the sample rate set by Freeswitch? Or am I not on the right track with what you were suggesting?
I've also noticed that when using 50ms ptimes, one of the RTP streams from a client is not very 'steady'. One stream seems acceptable, with only one or two packets straying to 60ms, and jitter hovers around 2-3ms. However the other stream really struggles, the delta(ms) values in wireshark are all over the place. This is the summary of a 20 second RTP stream in wireshark -
Max delta = 120.95 ms at packet no. 1250 Max jitter = 22.00 ms. Mean jitter = 18.12 ms. Max skew = 65.24 ms.
This seems odd since the test I did was all internal on the same LAN. I'll try and track down the cause tomorrow by switching around some kit so that it cuts out any potential problems.
Are there tolerance levels in Freeswitch for RTP streams that are affected during transit? If so, how does Freeswitch react when one of these tolerance levels is exceeded? My FS server seems to just hang during call setup, and no RTP stream is sent out the server to the clients.
Thanks for the help, I'll let you know how I get on tomorrow with some further tests.
Regards,
Ben
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: 04 December 2012 15:11 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Doubts over G729 passthru for 50ms ptimes
PCAP's will show you.... I suspect something is telling a lie about the timestamps. Very common. -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH_Wire T: +1.918.420.9266 | F: +1.918.420.9267 | M: +1.918.424.WEST iNUM: +883 5100 1420 9266 UK: +44 20 3298 4900 ISN: 410*543
On Dec 3, 2012, at 9:31 AM, Ben <ben122uk@gmail.com> wrote:
I tried setting the {passthru_ptime_mismatch=true} variable in the dialplan, but no joy unfortunately. I'm also fairly sure that the codecs are matched on both call legs, so shouldn't be having that sort of issue.
I'm going to gather up some evidence and console logs/traces etc so that I can put something together for a bug report on Jira. Is there anything else that someone can suggest I try before it goes on Jira? Is anyone able to re-produce the same problem? Admittedly, I'm not on the latest GIT, but I'm on a recent (last couple of months) stable release.
Thanks in advance for any assistance!
Regards,
Ben
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@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
Thanks for the info, I suspected that it should always add up to 8000 samples per second :-) Yes hardware is my next area of investigation. Both endpoints are iPhones, I'll be checking tomorrow to see if these are the cause of the dodgy RTP stream. Cheers, Ben -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Kristian Kielhofner Sent: 04 December 2012 21:00 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Doubts over G729 passthru for 50ms ptimes RTP timestamps = ptime x 8, so: PTIME:timestamp increment 10:80 20:160 30:240 40:320 50:400 Your endpoints seem to be writing their RTP timestamps correctly. For the endpoint that's all over the place, check the hardware. I've seen bad DSPs, etc cause strange RTP skew before. On Tue, Dec 4, 2012 at 3:40 PM, Ben <ben122uk@gmail.com> wrote:
Hi Brian,
I looked at the timestamps for both RTP streams that are being sent by each client, it appears that the timestamp increments by a value of 400 for each packet, for both streams. I can also see this in FS for each stream -
2012-12-03 15:51:03.374955 [DEBUG] sofia_glue.c:5094 Audio Codec Compare [G729:18:8000:50:8000]/[G729:18:8000:50:8000] 2012-12-03 15:51:03.374955 [DEBUG] sofia_glue.c:3077 Set Codec sofia/internal/1002@192.168.17.154 G729/8000 50 ms 400 samples 8000 bits
Looking at the Freeswitch log, I'm guessing that the timestamps set by the client correlate to the sample rate set by Freeswitch? Or am I not on the right track with what you were suggesting?
I've also noticed that when using 50ms ptimes, one of the RTP streams from a client is not very 'steady'. One stream seems acceptable, with only one or two packets straying to 60ms, and jitter hovers around 2-3ms. However the other stream really struggles, the delta(ms) values in wireshark are all over the place. This is the summary of a 20 second RTP stream in wireshark -
Max delta = 120.95 ms at packet no. 1250 Max jitter = 22.00 ms. Mean jitter = 18.12 ms. Max skew = 65.24 ms.
This seems odd since the test I did was all internal on the same LAN. I'll try and track down the cause tomorrow by switching around some kit so that it cuts out any potential problems.
Are there tolerance levels in Freeswitch for RTP streams that are affected during transit? If so, how does Freeswitch react when one of these tolerance levels is exceeded? My FS server seems to just hang during call setup, and no RTP stream is sent out the server to the clients.
Thanks for the help, I'll let you know how I get on tomorrow with some further tests.
Regards,
Ben
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: 04 December 2012 15:11 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Doubts over G729 passthru for 50ms ptimes
PCAP's will show you.... I suspect something is telling a lie about the timestamps. Very common. -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH_Wire T: +1.918.420.9266 | F: +1.918.420.9267 | M: +1.918.424.WEST iNUM: +883 5100 1420 9266 UK: +44 20 3298 4900 ISN: 410*543
On Dec 3, 2012, at 9:31 AM, Ben <ben122uk@gmail.com> wrote:
I tried setting the {passthru_ptime_mismatch=true} variable in the dialplan, but no joy unfortunately. I'm also fairly sure that the codecs are matched on both call legs, so shouldn't be having that sort of issue.
I'm going to gather up some evidence and console logs/traces etc so that I can put something together for a bug report on Jira. Is there anything else that someone can suggest I try before it goes on Jira? Is anyone able to re-produce the same problem? Admittedly, I'm not on the latest GIT, but I'm on a recent (last couple of months) stable release.
Thanks in advance for any assistance!
Regards,
Ben
______________________________________________________________________ ___ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs http://www.freeswitch.org
______________________________________________________________________ ___ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs http://www.freeswitch.org
-- Kristian Kielhofner _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Ben
-
Brian West
-
Kristian Kielhofner