Re: [Sip] draft-ietf-sip-cc-transfer-05

Sarvi Shanmugham <sarvi@cisco.com> Fri, 05 October 2001 05:25 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02629 for <sip-archive@odin.ietf.org>; Fri, 5 Oct 2001 01:25:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15869; Fri, 5 Oct 2001 00:27:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15838 for <sip@ns.ietf.org>; Fri, 5 Oct 2001 00:27:37 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01131 for <sip@ietf.org>; Fri, 5 Oct 2001 00:27:35 -0400 (EDT)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f954OvC27519; Thu, 4 Oct 2001 21:24:57 -0700 (PDT)
Received: from cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAQ00559 (AUTH sarvi); Thu, 4 Oct 2001 21:26:45 -0700 (PDT)
Message-ID: <3BBD3517.4D7223F2@cisco.com>
Date: Thu, 04 Oct 2001 21:20:39 -0700
From: Sarvi Shanmugham <sarvi@cisco.com>
Organization: Cisco Systems Inc.
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks <rsparks@dynamicsoft.com>
CC: sip@ietf.org
Subject: Re: [Sip] draft-ietf-sip-cc-transfer-05
References: <9BF66EBF6BEFD942915B4D4D45C051F338E61D.13168@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: multipart/mixed; boundary="------------280CB5909750897A0F6C5F98"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi Robert,
      Could you please refer me to the thread that discusses this.

What is the reasoning for not allowing provisional responses to the REFER
method.

Seems to me, that would be the cleaner way of doing this than a one time
REGISTER with a NOTIFY option.

As with this method, the Transferor cannot get intermediate status of how
the transfer is going. The transferor application may want do certain things
based on that status.
One example on a TELE-to-SIP gateway, would be a choice of when the TELE
side should be disconnected or dropped.
The application might want to keep the telephony leg active till,
       1. the Transferee ACKs the REFER(which I believe doesn't necessarily
mean the phone is ringing)
       2. the Transferee says the destination is ringing(may be he wants to
reconnect if the destination comes back as a ring no-answer.
      3. the Transferee says the destination is connected.

Thanks,
Sarvi

Robert Sparks wrote:

> If only we could...
>
> No. Non-INVITE transactions do not pend. They must
> complete immediately. If you've been following the
> open issues threads, you'll have seen the suggestion
> to kill off provisional responses (other than a 100
> Trying to quench retransmissions) to non-INVITES.
>
> This feature of the non-INVITE transaction model is
> why we have the implicit subscribe and the separate
> NOTIFY instead of just waiting for the triggered
> action to complete before sending the final response
> to the REFER (on a historical note, that was the original
> proposal of over a year ago).
>
> RjS
>
> > -----Original Message-----
> > From: Sarvi Shanmugham [mailto:sarvi@cisco.com]
> > Sent: Tuesday, September 25, 2001 11:57 AM
> > To: sip@ietf.org
> > Subject: [Sip] draft-ietf-sip-cc-transfer-05
> >
> >
> >
> > I have a question/concern in the blind transfer case.
> >
> > As per the current spec,
> >     The TRANSFEREE responds with a Ack 202 to the REFER method, before
> > the attempt to the Transfer target is initiated.
> >
> >     The next possible message from the Transferee to the Transferor is
> > NOTIFY(200 OK) and this is when the Transfer target
> > accepts(picks up the
> > phone).
> >
> >      In a blind transfer, where I want to release the
> > Transferor, Ack202
> > "may be" premature, and NOTIFY(200 OK) may be too late.
> >
> >      Can the Transferee gateway, send an intermediate NOTIFY(180 OK)
> > when the transfer target is "ringing". This could be a more reliable
> > place to release the Transferee's line, than Ack 202
> >
> > Any thoughts,
> > Sarvi
> >
>
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip