Hi again Brian,<br><br>I can confirm that having followed your advice, it now works perfectly.<br><br>Many, many thanks for your extraordinarily quick and comprehensive help with this.<br><br>Best wishes<br>Bruce<br><br><div class="gmail_quote">
On 9 February 2010 22:13, Bruce Hopkins <span dir="ltr"><<a href="mailto:jbrucehopkins@gmail.com">jbrucehopkins@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Aha - I will try this now. At the moment I only have SPEEX without anything like @8000h or 16000h.<br><br>Thanks in advance, as I am sure you have spotted my noob error !<br><font color="#888888"><br>Bruce</font><div><div>
</div><div class="h5"><br><br><div class="gmail_quote">On 9 February 2010 22:00, Brian West <span dir="ltr"><<a href="mailto:brian@freeswitch.org" target="_blank">brian@freeswitch.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You need to allow SPEEX@8000h,SPEEX@16000h,SPEEX@32000h<br>
<font color="#888888"><br>
/b<br>
</font><div><br>
On Feb 9, 2010, at 3:55 PM, Bruce Hopkins wrote:<br>
<br>
> Willdo,<br>
><br>
> To clarify in brief though, the scenario which occurs and causes the call to fail is:<br>
><br>
> SIP client 1 (g.722 enabled only ) -----> INVITE (with SDP offer: Media Attribute (a): rtpmap:9 g722/8000 ) -->FreeSWITCH<br>
><br>
> ---> INVITE (with SDP offer including a bunch of codecs including rtpmap: rtpmap:98 SPEEX/8000 but crucially not including SPEEX/16000 or SPEEX/32000)<br>
><br>
> ---> SIP client 2 (with only SPEEX/16000 or SPEEX/32000 enabled).<br>
><br>
> The second SIP client does not get offered a codec it can accept, so SIP client 1 is sent a method 488 "Not Acceptable Here" message and the calling party gets directed to the voicemail for the other SIP client.<br>
><br>
> By contrast, there is no problem calling SPEEX/32000 --> SPEEX/32000 or calling SPEEX/16000 --> SPEEX/16000.<br>
><br>
> there is also no problem calling SPEEX/32000 --> g.722/8000.<br>
><br>
> I am wondering if the problem is that FreeSWITCH is interpreting g.722 as being a narrowband (8kHz sample rate) codec, due to the historic anomaly of it presenting g722/8000 in the SDP even though it in fact uses 16kHz sampling, and for that reason not wanting to offer a 16kHz sample rate codec to the second SIP client?<br>
><br>
> I suggest this as I also found trying to call alaw --> SPEEX/16000 does not work, for example.<br>
<br>
<br>
</div><div><div></div><div>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">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>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>