Subject: [Sip] comments on draft-ietf-sip-refer-02.txt

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 4 Apr 2002 09:17:02 -0500

The draft talks about the use of REFER outside a dialog:

"A REFER request MAY be placed outside the scope of a dialog created with an INVITE."

"A UA accepting a well-formed REFER request SHOULD request approval from the user to proceed"

I am not sure what kind of approval are we talking about here ?
If a REFER comes from a proxy to a SIP phone or a gateway (with multiple lines on it), what are we supposed to do ? Surely not ring the phone ?

---

From: Robert Sparks <[email-masked]>
Date: 04 Apr 2002 09:10:14 -0600

> I am not sure what kind of approval are we talking about here ?
Whatever is appropriate for the device and application - it may
be a direct prompt of the user, it may be a matter of using policy
that the user has placed in the device. 
> If a REFER comes from a proxy to a SIP phone or a gateway (with multiple
> lines on it), what are we supposed to do ? Surely not ring the phone ?
Why not? I've heard of phone implementations that provide a special
alert and put a "X is requesting that you call Y, proceed?" type prompt
on the display. On a gateway, your interface is obviously more limited.
If you were ambitious, you could invoke media/ivr servers, alert the
black phone, play the prompt above to it and ask for what to do.Or you
could decide its not worth extending this kind of functionality to the
old phones. There's a lot of room for innovation in between.

RjS

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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 4 Apr 2002 10:54:00 -0500

I think by the IVR approach, you mean REFER in a
dialog context.

That kind of an approach seems to be much more
preferable, as it works for all endpoints unlike the one w/o
a dialog which tries to do similar things. The caller obviously
wont know that the destination is a smart phone or not.

Ironically, w/o dialog seems to be syntactically more general.
Maybe its use should be restricted somehow for interop
reasons or so ?

---

From: Robert Sparks <[email-masked]>
Date: 04 Apr 2002 10:08:24 -0600

> I think by the IVR approach, you mean REFER in a
No - I didn't.

> wont know that the destination is a smart phone or not.

A caller doesn't know if the destination will accept an INVITE
either. That's what the response part of the SIP transaction is for.
If you send an out-of-band refer to something that by policy or
reason of physical limitations can't deal with it, it will decline.

REFER is a primitive, not an application. We've been able to build
one application on top of REFER (transfer) without invoking Require:.
Some future application may need to know that the far end is going
to do something special with a REFER before it sends it - that 
application will use a Require: token.

> Maybe its use should be restricted somehow for interop
I've seen no reason to introduce any such restriction.

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 4 Apr 2002 18:59:30 -0500

I am not sure we are talking about the same thing, so let me describe
the scenario:

A and B are two endpoints not involved in any call. So A sends
a REFER to B. (Both A and B support the REFER).

Now going back to your reply, I dont understand how you can
alert B and play an ivr etc, without first setting up a dialog with it.

Also, I am confused how the "Require:" header fits into this
discussion.

----- Original Message -----
From: "Robert Sparks" <[email-masked]>
To: "Medhavi Bhatia" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 04, 2002 11:08 AM
Subject: Re: [Sip] comments on draft-ietf-sip-refer-02.txt

> > > > "A UA accepting a well-formed REFER request SHOULD request approval
from
> > > > the user to proceed"

---

From: Robert Sparks <[email-masked]>
Date: 04 Apr 2002 19:36:14 -0600

> alert B and play an ivr etc, without first setting up a dialog with it.
If you have a sip phone, you don't need to invoke an ivr - you don't
need a dialog. The implementations I describe provide a special alert
and a prompt.

To get to the IVR driving black phone example, you have to have
an application that fronts the pstn gateway - the pstn
gateway itself will likely reject out-of-band refers for lack
of a way to get user permission to do something reasonable. 
(likely only in a time-local sense - there are _vast_ opportunities
for innovation here). The server running that application will
terminate the REFER and enter into a series of INVITEs, establishing
the sessions you talk about, to build authorization, then possibly
entering into a 3pcc-like control mode with the gateway to deal with
the referred action.

> Also, I am confused how the "Require:" header fits into this
You suggested (abstractly) to limit out-of-band REFERs because
of potential interop problems. I counter that the first application
of REFER does not have those interop problems and that if interop 
problems are encountered in future applications, they can be addressed
through judicious application of Require:.

RjS