Hey Mike,

You will appreciate this ..  I had to lookup iirc, that’s not one I am familiar with.  The first definition I found was “irritated ignitable rectum cock.”  No one has called me that for a while, so I kept looking!

I will check a PCAP and update if I find anything.  However, what appears in the FS log seems to match the phones’ setup and the resulting audio quality.  FS clearly shows PCMU:20 on the a-leg and PCMU:30 on the b-leg with no correction for asynch ptime, but only on a transferred call.

Sean

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris
Sent: Tuesday, May 27, 2014 9:34 AM
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] Jira-6550 - Ansynch PTime not detected on transfered call

iirc, those phones had a bad habit of saying one thing and doing another in regards to ptime, check out a pcap to confirm that is what is going on.

On May 24, 2014, at 2:51 PM, Sean Devoy <sdevoy@bizfocused.com> wrote:

<image001.gif>

Hi All,

Just curious if anyone else has seen this, I opened a JIRA.

My Configuration:

· Voip ISP w/ preferred CODEC PCMU:20

· Phone A – Cisco SPA504G w/ pref Codem PCMU and PTime 20

· Phone A – Cisco SPA504G w/ pref Codem PCMU and PTime 30

My ISP calls go through an IVR.  Calling through the IVR to Phone A is perfect, PCMU:20 <->PCMU:20.  Calling in through IVR to Phone B is still great, FS detects the Ansych PTIME and adjusts to PCMU:20<->PCMU:20.  But if the call goes through the IVR to Phone A (PCMU:20<->PCMU:20), and THEN is (attended) XFERed to Phone B, the result is a badly delayed (3 to 5 second) and degraded audio stream PCMU:20<->PCMU:30.

Calling direct to Phone B, FS says “Asynch ptime not allowed, changing our end from 30 to 20.” Freeswitch does not detect the same asynch ptime mismatch at the end of the attended xfer!

I understand changing Phone B resolves this problem, but it is still a bug  (I think).

Sean