Gents,

Thanks for the responses.

Now gotten Howler to send me a custom build that will not offer G729b in any shape or form, as well as the customer to switch off G729b.

Cisco gateways are negotiating correctly by specifying a=fmtp:18 annexb=yes. If this line is missing, or has an annexb=no, then they will negotiate G729a.

Now the million dollar question: ${switch_r_sdp} will get you the SDP for the remote leg. It's returned as a single string in that variable from what I could tell.

What sort of regex is allowed in the match condition ? can I, for example, simply use the Perl s/<expression>/<replacement> syntax to search for the annexb string and get it rewritten ?

My experiments have so far failed in this regard, i.e. to rewrite the string. Can anyone provide an example ?

I would like to handle codecs in the following way:

  1. receive inbound call
  2. return ringing tone through 3pcc and ring_back
  3. set continue_on_fail=true
  4. set hangup_after_bridge=true
  5. bridge
  6. on failure, transfer to an extension that will look at outcome of codec negotiation
  7. rewrite sdp of the A-leg so that remote end point will successfully accept it
  8. bridge the call again with the SDP appropriately written
  9. If we fail, then hangup with NORMAL_CIRCUIT_CONGESTION, otherwise just let the call be
Regards, and thanks once more.

Ahmed.

2010/1/19 Steve Underwood <steveu@coppice.org>
On 01/20/2010 12:36 AM, Brian West wrote:
> g729a is 100% INVALID in the sdp fix the param in your cisco SPA or your Linksys SPA phone and it will stop doing that.  Hopefully they'll fix this "bug" soon in the cisco phones to not include the a in the sdp.  The fmtp is the proper way to specify annex a or any other options for g729.
>
Annex A only affects the inner workings of the codec. There is
absolutely no difference whatsoever between G.729 and G.729A on the
wire. The SDP has no reason to mention it, and the standards say it
shouldn't.
> /b
>
> On Jan 19, 2010, at 10:31 AM, Ahmed Naji wrote:
>
>
>> Hi everyone,
>>
>> I have the following scenario and a major customer-affecting issue thereof.
>>
>> Here is the scenario: customer traffic encoded as G.729 from a cisco gateway
>> ->  our FS (G729 passthrough) ->  remote end gw (G729)
>>
>> Calls were failing at an alarming rate, so I looked at the debug logs. It
>> transpired that the Cisco is offering G729 annex b, while the remote end can
>> only do G729a.
>>
>> Besides changing source or destination preferences, is there a way to ensure
>> that G729a is used end-end ?
>>
>> Thanks in advance.
>>
>
Steve


_______________________________________________
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



--
Ahmed Naji