H.

323

Primera parte RAS:

RAS: H.225
In Phase A, registration, admission, and status (RAS) is the protocol that synchronizes
communication between end-points (terminals and gateways) and gatekeepers. The RAS
protocol (H.225) is a subset of the ITU-T Q.931 protocol, and is used to perform registration,
admission control, bandwidth changes, status, and disengage procedures between endpoints
and gatekeepers. A RAS channel is used to exchange RAS messages. This signaling channel
is opened between an endpoint and a gatekeeper prior to the establishment of any other
channels.

Segunda Parte Señalización (set up)

The H.225 Call Signaling Diagram illustrates this process:
1. The originating gateway sends a setup message to the destination gateway by means of the
gatekeeper. The gatekeeper, when involved in the call setup process as it is in this example,
can provide call accounting services.

2. The destination gateway receives the setup message via the gatekeeper, and responds with a
call proceeding message.
The call setup and call proceeding messages are two of seven ISDN Q.931 call setup protocol
messages. There is one additional Q.932 protocol. The H.225 Mandatory Messages Table lists
these eight messages:

Control:
H.245

H.245 Control Signaling

The steps for control signaling are as follows:
1. The first step in H.245 call negotiation is capability exchange; this is H.323 call setup Phase
B. The two endpoints negotiate such things as codec parameters and transport layer port
numbers. For example, the source gateway may present a list of codecs it supports to the
destination, in a preferred order. The destination device checks the list to see if it supports
those protocols, and picks one from the top of the list. If the destination prefers a different
codec order, it might send a message to the source saying it prefers them in its own order.
The originator might then send with its preferred codec, while the destination might send with
its preferred codec. This is acceptable behavior as long as each device selects the correct
receiving codec to match that used to send the media.
Another part of the capabilities exchange process is determining the master controller of a
multipoint conference. Each conferring device lists its capabilities; the protocol assigns each
capability a point value. The devices sum these point values, and the one with the highest
total becomes the master. The initial master remains the master for the conference's duration,
even if another device joins with a point value higher than that of the current master.

2. Once the H.245 housekeeping tasks are complete, Phase C opens media channels between
the endpoints. The originating gateway sends an open logical channel message to the
destination gateway.

3. The destination gateway replies to the open logical channel message with an open logical
channel acknowledgment message. The devices use the codecs and other parameters they
negotiated in Step 1 to open the first media channel.

4. The destination gateway then repeats Steps 2 and 3, opening the second media channel
necessary for full duplex communications between endpoints.
If the terminals select a bandwidth requirement exceeding that allocated by the gatekeeper,
Phase D comes into play. In Phase D, the receiving endpoint uses Bandwidth Request (BR)
messages to ask the gatekeeper for more bandwidth. If the gatekeeper can honor the
request, it responds with a Bandwidth Confirm (BCF) message. This process requires the
logical channel requesting the bandwidth variance to close and reopen with the new
parameters. If there is no bandwidth discrepancy, the devices do not invoke Phase D.

The five key SIP call establishment and maintenance aspects are as follows:
1. Call setup--SIP sets up point-to-point and multipoint conferences and simple calls.

2. User location services--A user may move to other locations and still access telephony
features from remote locations. This service equates to RAS in H.323.

3. User capabilities--SIP uses the Session Description Protocol (SDP) for negotiating media
parameters (codecs, etc.), much like H.323 uses H.245 or fastStart to do the same.

4. User availability--Determines the called party's willingness to engage in communications.

SIP defines explicit response codes, providing detailed information about a user's current
availability.
5. Call handling--Includes established call transfer, telephony call features, and simple call
termination.

SIP Addressing
SIP identifies source, current destination, ultimate destination, and specific redirection
addresses using Uniform Resource Locators (URLs), formatted in the e-mail-style encoding
<username>@<domain.com>. The username could be a text username, such as
[email protected], or a telephone number, such as [email protected].
Additionally, the domain portion can be a textual domain name or an IP address. The URL can
include UDP port numbers; the SIP well-known UDP port number is 5060.

SIP users register with SIP servers, to provide location contact information. A SIP registration
entry could look as follows:

REGISTER: [email protected]

CONTACT: [email protected]

SIP Partner Protocols

SIP does not depend on other protocols such as RSVP, RTP, RTCP, or Real-Time Streaming
Protocol (RTSP) for establishing multimedia conferences, QoS control, and signaling. However,
media transport or physical level malfunctions can affect the overall system operation.
Resolution of these types of problems depends on the SIP implementation; in some cases the
TCP/IP Simple Network Management Protocol (SNMP) operates in parallel with SIP, providing
diagnostic reporting capabilities.

