Subject: [SIP] ID extension of REFER

From: Rohan Mahy <[email-masked]>
Date: Thu, 16 Nov 2000 15:21:48 -0800

Hi,

I just submitted an ID for an extension to the REFER method that I discussed
with Robert Sparks at Pittsburgh.  Until it appears in the archive it is
available at:

        ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-189-00.txt

        A SIP Extension: Informational Responses to the REFER method

                Abstract  
This document defines a SIP extension to the REFER method of the SIP Call
Control Framework.  This extension provides for the ability to convey
information about the progress of the Referred request when that request is in
a provisional state for a long period of time (many seconds or minutes).

Comments welcome.

thanks,
-rohan

---

From: Sean Olson <[email-masked]>
Date: Fri, 17 Nov 2000 11:02:34 +0100

Hello,

I am a little confused about the purpose of this I-D. The first question
that springs to mind is
why you don't use "183" for this purpose? The second question is whether
you
intend the 189 to lead to different timing than any other provisional
response?
(In other words, if the 189 does NOT cause different timing, than the
issue of a long
  period (> 37 seconds) between the INVITE and 200 OK is not really
solved. I realize
  this should be a very rare case.)

/sean

Rohan Mahy wrote:

>  Hi,
>
> I just submitted an ID for an extension to the REFER method that I
> discussed with Robert Sparks at Pittsburgh.  Until it appears in the
> archive it is available at:
>
>      This document defines a SIP extension to the REFER method of the
>      SIP Call Control Framework.  This extension provides for the
>      ability to convey information about the progress of the Referred
>      request when that request is in a provisional state for a long
>      period of time (many seconds or minutes).
>
>
> Comments welcome.
>
> thanks,
> -rohan
>
>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 17 Nov 2000 10:28:23 -0800

At 02:02 AM 11/17/00 , Sean Olson wrote:
>why you don't use "183" for this purpose? 

the semantics of 183 already means something different, and i did not think
I could overload those semantics cleanly.

>The second question is whether you

A sends REFER to B
B sends INVITE to C

A would get 189s any time B got provisionals from C.  

If C just 200 OKs  B's INVITE, no 189s are sent.
If C sends 180 or 183 and answers right away, A still gets a 189.  If you
don't need the information you can ignore it.

thanks,
-rohan

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Sun, 19 Nov 2000 09:24:44 +0530

Wouldn't simply forwarding the provisionals received allow the initiator of
REFER know more about 'call progress' instead of translating them to a
single 189 ? Are there any specific reasons against not doing so? Please
elaborate.

Venkatesh

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 20 Nov 2000 09:38:33 -0800

I am open to this option.  Realize however, that REFER summarizes final
responses so summarizing provisionals is consistent with behavior that
exists today; and that simply forwarding other provisionals overloads their
semantics.

thanks,
-rohan

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Tue, 21 Nov 2000 10:32:28 +0530

The main reason as to why I am for forwarding provisional responses is as
follows:

This allows the "Transferror" to decide when he/she wants to hang up, very
useful for certain applications, as I have mentioned in one of my previous
posts, which I repeat here for completeness...

Most transfers occur through a voice messaging system/IVR. Many of them
support a couple of nice features where in on a transfer request, they want
to know if the far end is busy, or if the far end is following a coverage
path(on no answer),  in which case they would want to abandon the transfer
request, and then voice a message saying, "The transferred extension is
busy/not available... To leave a message for <original_called_party> please
do so at the tone, to request another transfer press..." and so on.

On the other hand, there are other simpler applications would just want to
complete the transfer when they find the destination "ringing" and let the
caller follow the coverage path of the TT in case of no answer(this is just
to make sure that if the user mis-dialed and the voice messaging system did
a blind transfer, the user will not be stuck listening to an overflow tone
or would have to redial the entire number to reach another user).

I saw lack of ability to cleanly support such applications with the original
REFER based transfer solution. Your draft addresses this partly by sending a
provisional response of some sort, and builds an excellent mechanism for
supporting blind transfers(by dropping the necessity for the transferring UA
to wait until a final response for REFER is received), but I think allowing
provisional 1xx responses back to the transferring party would help
continuing support for such existing applications.

BTW, I thought  the only consolidation that REFER provided as regards final
response is that it consolidates a 3xx class response alone (Please correct
me if I am wrong, but as far as I know, any 400-600 class responses MAY be
issued in response to a REFER request. I don't know the rationale as to why
only 1xx and 3xx level responses were masked).

Venkatesh

----- Original Message -----
From: "Rohan Mahy" <[email-masked]>
To: "Venkatesh Venkataramanan" <[email-masked]>; "Sean
Olson" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 20, 2000 11:08 PM
Subject: Re: [SIP] ID extension of REFER