[Freeswitch-users] G729 coded issues

[Ahmed Naji]

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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100120/203d2bd4/attachment-0002.html