SIP, like H.323, specifies using RTP for media transport and RTCP for call quality monitoring
and gathering statistical data. This statistical data can be made available to the SIP server
through the signaling platforms design considerations.

SIP uses SDP to define media streams the clients are capable of receiving. According to RFC
2327, "SDP is intended for describing multimedia sessions for the purpose of session
announcement, session invitation, and other forms of multimedia session initiation." SDP
encodes a session description as an ASCII text string using an abbreviated message format in
the format:

v=protocol version

o=owner/creator

s=session name

Also included in the message set are optional, time, and media descriptions.

SIP Signaling Methodology

SIP uses six signaling methods, shown in the SIP Requests (Methods) Table.

SIP Requests (Methods)

INVITE
 The INVITE method initiates a call. Parts of the INVITE method include the calling party, call
identification, called party, call sequence number, and other header-defined information. An
INVITE request can be generated at any time during the course of a call to modify the call's
state.

ACK
An ACK indicates that the calling agent successfully received the 200 response from the called
party, which was sent as a response to the original INVITE request; ACK is used only with
INVITE requests. ACK indicates the calling party has received confirmation to an INVITE
request.

OPTIONS
This message queries the call agent's capabilities.

BYE
The BYE request indicates to the SIP server that a clients wishes to release a call. Either client
can issue the BYE request, and the other end need not send a BYE response. The other party's
response has no effect on the BYE request.

CANCEL
CANCEL requests cancel a call request in progress, as specified by the Call-ID field. CANCEL
has no effect on a completed request. A user agent or proxy can issue a CANCEL at any time.

REGISTER
The REGISTER method allows a client to register the To: SIP header field address with a SIP
server. A user agent may register with a local server on startup by sending a REGISTER
request to the well-known "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75).

Additionally, SIP defines six responses, as shown in the SIP Responses table.

SIP Responses
1xx
Informational

2xx
Success

3xx
Redirection

4xx
Request Failure

5xx
Server Failure

6xx
Global Failure
The SIP Call Model
As we learned earlier, SIP servers can operate in either proxy mode or in redirect mode.
Proxy Mode
In proxy mode, calls flow as shown in the SIP Proxy Server Diagram.

SIP Proxy Server

The steps for the SIP Proxy Server are as follows:
1. The caller on the left, [email protected], wishes to place a call to the caller on the right,
[email protected]. Jane's endpoint sends an INVITE request to the SIP proxy server's UDP port
5060, passing call identification (Call-ID), command sequence (Cseq), and SDP information in
addition to routing information, such as From and To.

2. The SIP server determines if Bill is registered locally, and if so, finds his current location. The
local server consults a Lightweight Directory Access Protocol (LDAP) directory server for this
information. If the local server has Bill registered, it forwards the INVITE request to Bill's
location. The local SIP server leaves the call's To and From header information intact, adding
its server name in the Via field. The SIP proxy alters the INVITE request to represent Bill's
current location, which may differ from that specified in the original To: field.

3. SIP proxy mode servers can form a routing chain of any length. If Bill is not registered with the
local server, the directory server can inform the local SIP server that another server is better-
suited to responding to this location request. The local server then sends this INVITE request
to the next server, which adds its information to the call with a Via field entry.

4. Bill receives the incoming call, and responds with a SIP 200 OK response message. The SIP
proxy server then forwards the 200 message to Jane.

5. Jane acknowledges the 200 OK message with an ACK message. The SIP proxy forwards this
message to Bill.
The SIP proxy can handle call accounting services, such as billing. Once the endpoints
establish the call, the media flows directly between the originator and destination. The SIP
server may be involved in the call's teardown as well.
Redirect Mode
A call established using a SIP server in redirect mode progresses as shown in the SIP Redirect
Server Diagram.

SIP Redirect Server

The steps for the SIP Redirect Server are as follows:
1. Once again, Jane wishes to call Bill. Jane's endpoint sends an INVITE message to
[email protected] by way of the SIP redirect server.

2. The SIP server looks up Bill's information. Once it locates Bill, the SIP server sends a SIP 300
Redirection message back to Jane, passing Bill's current contact information.

3. Jane's endpoint sends an ACK to the SIP server. It then sends a new INVITE directly to Bill's
endpoint in its new location.

4. Once Bill's endpoint receives the INVITE message, it replies with a 200 OK message, directly
to Jane's endpoint.

5. Jane's endpoint replies to this 200 message with an ACK.