[recon-devel] relaying DTMF

[Daniel Pocock]

I've been looking at how recon handles DTMF and whether it can relay
DTMF from one participant to another

Without any explicit coding by the application developer, it appears
that recon swallows any out-of-band DTMF sent by a participant and does
not relay it to any other participant

The simplest solution is to modify MyConversationManager::onDtmfEvent(),
adding a call to createMediaResourceParticipant()

However, this also echoes the tone back to the participant who sent the tone

I suspect that calling modifyParticipantContribution() probably won't
help because the RFC 2833 tones would still be sent anyway

Looking at the interface to sipXtapi, it looks like sipXtapi also
insists on sending the tones to all channels in a flow graph (e.g. the
CpMediaInterface::startTone() method)

Scott, could you make any suggestions about how this could be
implemented or have I missed something in this analysis? My familiarity
with the sipX code is much less than with reSIProcate.

I thought it would be useful to have a new MediaParticipant URI
parameter (like the "remote-only" parameter) that would allow the tone
to exclude or include a specific participant, e.g.

tone:0;duration=200;exclude-participant=2

[Scott Godin]

...inline...

Post by Daniel Pocock
I've been looking at how recon handles DTMF and whether it can relay
DTMF from one participant to another
Without any explicit coding by the application developer, it appears
that recon swallows any out-of-band DTMF sent by a participant and does
not relay it to any other participant

[Scott] This is the behaviour I would expect. recon was designed to be
used a conference server as well as a UA. It would be undesirable to have
DTMF control tones propagated to all callers in a conference.

Post by Daniel Pocock
The simplest solution is to modify MyConversationManager::onDtmfEvent(),
adding a call to createMediaResourceParticipant()
However, this also echoes the tone back to the participant who sent the tone
I suspect that calling modifyParticipantContribution() probably won't
help because the RFC 2833 tones would still be sent anyway
Looking at the interface to sipXtapi, it looks like sipXtapi also
insists on sending the tones to all channels in a flow graph (e.g. the
CpMediaInterface::startTone() method)
Scott, could you make any suggestions about how this could be
implemented or have I missed something in this analysis? My familiarity
with the sipX code is much less than with reSIProcate.

[Scott] Sorry I don't have much for you. Your analysis seems correct to
me. If sipXtapi had an interface to generate RFC2833 to a single endpoint
then we could take advantage of that - but I'm not very familiar with
sipXtapi's handling of DTMF. You could try the sipXtapi mailing list for
help.

Post by Daniel Pocock
I thought it would be useful to have a new MediaParticipant URI
parameter (like the "remote-only" parameter) that would allow the tone
to exclude or include a specific participant, e.g.
tone:0;duration=200;exclude-participant=2
_______________________________________________
recon-devel mailing list
List Archive: http://list.resiprocate.org/archive/recon-devel/

[Daniel Pocock]

Post by Scott Godin
...inline...
I've been looking at how recon handles DTMF and whether it can relay
DTMF from one participant to another
Without any explicit coding by the application developer, it appears
that recon swallows any out-of-band DTMF sent by a participant and does
not relay it to any other participant
[Scott] This is the behaviour I would expect. recon was designed to
be used a conference server as well as a UA. It would be undesirable
to have DTMF control tones propagated to all callers in a conference.

Agreed - that is quite understandable and I didn't expect to see
anything actively using the tones in testUA for example

Post by Scott Godin
The simplest solution is to modify
MyConversationManager::onDtmfEvent(),
adding a call to createMediaResourceParticipant()
However, this also echoes the tone back to the participant who sent the tone
I suspect that calling modifyParticipantContribution() probably won't
help because the RFC 2833 tones would still be sent anyway
Looking at the interface to sipXtapi, it looks like sipXtapi also
insists on sending the tones to all channels in a flow graph (e.g. the
CpMediaInterface::startTone() method)
Scott, could you make any suggestions about how this could be
implemented or have I missed something in this analysis? My familiarity
with the sipX code is much less than with reSIProcate.
[Scott] Sorry I don't have much for you. Your analysis seems correct
to me. If sipXtapi had an interface to generate RFC2833 to a single
endpoint then we could take advantage of that - but I'm not very
familiar with sipXtapi's handling of DTMF. You could try the sipXtapi
mailing list for help.

I found that sipXtapi does actually have a method startChannelTone() for
sending the tone to a single channel

There is a bug in it however: it sends the RFC2833 tone to the specified
channel but it sends the inband audio to the entire flowgraph. I found
that the person sending the tone would hear their local feedback tone, a
split second pause and then some of the inband tone from sipXtapi and
the user would think they had double-pressed the button.

I've added a new method into the sipXtapi API that has two booleans, one
for enabling inband and the other to enable rfc2833 tones. The latest
code I've committed in recon uses the startChannelTone() method and it
uses the new arguments to disable the inband tone completely and only
enable rfc2833.

Post by Scott Godin
I thought it would be useful to have a new MediaParticipant URI
parameter (like the "remote-only" parameter) that would allow the tone
to exclude or include a specific participant, e.g.
tone:0;duration=200;exclude-participant=2

I've done this the other way around, a tone can be targetted at a
selected participant with a URI like this:

tone:0;duration=200;participant-only=3