[Freeswitch-users] INCOMPATIBLE_DESTINATION

Wed Aug 21 01:18:00 MSD 2013

I agree, the inconsistency is really baffling. I am intimately familiar
with this environment and can assure there is nothing but basic network
switches between the Adtrans and the FreeSWITCH instances. They are all in
the same rack and plugged into Dell PowerEdge switches.

Royce Mitchell, IT Consultant
ITAS Solutions
royce3 at itas-solutions.com

On Tue, Aug 20, 2013 at 3:52 PM, Vallimamod ABDULLAH <
vallimamod.abdullah at imtelecom.fr> wrote:

> Hi,
>
> What is really strange is that your problem does not happen consistently.
>
> Have you checked for any sip enabled firewall or rtp proxy on the call
> path?
> You can make a sip trace with ngrep on the interface connected to the pri
> gateway and check if you get the 0 port sdp everytime from the adtran or
> only when you get the error on freeswitch (in wich case, you can point that
> to their support.)
> Make also ngrep trace on the freeswith interface and on any router in the
> middle to check if your invite is modified along the path.
>
> --
> Cheers,
> Vallimamod
> .
>
> On Aug 20, 2013, at 6:01 PM, Royce Mitchell III <royce3 at gmail.com> wrote:
>
> It happened again this morning. I enabled console loglevel debug and
> placed a test call. Then, to try something different, I rebooted the
> primary adtran instead of FreeSWITCH. Just like when I restarted FreeSWITCH
> the first time, rebooting the Adtran fixed the problem, as calls started
> rolling in normally once it came back up.
>
> Given that the adtran is sending these "0" port packets, I think I need to
> open a ticket with them. Can I get some advice on what to tell them as to
> why sending a one-way audio packet during early media is a problem ( or am
> I even describing the problem correctly )?
>
>
>
> Royce Mitchell, IT Consultant
> ITAS Solutions
> royce3 at itas-solutions.com
>
>
> On Mon, Aug 19, 2013 at 12:59 PM, Royce Mitchell III <royce3 at gmail.com>wrote:
>
>> 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.
>>
>> On another note, I just searched a recent log file, and I don't find the
>> string "m=audio 0" anywhere in the file.
>>
>>
>>
>> Royce Mitchell, IT Consultant
>> ITAS Solutions
>> royce3 at itas-solutions.com
>>
>>
>> On Mon, Aug 19, 2013 at 11:45 AM, Steven Ayre <steveayre at gmail.com>wrote:
>>
>>> AFAIK port zero is a method of putting the call on hold in a reinvite,
>>> and shouldn't be in the initial invite.
>>>
>>> Without a port you can only receive audio not send it (as you have
>>> nowhere to send to).
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> On Monday, August 19, 2013, Vallimamod ABDULLAH wrote:
>>>
>>>> Hi,
>>>>
>>>> It looks like the remote SDP does not contain correct rtp port
>>>> information. You have:
>>>>
>>>> m=audio 0 RTP/AVP 0 18 101
>>>>
>>>> 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.
>>>> Hope this helps.
>>>>
>>>> --
>>>> Best Regards,
>>>> Vallimamod
>>>> .
>>>>
>>>>
>>>>
>>>> On Aug 19, 2013, at 2:59 PM, Royce Mitchell III <royce3 at gmail.com>
>>>> wrote:
>>>>
>>>> Here is one example, thanks
>>>>
>>>>
>>>>
>>>> Royce Mitchell, IT Consultant
>>>> ITAS Solutions
>>>> royce3 at itas-solutions.com
>>>>
>>>>
>>>> On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <steveayre at gmail.com>wrote:
>>>>
>>>> Can you paste a debug log of the entire lifetime of the call?
>>>>
>>>>
>>>> On 16 August 2013 21:57, Royce Mitchell III <royce3 at gmail.com> wrote:
>>>>
>>>> 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 )
>>>>
>>>>
>>>>
>>>> Royce Mitchell, IT Consultant
>>>> ITAS Solutions
>>>> royce3 at itas-solutions.com
>>>>
>>>>
>>>> On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <
>>>> lconroy at insensate.co.uk> wrote:
>>>>
>>>> Hi there,
>>>>  Are you sure about fS allowing PCMU?
>>>> According to the remote SDP, your incall is proposing PCMU as its top
>>>> choice; g729 is 2nd best (quite right too :).
>>>> Forcing the adtran to offer only PCMU should not make ay difference to
>>>> that -- it'll still propose PCMU so no change.
>>>> 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.
>>>> Assuming that PCMU is in the fS vars codec lists, does your dialplan do
>>>> anything funky with the codec list for an incall?
>>>> all the best,
>>>>   Lawrence
>>>>
>>>> On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
>>>> > My FreeSWITCH is configured to prefer PCMU, and the devices it is
>>>> talking
>>>> > to are Adtran 908e's. The Adtrans are configured for the default codec
>>>> > group which is supposed to be PCMU, but I can reconfigure them to
>>>> > explicitly allow only PCMU. I will try that and see if it makes a
>>>> > difference.
>>>> >
>>>> >
>>>> >
>>>> > Royce Mitchell, IT Consultant
>>>> > ITAS Solutions
>>>> > royce3 at itas-solutions.com
>>>> >
>>>> >
>>>> > On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre at gmail.com>
>>>> wrote:
>>>> >
>>>> >> INCOMPATIBLE_DESTINATION means a codec problem.
>>>> >>
>>>> >> The remote SDP sends they're offerring PCMU and G729.
>>>> >>
>>>> >> What codecs are you allowing, what codecs are you bridging with, and
>>>> since
>>>> >> G729 is on the list are you perhaps trying to transcode without using
>>>> >> mod_com_g729+licenses?
>>>> >>
>>>> >>
>>>> >> On 16 August 2013 16:07, Royce Mitchell III <
>>>>
>>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> 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
>>>
>>>
>>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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/20130820/92c95101/attachment-0001.html 