> Just to clarify this message, that's the 'set' application logging that the
> variable has been set on the channel, not anything suggesting that it is
> taking effect.

Correct, the variable has been set.

> Is the b-leg of the bridge not sending any early media ringback?

No, and I assumed this to be normal?  When one sip client places a
call to a second sip client on the same Freeswitch, I wouldn't expect
the second sip client to provide some sort of ringing.  In fact,
shouldn't this ringing be happening while the B-leg is being
contacted?  I don't see how it could be the one providing the sound.
In the example dialplan Freeswitch does provide this ringback, but in
doing so it also negotiates a codec.  Hence I removed the ringback,
and suddenly my inherit_codec is providing the functionality expected
minus the ring.

On Thu, Sep 19, 2013 at 11:06 AM, Steven Ayre <steveayre@gmail.com> wrote:
>> It logs that it is set to true
>
>
> Just to clarify this message, that's the 'set' application logging that the
> variable has been set on the channel, not anything suggesting that it is
> taking effect.
>
>> I just can't have a phone system with no ringing for the calling party.
>
>
> Is the b-leg of the bridge not sending any early media ringback?
>
>
> On 19 September 2013 13:03, sangdrax8 <sangdrax8@gmail.com> wrote:
>>
>> Yes, I did make sure that was activated in the profile.  the
>> configuration that comes from the git repo has that turned on, and I
>> am using the demo config directly from git.
>>
>> The demo dial plan doesn't include the inherit_codec=true line, so I
>> did add that.  It logs that it is set to true, but freeswitch ends up
>> transcoding.  If I remove the ringback, suddenly everything works as
>> expected.  I just can't have a phone system with no ringing for the
>> calling party.  Still it does indicate that inbound late negotiation
>> and the inherit_codec are capable of doing the right thing.  Just when
>> a ring back is added, it seems to fail to work.
>>
>> If I am configuring this correctly (only 1 change from the demo
>> configuration provided) should I open a bug somewhere, or e-mail a dev
>> list?  I didn't want to do either of these without someone confirming
>> that my configuration part is correct and that it is a bug.
>>
>> "Faithless is he, who says 'farewell', when the path darkens."
>> "you just keep on trying till you run out of cake"
>>
>>
>> On Wed, Sep 18, 2013 at 7:31 PM, Steven Ayre <steveayre@gmail.com> wrote:
>> > Inherit_codec requires late negotiation - is that enabled too? Otherwise
>> > the
>> > aleg codec has already been picked before hitting the dialplan.
>> >
>> >
>> > On Wednesday, September 18, 2013, sangdrax8 wrote:
>> >>
>> >> Did I explain a bit to much detail for the users list?
>> >>
>> >> Does anyone use "inherit_codec=true" and have it working?
>> >>
>> >>
>> >> On Tue, Sep 17, 2013 at 2:27 PM, sangdrax8 <sangdrax8@gmail.com> wrote:
>> >> > I pulled the latest freeswitch from git this morning, and am still
>> >> > having issues using inherit_codec=true.  It seems the only way I can
>> >> > get it to defer to the choice of the b-leg call is to remove the
>> >> > ringback, and thus the need for early media.
>> >> >
>> >> > My setup has 2 phones with the following codecs configured:
>> >> >
>> >> > phone1000:  g722, ulaw
>> >> > phone1001:  ulaw
>> >> >
>> >> > My goal is to have a call initiated by phone1000 (a-leg) to defer the
>> >> > codec choice until phone1001 (b-leg) chooses one.  This would allow
>> >> > them to talk with no transcoding required by freeswitch.  With the
>> >> > following dial plan, this fails to work.
>> >> >
>> >> > <extension name="Local_Extension">
>> >> >       <condition field="destination_number"
>> >> > expression="^(10[01][0-9])$">
>> >> >         <action application="export" data="dialed_extension=$1"/>
>> >> >         <action application="set" data="ringback=${us-ring}"/>
>> >> >         <action application="set"
>> >> > data="transfer_ringback=$${hold_music}"/>
>> >> >         <action application="set" data="call_timeout=30"/>
>> >> >         <action application="set" data="hangup_after_bridge=true"/>
>> >> >         <action application="set" data="inherit_codec=true" />
>> >> >         <action application="bridge"
>> >> > data="user/${dialed_extension}@${domain_name}"/>
>> >> >       </condition>
>> >> > </extension>
>> >> >
>> >> > It does log that it is going to defer:
>> >> >
>> >> > 2013-09-17 13:15:10.956535 [DEBUG] mod_sofia.c:4542 [zrtp_passthru]
>> >> > Setting a-leg inherit_codec=true
>> >> > 2013-09-17 13:15:10.956535 [DEBUG] mod_sofia.c:4545 [zrtp_passthru]
>> >> > Setting b-leg
>> >> > absolute_codec_string='G722@8000h@20i@64000b,PCMU@8000h@20i@64000b'
>> >> >
>> >> >
>> >> > then it tries to provide the ringback for the a-leg, and it
>> >> > negotiates
>> >> > to g722 since freeswitch supports that and it is the first match.
>> >> > Later when the b-leg is answered, it also negotiates, this time to
>> >> > ulaw as that is all b supports.  My call completes, but freeswitch
>> >> > has
>> >> > to transcode between the two.
>> >> >
>> >> > In an attempt to see inherit_codec work, I then commented out the
>> >> > ringback line from the above dialplan.  With only this one change,
>> >> > freeswitch now waits until the b-leg negotiation, and passes that
>> >> > back
>> >> > to the a-leg.  The call completes and both handsets are using ulaw
>> >> > and
>> >> > no transcoding is required.  The problem being that the calling party
>> >> > never gets a ring while waiting.
>> >> >
>> >> > I can't imagine that the only way to use inherit_codec=true is with
>> >> > all ringing turned off.  Can someone tell me if there is an
>> >> > additional
>> >> > option I am missing?  All documentation I read seems to indicate that
>> >> > just adding "inherit_codec=true" will fix things, but even the
>> >> > default.xml provided as an example uses ringback and therefore fails.
>> >>
>> >>
>> >> _________________________________________________________________________
>> >> Professional FreeSWITCH Consulting Services:
>> >> consulting@freeswitch.org
>> >> http://www.freeswitchsolutions.com
>> >>
>> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>> >> http://www.cudatel.com
>> >>
>> >> Official FreeSWITCH Sites
>> >> http://www.freeswitch.org
>> >> http://wiki.freeswitch.org
>> >> http://www.cluecon.com
>> >>
>> >> FreeSWITCH-users mailing list
>> >> FreeSWITCH-users@lists.freeswitch.org
>> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> >> UNSUBSCRIBE:http://lists.free
>> >
>> >
>> >
>> > _________________________________________________________________________
>> > Professional FreeSWITCH Consulting Services:
>> > consulting@freeswitch.org
>> > http://www.freeswitchsolutions.com
>> >
>> > FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>> > http://www.cudatel.com
>> >
>> > Official FreeSWITCH Sites
>> > http://www.freeswitch.org
>> > http://wiki.freeswitch.org
>> > http://www.cluecon.com
>> >
>> > 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
>> >
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting@freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>> http://www.cudatel.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> 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
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting@freeswitch.org
> http://www.freeswitchsolutions.com
>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> http://www.cudatel.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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
>

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

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