VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
mayamatakeshi at gmail... Guest
|
Posted: Mon Feb 08, 2021 4:10 am Post subject: [Freeswitch-users] Prevent conversion from rfc2833 to SIP IN |
|
|
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
|
Posted: Mon Feb 08, 2021 7:52 pm Post subject: [Freeswitch-users] Prevent conversion from rfc2833 to SIP IN |
|
|
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 |
|
|
|
|
|
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
|