Hello, Why do this call result in INCOMPATIBLE_DESTINATION? http://pastebin.freeswitch.org/13736 Regards, Jonas
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@212.247.E.E>;tag=rccD75cXD61Kr To: <sip:0771221122@voipprovider.se <sip%3A0771221122@voipprovider.se>
;tag=686577264 Call-ID: c3e8e0e8-2c3c-122e-479c-1fc6e9408ca4 CSeq: 1106961 INVITE Contact: <sip:0771221122@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@voipprovider.se <sip%3A0771221122@voipprovider.se>SIP/2.0 Via: SIP/2.0/UDP 212.247.E.E;rport;branch=z9hG4bK52XcXtpQBp3BH Max-Forwards: 68 From: "blablabla" <sip:02345678@212.247.E.E>;tag=rccD75cXD61Kr To: <sip:0771221122@voipprovider.se <sip%3A0771221122@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@212.247.E.E>;tag=rccD75cXD61Kr To: <sip:0771221122@voipprovider.se <sip%3A0771221122@voipprovider.se>
;tag=686577264 Call-ID: c3e8e0e8-2c3c-122e-479c-1fc6e9408ca4 CSeq: 1106961 INVITE Contact: <sip:0771221122@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@voipprovider.se <sip%3A0771221122@voipprovider.se>SIP/2.0 Via: SIP/2.0/UDP 212.247.E.E;rport;branch=z9hG4bK52XcXtpQBp3BH Max-Forwards: 68 From: "blablabla" <sip:02345678@212.247.E.E>;tag=rccD75cXD61Kr To: <sip:0771221122@voipprovider.se <sip%3A0771221122@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Jonas Gauffin
-
Steven Ayre