Aha - I will try this now.  At the moment I only have SPEEX without anything like @8000h or 16000h.

Thanks in advance, as I am sure you have spotted my noob error !

Bruce

On 9 February 2010 22:00, Brian West <brian@freeswitch.org> wrote:
You need to allow SPEEX@8000h,SPEEX@16000h,SPEEX@32000h

/b

On Feb 9, 2010, at 3:55 PM, Bruce Hopkins wrote:

> Willdo,
>
> To clarify in brief though, the scenario which occurs and causes the call to fail is:
>
> SIP client  1 (g.722 enabled only ) -----> INVITE (with SDP offer: Media Attribute (a): rtpmap:9 g722/8000 ) -->FreeSWITCH
>
> ---> INVITE (with SDP offer including a bunch of codecs including rtpmap: rtpmap:98 SPEEX/8000 but crucially not including SPEEX/16000 or SPEEX/32000)
>
> ---> SIP client 2 (with only SPEEX/16000 or SPEEX/32000 enabled).
>
> 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.
>
> By contrast, there is no problem calling SPEEX/32000 --> SPEEX/32000 or calling SPEEX/16000 --> SPEEX/16000.
>
> there is also no problem calling SPEEX/32000 --> g.722/8000.
>
> 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?
>
> I suggest this as I also found trying to call alaw --> SPEEX/16000 does not work, for example.