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

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

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,

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.

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.
-----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.

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.

_______________________________________________
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: "Steven Gardell" <[email-masked]>
Date: Sat, 28 Apr 2001 09:19:17 -0400

It is certainly a good idea to have a flexible architecture that
enables us to build "service deployment vehicles" in a
variety of different ways as described in
draft-rosenberg-sip-app-components, but I would
point out that there are many different possibilities for the
communication mechanisms between the logical "AS" and "MS"
components. As the aforementioned draft discussed, in some
cases such as a dedicated messaging platform, these
components might be merged (Scaling might be
accomplished by alternative mechanisms such as a call
distributing proxy server.) It really depends on the service.
What is optimal for voice mail may be sub-optimal for a much
less media-intensive service such as a calling card platform.

----- Original Message -----
From: Eric Burger <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 27, 2001 1:12 PM
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   +------+

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,

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.

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.

Robert.