Subject: Re: Detecting DTMF tones on a SIP voice session

From: "Gregory D. Girard" <[email-masked]>
Date: Fri, 29 Oct 1999 16:00:01 -0400

Jean-Hughes,
You have provided a much more clear explanation of the problem I have been
trying to solve.
I attempted to clarify this scenario in a few descriptions, however you said
it better than I did.
I believe that your point (and my point) argues strongly for incorporating
DTMF information into SIP
for all connection modes, including a third-party mode where the participant
does not reside at
either endpoint. Using the RTP stream, even if it contains simple DTMF digit
information in binary form,
is still going to send it to the wrong place in certain circumstances.

Regards,

Greg Girard
CTO
Iperia, Inc.

-----Original Message-----
From: Jean-Hugues ROBERT <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, October 29, 1999 12:25 PM
Subject: Re: Detecting DTMF tones on a SIP voice session

>Hi,
>
>I believe there is a confusion about third party control
>& DTMF.
>
>1) Third party control
>
>This is about the remote 'control & observation' of a SIP
>call, by a third entity, neither the caller nor the callee.
>
>Example of third party control (Distributed IVR):
>
> Customer make a Call to Company (INVITE)
> Company SIP Server redirect call to IVR Application (BYE(Also))
> IVR Application redirect Call to Announcement Server (3rparty-INVITE)
> Announcement Server Play 'Greeding + please enter you ID'
> IVR Application receives entered ID (one digit at a time or as a block,
INFO)
> IVR Application transfers Call to proper destination (3rparty-BYE(Also))
>
>As you can see the RTP stream never terminates at the IVR Application.
>It terminates at the Announcement Server.
>However the 'control' is done by the IVR Application, the Announcement
Server
>is merely a media resource under the control of the IVR Application.
>
>This is a mean to achieve control / media separation, where the media is
>handled by a media entity distinct from the control entity.
>
>This separation of concern / untighting between media & control is one of
the
>advantages of third party control. One can argue that this is already done
>in SIP with SDP. However the DTMF issue is not clearly solved.
>
>This achievement was reached in the MGC/MG solution using MGCP (now
MEGACO),
>as pointed out earlier. Lucent Softswitch (& others) can already get
>DTMF without terminating the media.
>
>Something similar in the SIP world would be nice too.
>
>Please note that the media / control distinction is at the heart of the
>Intelligent
>Network architecture (SS7, more than ISUP).
>
>A simple solution to extend SIP for third party control would be to
>consider a SIP endpoint as an '3rd party relay'.
> On receipt of 3rd-INVITE the relay understand that it is in presence
> of a third party initiated call.
> It sends the INVITE as if initiated locally.
> And from now on it proceeds normally but:
> Every message it receives or sends from/to the remote entity
> is 'relayed' (copied, notified) to the 3rd party that initiated
> the call (Notified-Entity).
> That way the 3rd party can 'observe' the call.
> The 3rd party may also 'control' the call (BYE, re-INVITE...), by
> ways of 3rd-BYE...
> Nota: this could be implemented by adding an optionnal parameter
> "Notified-entity:3RD-PARTY-SIP-URL"
>
>Third party control is at the heart of CTI in the enterprise world.
>
>2) DTMF
>
>DTMF signal can be carried with RTP using to solutions:
> Blended with the media stream (G711 payload for example)
> On the media stream with a specific payload (dtmf or tone payload)
>
>Obviously the second solution helps detecting DTMF at the receiving
>entity. No DSP is needed to analyse the sound. The detection was
>either done in a PSTN-GW or the dtmf payload was directly sent by
>the remote entity.
>
>This is nice.
>
>But one can argue that both scheme are in fact 'in-band' signaling.
>'out of band' signaling would then mean that another entity, distinct
>from the one that receives the media, would receive the dtmf RTP payload.
>
>Unfortunately I do not believe there is a way for a SDP profile to
>specify how to achieve that. Maybe we can get by using 2 SDPs, one
>for voice (G711 or whatever) and another for DTMF. If this can work
>then we can specify distinct entities, one in each SDP.
>
>The previous IVR example becomes:
>
> Customer make a Call to Company (INVITE)
> Company SIP Server Redirects Call to IVR Application.
> IVR Application act as a proxy and Forwards the Call to
> the Announcement Server, asking for DTMF notifications to
> be delivered to it (INVITE(sdp1,sdp2)).
> When IVR Application receives enough DTMF it transfers the
> initial Call to the proper destination (BYE(Also))
> And then breaks the Annoucement leg (BYE)
>
>In this case the Annoucement Server terminates the 'voice' part of
>the RTP Media Steam, and the IVR terminates the 'dtmf' part of the
>steam.
>
>Which solution is more SIP, third party control or dual SDPs ?
>Are there other ongoing work on that matter ?
>
>Thanks,
>
>Jean-Hugues Robert
>Engineering Manager
>
>
>
>--------------------------------------------------------------------
>[email-masked]                                        "Think globally.
>www.8x8.com                                            Act locally."
>