[Freeswitch-users] ptime mismatch confusion

[Anthony Minessale]

Thats not really enough info
you should have a full pcap of a single call

also you should not be using that codec negotiation scrooge unless its
a very specific case.

get a trace without the scrooge mode and consider reporting it to
consulting at freeswitch.org for expedited commercial assistance.



On Thu, Jun 2, 2011 at 2:49 PM, Michael Gende <mgende at gendesign.com> wrote:
> Hello,
>
> If you are a codec/ptime person, great. I've been "round and round" with the
> vendor on this and and not making much headway.
>
> We've an FS switch that has two numbers registered with our provider. That
> provider is, in turn, getting service from another gateway provider of their
> own.
>
> On our FS, one DID works with no issues and has for more than a year. They
> other recently started having ptime mismatch issues making it unusable.
> Tried Scrooge setting to no avail.
>
> For the daring (and merciful), here's FS output for a "bad" call and then a
> "good" one (just a little output from the start):
>
>
> 2011-06-02 14:12:06.756170 [DEBUG] switch_core_state_machine.c:397
> (sofia/external/8151231234 at xxx.xxx.xxx.xxx:5060) Running State Change CS_NEW
>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia.c:3210 Channel
> sofia/external/8151231234 at xxx.xxx.xxx.xxx:5060 entering state
> [received][100]
> 2011-06-02 14:12:06.756170 [DEBUG] sofia.c:3217 Remote SDP:
>
>
> v=0
>
>
> o=Acme_UAS 0 1 IN IP4 xxx.xxx.xxx.xxx
>
>
> s=SIP Media Capabilities
>
>
> c=IN IP4 yyy.yyy.yyy.yyy
>
>
> t=0 0
>
>
> m=audio 52024 RTP/AVP 0 18 101
>
>
> a=rtpmap:0 PCMU/8000
>
>
> a=rtpmap:18 G729/8000
>
>
> a=rtpmap:101 telephone-event/8000
>
>
> a=maxptime:30
>
>
>
>
>
> 2011-06-02 14:12:06.756170 [DEBUG] switch_core_state_machine.c:403
> (sofia/external/8151231234 at xxx.xxx.xxx.xxx:5060) State NEW
>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia_glue.c:3081 Audio Codec Compare
> [PCMU:0:8000:30]/[PCMU:0:8000:20]
>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia_glue.c:3092 Bah HUMBUG! Sticking
> with PCMU at 8000h@20i
>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia_glue.c:2039 Set Codec
> sofia/external/8151231234 at xxx.xxx.xxx.xxx:5060 PCMU/8000 20 ms 160 samples
>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia_glue.c:3041 Set 2833 dtmf payload
> to 101
>
>
>
> Note that whilst it says its sticking with ptime of 20 (bolded above), our
> vendor in-the-middle sees us as still using ptime=30. Weird. But, on the
> same switch with different DID, we get the following "good" result:
>
>
>
> 2011-06-02 14:15:15.135193 [DEBUG] switch_core_state_machine.c:397
> (sofia/external/8151231234 at xxx.xxx.xxx.xxx:5060) Running State Change CS_NEW
>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia.c:3210 Channel
> sofia/external/8151231234@ xxx.xxx.xxx.xxx:5060 entering state
> [received][100]
> 2011-06-02 14:15:15.135193 [DEBUG] sofia.c:3217 Remote SDP:
>
>
> v=0
>
>
> o=Acme_UAS 0 1 IN IP4 xxx.xxx.xxx.xxx
>
>
> s=SIP Media Capabilities
>
>
> c=IN IP4 yyy.yyy.yyy.yyy
>
>
> t=0 0
>
>
> m=audio 52052 RTP/AVP 0 18 101
>
>
> a=rtpmap:0 PCMU/8000
>
>
> a=rtpmap:18 G729/8000
>
>
> a=rtpmap:101 telephone-event/8000
>
>
> a=maxptime:20
>
>
>
>
>
> 2011-06-02 14:15:15.135193 [DEBUG] switch_core_state_machine.c:403
> (sofia/external/8151231234 at xxx.xxx.xxx.xxx.10:5060) State NEW
>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia_glue.c:3081 Audio Codec Compare
> [PCMU:0:8000:20]/[PCMU:0:8000:20]
>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia_glue.c:3092 Bah HUMBUG! Sticking
> with PCMU at 8000h@20i
>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia_glue.c:2039 Set Codec
> sofia/external/8151231234 at xxx.xxx.xxx.xxx:5060 PCMU/8000 20 ms 160 samples
>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia_glue.c:3041 Set 2833 dtmf payload
> to 101
>
>
> Naturally, the "far end" vendor says they think its a "FreeSwitch problem".
> Huh? For my part, I'd just like to FORCE a ptime of 20 in all cases, no
> matter the codec, for incoming calls, either DID. Tried, but so far, no go.
>
> A packet capture showed "bad" call coming in with ptime max of 30, we
> respond that 30 is OK but them re-invite with ptime set to 20, but it
> doesn't seem to "catch". On the good DID, they proffer ptime max of 30, we
> respond with ptime of 20 and life is good.
>
> Sorry to post again on this. I have put in some hours but still same results
> so far. Any suggestions much appreciated.
>
> Regards,
>
> Mike
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900