rfc 2833 not offered on outbound leg in bridge scenario with FS 1.6.7 (worked properly in FS 1.6.6)
I’m running into a problem on v1.6.7 with something that seemed to work properly on v1.6.6, and I am wondering if this is a known bug. I have an application that receives an incoming call and bridges it to an outbound destination. Where there is RFC 2833 offered on the A leg for dtmf I want that to offer that on the B leg as well. I have defined late-negotiation=true on my sip profile. In v1.6.6 (specifically, User agent header identifies as 1.6.6+git~20160111T201612Z~d2d0b3283a~64bit) this worked as expected. In v1.6.7 (specifically, User agent header identifies as 1.6.7+git~20160401T134007Z~f0c3870be3~64bit) it doesn’t. The SDP offered on the B leg does not include RFC 2833 even though the A leg offered it. Is this a known bug? If so, is there a patch? If not, I can provide more information (pastebin logs, etc) to help troubleshoot. Please let me know what would be most useful to see.
Could you please find commit where is bug has been introduced using "git bisect" commands. On Fri, Apr 15, 2016, 06:41 Dave Horton <daveh@beachdognet.com> wrote:
I’m running into a problem on v1.6.7 with something that seemed to work properly on v1.6.6, and I am wondering if this is a known bug.
I have an application that receives an incoming call and bridges it to an outbound destination. Where there is RFC 2833 offered on the A leg for dtmf I want that to offer that on the B leg as well. I have defined late-negotiation=true on my sip profile.
In v1.6.6 (specifically, User agent header identifies as 1.6.6+git~20160111T201612Z~d2d0b3283a~64bit) this worked as expected.
In v1.6.7 (specifically, User agent header identifies as 1.6.7+git~20160401T134007Z~f0c3870be3~64bit) it doesn’t. The SDP offered on the B leg does not include RFC 2833 even though the A leg offered it.
Is this a known bug? If so, is there a patch?
If not, I can provide more information (pastebin logs, etc) to help troubleshoot. Please let me know what would be most useful to see. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Id suggest you guys take a look at FS-9051 also note, that I found that I could work around this bug by explicitly setting <param name="dtmf-type" value="rfc2833"/> in the sip profile. Jay On 15 April 2016 at 13:53, Sergey Safarov <s.safarov@gmail.com> wrote:
Could you please find commit where is bug has been introduced using "git bisect" commands.
On Fri, Apr 15, 2016, 06:41 Dave Horton <daveh@beachdognet.com> wrote:
I’m running into a problem on v1.6.7 with something that seemed to work properly on v1.6.6, and I am wondering if this is a known bug.
I have an application that receives an incoming call and bridges it to an outbound destination. Where there is RFC 2833 offered on the A leg for dtmf I want that to offer that on the B leg as well. I have defined late-negotiation=true on my sip profile.
In v1.6.6 (specifically, User agent header identifies as 1.6.6+git~20160111T201612Z~d2d0b3283a~64bit) this worked as expected.
In v1.6.7 (specifically, User agent header identifies as 1.6.7+git~20160401T134007Z~f0c3870be3~64bit) it doesn’t. The SDP offered on the B leg does not include RFC 2833 even though the A leg offered it.
Is this a known bug? If so, is there a patch?
If not, I can provide more information (pastebin logs, etc) to help troubleshoot. Please let me know what would be most useful to see. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Sincerely Jay
Dave, Looks like this was fixed in FS-9049 so DTMF should work properly in master and/or when 1.6.8 is released. regards, David On 15 April 2016 at 13:53, Sergey Safarov <s.safarov@gmail.com> wrote:
Could you please find commit where is bug has been introduced using "git bisect" commands.
On Fri, Apr 15, 2016, 06:41 Dave Horton <daveh@beachdognet.com> wrote:
I’m running into a problem on v1.6.7 with something that seemed to work properly on v1.6.6, and I am wondering if this is a known bug.
I have an application that receives an incoming call and bridges it to an outbound destination. Where there is RFC 2833 offered on the A leg for dtmf I want that to offer that on the B leg as well. I have defined late-negotiation=true on my sip profile.
In v1.6.6 (specifically, User agent header identifies as 1.6.6+git~20160111T201612Z~d2d0b3283a~64bit) this worked as expected.
In v1.6.7 (specifically, User agent header identifies as 1.6.7+git~20160401T134007Z~f0c3870be3~64bit) it doesn’t. The SDP offered on the B leg does not include RFC 2833 even though the A leg offered it.
Is this a known bug? If so, is there a patch?
If not, I can provide more information (pastebin logs, etc) to help troubleshoot. Please let me know what would be most useful to see. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- David Witham Senior Voice/Systems Engineer Netsip pty ltd – An Over the Wire Company Level 1, 24 Little Edward St, Spring Hill QLD 4000 t +61 1300 638 747 e david.witham@netsip.com.au www.netsip.com.au <https://macowa.netsip.com.au/owa/redir.aspx?C=95eec4d12cf0400796940d56513ed0f7&URL=http%3a%2f%2fwww.netsip.com.au> <https://macowa.netsip.com.au/owa/redir.aspx?C=95eec4d12cf0400796940d56513ed0f7&URL=http%3a%2f%2fwww.netsip.com.au>
participants (4)
-
Dave Horton
-
David Witham
-
jay binks
-
Sergey Safarov