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

[Robert Sparks <[e-mail]>]

Look for threads back in the Dec 2000 / Feb 2001 timeframe
(check the minutes of the Dec ietf and the Feb interim meeting).

I've got the reasoning below - REFER is not INVITE. The non-INVITE
transaction model times out quickly whether there are provisional
responses or not. (There have been other threads on disallowing
provisionals for non-INVITEs. They are allowed currently but they
don't cause the transaction to wait any longer for a final response).

I'm not sure I understand your third paragraph. Nothing in the 
current drafts prevents you from issuing NOTIFYs with progress
information if you wish to expose it. (One could have a sipfrag
with a status line of 183 for example).

RjS

> -----Original Message-----
> From: Sarvi Shanmugham [mailto:[e-mail]]
> Sent: Thursday, October 04, 2001 11:21 PM
> 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
> 

_______________________________________________
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