[Freeswitch-users] inherit_codec failing with pre-media

Steven Ayre steveayre at gmail.com
Mon Sep 23 18:33:55 MSD 2013


>
> 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.


Usually in SIP calling A -> FS -> B

Bridge sends INVITE to B. 100 Trying is sent back immediately to
acknowledge. A hears nothing.

Then you receive either 180 or 183/SDP:
- 180 Ringing indicates the phone is ringing but that A should generate its
own ringback tone
- 183/SDP indicates that B is sending early media (usually containing a
ringback tone), FS forwards this to A

Then you get 200 OK (answer) at which point you get 2-way audio setup.

So either A or B generates the ringback, FS usually does not need to.












On 23 September 2013 12:55, sangdrax8 <sangdrax8 at gmail.com> wrote:

> > 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 at 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 at 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 at 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 at 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 at 8000h@20i at 64000b,PCMU at 8000h@20i at 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 at freeswitch.org
> >> >> http://www.freeswitchsolutions.com
> >> >>
> >> >> 
> >> >> 
> >> >>
> >> >> Official FreeSWITCH Sites
> >> >> http://www.freeswitch.org
> >> >> http://wiki.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.free
> >> >
> >> >
> >> >
> >> >
> _________________________________________________________________________
> >> > Professional FreeSWITCH Consulting Services:
> >> > consulting at freeswitch.org
> >> > http://www.freeswitchsolutions.com
> >> >
> >> > 
> >> > 
> >> >
> >> > Official FreeSWITCH Sites
> >> > http://www.freeswitch.org
> >> > http://wiki.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://wiki.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://wiki.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://wiki.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/20130923/b4947905/attachment-0001.html 


Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-users mailing list