Subject: [Sipping] Re: 3pcc, click-to-dial, ringing

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 02 Nov 2002 14:36:21 -0500

Eric,

This note is timely.

The new app interaction framework, due out from the i-d editor any day 
now, addresses this problem. In case you want, you can check it out now at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-app-interaction-framework-00.txt

Anyway, there are two solutions based on that framework:

1. instantiate a remote user interface, play media out that way. Thats 
what you can do with 3pcc today.

2. instantiate a local user interface. To do that, we need a markup that 
can tell a client to play out tones of sorts. Clearly, voicexml can do 
that, but its overkill. THe snowshore mscml is probably closer. It would 
tell the client to fetch a media file and play it.

-Jonathan R.

Eric Cheung wrote:
> Hi Jonathan
> 
> Regarding the issue in 3pcc I-D call flows, where participant A does not
> know when caller B is being alerted.  From your posting on May 16:
> 
> 
>>Anyway, with that out of the way, of course an alerting tone can be
>>provided to A. It is documented in Figure 7. If party B provides any
>>kind of early media, whether its ringtone or announcements or whatever,
>>they will be heard by A.
>>
>>Now, the more complicated case is when B doesn't provide inband ringing.
>>If, instead, it generates a 180 without SDP, or provides a other
>>provisional response with an Alert-Info header. This is something that
>>doesn't exist in circuit switched networks, and is unique to VoIP.
>>Today, the best you can do is have the controller connect user A to a
>>media server to play it an in-band ringing, which is far from desirable.
>>We need some kind of standards-based way for the controller to tell one
>>of the participants to generate some kind of media locally after it has
>>answered the call. We have no standards for that today. One can always
>>just invent some kind of header or something, but I think it is worth
>>considering the problem more broadly. Sounds like a requirements
>>document for enhanced 3pcc is in order...
>>
> 
> 
> I wonder if you have had more thoughts on this?  I did not see anything
> in the 3pcc-02 I-D that came out since.
> 
> IMHO, while the inband ringback tone provides some degree of backward
> compatibility, it is not a good solution going forward.  For example,
> what if a feature want to act on the condition equivalent to 180
> RINGING.
> 
> Thanks
> Eric
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Steve Fisher" <[email-masked]>
Date: Sat, 2 Nov 2002 23:15:01 -0500

Jonathan,

Thanks for posting the app interaction framework document. I personally
think this is very exciting work. I do have a couple of questions, one
about the example in section 7.2.2 and the second about the model
described in section 7.2.2.1.

There are two aspects of the example in section 7.2.2 that puzzled me:

1) Wouldn't the Prepaid Card Application want to avoid the RTP in step
#11, and couldn't this be done by sending the INVITE in step #14 (but
including the SDP for the Recorder App) before sending the ACK in step
#10 (which would then include the SDP for the Caller)?

2) In previous examples, the Recorder App didn't start recording until
either the caller or the callee requested recording. If that's also the
case in this example, then why would the media go through the Recording
App initially? Wouldn't the Recording App send a KPML document to both
the caller and the callee, looking for the "start" command (such as
"##0")? In this case, the callee would have two KPML documents, one
looking for long pound, and the other looking for "##0", and media would
only flow from caller to callee, unless and until the caller pressed
long pound or "##0", or the callee pressed "##0".

Am I missing something, or wouldn't such an example show that (a) media
only needs to flow to a B2BUA when that B2BUA needs to interact with
another UA, and (b) multiple applications can apply markup on the same
dialog?

Also, I think the model in Section 7.2.2.1 is very interesting, and
would seem to have the potential to address the "Transfer Connect"
example that Eric Cheung and I discussed a few weeks ago, in which once
the "Transfer Connect" application has focus (e.g. the caller presses
"*T"), then subsequent tones are suppressed from the media stream, so
that the Transfer Connect app can determine which phone number to
transfer the caller to without the other participants on the call
hearing the tones that represent this number. 

I assume that this would work as follows: the Transfer Connect
application (acting as a UA, not a B2BUA) would establish a dialog with
the caller (acting as a focus), and would send the caller's UA a KPML
document specifying "*T" as a trigger. Then, when the user presses "*T",
the caller's UA would signal the Transfer Connect app via HTTP, and the
Transfer Connect app would request that the caller's media policy server
stop sending media to other UAs and start sending media to the Transfer
Connect app (one question -- would this be fast enough to avoid the
Transfer Connect app missing some of the tones that the caller sent
following the "*T"?). Then, once the Transfer Connect app has received
the phone number from the caller, it would both transfer the caller to
the specified UA, as well as request that the media policy server
restore the previous state of the media streams. Do I understand the
model correctly? 

I'm also not clear exactly how to transfer the caller to a new UA (the
goal of the Transfer Connect app). In the Pipe-and-Filter model, the
Transfer Connect app (acting as a B2BUA) would (I think) send an INVITE
to the UA for the new device, a re-INVITE (with the SDP for the new
device) to the callee's UA, and a BYE to the caller's current UA. In the
client model described in 7.2.2.1 I'm not clear if the Transfer Connect
app still has the necessary signalling relationship with the callee to
effect the transfer. 

Thanks!
Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jonathan Rosenberg
Sent: Saturday, November 02, 2002 2:36 PM
To: Eric Cheung
Cc: [email-masked]
Subject: [Sipping] Re: 3pcc, click-to-dial, ringing

Eric,

This note is timely.

The new app interaction framework, due out from the i-d editor any day 
now, addresses this problem. In case you want, you can check it out now
at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-app-interaction-fr
amework-00.txt

-Jonathan R.

Eric Cheung wrote:
> Hi Jonathan
> 
> Regarding the issue in 3pcc I-D call flows, where participant A does 
> not know when caller B is being alerted.  From your posting on May 16:
> 
> 
>>kind of early media, whether its ringtone or announcements or 
>>whatever, they will be heard by A.
>>
>>Now, the more complicated case is when B doesn't provide inband 
>>ringing. If, instead, it generates a 180 without SDP, or provides a 
>>other provisional response with an Alert-Info header. This is 
>>something that doesn't exist in circuit switched networks, and is 
>>unique to VoIP. Today, the best you can do is have the controller 
>>connect user A to a media server to play it an in-band ringing, which 
>>is far from desirable. We need some kind of standards-based way for 
>>the controller to tell one of the participants to generate some kind 
>>of media locally after it has answered the call. We have no standards 
>>for that today. One can always just invent some kind of header or 
>>something, but I think it is worth considering the problem more 
>>broadly. Sounds like a requirements document for enhanced 3pcc is in 
>>order...
>>
> 
> 
> I wonder if you have had more thoughts on this?  I did not see 
> anything in the 3pcc-02 I-D that came out since.
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP