Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community
 SearchSearch 

[Freeswitch-users] Prevent conversion from rfc2833 to SIP INFO


 
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users
View previous topic :: View next topic  
Author Message
mayamatakeshi at gmail...
Guest





PostPosted: Mon Feb 08, 2021 4:10 am    Post subject: [Freeswitch-users] Prevent conversion from rfc2833 to SIP IN Reply with quote

Hi,

I have a gateway inviting FS with an SDP without payload telephone-event (rfc2833).
This channelA is bridged to another channelB that does support rfc2833.
I noticed that in this case FS converts the rfc28333 digit from channelB to SIP INFO to channelA.
The gateway doesn't support SIP INFO, but does support rfc2833 even if it doesn't advertise it (at least it does support it for outgoing calls from what was reported to me).
I tried to use this before the bridge:
       <action application="set" data="pass_rfc2833=true"/>
but behavior didn't change.
Is there anything else I can try?
Back to top
mayamatakeshi at gmail...
Guest





PostPosted: Mon Feb 08, 2021 7:52 pm    Post subject: [Freeswitch-users] Prevent conversion from rfc2833 to SIP IN Reply with quote

On Mon, Feb 8, 2021 at 5:50 PM mayamatakeshi <mayamatakeshi@gmail.com (mayamatakeshi@gmail.com)> wrote:

Quote:
Hi,

I have a gateway inviting FS with an SDP without payload telephone-event (rfc2833).
This channelA is bridged to another channelB that does support rfc2833.
I noticed that in this case FS converts the rfc28333 digit from channelB to SIP INFO to channelA.
The gateway doesn't support SIP INFO, but does support rfc2833 even if it doesn't advertise it (at least it does support it for outgoing calls from what was reported to me).
I tried to use this before the bridge:
       <action application="set" data="pass_rfc2833=true"/>
but behavior didn't change.
Is there anything else I can try?





Thinking again, since the telephone-event was not negotiated at channelA side, of course FS cannot relay the RFC2833 packet.
So I am thinking in detect rfc2833 digits at channelB and send them as inband tones at channelA using:
  send_dtmf <dtmf digits>[@<tone_duration>]
But I'm worried with the possibility of overlapping tones at channelA.
Does anyone know if send_dtmf has queueing behavior, meaning if I call it multiple times in rapid succession, one operation will not interrupt the previous one?
 
Back to top
Display posts from previous:   
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group

VoiceMeUp - Corporate & Wholesale VoIP Services