Subject: [SIP] Join as replacement for DTMF/voice-forking.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 25 Apr 2001 06:17:42 -0700

If at first you don't succeed .....

Hi,

I still didn't receive any comment back on using Join as a replacement to
beleaguered SDP based DTMF-forking. I am not sure if this is because 
a)	people don't see the problems with the existing DTMF forking scheme
(that has not been standardized anywhere), or
b)	people see problems with using join to provide this service in a
highly flexible and generic manner that is easy to implement, extend and
handles cases where there are multiple media streams <grin>, or
c)	people don't understand what I am proposing.

What is the status of the Join: header work ? Who is handling it?

This approach in my mind seems so much cleaner (and in the spirit of SIP)
than the current SDP based-approach. 

The concept is simple. A second is INVITE is sent from the joiner to the
joinee (where the joinee already has an established SIP session). Rather
than a Replaces header, the INVITE has a Join header. Other than that it is
almost identical to the current Replaces process. The only addition required
is perhaps a header parameter that specifies whether the Join is for full or
only local media mixing at the Joinee. In local mixing only the media from
the joinee is sent to the joiner and the joiner's media is only mixed with
the joinee rather than full conference-bridge style mixing. A possible
extension may also allow the joiner to be NOTIFIED when it is the last
INVITE present in the session.

This is of course compatible with the REFER draft which even further extends
what can be achieved with this simple addition. 

The SDP handling is easy as the Joiner can simply put no SDP in the INVITE,
the Joinee will then return the current session SDP in the 200OK. It is then
a simple matter for the joiner  to select what media streams are to be
"forked" in the ACK. No complicated "SDP" guessing games and SDP
manipulation by proxies (as for current forked-DTMF suggestions). It simply
supports multiple media streams and the addition or deletion of media
streams.

Additionally, it is easy to determine if a UA supports the Join header and
an application server can alternatively Require it in the initial INVITE.
Lastly, a join fails it does not jeopardize the existing sessions (as it
would in the existing forked DTMF proposal). This is especially important if
there are more than one application servers that are requesting to be
Join'ed.

I'd like to hear other peoples thoughts on this approach to problem that
really needs to be solve properly. At the last bakeoff there were many
companies wanting to use/deploy these important features. Where there is a
need without a specification then people often go off and implement their
own solutions (such as forking media streams through heuristical
interpretation of adding new SDP media streams).

Regards,

Robert.

---

From: Steve Gardell <[email-masked]>
Date: Thu, 26 Apr 2001 08:05:25 -0400

The additional discussion really helps for those of us who don't
have the several hours a day it takes to really keep up on the SIP list!
 
At any rate, one concern - probably with both models - is that we can't
make the assumption that all gateways are willing to "invest" in the
additional DSP to support mixing or, for that matter, mid-call DTMF
recognition.
In that case one could imagine implementing a B2BUA (with associated 
media processing) that can do this "in the network" with join as suggested 
or simply implementing the service in it's entirety at a B2BUA. Which of
these
3 variants is most cost effective might well be service-provider dependent.
 
I agree that control over "full or local" mixing is important to support a 
calling card service.

 -----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Wednesday, April 25, 2001 9:18 AM
To: [email-masked]'
Subject: [SIP] Join as replacement for DTMF/voice-forking.

Hi, 

a.	people don't see the problems with the existing DTMF forking scheme
(that has not been standardized anywhere), or 

b.	people see problems with using join to provide this service in a
highly flexible and generic manner that is easy to implement, extend and
handles cases where there are multiple media streams <grin>, or 

c.	people don't understand what I am proposing. 

Regards, 

Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 26 Apr 2001 07:38:10 -0700

Hi Steve,
 
Thanks for your comment.
 
Pretty much everything can be done as a B2BUA and I agree with you: until
UA's with REFER &  Replaces capability are widely deployed, then B2BUA is
pretty much the only way to accomplish many of the "advanced call control"
features in an hetrogenous/non-controlled SIP network (IMO). However,
unfortuately a B2BUA does not help in the scenario described in this thread.

