Subject: Re: [SIP] REFER progress

From: Billy Biggs <[email-masked]>
Date: Wed, 10 Jan 2001 13:00:55 -0500

Maybe I can better explain the issue:

  Say we use REFER to negotiate transfer, and the transfer fails.  Rick
wants the REFER receiver to send a re-INVITE back to the REFER sender to
re-negotiate the session, not a NOTIFY.  Reasons:

  1. The code on the INVITE receiver can be reused.  The REFER sender
     sends a 180 Ringing until the user answers the line.  The INVITE
     sending phone correctly plays local ringback.

  2. How does the NOTIFY sender know to play local ringing?  Send a 180
     response to the NOTIFY?  Should we play ringing in the RTP?

  3. The INVITE transaction can take a long time.  NOTIFY can't, meaning
     we can't send 180s to the NOTIFY otherwise we get the same problem
     we had with REFER.

  As a compromise, I suggested that the NOTIFY and the REFER allow SDP
bodies so that at least we could avoid message queues for re-negotiation
of the session.  This way, we can at least send the ringing as audio in
an RTP session, and negotiate this session without having a message
queue (send NOTIFY then send re-INVITE).  To optimize a successful
transfer case, I want to allow a BYE to mean that no NOTIFY will be sent
(to avoid send NOTIFY then send BYE).

  I understand the desire for a primitive, but please try to think about
how to design transfer using REFER.   Especially the flow for a failed
transfer.  How does each actor know what to do?  How should the ringing
sound be sent as you ring back the REFER sender?  If using REFER to
is too difficult, then the primitive is wrong.  One problem we have here
is that most of the people arguing about the NOTIFY stuff aren't trying
to design a phone.

-- 
Billy Biggs
[email-masked]

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

---

From: Sean Olson <[email-masked]>
Date: Wed, 10 Jan 2001 14:23:52 -0600

Allow me to clarify a few things :)

> re-negotiate the session, not a NOTIFY.  Reasons:

I never, ever, intended the NOTIFY to be used to re-negotiate
the session. Session negotiation is what INVITE does.
NOTIFY was meant as an indication which a service could use
to determine the success or failure of the REFER. That is all.
Re-negotiation of the session would happen subsequently or
perhaps independently of the NOTIFY.

>      sending phone correctly plays local ringback.

       I can't imagine what you are trying to do here.
       Why does the REFER sender have to worry about ringing
       at the transferee? Why isn't this left to a "180 Ringing"
       or otherwise that is received from the transfer target?
       It seems like you are looking for device control here and
       I don't think SIP is good at that.

>      response to the NOTIFY?  Should we play ringing in the RTP?

       Why does the NOTIFY sender need to play local ringing?
       You are just using an existing session to the REFER sender
       right? i.e. there is no SIP signalling needed here. The
       NOTIFY is just a nicety.

>      we can't send 180s to the NOTIFY otherwise we get the same problem

       Agreed. This is a very poor use of NOTIFY.

> (to avoid send NOTIFY then send BYE).

I think that the problems you are encountering are because
of the interdependency of the INVITE/REFER. For this
particular case (blind transfer with "automatic" session
re-negotiation upon failure), I would recommend the following:

1) The transferor sends a REFER without a Refer-Notify:
    header indicating that the transferor doesn't care to
    receive a NOTIFY at all. The transferee immediately
    responds with a 200 OK to the REFER.

2) The transferor immediately sends a BYE. At this point
    the transferor is completely removed from the situation.

3) The transferee sends an INVITE to the transfer target.

4) The INVITE fails for whatever reason ...

5) The transferee sends a new INVITE to the transferor.
    This is a brand new session.

6) Repeat as necessary ...

With this message sequence the roles of all the actors at each
point in the call is well defined. No real magic needed. Granted,
this probably not what you had in mind -- you wanted the transferor
to remain on "hold" while the REFER was being handled. I don't
see any great advantage to this.

However, if you really want this then:

1) The transferor sends a REFER without a Refer-Notify:
    header indicating that the transferor doesn't care to
    receive a NOTIFY at all. The transferee immediately
    responds with a 200 OK to the REFER.

2) The transferor "switches to a new line". No SIP
    signalling needed here. You could, optionally, actually
    place the transferor on hold here if needed.
    The transferee sends an INVITE to the transfer target

3) The INVITE fails for some reason ...
    (If the INVITE did not fail, then the transferee could
     simply send a BYE to the transferor)

4) The transferee switches back to the original line
    (No SIP signalling involved). There is no ringing to
    worry about, etc. This is based on the concept that there
    is an actual human user at the transferor UA.

This seems a little too obvious. I must be missing a fundamental
requirement/feature of the service you are trying to build.

> is that most of the people arguing about the NOTIFY stuff aren't trying

On the contrary, my arguments for NOTIFY are based entirely on
the endpoints perspective. I may not be designing a phone,
but I am aware that we need phones to make this whole thing
useful :)

/sean

---

