<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Thanks for the help. I'm working on a clean log. We had many outgoing calls at the same time, the console log is mixed up with other calls.</div><div><br></div><div>Digging more into our logs, it seems the issue is sporadic: 50% of the time we can connect to a switch offering only PCMA, and other times we only offer PCMU and get this codec negotiation error. The configuration has not changed across calls:</div><div><br></div><div><blockquote type="cite"><blockquote type="cite"> <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G722,PCMU,PCMA,GSM"/><br> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMU,PCMA,GSM"/></blockquote></blockquote><br></div><div>I'll work on a console log and sip trace. In the meantime, any idea what could cause variation between calls in the codecs offered?</div><div><br></div><div>+Mark</div><div><br></div><div><br></div><br><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica';">Kristian Kielhofner <<a href="mailto:kris@kriskinc.com">kris@kriskinc.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica';"><b>Re: [Freeswitch-users] Error in codec negotiation: What are all the places that specify accepted codecs for outgoing calls?</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica';">6 June 2014 18:17:47 GMT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica';">FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org">freeswitch-users@lists.freeswitch.org</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Reply-To: </b></span><span style="font-family:'Helvetica';">FreeSWITCH Users Help <<a href="mailto:freeswitch-users@lists.freeswitch.org">freeswitch-users@lists.freeswitch.org</a>><br></span></div><br><br>We would need to see a full siptrace and console log to see what's<br>happening here.<br><br>On Fri, Jun 6, 2014 at 10:27 AM, Mark Boots <<a href="mailto:mark@votomobile.org">mark@votomobile.org</a>> wrote:<br><blockquote type="cite">We're using a major VoIP terminator and finding that on many outgoing calls,<br>Freeswitch hangs up with INCOMPATIBLE_DESTINATION after trying to negotiate<br>codecs.<br><br>The carrier offers PCMA, and it looks like Freeswitch refuses to accept<br>anything but PCMU:<br><br><br>2014-06-06 13:18:54.115197 [NOTICE] sofia_media.c:92 Pre-Answer<br>sofia/external/0011104555493618652!<br>2014-06-06 13:18:54.115197 [DEBUG] switch_channel.c:3277<br>(sofia/external/0011104555493618652) Callstate Change DOWN -> EARLY<br>2014-06-06 13:18:54.175210 [DEBUG] switch_core_session.c:1005 Send signal<br>sofia/external/0011104555391494140 [BREAK]<br>2014-06-06 13:18:54.175210 [DEBUG] switch_core_session.c:1005 Send signal<br>sofia/external/0011104555391494140 [BREAK]<br>2014-06-06 13:18:54.175210 [DEBUG] sofia.c:5741 Channel<br>sofia/external/0011104555391494140 entering state [proceeding][183]<br>2014-06-06 13:18:54.175210 [DEBUG] sofia.c:5750 Remote SDP:<br>v=0<br>o=- 313783328916230866 1 IN IP4 81.52.176.165<br>s=-<br>c=IN IP4 81.52.176.165<br>t=0 0<br>a=sendrecv<br>m=audio 25080 RTP/AVP 8 13 101<br>a=rtpmap:8 PCMA/8000<br>a=rtpmap:13 CN/8000<br>a=rtpmap:101 telephone-event/8000<br>a=fmtp:101 0-15<br><br>2014-06-06 13:18:54.175210 [DEBUG] switch_core_media.c:2585 Set comfort<br>noise payload to 13<br>2014-06-06 13:18:54.175210 [DEBUG] switch_core_media.c:2662 Audio Codec<br>Compare [PCMA:8:8000:20:64000]/[PCMU:0:8000:20:64000]<br>2014-06-06 13:18:54.175210 [DEBUG] switch_core_media.c:2662 Audio Codec<br>Compare [CN:13:8000:20:0]/[PCMU:0:8000:20:64000]<br>2014-06-06 13:18:54.175210 [DEBUG] switch_core_media.c:2662 Audio Codec<br>Compare [telephone-event:101:8000:20:0]/[PCMU:0:8000:20:64000]<br>2014-06-06 13:18:54.175210 [DEBUG] switch_core_media.c:2824 Set 2833 dtmf<br>send payload to 101<br>2014-06-06 13:18:54.175210 [DEBUG] switch_core_session.c:1005 Send signal<br>sofia/external/0011104555391494140 [BREAK]<br>2014-06-06 13:18:54.175210 [NOTICE] sofia.c:5868 Hangup<br>sofia/external/0011104555391494140 [CS_CONSUME_MEDIA]<br>[INCOMPATIBLE_DESTINATION]<br><br><br>However, our codec settings in vars.xml specify:<br><br> <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G722,PCMU,PCMA,GSM"/><br> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMU,PCMA,GSM"/><br><br>The sip profile uses these settings. Any idea how to debug what codecs<br>Freeswitch is willing to accept?<br><br>Thanks!<br>+Mark<br><br>_________________________________________________________________________<br>Professional FreeSWITCH Consulting Services:<br><a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>http://www.freeswitchsolutions.com<br><br>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>http://www.cudatel.com<br><br>Official FreeSWITCH Sites<br>http://www.freeswitch.org<br>http://wiki.freeswitch.org<br>http://www.cluecon.com<br><br>FreeSWITCH-users mailing list<br>FreeSWITCH-users@lists.freeswitch.org<br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org<br><br></blockquote><br><br><br>-- <br>Kristian Kielhofner<br></blockquote></div><br></body></html>