Subject: [SIP] RSVP/SIP problem

From: [email-masked]
Date: Thu, 13 Apr 2000 15:07:15 +0100

When building a telephone network a very important factor is GoS - Grade of
Service, i.e. the probability that a call will block due to resources not being
available. I would like to confirm my understanding of how this can happen with
SIP.

If resources for a call are not available the call should block before the
called party is alerted. For this to happen both endpoints must have all the
information they need to know to perform resource reservation before the called
party is alerted, and they should be able to communicate this availability.

Assuming RSVP is going to be used for resource reservation:

These events are required for a reservation: (taken from RSVP rfc)
      H1   A receiver joins the multicast group specified by
           DestAddress, using IGMP.

      H2   A potential sender starts sending RSVP Path messages to the
           DestAddress.

      H3   A receiver application receives a Path message.

      H4   A receiver starts sending appropriate Resv messages,
           specifying the desired flow descriptors.

      H5   A sender application receives a Resv message.

      H6   A sender starts sending data packets.

As far as I understand the SIP exchange of INVITE, RINGING does not permit this.

I will look at a point to point full duplex audio call:

The calling end determines the local address to which media should be sent
The calling end sends INVITE, passing the local address to which media should be
sent.
The calling end cannot make any resource reservation yet, since it does not know
the destination address for media
The INVITE is routed to the receiving end of the call.
The receiving end of the call can now send a RSVP path message back to the
calling end to reserve a media path in that direction
The called end determines the local media address where media should be
received.
The called end sends this local address to the calling end via a 183 response
The called end starts alerting

Here is the problem. The called end has started alerting without knowing that
bandwidth has been reserved in the direction from the calling end to the called
end. Potentially when the user picks up the phone only a one way voice path will
be possible.

To solve this problem an ACK to the 183 response, confirming that bandwidth is
available should be sent from the calling end before ringing commences.

regds,

Simon Barber
Orange PCS Ltd

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