That's what I'll try. Thanks. <br><br><div class="gmail_quote">On Thu, Jun 2, 2011 at 2:55 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com">anthony.minessale@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Thats not really enough info<br>
you should have a full pcap of a single call<br>
<br>
also you should not be using that codec negotiation scrooge unless its<br>
a very specific case.<br>
<br>
get a trace without the scrooge mode and consider reporting it to<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a> for expedited commercial assistance.<br>
<div><div></div><div class="h5"><br>
<br>
<br>
On Thu, Jun 2, 2011 at 2:49 PM, Michael Gende <<a href="mailto:mgende@gendesign.com">mgende@gendesign.com</a>> wrote:<br>
> Hello,<br>
><br>
> If you are a codec/ptime person, great. I've been "round and round" with the<br>
> vendor on this and and not making much headway.<br>
><br>
> We've an FS switch that has two numbers registered with our provider. That<br>
> provider is, in turn, getting service from another gateway provider of their<br>
> own.<br>
><br>
> On our FS, one DID works with no issues and has for more than a year. They<br>
> other recently started having ptime mismatch issues making it unusable.<br>
> Tried Scrooge setting to no avail.<br>
><br>
> For the daring (and merciful), here's FS output for a "bad" call and then a<br>
> "good" one (just a little output from the start):<br>
><br>
><br>
> 2011-06-02 14:12:06.756170 [DEBUG] switch_core_state_machine.c:397<br>
> (sofia/external/8151231234@xxx.xxx.xxx.xxx:5060) Running State Change CS_NEW<br>
><br>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia.c:3210 Channel<br>
> sofia/external/8151231234@xxx.xxx.xxx.xxx:5060 entering state<br>
> [received][100]<br>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia.c:3217 Remote SDP:<br>
><br>
><br>
> v=0<br>
><br>
><br>
> o=Acme_UAS 0 1 IN IP4 xxx.xxx.xxx.xxx<br>
><br>
><br>
> s=SIP Media Capabilities<br>
><br>
><br>
> c=IN IP4 yyy.yyy.yyy.yyy<br>
><br>
><br>
> t=0 0<br>
><br>
><br>
> m=audio 52024 RTP/AVP 0 18 101<br>
><br>
><br>
> a=rtpmap:0 PCMU/8000<br>
><br>
><br>
> a=rtpmap:18 G729/8000<br>
><br>
><br>
> a=rtpmap:101 telephone-event/8000<br>
><br>
><br>
> a=maxptime:30<br>
><br>
><br>
><br>
><br>
><br>
> 2011-06-02 14:12:06.756170 [DEBUG] switch_core_state_machine.c:403<br>
> (sofia/external/8151231234@xxx.xxx.xxx.xxx:5060) State NEW<br>
><br>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia_glue.c:3081 Audio Codec Compare<br>
> [PCMU:0:8000:30]/[PCMU:0:8000:20]<br>
><br>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia_glue.c:3092 Bah HUMBUG! Sticking<br>
> with PCMU@8000h@20i<br>
><br>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia_glue.c:2039 Set Codec<br>
> sofia/external/8151231234@xxx.xxx.xxx.xxx:5060 PCMU/8000 20 ms 160 samples<br>
><br>
> 2011-06-02 14:12:06.756170 [DEBUG] sofia_glue.c:3041 Set 2833 dtmf payload<br>
> to 101<br>
><br>
><br>
><br>
> Note that whilst it says its sticking with ptime of 20 (bolded above), our<br>
> vendor in-the-middle sees us as still using ptime=30. Weird. But, on the<br>
> same switch with different DID, we get the following "good" result:<br>
><br>
><br>
><br>
> 2011-06-02 14:15:15.135193 [DEBUG] switch_core_state_machine.c:397<br>
> (sofia/external/8151231234@xxx.xxx.xxx.xxx:5060) Running State Change CS_NEW<br>
><br>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia.c:3210 Channel<br>
> sofia/external/8151231234@ xxx.xxx.xxx.xxx:5060 entering state<br>
> [received][100]<br>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia.c:3217 Remote SDP:<br>
><br>
><br>
> v=0<br>
><br>
><br>
> o=Acme_UAS 0 1 IN IP4 xxx.xxx.xxx.xxx<br>
><br>
><br>
> s=SIP Media Capabilities<br>
><br>
><br>
> c=IN IP4 yyy.yyy.yyy.yyy<br>
><br>
><br>
> t=0 0<br>
><br>
><br>
> m=audio 52052 RTP/AVP 0 18 101<br>
><br>
><br>
> a=rtpmap:0 PCMU/8000<br>
><br>
><br>
> a=rtpmap:18 G729/8000<br>
><br>
><br>
> a=rtpmap:101 telephone-event/8000<br>
><br>
><br>
> a=maxptime:20<br>
><br>
><br>
><br>
><br>
><br>
> 2011-06-02 14:15:15.135193 [DEBUG] switch_core_state_machine.c:403<br>
> (sofia/external/8151231234@xxx.xxx.xxx.xxx.10:5060) State NEW<br>
><br>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia_glue.c:3081 Audio Codec Compare<br>
> [PCMU:0:8000:20]/[PCMU:0:8000:20]<br>
><br>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia_glue.c:3092 Bah HUMBUG! Sticking<br>
> with PCMU@8000h@20i<br>
><br>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia_glue.c:2039 Set Codec<br>
> sofia/external/8151231234@xxx.xxx.xxx.xxx:5060 PCMU/8000 20 ms 160 samples<br>
><br>
> 2011-06-02 14:15:15.135193 [DEBUG] sofia_glue.c:3041 Set 2833 dtmf payload<br>
> to 101<br>
><br>
><br>
> Naturally, the "far end" vendor says they think its a "FreeSwitch problem".<br>
> Huh? For my part, I'd just like to FORCE a ptime of 20 in all cases, no<br>
> matter the codec, for incoming calls, either DID. Tried, but so far, no go.<br>
><br>
> A packet capture showed "bad" call coming in with ptime max of 30, we<br>
> respond that 30 is OK but them re-invite with ptime set to 20, but it<br>
> doesn't seem to "catch". On the good DID, they proffer ptime max of 30, we<br>
> respond with ptime of 20 and life is good.<br>
><br>
> Sorry to post again on this. I have put in some hours but still same results<br>
> so far. Any suggestions much appreciated.<br>
><br>
> Regards,<br>
><br>
> Mike<br>
><br>
</div></div>> _______________________________________________<br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:<a href="tel:%2B19193869900" value="+19193869900">+19193869900</a><br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br>