Subject: RE: [SIP] Solving the REFER retransmit issue

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Dec 2000 10:10:40 -0500

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Friday, December 22, 2000 5:03 PM
> To: Jonathan Rosenberg
> Cc: Sean Olson; Henning G. Schulzrinne; Rohan Mahy; Robert Sparks;
> [email-masked]
> Subject: Re: [SIP] Solving the REFER retransmit issue
> 
> 
> Jonathan Rosenberg ([email-masked]):
> 
> > case REFER means refer, and nothing else; i.e., don't use a 
> header in
> > an INVITE, since INVITE is not a transfer/refer function. There is
> > something in the sip guidelines document that says that 
> headers should
> > not alter the basic functional processing of a request. This was one
> > of the problems with the original Also proposal.
> 
>   In our proposal, the INVITE semantics are preserved.  The referred
> user wishes to renegotiate the old session, and wishes the 
> phone at the
> far end to ring.  The header does not alter the functional processing,
> but rather indicates that this re-INVITE is because a response arrived
> to the spawned call.
> 
>   This is both simple and explicit.
> 
> > So, I still believe that the best solution is REFER that 
> generates an
> > automatic NOTIFY. I think the idea of including a header in the
> > request which tells you whether to send the notify or not is
> > acceptable.
> 
>   This might be alright, but how about:
> 
>   1) No NOTIFY is sent if the referred party shuts down the call leg
>      with a BYE.
> 
>   2) The NOTIFY and REFER may contain SDP.

I really, really don't like this.

REFER as defined now has a simple, clean, very specific but broadly useful
semantic. You are basically trying to push us towards the approach of
defining service specific methods. I don't want to do that.

> 
> 
>   I want, for a failed transfer scenario:
> 
>        Referrer             Referred Party
>          ---- REFER (hold SDP) -->
>          <--- OK (hold SDP) ------
> 
>              (after failed INVITE)
>          <- NOTIFY (active SDP) --
>          -- OK (active SDP) ----->
> 
>   Message Count: 4
> 
> 
>   I want to avoid this:
> 
>        Referrer             Referred Party
>          --- INVITE/OK/ACK (hold) -->
>          ------ REFER -------------->
>          <----- OK ------------------
> 
>              (after failed INVITE)
>          <-- NOTIFY -----------------
>          --- OK -------------------->
>          <-- INVITE/OK/ACK (active) -
> 
>    Message Count: 10

The aim is not message count reduction. The aim is general purpose tools
that we can use to build more than one service.

-Jonathan R.
 
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Billy Biggs <[email-masked]>
Date: Fri, 29 Dec 2000 10:46:14 -0600

Jonathan Rosenberg ([email-masked]):

> REFER as defined now has a simple, clean, very specific but broadly
> useful semantic. You are basically trying to push us towards the
> approach of defining service specific methods. I don't want to do
> that.

  Transfer is a fundamental service.  There must be an accepted and
interoperable transfer scheme which is simple and small enough that
everyone will implement it.  I also care about performance.

  If SDP cannot be placed in the REFER, then requesting a transfer will
take two transactions (on hold, then refer).  I guess you can forget
about the hold and hope that the far end will stop sending media when it
gets the REFER...  Ugh.

  If you must send a NOTIFY and then a BYE seperately, then the REFER
recipient will have to maintain a queue of operations to perform after
the transfer is successful.  This is alot of work for small
implementations.

> that we can use to build more than one service.

  Please optimize for the primary use.

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