[Freeswitch-users] REg IVR and codec negotiation

[indra sena]

Hi Steven,

Thanks for your quick response and valuable suggestions.

With out transcoding is there any way to achieve this ?

Like after receiving b-leg codec as G711 can we switch from G729 codec to
G711 in A-leg by sending reinvite/update to A-leg with SDP with G711 ? Is
this procedure works ? currently is freeswitch supports this ?

I have one below query.
After IVR , while giving answer to the A-leg why it is putting only one
codec (with which it has playing IVR), not putting all the allowables
codecs by A-leg ?

Thanks in advance.

Thanks,
GISR.



On Fri, Jan 9, 2015 at 4:32 PM, Steven Ayre <steveayre at gmail.com> wrote:

> Default behaviour should be that it offers all codecs to the gateway and
> transcodes G729-G711 if required.
>
> Check outbound-codec-prefs on the profile you're sending to the gateway
> from? Check it includes both G729 and G711.
>
> Check disable-transcoding is not set to true
>
> If you're using absolute_codec_string check it's including G711, this
> would override any other settings
>
>
>
> On 9 January 2015 at 10:54, indra sena <myforums.indra at gmail.com> wrote:
>
>> Hi All,
>>
>> Do any body have any suggestion on this ?
>>
>>
>> I have observed in freeswitch that, In case of  IVR scenario prior to the
>> bridge FreeSwitch plays IVR with the 1st priority codec then invite to the
>> bridge endpoint (B-leg) with SDP containing only the codec negotiated for
>> IVR. Also the answer (183 ) to originator(A-leg) with SDP containing only
>> with IVR negotiated codec.
>>
>> I am having one issue here for example.
>>
>> Originator(A-leg) sends invite with G729, G711 and Freeswitch negotiated
>> with G729 and starts playing IVR with G729 and answered(183) to originator
>> with SDP containing only G729. And Invited to termination endpoint with SDP
>> having only G729 and termination gateway having support of only G711, and
>> it is rejecting call after receiving invite with only G729.
>>
>> It should be work like after IVR , invite can be having sdp with all the
>> originator supported codecs and if termination (b-leg) having different
>> priority codecs then it can send re-Invite sanding the same.
>>
>> I have observed one issue in freeswitch Jeera (
>> https://freeswitch.org/jira/browse/FS-880) , but there is no solution in
>> that page.
>>
>> Do we have any solution for this right now ?
>>
>> Your answers will be very much helpful for me. I appreciate if you can
>> quick response or give some solution for this.
>>
>> Thanks & Reagrds,
>> GISR..
>>
>> On Thu, Jan 8, 2015 at 12:39 PM, indra sena <myforums.indra at gmail.com>
>> wrote:
>>
>>> Hi ,
>>>
>>> I have observed in freeswitch that, In case of  IVR scenario prior to
>>> the bridge FreeSwitch plays IVR with the 1st priority codec then invite to
>>> the bridge endpoint (B-leg) with SDP containing only the codec negotiated
>>> for IVR. Also the answer (183 ) to originator(A-leg) with SDP containing
>>> only with IVR negotiated codec.
>>>
>>> I am having one issue here for example.
>>>
>>> Originator(A-leg) sends invite with G729, G711 and Freeswitch negotiated
>>> with G729 and starts playing IVR with G729 and answered(183) to originator
>>> with SDP containing only G729. And Invited to termination endpoint with SDP
>>> having only G729 and termination gateway having support of only G711, and
>>> it is rejecting call after receiving invite with only G729.
>>>
>>> It should be work like after IVR , invite can be having sdp with all the
>>> originator supported codecs and if termination (b-leg) having different
>>> priority codecs then it can send re-Invite sanding the same.
>>>
>>> I have observed one issue in freeswitch Jeera (
>>> https://freeswitch.org/jira/browse/FS-880) , but there is no solution
>>> in that page.
>>>
>>> Do we have any solution for this right now ?
>>>
>>> Your answers will be very much helpful for me. I appreciate if you can
>>> quick response or give some solution for this.
>>>
>>> Thanks in advance.
>>>
>>> Thanks & Regards,
>>> GISR..
>>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> 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
>>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150109/2cf315b8/attachment.html