[Freeswitch-users] INCOMPATIBLE_DESTINATION

Sun Aug 29 09:55:49 PDT 2010

I've done some debugging and found the problem (but not the cause).

switch_core_session_perform_receive_message fails
to switch_core_session_read_lock the session (error code: 720258).

Should I post it as a jira issue?

What does 720258 mean?

On Fri, Aug 27, 2010 at 1:36 PM, Jonas Gauffin <jonas.gauffin at gmail.com>wrote:

> Excellent information thanks. The server is a dedicated voip server and
> nothing else is running on it (and therefore the port should be free).
>
> I've talked to my voip provider and they were kind enough to give me their
> traces.
>
> Freeswitch get's their SDP on the bleg (their software have modified the
> trace a bit):
>
> SIP/2.0 183 Session Progress
> Via: SIP/2.0/UDP 212.247.E.E;rport=5060;branch=z9hG4bK52XcXtpQBp3BH
> From: "blablabla" <sip:02345678 at 212.247.E.E>;tag=rccD75cXD61Kr
> To: <sip:0771221122 at voipprovider.se <sip%3A0771221122 at voipprovider.se>
> >;tag=686577264
> Call-ID: c3e8e0e8-2c3c-122e-479c-1fc6e9408ca4
> CSeq: 1106961 INVITE
> Contact: <sip:0771221122 at 212.151.Y.Y:5060>
> Record-Route: <sip:130.244.Z.Z;lr;ftag=rccD75cXD61Kr;t2diag=c82.4127173>
> Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
> Content-Type: application/sdp
> Content-Length: 169
>
> v=0
> o=- 46541649 0 IN IP4 130.244.x.x
> s=Cisco SDP 0
> c=IN IP4 130.244.x.x
> t=0 0
> m=audio 18928 RTP/AVP 8 101
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
>
> which makes FS cancel the call leg:
>
> CANCEL sip:0771221122 at voipprovider.se <sip%3A0771221122 at voipprovider.se>SIP/2.0
> Via: SIP/2.0/UDP 212.247.E.E;rport;branch=z9hG4bK52XcXtpQBp3BH
> Max-Forwards: 68
> From: "blablabla" <sip:02345678 at 212.247.E.E>;tag=rccD75cXD61Kr
> To: <sip:0771221122 at voipprovider.se <sip%3A0771221122 at voipprovider.se>>
> Call-ID: c3e8e0e8-2c3c-122e-479c-1fc6e9408ca4
> CSeq: 1106961 CANCEL
> Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION"
> Content-Length: 0
>
>
>
> On Fri, Aug 27, 2010 at 9:57 AM, Steven Ayre <steveayre at gmail.com> wrote:
>
>> Yes, G.729a and G.729b are incorrect and your device is at fault... only
>> other phones of the same type would probably recognise it without issue.
>>
>> PCMA should be used in this case though.
>>
>> RTP payload numbers are spread through multiple RFCs. Anything in the
>> 96-127 range is dynamic and the codec is determined from the matching rtpmap
>> line, any of the static numbers don't need a rtpmap line to work. IANA
>> oversees assignment of the static numbers and they have the full list:
>> http://www.iana.org/assignments/rtp-parameters
>>
>> As you can see 0=PCMU, 8=PCMA, and G.729 should use 18. Support of annex B
>> is specified in the fmtp parameter, not the codec name - e.g. "a=fmtp:18
>> annexb=no". Annex A never needs to be specified as it can be read normally
>> by plain G.729, so it's just up to the implementation on whether it wants to
>> save quality or cpu when encoding.
>>
>> Do you have any other applications running which would also be using the
>> RTP port range? A call will fail if it tries to use a port that's already in
>> use, perhaps with that message. FS should avoid using ports it's already
>> using, but can't know about any other programs on the system.
>>
>> -Steve
>>
>>
>>
>> On 27 August 2010 08:03, Jonas Gauffin <jonas.gauffin at gmail.com> wrote:
>>
>>> It doesn't happen every time and it's on a production system with a bit
>>> of volume. therefore a bit hard to get SIP traces. I'll try if Anthony
>>> really needs them.
>>>
>>> FS do say this:
>>> 2010-08-27 07:14:10.758750 [DEBUG] switch_ivr_originate.c:3111sofia/external/
>>> 0700123456 at 212.151.Y.Y:5060 Media Establishment Failed
>>>
>>> In which RFC are codec names defined? rfc3551 defines "G729" but no
>>> "G.729A" or "G.729B". But as you say, shouldn't FS use PCMA in any case?
>>>
>>>
>>>
>>> On Fri, Aug 27, 2010 at 8:43 AM, Steven Ayre <steveayre at gmail.com>wrote:
>>>
>>>> Ordinarily it'd mean there was a problem with the codecs (e.g. needing
>>>> to use an unsupported codec or transcode a codec that only works as a
>>>> passthrough one).
>>>>
>>>> Looks like it should have gone through with PCMA (8) though. Can you
>>>> repeat the call with sip trace on? Perhaps the incompatible destination
>>>> comes from an endpoint.
>>>>
>>>> 'sofia profile <profilename> siptrace on' from the CLI, replace on with
>>>> off to turn it off again.
>>>>
>>>> -Steve
>>>>
>>>>
>>>>
>>>>   On 27 August 2010 07:26, Jonas Gauffin <jonas.gauffin at gmail.com>wrote:
>>>>
>>>>>   Hello,
>>>>>
>>>>> Why do this call result in INCOMPATIBLE_DESTINATION?
>>>>>
>>>>> http://pastebin.freeswitch.org/13736
>>>>>
>>>>> Regards,
>>>>>   Jonas
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20100829/08d2a314/attachment-0001.html 