[Standards-JIG] RE: Jingle: DTMF

Simon Guindon simon.guindon at tomahawk.ca
Thu Feb 16 15:02:11 UTC 2006


Good morning Jean,

There is 2 real important cases I believe your missing here. Your
assuming the client end is always Jingle (RTP) and it can always do
RFC2833. The client end most definitely may not be a RTP protocol at
all. Jingle in my understanding is meant for media connections in
general.

Let's take into account:
--------    JINGLE     --------            -------  
|IAX   |---------------| GW   |            |      |
|      |---|           --------            | ASTE |
--------   |            IAX                | RISK |
PSTN/RTP/SIP/IAX/etc...
           |-------------------------------|      |---------
                                           --------   
(*Please keep in mind JINGLE above is simply signalling for negotiation
not audio)                    

I'm not sure if I've drawn this out properly but your client might be
(in future perhaps) Jingle IAX instead of Jingle Audio. You would send a
Jingle negotiation through XMPP to a gateway that might be a gateway to
asterisk. This gateway might tell you, you can connect to asterisk/peer
direct with IAX. So in this scenario we have no RTP and no Jingle Audio.
IAX has built in DTMF, there is no reason here why we should use
RFC2833.

The 2nd possibility I can think of is:
Let's take into account:
--------    JINGLE     --------            -------  
|IAX   |---------------| GW   |            |      |
|      |---|           |      |            | ASTE |
--------   |           |      |            | RISK |
PSTN/RTP/SIP/IAX/etc...
           |-----------|      |------------|      |---------
               IAX     --------    SIP     --------   
(*Please keep in mind JINGLE above is simply signalling for negotiation
not audio) 

Similar case but the Gateway/Asterisk has perhaps told us to call
through the gateway because theres no direct route/compatible format.

Here's basically my case. When *possible* the protocol uses its native
DTMF (which I assume will be 99% of the case) because A. you are either
connecting to the same protocol on the other end, or B. you are being
gatewayed (translated) anyways so the gateway can make the translation
of DTMF.

Where jabber:x:data comes into play is for enhanced feature set.

The only problem I see here is, since I am told SIP has multiple methods
for DTMF it may be a good option to solidify what we choose for this or
else you end up with perhaps what Matt is saying where your now forcing
clients/gateways to support both because you never know what to expect.
Perhaps this is where RFC2833 comes into play?

Thanks and take care,
Simon

-------------------------------------------------------
Simon Guindon
Tomahawk Technologies Inc.
simon.guindon at tomahawk.ca
www.tomahawk.ca
-------------------------------------------------------

-----Original Message-----
From: standards-jig-bounces at jabber.org
[mailto:standards-jig-bounces at jabber.org] On Behalf Of Jean-Louis
Seguineau
Sent: Thursday, February 16, 2006 4:18 AM
To: standards-jig at jabber.org
Subject: [Standards-JIG] RE: Jingle: DTMF 

Just to make sure we are on the same page, let me just illustrate the
different uses cases. If you feel there are others, please do not
hesitate to add to the use cases.

1/ P2P use case: we use existing standards

--------    RFC2833    --------
|Jingle|---------------|Jingle|
--------     RTP       --------


2/ SIP/PSTN GW

--------    JINGLE     --------    SIP     --------  
|Jingle|---------------| GW   |------------| PSTN |
|      |---|           --------            |      |      -----
--------   |            RFC2833            |      | -----|IVR|
           |-------------------------------| PSTN |      -----
                          RTP              --------  

In this use case, we are connected to a legacy system which only
understands DTMF. The system needs a GW for converting the signaling
between Jingle and the signaling understood by the PSTN GW. SIP is used
in this example as this is the most likely setup.
The GW only needs to convert the signaling part, and ensure that the
Jingle client and PSTN GW establish their media stream with each other.
For the Jingle client, the remote party will in fact be 'proxied' by the
PSTN GW, not the Jingle/SIP GW.
Once again, we use existing standard protocol for DTMF. Most PSTN GW
provide this support.

3/ SIP GW

--------    JINGLE     --------    SIP     --------  PSTN
|Jingle|---------------| GW   |------------|      |---------
|      |---|           --------            | IPBX |
--------   |            RFC2833            |      |  RTP
           |-------------------------------|      |---------
                          RTP              --------  

In this use case, we are connected to an IPBX which understands RFC2833
(a vast majority). The system needs a GW for converting the signaling
between Jingle and the SIP signaling understood by the IPBX. 

The GW only needs to convert the signaling part, and ensure that the
Jingle client and IPBX establish their media stream with each other. For
the Jingle client, the remote party is the IPBX, not the Jingle/SIP GW.
Once again, we use existing standard protocol for DTMF. Most IPBX
provide this support.

4/ IAX GW

--------    JINGLE     --------    IAX     --------  PSTN
|Jingle|---------------| GW   |------------|      |---------
|      |---|           --------            | ASTE |
--------   |            RFC2833            | RISK |  RTP
           |-------------------------------|      |---------
                          RTP              --------  

In this use case, we are connected to an Asterisk IPBX which understands
DTMF. The system needs a GW for converting the signaling between Jingle
and the IAX signaling understood by the IPBX.  
The GW only needs to convert the signaling part, and ensure that the
Jingle client and IPBX establish their media stream with each other. For
the Jingle client, the remote party is the IPBX, not the Jingle/IAX GW.
Once again, we use existing standard protocol for DTMF.

4/ CSTA GW

--------    JINGLE     --------    CSTA    -----------
|Jingle|---------------| GW   |------------|Controler|
|      |---|           --------            -----------
--------   |            RFC2833            --------------
           |-------------------------------|Media Bridge|
                          RTP              --------------  

In this use case, we are connected to some voice media conference bridge
which understands DTMF. The system needs a GW for converting the
signaling between Jingle and the CSTA signaling understood by the media
controler.  
The GW only needs to convert the signaling part, and ensure that the
Jingle client and IPBX establish their media stream with each other. For
the Jingle client, the remote party is the media bridge, not the
Jingle/CSTA GW.
Once again, we use existing standard protocol for DTMF.


Note how in every case, the media stream does not go through the GWs,
which is actually the way it is done in the SIP world. SIP or Jingle in
our case is only here to establish the session when dealing with legacy
DTMF.

When the remote party provides separate path for media and signaling,
such as described above, then we only need to map the Jingle signaling
part to the remote party signaling part. Once a media stream is
established, then we are back to RFC2833 support. And there is no need
to advertise it, we just need to mandate it.

Hope it helps

Jean-Louis




More information about the Standards mailing list