Subject: Re: [Sipping] Call Waiting - who does the tone (round 2)

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jun 2003 17:32:40 -0400

In principle, by design, what you desire can't in general be provided 
without the cooperation of the endpoint.

(Suppose the phone is currently involved in a call where the media 
stream is secured end:end.)

For phones that are capable this ought to be implemented in the phone. 
If someone wants this service on a phone that isn't capable of providing 
it, then you probably need to put a B2BUA in front of the phone for all 
calls. That B2BUA can then assume the responsibilities that the phone is 
incapable of.

The same answer may apply to all mid-call features & tones.

	Paul

[email-masked] wrote:
> In a message dated 6/20/2003 1:24:06 PM Eastern Standard Time, 
> [email-masked] writes:
> 
> 
>> If you want
>> to offer a service which duplicates the current MLPP experience, then I
>> suggest that you do everything in the UA except for call forwarding
>> unavailable, which obviously you cannot do in the UA if it is not
>> there.
> 
> 
> 
> 
> The problem with that is similar to what I think started this discussion 
> on Call Waiting. For Assured Service (MLPP), the "network" needs to be 
> able to preempt a call at a UA and play a preemption tone to the human 
> involved in that call, but there is no quarantee that the particular UA 
> that person is using would understand what a "preemption tone" is or how 
> to generate it. It needs to come from someplace else, just like some 
> have suggested for the Call Waiting tone. I tossed this reference about 
> Assured Service into the discussion since it is one of many service 
> examples that need the same thing: a tone (or announcement) stuck into 
> an existing "connection".
> 
> After all the time spent on this, I would hope that you could point me 
> (and others) to a clear explanation in an existing document on how to do 
> it.
> 
> Mike Pierce

_______________________________________________
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: [email-masked]
Date: Fri, 20 Jun 2003 17:16:08 EDT

> unavailable, which obviously you cannot do in the UA if it is not 

The problem with that is similar to what I think started this discussion on 
Call Waiting. For Assured Service (MLPP), the "network" needs to be able to 
preempt a call at a UA and play a preemption tone to the human involved in that 
call, but there is no quarantee that the particular UA that person is using 
would understand what a "preemption tone" is or how to generate it. It needs to 
come from someplace else, just like some have suggested for the Call Waiting 
tone. I tossed this reference about Assured Service into the discussion since it 
is one of many service examples that need the same thing: a tone (or 
announcement) stuck into an existing "connection".

After all the time spent on this, I would hope that you could point me (and 
others) to a clear explanation in an existing document on how to do it.

Mike Pierce

---

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Jun 2003 19:08:43 -0400

There's a fairly simple answer to tone/announcement injection by the service 
provider, but it contradicts the e2e premise.  The service provider routes the media 
streams through a media proxy.  This also implies a B2BUA to manipulate the SDP. 
I'm just demonstrating feasibility, not expecting that the WG wants to spell out the 
call flows involved.

One example of a familiar scenario that might use this is a tone indication or 
announcement that the money prepaid for the call is running out and more must be 
provided.  Of course, that happens on payphones in the legacy network, and the SIP 
equivalent would probably handle call timing itself (with the help of the 
appropriate AAA protocol exchanges to tell it how to rate the call).

(Yeah, yeah, I know payphones are old-fashioned, but you still need public terminals 
of some sort for the minority of us who don't carry cell phones.)

Paul Kyzivat wrote:

>> The problem with that is similar to what I think started this 
>> discussion on Call Waiting. For Assured Service (MLPP), the "network" 
>> needs to be able to preempt a call at a UA and play a preemption tone 
>> to the human involved in that call, but there is no quarantee that the 
>> particular UA that person is using would understand what a "preemption 
>> tone" is or how to generate it. It needs to come from someplace else, 
>> just like some have suggested for the Call Waiting tone. I tossed this 
>> reference about Assured Service into the discussion since it is one of 
>> many service examples that need the same thing: a tone (or 
>> (and others) to a clear explanation in an existing document on how to 
>> do it.
>>
>> Mike Pierce
> 
> 
>

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 20 Jun 2003 18:12:28 -0700

Hi Mike,

On Friday, June 20, 2003, at 02:16 PM, [email-masked] wrote:

> to the human involved in that call,

as far as i've heard, there is no requirement that the "network" do 
this, merely that the system when taken as a whole allows authorized 
calls to preempt lower priority calls and play the appropriate tones 
during preemption.  perhaps I am missing a requirement, but I believe 
this is actually very easy to implement in the user agents.

> but there is no quarantee that the particular UA that person is using 
> would understand what a "preemption tone" is or how to generate it. It 
> needs to come from someplace else, just like some have suggested for 
> the Call Waiting tone. I tossed this reference about Assured Service 
> into the discussion since it is one of many service examples that need 
> the same thing: a tone (or announcement) stuck into an existing 
> "connection".
>

I wish I could point you at such a document.  If there is sufficient 
interest though we might get one either just before Monday or after 
Vienna.

thanks,
-rohan

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 23 Jun 2003 00:20:04 -0500

I'm thinking that the requirement that I'm hearing in this whole discussion
is essentially analogous to the operator service of "barge in." For those of
you unfamiliar with this service, it allows operators with special
privileges to intercept the media flow of an existing call and reconnect it
elsewhere.

Given that SIP nodes are what they are, it is in general impossible to
implement this sort of function without the cooperation of the endpoints
involved. To do otherwise would be a violation of the OPES principles, and
probably UNSAF as well.

The good news is that this doesn't have any impact on the protocol
specification. Such a service can be readily implemented with today's SIP.
It also isn't required in every SIP node -- just in nodes operating in the
sort of regulated environment that "phone people" envision. Or in call
centers, or similar operations.

There are many possible implementations. For example, the "public network
certified" terminal might be configured to automatically accept invitations
signed by a designated key, and preempt any other session in progress. The
trick, of course, is in the secrity aspects.

I don't know whether 3GPP has as-yet addressed this task, but it would be
worth asking people knowledgable about their current work.

Can we reframe this conversation from the perspective of requirements and
responsibilities?

Service providers (especially providers in regulated environments) may
require certain behaviors in network nodes receiving service from those
providers. 

Exactly what are these requirements, and who should specify them? Is that in
the scope of SIPPING? Is it in the scope of the device reuirements
individual draft that is under discussion? Do we need to do a formal
existence proof or discussion document? Or should it be left to
organizations that actually have the regulations to deal with?

--
Dean