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