A B2BUA cannot inherently cause a _normal_ UA to fork or mix the media. The
Application (or some related RTP processing/splitting/forwarding entity)
could process the media for every call for the entire duration of the call
[for common usage scenario]. However, I don't beleive this is generally a
scalable solution. I don't think you are denying that the features being
discussed are not very important to people wishing to provide calling-card
style services (non-disruptive in-call warnigns and announcements, media
triggered events such as triple # for call follow-on/return, etc).
 
For "Join" to work, one of the endpoints must support the Join header - just
like REFER you cannot guarantee every UA will implement this. This is the
same for the existing SDP-based stream forking behavior. I don't see that
this is a problem specific to this suggestion but rather a general problem
for adding extensions - not everyone is going to implement every extension.
This is not a reason to stop publishing extensions (which I'm sure you are
not debating). 
 
However, that does bring up a good advantage to this Join approach. IMO, it
is seems much easier for many PSTN-gateway based calling card services to
control the features supported by just _one_ of the UA's involved in a call
(usually the gateway). However, it may not always be the caller, for
instance, in a "PC to Phone" application where the client is located on a
"plain-vanilla" SIP client on the internet. In this case it might be usefull
to allow the Join header to be sent to the callee (the gateway) and specify
that the Join is only towards the remote party. (So the Join header options
become "local", "remote", or "full" mixing). This facility is not possible
with the current SDP-based stream forking approach.
 
To me this seems such a flexible, easy and clean way of achieving this
functionality.
 
Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 27 Apr 2001 07:46:53 -0700

Hi again,
 
The Join approach could provide a good reason to stick with the SDP vocoder
set behaviour decided at the last IETF meeting rather than what was being
bandied about on the list.
 
If you want to do DTMF monitoring and non-disruptive voice announcements
from an AS to a SIP session (eg calling card service as previously
discussed), then you will want to receive only the DTMF stream and send
voice. [An AS will not usually want to receive the voice traffic all the
time due to loading issues - I know people are talking about voice
recognition but this is normally when the caller is connected to AS not all
the time, right?] 
 
Now the voice and DTMF are normally syncronized in the same SDP m= line -
possibly causing problems. This is not a problem if each side only saying
what it is willing to recieve - NOT send and receive. That is, the UA would
put that it can recieve both voice and DTMF (as normal) and the AS would
indicate that it can only receive DTMF. 
 
However, thanks to the flexibility of the Join header <grin> it will work
even if we go with the send-and-receive SDP vocoder defintion. Instead you
would just send two INVITE's with Join headers: one specifying "a=recvonly"
listing the DTMF vocoder and the other specifying "a=sendonly" with the
voice coder.
 
Regards,
 
Robert.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 3:38 PM
To: 'Steve Gardell'; [email-masked]'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.

Hi Steve,
 
Thanks for your comment.

 

 
Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 27 Apr 2001 10:25:51 -0700

Hi Eric,

The problem is not when the caller (which may or may not be coming in
through a local gateway) is "talking" to the AS (through the media server).
The problems occur when the caller is talking to a third party. So voice +
DTMF RTP needs to go between the caller and third-party but the AS (through
media server or whatever) still needs to be able to a react to some
"triggers" (in my example, DTMF events) or play prompts to the Caller while
they are having a converstation with the third-party (eg, "You have one
minute remaining"). This is what I consider a "typical" pre-paid calling
card scenario. 

Robert.

-----Original Message-----
From:	Eric Burger [mailto:[email-masked]]
Sent:	Friday, April 27, 2001 6:12 PM
To:	[email-masked]
Subject:	RE:  [SIP] Join as replacement for DTMF/voice-forking.

Note that the media does not necessarily have to go to the AS.  In fact,
it's probably a bad idea for the reasons you list below.

A more scalable approach is to use a media server, and have the media server
report the DTMF events to the AS, either through http (as in
draft-rosenberg-sip-app-components), SIP INFO [no flames, please], or RFC
2833.

 +--------+   SIP   +------+
 |Caller/ |-------->|  AS  |
 |  GW    |         +------+
 +--------+          ^
         \          /
          \RTP     / SIP | SIP+http | SIP+RFC 2833
           \      /
            V    V
           +------+
           |  MS  |
           +------+

The media server does the media lifting for the application server, such as
playing prompts and collecting digits, while the application server does the
application heavy lifting, such as data base lookup, verification, etc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Fairlie-Cuninghame, Robert
Sent: Friday, April 27, 2001 10:46 AM
To: 'Steve Gardell'; [email-masked]'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.

Hi again,

Regards,

Robert.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 3:38 PM
To: 'Steve Gardell'; [email-masked]'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.

Hi Steve,

Thanks for your comment.

Robert.
-----Original Message-----
From: Steve Gardell [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 1:05 PM
To: 'Fairlie-Cuninghame, Robert'; [email-masked]'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Eric Burger <[email-masked]>
Date: Fri, 27 Apr 2001 17:35:00 GMT

If the calling user agent supports forking, then JOIN might work, but why not just have the application server INVITE into the call as a conference with an m= line for RFC 2833?  That doesn't require any changes to SIP.  It does require the UA/GW to support RFC 2833 "media", as well as supporting a micro conference consisting of the two voice parties and the RFC 2833, sendonly, application server party.  If the calling user agent supports forking, it may as well support it in the straight-forward way.

Likewise, the existing 3pcc proposals describe how to break-in and play prompts.  Looking at real implementations, you can put the called party on hold while you prompt the caller.  If you want "whisper-in-your-ear" to the caller, you'll probably either want to run the whole call through a media server or re-invite the entire call to the media server for the prompting sequence.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Friday, April 27, 2001 1:25 PM
To: 'Eric Burger'; [email-masked]
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.

Hi Eric, 
The problem is not when the caller (which may or may not be coming in through a local gateway) is "talking" to the AS (through the media server). The problems occur when the caller is talking to a third party. So voice + DTMF RTP needs to go between the caller and third-party but the AS (through media server or whatever) still needs to be able to a react to some "triggers" (in my example, DTMF events) or play prompts to the Caller while they are having a converstation with the third-party (eg, "You have one minute remaining"). This is what I consider a "typical" pre-paid calling card scenario. 
Robert.