Subject: Re: [SIP] REFER progress

From: Rick Dean <[email-masked]>
Date: Tue, 9 Jan 2001 18:07:45 -0600

----- Forwarded message from Rick Dean <[email-masked]> -----

Sean,

How does the REFER sender get the REFERDONE/NOTIFY sender
to send an INVITE so the ringback can flow in the right
direction?   Please don't say, "Send another REFER".

Does the REFERDONE/NOTIFY sender have to wait for the
REFERDONE/NOTIFY to complete before he sends a
re-INVITE/BYE?  I have been trying hard not to have 
a message queue.

Internet telephony is usable over 100ms round-trip times.
If we start requiring more than one round trip, signaling
can be noticeably slow.
More messages make the trace files long and complicated.
The error notices get worse:  "packet/state 5
of 9 didn't complete"   More messages gives
people more states to make a bug.  More messages
are harder to test packet loss/reordering cases for.

As for your second point, if I get a re-INVITE after
sending a REFER, I cannot be certain the REFER
failed because the re-INVITE may have crossed
the REFER in transit.  I need a header in the re-INVITE.

--
Rick
[email-masked]

On Tue, Jan 09, 2001 at 05:29:39PM -0600, Sean Olson wrote:
> If I understnnd your concerns correctly, the
> use of an INVITE/BYE instead of NOTIFY buys
> you a couple of things:
> 
> 1) You save the 2 message overhead of NOTIFY/200
> 2) You provide a mechanism to re-establish or
>     end the session between the transferor and
>     transferee based on the outcome of the
>     (blind transfer) REFER.
> 
> The first issue can be solved by my recommendation
> of a Refer-Notify: header that states whether or
> not the transferor wants to be notified of the status
> of the REFER.
> 
> The second issue is independent of whether or not
> NOTIFY is used. In other words, to get the functionality
> you want (as I understand it), you send a REFER without
> a Refer-Notify: header. Then, when the INVITE times out/fails,
> the transferee can send an INVITE/BYE to the transferor as
> you want (in place of the NOTIFY).
> 
> Is there some aspect that I am overlooking (very possible
> since I am dead tired)?
> 
> /sean
> 

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

---

From: "Robert Sparks" <[email-masked]>
Date: Wed, 10 Jan 2001 09:09:27 -0600

> Sean,
I'm not Sean, but I'll take a stab at one of these.

> re-INVITE/BYE?  I have been trying hard not to have 

Why would it have to? If the application doesn't really
care about the final response to the refer, it can send
the BYE (or do whatever else is appropriate at the time)
immediately. It doesn't need to keep state to respond
to the NOTIFY.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 10 Jan 2001 11:07:40 -0500

> immediately. It doesn't need to keep state to respond

I don't see why a system that doesn't care about the NOTIFY needs to
keep state. Just treat it like any other unsolicited request, with a 200
if you want to be charitable or 481 or whatever the events draft
specifies (or should...).

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

---

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

> immediately. It doesn't need to keep state to respond

My REFER sender does care if the blind transfer fails.  
Of the errors, this one will be most common.

Billy makes an excellent point about the timeout
constraints of a NOTIFY with SDP.  Quite frankly,
treating a NOTIFY like a re-INVITE is ugly in
the code, and a suprising use case.  

My proposal is very simple:  The Event:
can come in any method.  

Please suggest in the draft that if the transferee
wants to re-establish a session, he should
send it in a INVITE.  I am sure it will be popular
with the implementors.  

Protocols must be chosen by which one handles
the error cases best.  

--
Rick