Re: [Freeswitch-users] inherit_codec failing with pre-media
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.
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<http://lists.freeswitch.org/mailman/options/freeswitch-users>
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
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
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
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@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@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
Thank you for the explanation! I went back and double checked, and with freeswitch's ring commented out I do in fact get the 180's as you described. In fact, the ringing sound is there as well, it was just providing a much quieter beep rather than a ring, so I must have missed it. So this makes sense then. As long as you don't ask freeswitch to send a ring of a specific type, then inherit_codec can work. I'll have to look at my sip client and see if I can configure this ring to sound like a standard ring my users would expect. thank you, I'll continue to work on this! On Mon, Sep 23, 2013 at 10:33 AM, Steven Ayre <steveayre@gmail.com> wrote:
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@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@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
_________________________________________________________________________ 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
participants (2)
-
sangdrax8
-
Steven Ayre