From: Rick Dean <[email-masked]>
Date: Wed, 10 Jan 2001 15:13:38 -0600

> 6) Repeat as necessary ...

This is BYE-Also.  Unreliable.  Keeping around
the old call leg until the new one succeeds better
ensures the call wont be dropped, and can be resolved
faster.  Dropping calls is bad.

>     is an actual human user at the transferor UA.

Exactly.  Does the REFER recipient send a NOTIFY?

If no, the the transfer failure has to pass through the
human-band.  "Hello" "Hello" "Did you transfer me?" 
"Didn't it work? Let me try again".

If yes, we need to renegotiate the audio at the same time
we need to send a NOTIFY in the same call-leg, same direction.  
Which message goes first?   Either way you have added
another state.

What was that exception you proposed about the NOTIFY and 
INVITE being independent and thus allowing overlaping
transactions?  Do they use the same CSeq?  I don't like
where this is going.  Please stop.

500-port gateways need to budget their media bandwith carefully.  
Don't assume everyone has enough capacity to support additional
streams, or will mix.  Phones also have problems.

Transfer needs to be easy because it needs to be supported,
especially on the gateways.  We have seen many people
have trouble with the most basic features of SIP.  Who
knew that development time would be the most binding
constraint?  

Is anyone ready to interoperate with me?  Preferrably
against something without a hard disk and 19" monitor.

--
Rick

---

From: Sean Olson <[email-masked]>
Date: Wed, 10 Jan 2001 16:28:08 -0600

Thank you. The pieces all fell together for me, finally :)
Some minor comments below. For what you want, I agree
that the best solution is to send a re-INVITE with a
Refer-Status: header. Will this go in the transfer draft
or is it an extension to that draft?

/sean

> "Didn't it work? Let me try again".

This is indeed very clumsy.

> where this is going.  Please stop.

I didn't see the INVITE/REFER sharing the same
Call-ID. This is why I didn't see the problem
you have. This was the independence I was looking
for. I understand your desire to use the same
Call-ID though.

> streams, or will mix.  Phones also have problems.

I try to never make those assumptions. Thus the
option to place the transferor on hold (or vice
versa).

> knew that development time would be the most binding

I agree with the sentiment. I don't think any
of the possible approaches we have discussed
are that different in terms of complexity. They
do differ in the way the service looks to the
end user.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 10 Jan 2001 18:39:56 -0500

Sean Olson wrote:

> see any great advantage to this.

Generally, I think 'hold' is a poor UI choice for longer-duration
interruptions.  It means that a long-forgotten call can suddenly come
back with a mysterious voice starting to talk.  Just because PBX do it
that way doesn't mean that we should. I would find it very peculiar to
suddenly have the person that I thought I handed off to somebody else
talk to me after a minute or two.  (Also, note that the In-Reply-To
header can provide hints that this is "return engagement" has a
relationship with an older call. The UI is then free to do something
special if desired.)

> requirement/feature of the service you are trying to build.

This is basically attended transfer, right?

Given the ease with which multiple "lines" can be implemented in SIP
phones, the traditional distinction between attended and unattended
transfer may not matter that much. 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Wed, 10 Jan 2001 18:53:46 -0500

Henning G. Schulzrinne ([email-masked]):

> interruptions.

  The line would likely "disappear" from the UI or be hidden or
something.  The re-INVITE after failure would then cause the phone to
ring as if it was an incoming call.

> (Also, note that the In-Reply-To header can provide hints that this is
> "return engagement" has a relationship with an older call. The UI is
> then free to do something special if desired.)

  We want to use the existing session, re-INVITE rather than a new
INVITE, in order to avoid forking and make recovery reliable.

> > 1) The transferor sends a REFER without a Refer-Notify: [...]
> > 2) The transferor "switches to a new line". [...]
> > 3) The INVITE fails for some reason ... [...]
> > 4) The transferee switches back to the original line [...]
> > 

  No.   Attended transfer is when a bridge excuses itself from a 3-way
call, connecting the two endpoints it was conversing with directly.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 10 Jan 2001 16:32:59 -0800

Hi,

We need to go back to the requirements.  Callback on transfer failure is a 
nice feature, but you and Rick seem to be assuming that this feature is 
common enough to merit special optimizations.  I'm not convinced.  Maybe we 
will decide the proposed optimization (Event header in any method) is 
useful and simple or benign enough to make it a standard, but let everyone 
see the complete picture before we decide.

thanks,
-rohan

---

From: Rick Dean <[email-masked]>
Date: Thu, 11 Jan 2001 14:21:13 -0600

I don't consider it a feature, more of a contingency.
On the first try I (as the REFER sender) refer you through
your gateway.  When that fails I refer you through mine.  Next,
I back-to-back UA you to my gateway.  Firewalls of course make
this all possible.... er... I mean....  unfortunately necessary.

Needing more time is fine.  I would like us to have as many
lessons from implementation as we can before we commit ourselves.

Cheers,
Rick
[email-masked]