[Freeswitch-users] ptime mismatch confusion

[Michael Gende]

That's what I'll try. Thanks.

On Thu, Jun 2, 2011 at 2:55 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> 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
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110602/14850e18/attachment-0001.html