<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">The other device is not a phone, but a pair of Adtran 908e 2nd Gen doing basic PRI to VoIP conversion. All of a sudden all calls were rejecting like this, but when I restarted FreeSWITCH everything started working fine again. I did not reboot or otherwise do anything to the Adtrans. The Adtrans are sending early media and have no reason to receive it, yet, so that might explain why they are sending the 0.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">On another note, I just searched a recent log file, and I don't find the string "m=audio 0" anywhere in the file.</div>
</div><div class="gmail_extra"><br clear="all"><div><div><span style="font-family:arial;font-size:small"><br></span></div><div><span style="font-family:arial;font-size:small"><br></span></div><span style="font-family:arial;font-size:small">Royce Mitchell, </span>IT Consultant<div style="font-family:arial;font-size:small">
ITAS Solutions</div><div style="font-family:arial;font-size:small"><a href="mailto:royce3@itas-solutions.com" target="_blank">royce3@itas-solutions.com</a></div></div>
<br><br><div class="gmail_quote">On Mon, Aug 19, 2013 at 11:45 AM, Steven Ayre <span dir="ltr"><<a href="mailto:steveayre@gmail.com" target="_blank">steveayre@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AFAIK port zero is a method of putting the call on hold in a reinvite, and shouldn't be in the initial invite.<div><br></div><div>Without a port you can only receive audio not send it (as you have nowhere to send to).</div>
<div><br></div><div>Your SDP shows the phone is hiding its model - what is it? There's a 2011 mailing list thread suggesting it may be an issue with a bad firmware on a type of phone.<span></span></div><div class="HOEnZb">
<div class="h5"><div><br></div>
<div><br></div><div><br><br>On Monday, August 19, 2013, Vallimamod ABDULLAH wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div>Hi,</div><div><br></div><div>It looks like the remote SDP does not contain correct rtp port information. You have:</div><div><br></div><div><div>m=audio 0 RTP/AVP 0 18 101</div><div><br></div><div>The first '0' should be the rtp port normally. I am not sure but it does not looks correct and may be the cause of the incompatible destination error.</div>
<div>Hope this helps.</div><div><br></div><div>-- </div><div>Best Regards,</div><div>Vallimamod</div><div>.</div><div><br></div><div><br></div></div>
<br><div><div>On Aug 19, 2013, at 2:59 PM, Royce Mitchell III <<a>royce3@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div style="font-family:courier new,monospace">Here is one example, thanks</div>
</div><div><br clear="all"><div><div><span style="font-family:arial;font-size:small"><br>
</span></div><div><span style="font-family:arial;font-size:small"><br></span></div><span style="font-family:arial;font-size:small">Royce Mitchell, </span>IT Consultant<div style="font-family:arial;font-size:small">ITAS Solutions</div>
<div style="font-family:arial;font-size:small"><a>royce3@itas-solutions.com</a></div></div>
<br><br><div>On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <span dir="ltr"><<a>steveayre@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Can you paste a debug log of the entire lifetime of the call?</div><div><div><div><br><br><div>On 16 August 2013 21:57, Royce Mitchell III <span dir="ltr"><<a>royce3@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:courier new,monospace">The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )</div>
</div><div><div><br clear="all"><div><div><span style="font-family:arial;font-size:small"><br></span></div><div><span style="font-family:arial;font-size:small"><br></span></div><span style="font-family:arial;font-size:small">Royce Mitchell, </span>IT Consultant<div style="font-family:arial;font-size:small">
ITAS Solutions</div><div style="font-family:arial;font-size:small"><a>royce3@itas-solutions.com</a></div></div>
<br><br></div><div><div>On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <span dir="ltr"><<a>lconroy@insensate.co.uk</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi there,<br>
Are you sure about fS allowing PCMU?<br>
According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :).<br>
Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change.<br>
Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU.<br>
Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall?<br>
all the best,<br>
Lawrence<br>
<div><br>
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:<br>
> My FreeSWITCH is configured to prefer PCMU, and the devices it is talking<br>
> to are Adtran 908e's. The Adtrans are configured for the default codec<br>
> group which is supposed to be PCMU, but I can reconfigure them to<br>
> explicitly allow only PCMU. I will try that and see if it makes a<br>
> difference.<br>
><br>
><br>
><br>
> Royce Mitchell, IT Consultant<br>
> ITAS Solutions<br>
> <a>royce3@itas-solutions.com</a><br>
><br>
><br>
> On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <<a>steveayre@gmail.com</a>> wrote:<br>
><br>
>> INCOMPATIBLE_DESTINATION means a codec problem.<br>
>><br>
>> The remote SDP sends they're offerring PCMU and G729.<br>
>><br>
>> What codecs are you allowing, what codecs are you bridging with, and since<br>
>> G729 is on the list are you perhaps trying to transcode without using<br>
>> mod_com_g729+licenses?<br>
>><br>
>><br>
>> On 16 August 2013 16:07, Royce Mitchell III <<a></a></div></blockquote></div></div></div></blockquote></div></div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div>
</div></div><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><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>
<br></blockquote></div><br></div>