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

["Tom-PT Taylor" <[e-mail]>]

The problem with allowing provisional responses to REFER is that the REFER
transaction will generally time out long before the triggered call is
answered.  This was discussed at the 49th IETF: the slides may still be
available at
http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe
r-02.htm 

There were a number of REFER threads at the turn of the year.  I suppose
"Solving the REFER retransmit issue" (beginning 12/12/2000) might be a
typical one.

-----Original Message-----
From: Sarvi Shanmugham [mailto:[e-mail]]
Sent: Friday, October 05, 2001 12:21 AM
To: Robert Sparks
Cc: [e-mail]
Subject: Re: [Sip] draft-ietf-sip-cc-transfer-05


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:[e-mail]]
> > Sent: Tuesday, September 25, 2001 11:57 AM
> > To: [e-mail]
> > 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip