Subject: RE: [SIP] Simple REFER Solution

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 21 Dec 2000 16:15:11 -0800

> 
> > I must be missing something.  If I send the REFER, how do I find out
> > if it is successful?  By the absence of a BYE?
> 
>   If the far end still wants to talk to you, they will 
> re-INVITE with a
> Refer-Response header containing the response code from the spawned
> INVITE.  This can of course be "200 OK".
> 
>   If you see a BYE it may also mean it's successful, but at that point
> what do you care?  If there is a legitimate requirement, it 
> may justify
> a Refer-Response header in the BYE too.
> 
> 
>   I really like this algorithm.  Thoughts?
> 

Hi Billy,

What happens when there is not an active SIP (INVITE) session between the
referer and referee ? Sending an INVITE in this case may have unwanted
effects (like initiating a call). Are you proposing that either a) you would
only send the INVITE/BYE if a corresponding SIP (INVITE) sessions exists or
b) that REFERS are not allowed outside of a SIP session?

Cheers,

Robert.
 
> >>   Keep REFER simple:  Have no REFER-response method and no
> >> subscription.
> >>
> >>   We have found the following algorithm to be smallest, simplest,
> >> easiest to understand, and least verbose.
> >>
> >>  1.  The REFER is responded to immediately.
> >>
> >>  2.  If the Referred Party wishes to resume the call later (usually
> >>      if the REFER-spawned call failed), then they send an 
> INVITE with
> >>      a 'Refer-Response' header containing the response 
> code from the
> >>      spawned INVITE.
> >>
> >>  3.  If the Referred Party wishes to end the old call (the
> >>      REFER-spawned call succeeded), then they BYE the referrer.
> >>
> >>  4.  To keep the number of messages down, REFER and its 
> response may
> >>      contain SDP (such as hold SDP).
> >>
> >>  Rationalle:
> >>
> >>   Avoids queues in either device.  A "first send NOTIFY 
> then send BYE
> >> to shut down the call" proposal has difficult error cases.  Want to
> >> keep recovery of the old session from a failed transfer as 
> speedy as
> >> possible.
> 
> -- 
> Billy Biggs, 3Com               Email: [email-masked]
> http://www.div8.net/billy/      Phone: [email-masked]
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Billy Biggs <[email-masked]>
Date: Thu, 21 Dec 2000 20:23:04 -0600

Fairlie-Cuninghame, Robert ([email-masked]):

> What happens when there is not an active SIP (INVITE) session between
> the referer and referee ? Sending an INVITE in this case may have
> unwanted effects (like initiating a call). Are you proposing that
> either a) you would only send the INVITE/BYE if a corresponding SIP
> (INVITE) sessions exists or b) that REFERS are not allowed outside of
> a SIP session?

  What does a REFER outside of a session mean?

  1) All user agents at the destination to immediately act upon the
     request.

     - evil denial of service
     - doesn't make sense in many cases (no user may be present, might
       be a gateway, ...)

  2) All user agents to prompt the user (if applicable) to act upon the
     request (DoS)

     - Is there an expiry time?
     - If one UA acts upon it, you can't coordinate the others not to
     - ??

  3) ??

  Most of this seems like pure device control, which is definitely
outside of the scope.

  I think REFER outside of a session should be disallowed.  It has a
distinct meaning from an in-call REFER.  If you want to ask someone to
join a session, sounds like an INVITE.  If you want something else, then
you should probably draft a new method.