<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">No, and I assumed this to be normal? When one sip client places a<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">call to a second sip client on the same Freeswitch, I wouldn't expect<br></span><span style="font-family:arial,sans-serif;font-size:13px">the second sip client to provide some sort of ringing. In fact,<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">shouldn't this ringing be happening while the B-leg is being<br></span><span style="font-family:arial,sans-serif;font-size:13px">contacted? I don't see how it could be the one providing the sound.<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">In the example dialplan Freeswitch does provide this ringback, but in<br></span><span style="font-family:arial,sans-serif;font-size:13px">doing so it also negotiates a codec. Hence I removed the ringback,<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">and suddenly my inherit_codec is providing the functionality expected<br></span><span style="font-family:arial,sans-serif;font-size:13px">minus the ring.</span></blockquote>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">Usually in SIP calling A -> FS -> B</font></div><div><font face="arial, sans-serif"><br></font></div>
<div><font face="arial, sans-serif">Bridge sends INVITE to B. 100 Trying is sent back immediately to acknowledge. </font><span style="font-family:arial,sans-serif">A hears nothing.</span></div><div><br></div><div><font face="arial, sans-serif">Then you receive either 180 or 183/SDP:</font></div>
<div><font face="arial, sans-serif">- 180 Ringing indicates the phone is ringing but that A should generate its own ringback tone</font></div><div><font face="arial, sans-serif">- 183/SDP indicates that B is sending early media (usually containing a ringback tone), FS forwards this to A</font></div>
<div><br></div><div><font face="arial, sans-serif">Then you get 200 OK (answer) at which point you get 2-way audio setup.</font></div><div><font face="arial, sans-serif"><br></font></div><div><span style="font-family:arial,sans-serif">So either A or B generates the ringback, FS usually does not need to.</span><font face="arial, sans-serif"><br>
</font></div><div><br></div><div><br></div><div><br></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 23 September 2013 12:55, sangdrax8 <span dir="ltr"><<a href="mailto:sangdrax8@gmail.com" target="_blank">sangdrax8@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Just to clarify this message, that's the 'set' application logging that the<br>
> variable has been set on the channel, not anything suggesting that it is<br>
> taking effect.<br>
<br>
</div>Correct, the variable has been set.<br>
<div class="im"><br>
> Is the b-leg of the bridge not sending any early media ringback?<br>
<br>
</div>No, and I assumed this to be normal? When one sip client places a<br>
call to a second sip client on the same Freeswitch, I wouldn't expect<br>
the second sip client to provide some sort of ringing. In fact,<br>
shouldn't this ringing be happening while the B-leg is being<br>
contacted? I don't see how it could be the one providing the sound.<br>
In the example dialplan Freeswitch does provide this ringback, but in<br>
doing so it also negotiates a codec. Hence I removed the ringback,<br>
and suddenly my inherit_codec is providing the functionality expected<br>
minus the ring.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Sep 19, 2013 at 11:06 AM, Steven Ayre <<a href="mailto:steveayre@gmail.com">steveayre@gmail.com</a>> wrote:<br>
>> It logs that it is set to true<br>
><br>
><br>
> Just to clarify this message, that's the 'set' application logging that the<br>
> variable has been set on the channel, not anything suggesting that it is<br>
> taking effect.<br>
><br>
>> I just can't have a phone system with no ringing for the calling party.<br>
><br>
><br>
> Is the b-leg of the bridge not sending any early media ringback?<br>
><br>
><br>
> On 19 September 2013 13:03, sangdrax8 <<a href="mailto:sangdrax8@gmail.com">sangdrax8@gmail.com</a>> wrote:<br>
>><br>
>> Yes, I did make sure that was activated in the profile. the<br>
>> configuration that comes from the git repo has that turned on, and I<br>
>> am using the demo config directly from git.<br>
>><br>
>> The demo dial plan doesn't include the inherit_codec=true line, so I<br>
>> did add that. It logs that it is set to true, but freeswitch ends up<br>
>> transcoding. If I remove the ringback, suddenly everything works as<br>
>> expected. I just can't have a phone system with no ringing for the<br>
>> calling party. Still it does indicate that inbound late negotiation<br>
>> and the inherit_codec are capable of doing the right thing. Just when<br>
>> a ring back is added, it seems to fail to work.<br>
>><br>
>> If I am configuring this correctly (only 1 change from the demo<br>
>> configuration provided) should I open a bug somewhere, or e-mail a dev<br>
>> list? I didn't want to do either of these without someone confirming<br>
>> that my configuration part is correct and that it is a bug.<br>
>><br>
>> "Faithless is he, who says 'farewell', when the path darkens."<br>
>> "you just keep on trying till you run out of cake"<br>
>><br>
>><br>
>> On Wed, Sep 18, 2013 at 7:31 PM, Steven Ayre <<a href="mailto:steveayre@gmail.com">steveayre@gmail.com</a>> wrote:<br>
>> > Inherit_codec requires late negotiation - is that enabled too? Otherwise<br>
>> > the<br>
>> > aleg codec has already been picked before hitting the dialplan.<br>
>> ><br>
>> ><br>
>> > On Wednesday, September 18, 2013, sangdrax8 wrote:<br>
>> >><br>
>> >> Did I explain a bit to much detail for the users list?<br>
>> >><br>
>> >> Does anyone use "inherit_codec=true" and have it working?<br>
>> >><br>
>> >><br>
>> >> On Tue, Sep 17, 2013 at 2:27 PM, sangdrax8 <<a href="mailto:sangdrax8@gmail.com">sangdrax8@gmail.com</a>> wrote:<br>
>> >> > I pulled the latest freeswitch from git this morning, and am still<br>
>> >> > having issues using inherit_codec=true. It seems the only way I can<br>
>> >> > get it to defer to the choice of the b-leg call is to remove the<br>
>> >> > ringback, and thus the need for early media.<br>
>> >> ><br>
>> >> > My setup has 2 phones with the following codecs configured:<br>
>> >> ><br>
>> >> > phone1000: g722, ulaw<br>
>> >> > phone1001: ulaw<br>
>> >> ><br>
>> >> > My goal is to have a call initiated by phone1000 (a-leg) to defer the<br>
>> >> > codec choice until phone1001 (b-leg) chooses one. This would allow<br>
>> >> > them to talk with no transcoding required by freeswitch. With the<br>
>> >> > following dial plan, this fails to work.<br>
>> >> ><br>
>> >> > <extension name="Local_Extension"><br>
>> >> > <condition field="destination_number"<br>
>> >> > expression="^(10[01][0-9])$"><br>
>> >> > <action application="export" data="dialed_extension=$1"/><br>
>> >> > <action application="set" data="ringback=${us-ring}"/><br>
>> >> > <action application="set"<br>
>> >> > data="transfer_ringback=$${hold_music}"/><br>
>> >> > <action application="set" data="call_timeout=30"/><br>
>> >> > <action application="set" data="hangup_after_bridge=true"/><br>
>> >> > <action application="set" data="inherit_codec=true" /><br>
>> >> > <action application="bridge"<br>
>> >> > data="user/${dialed_extension}@${domain_name}"/><br>
>> >> > </condition><br>
>> >> > </extension><br>
>> >> ><br>
>> >> > It does log that it is going to defer:<br>
>> >> ><br>
>> >> > 2013-09-17 13:15:10.956535 [DEBUG] mod_sofia.c:4542 [zrtp_passthru]<br>
>> >> > Setting a-leg inherit_codec=true<br>
>> >> > 2013-09-17 13:15:10.956535 [DEBUG] mod_sofia.c:4545 [zrtp_passthru]<br>
>> >> > Setting b-leg<br>
>> >> > absolute_codec_string='G722@8000h@20i@64000b,PCMU@8000h@20i@64000b'<br>
>> >> ><br>
>> >> ><br>
>> >> > then it tries to provide the ringback for the a-leg, and it<br>
>> >> > negotiates<br>
>> >> > to g722 since freeswitch supports that and it is the first match.<br>
>> >> > Later when the b-leg is answered, it also negotiates, this time to<br>
>> >> > ulaw as that is all b supports. My call completes, but freeswitch<br>
>> >> > has<br>
>> >> > to transcode between the two.<br>
>> >> ><br>
>> >> > In an attempt to see inherit_codec work, I then commented out the<br>
>> >> > ringback line from the above dialplan. With only this one change,<br>
>> >> > freeswitch now waits until the b-leg negotiation, and passes that<br>
>> >> > back<br>
>> >> > to the a-leg. The call completes and both handsets are using ulaw<br>
>> >> > and<br>
>> >> > no transcoding is required. The problem being that the calling party<br>
>> >> > never gets a ring while waiting.<br>
>> >> ><br>
>> >> > I can't imagine that the only way to use inherit_codec=true is with<br>
>> >> > all ringing turned off. Can someone tell me if there is an<br>
>> >> > additional<br>
>> >> > option I am missing? All documentation I read seems to indicate that<br>
>> >> > just adding "inherit_codec=true" will fix things, but even the<br>
>> >> > default.xml provided as an example uses ringback and therefore fails.<br>
>> >><br>
>> >><br>
>> >> _________________________________________________________________________<br>
>> >> Professional FreeSWITCH Consulting Services:<br>
>> >> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
>> >> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
>> >><br>
>> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
>> >> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
>> >><br>
>> >> Official FreeSWITCH Sites<br>
>> >> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> >> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
>> >> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
>> >><br>
>> >> FreeSWITCH-users mailing list<br>
>> >> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> >> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> >> UNSUBSCRIBE:<a href="http://lists.free" target="_blank">http://lists.free</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > _________________________________________________________________________<br>
>> > Professional FreeSWITCH Consulting Services:<br>
>> > <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
>> > <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
>> ><br>
>> > FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
>> > <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
>> ><br>
>> > Official FreeSWITCH Sites<br>
>> > <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> > <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
>> > <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
>> ><br>
>> > FreeSWITCH-users mailing list<br>
>> > <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> > <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> > UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> > <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> ><br>
>><br>
>> _________________________________________________________________________<br>
>> Professional FreeSWITCH Consulting Services:<br>
>> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
>> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
>><br>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
>> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
>><br>
>> Official FreeSWITCH Sites<br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
>> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
>><br>
>> FreeSWITCH-users mailing list<br>
>> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
><br>
><br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div>