[Freeswitch-users] REg IVR and codec negotiation

[indra sena]

Hi Steven,

Thanks for all your deep insights and bearing with interminable questions.

1) But I'd first look at why the B-leg isn't being offered more codecs.
Avoiding transcoding would be more of an optimisation, you still need to
look at why the gateway wasn't offered G711.
I have found the reason for why gateway wasn't offered G711, because form
my dialplan is sending absolute_codec_string as 'ep_codec_string', i.e.
"absolute_codec_string=\${ep_codec_string}". It is received by fs as
"absolute_codec_string=G729 at 8000h@20i at 8000b,PCMU at 8000h@20i at 64000b" but
while parsing with switch_separate_string_string() it only assigning to
first one  upto first "," (there is a stmt Make sure you have single quotes
( 'PCMA,PCMU' ) around comma ( ',' ) separated list of codecs to protect it
from parsing list of variables inside of
{var1=val1,var2=val2,absolute_codec_string='GSM,PCMU'}). next cdecs are
considering as separate vars and it is considering like this.

Q1: So do we need to send all codecs by substituting instead
'ep_codec_string' like absolute_codec_string='G729,PCMU' from dialplan or
can we send 'ep_codec_string' any other way from dialplan so that it can
parse properly?

After hardcoding absolute_codec_string='G729,PCMU' in dialplan , B-leg is
getting offer with both G729, G711 and it is responding but due to
transcoder is not there there no voice between these two.

2) Before the bridge to that gateway you could try renegotiating the aleg
codec to G711, but it might not work with every client.
https://wiki.freeswitch.org/wiki/Mod_commands#uuid_media_reneg
Q1) As I need to avoid transcoder and IVR should be present. So after
playing IVR can we need to renegotiate with A-leb by uuid_media_reneg , can
we achieve this functionality through dialplan configuration ?

3Q)  FS-880 jeera
https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-880/, they
mentioned that playing your ringback then using refer "deflect" app to
blind transfer the call to the same box in proxy mode.How this will work.

Thanks for your suggestions.

Regards,
GISR.
<https://wiki.freeswitch.org/wiki/Mod_commands#uuid_media_reneg>


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

> > 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 ?
>
> Before the bridge to that gateway you could try renegotiating the aleg
> codec to G711, but it might not work with every client.
> https://wiki.freeswitch.org/wiki/Mod_commands#uuid_media_reneg
> But I'd first look at why the B-leg isn't being offered more codecs.
> Avoiding transcoding would be more of an optimisation, you still need to
> look at why the gateway wasn't offered G711.
>
> > 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 ?
>
> Because at that point it's negotiated which codec to use for the call. The
> a-leg sends the list of codecs it supports, freeswitch compares that to its
> own list and picks the single best match.
>
>
>
>
>
> On 9 January 2015 at 11:22, indra sena <myforums.indra at gmail.com> wrote:
>
>> 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
>>>
>>
>>
>> _________________________________________________________________________
>> 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/f0ac33eb/attachment-0001.html