[Standards-JIG] RE: Jingle: DTMF

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Thu Feb 16 09:17:52 UTC 2006


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