[Freeswitch-users] ptime mismatch confusion

[Michael Gende]

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<http://8154835414@208.94.159.10: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
<http://8154835414@208.94.159.10: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<http://8154835414@208.94.159.10: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<http://8154835414@208.94.159.10: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<http://8159535620@208.94.157.10: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 <http://8159535620@208.94.157.10: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<http://8159535620@208.94.157.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<http://8159535620@208.94.157.10: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110602/7eca4ba2/attachment.html