Subject: SIP, RTSP and resource reservation

From: [email-masked]
Date: Tue, 23 Sep 1997 11:44:33 -0700 (PDT)

Hi,

   Jeff Smith and I(NTT research Labs) are working on media server design 
using SIP and RTSP. Because of resource reservation for RECORD or PLAYBACK, 
we figured out that we have to add some attributes in SDP and/or add some 
methods in SIP. 

   The following is our input to this topic. We'd love to hear your 
comments so that we can make SIP and SDP more suitable for invitation.  

   Thanks,

Feng

o---------------------------------------------------------------------o
|  Feng Cao							      |
|								      |
|  Nippon Telegraph and Telephone Corporation  		              | 
|  Multimedia Communications Laboratories       Email:[email-masked]|
|  250 Cambridge Ave., Suite 205                TEL:  415-833-3627    |
|  Palo Alto, CA 94306                          FAX:  415-326-1878    |
o---------------------------------------------------------------------o

-------------------------our comments---------------------------------------- 
                   SIP, RTSP and Resource Reservation

Basic Assumption:
 1. SIP will be used to invite media servers to participate in a session.
 2. If  media servers agree to participate in a session, they must guarantee 
    the resource reservation for this session.
 3. RTSP will be used to SETUP the session,  send RECORD/PLAYBACK to the 
    media servers.

Design issues:
1. Since the resource reservations are made during SIP, some additional 
   attributes are needed for the exchange information between the inviter 
   and the invitees,

   Solution:some attributes are added for SDP used in SIP. (SDP)

2. resource reservation preview; (SIP and media server)
   review the schedules for certain resources; 

   Solution: this should provide queries to database; this may use OPTIONS 
        from SIP or add new method into SIP such REQUIRE.

2. resource reservation schedule; (media server)
      make reservation for the future session based on the current schedules;

      Problem: schedule algorithm; 

3. resource reservation authorization; (SIP, RTSP and media server)
      This covers check-in (make reservation) and check-out(resource 
         utilization).

      Solution: user-id; meeting-id;

4. resource reservation cancellation;   (SIP and media server)
      This needs new methods from SIP to cancel the resource reservation.

      Solution: new Method: CANCEL, with SDP

5. resource reservation update:  (SIP and media server)

       Solution: This could be done in two approaches:
         A. Cancel the previous reservation, and reinvite the media server.
              advantage: no need to change SIP; ......
              disadvantage:  delay; bad for some updates such as reducing 
                      some resources; .......

         B. add new method UPDATE to SIP
              advantage: minimum delay; good for small changes;......
              disadvantage: add method to SIP; ......

6. RTSP client's SETUP must add the  reservation id (call it meeting id 
      or conference id) to inform the server of its reservation, and get 
      back the session id. (RTSP)

Discussion One: More specifications for  adding SDP attributes:
   1. reservation-id(or Conference id) 
       A.Two approachs: determined by the inviter or the media servers.
           We choose the reservation-id determined by the inviter. The 
           reason is that the inviter must create a table to remember all 
           reservation-ids from different media servers.

       B. This id must be global unique.

       C. In SDP, define 
                    a=conference:<digit>

       E: In SDP, define
                    a=cancel:<digit>

       D. u=URI  is provided in SDP,  which can be used for URL information; but
           only one u=URI in each SDP.
           a=control:..... in SDP is provided for aggregate control for 
           media streams.

Discussion Two: More specification for adding cancellation for SIP:
   1. adding new method CANCEL in SIP.

   2. using a=cancel:<digit> in the above to inform the server.

   3. make Confirm:true for any cancellation operation. Retry it if it fails.

Discussion Three: More specification for RTSP SETUP:
   1. the easiest way is to use Conference=reservation-id  when the 
      inviter talks to the media server; after that a session id will be 
      generated and used for the whole session.

   2. it is possible to add an attribute to RTSP for reservation-id.

I for  inviter, M for media server
SIP invitation:
   I-->M: INVITE  Request-URI SIP/2.0
              From: .......
              To: ........
              .......
              a=conference:****

   M-->I: SIP/2.0 200 Request-URI
              .........
              a=conference:****
              u=URL

SIP cancellation:
   I-->M: CANCEL Request-URI SIP/2.0
              ........
              conference=****

   M-->I: SIP/2.0 200 Request-URI

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Sep 1997 19:12:59 -0400

I assume you are talking about reserving *server* resources such as disk
bandwidth rather than network resources, as the latter is probably more
the province of RSVP, YESSIR, ST-II, etc. (I believe advance reservation
for some of these has been proposed).

That said, a SIP INVITE for the same Call-ID could be made to override
the old one by having a new SDP session version. (Whether this is
desirable behavior or whether duplicate SIP INVITEs with the same
Call-ID should just be tossed silently is a matter to be debated.)

Since BYE and INVITE could be in the same packet, the likelihood that
somebody "steals" your resources after you release them is pretty slim.
We had discussed adding a CHANGE method at some point (in SCIP), to
allow changes in media agents, for example, so this might be a good
motivation to bring this back.

>         from SIP or add new method into SIP such REQUIRE.

What exactly do you mean by preview? The server should return a
'Retry-After' if the slot desired isn't available.

>       Solution: user-id; meeting-id;

SIP Call-ID -> RTSP Conference-ID?

>       Solution: new Method: CANCEL, with SDP

No need for CANCEL: we have BYE for that already.

>               disadvantage: add method to SIP; ......

See CHANGE suggestion above.

-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

---

From: [email-masked]
Date: Wed, 24 Sep 1997 12:25:35 -0700 (PDT)

The basic scenario for resource reservation in our work is to 
invite some media servers to a conference, and the conference can't
start without the involvement of those servers. So *server* resource
reservation is important for us. We think SIP can do it with adding
some new methods such as CHANGE, and it might be the right time to
bring up SIP, SDP and server resource reservation. 

> for some of these has been proposed).

  Yes, we want to reserve *server* resources such as disk bandwidth,
recording/playing devices, ......

> Call-ID should just be tossed silently is a matter to be debated.)

  We need some kind of reservation-id(or Call-ID) embeded in SDP.
We could add some kind of sequence number and/or time stamp for 
each INVITE for the same Call-ID.
 
> motivation to bring this back.

The CHANGE(or UPDATE) method is what we need.  Otherwise, the sequence number 
or the time stamp must be used to inform the server of any change of resource 
reservation.  

> 'Retry-After' if the slot desired isn't available.
  
  In the case that the media server must show up in a session(or conference), 
the 'Retry-After' is not efficient. The media server should return some
information about when it is going to be free. This will help the
initiator decide when start the session(or conference).
Preview means checking the server's schedule for some of its resources. 

> SIP Call-ID -> RTSP Conference-ID?

  This is possible. We need more discussion on it. 

Feng

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Sep 1997 23:12:30 -0400

[email-masked] wrote:

> each INVITE for the same Call-ID.

Doesn't SDP already have a globally unique identifier?

> Preview means checking the server's schedule for some of its resources.

If you go beyond a list of Retry-After's, this can get arbitrarily
complex. Possibly adding a parameter to Retry-After indicating how long
the resource will be available is sufficient.

Henning