Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Contents
14 SIP .............................................................................................................................................14-1
14.1 Description of SIP .....................................................................................................................................14-2
14.1.1 Related Terms ..................................................................................................................................14-2
14.1.2 SIP Addressing.................................................................................................................................14-4
14.2 SIP Message Types....................................................................................................................................14-4
14.2.1 Request Messages ............................................................................................................................14-5
14.2.2 Response Messages..........................................................................................................................14-5
14.3 SIP Message Structure...............................................................................................................................14-6
14.3.1 Request Message Structure ..............................................................................................................14-6
14.3.2 Response Message Structure..........................................................................................................14-12
14.4 Introduction to SIP-T ..............................................................................................................................14-13
14.5 SIP Signaling Procedures ........................................................................................................................14-14
14.5.1 Flows of Mobile Originated Calls Through SIP Trunks.................................................................14-14
14.5.2 SIP-T Signaling Procedure.............................................................................................................14-16
Figures
Tables
14 SIP
Section Describes
Call
A call consists of all participants in a conference invited by a common source. A SIP call is
identified by a globally unique Call-ID.
Therefore, if several people invite a user to the same multicast session, each of these
invitations will be a call. A point-to-point Internet telephony conversation maps into a single
SIP call.
Call Leg
The combination of Call-ID, To, and From identifies a call leg. For example, for a call
between A and B, the requests sent from A to B and from B to A use the same Call-ID,
belonging to the same call leg. A call leg is actually a path of messages for a call.
Transaction
A SIP transaction occurs between a client and a server. It comprises all messages from the
first request sent from the client to the server up to a final (non-1xx) response message sent
from the server to the client.
The CSeq sequence number within a call leg identifies a transaction. However, an ACK
request has the same CSeq number as the corresponding INVITE request, but comprises a
transaction of its own.
A normal call includes three transactions. Call initiation consists of two requests: INVITE and
ACK. The former requires a response. The latter is an acknowledgement that the final
response is received, requiring no response. Call termination contains one request BYE.
Location Service
Location services are offered by location servers. A SIP redirect or proxy server uses a
location service to obtain the possible location of a callee beyond the scope of this document.
However, the manner in which a SIP server requests location services is beyond the scope of
this manual.
Proxy Server
A proxy server is an intermediary program. It acts as both a server and a client to route SIP
requests to destinations. A proxy server may process requests internally or pass them on to
other proxy servers. It interprets, and, if necessary, rewrites a request before forwarding the
message.
Redirect Server
A redirect server performs the following:
z Accepts a SIP request.
z Maps the address into zero or more new addresses.
z Returns these addresses to the client.
Thus, the client can directly initiate requests to these new addresses again.
A redirect server implements the routing function instead of receiving or rejecting calls.
Registrar
A registrar is a server that accepts REGISTER requests. It is co-located with a proxy or
redirect server. A registrar needs to store the address mapping relationship in REGISTER
requests in a database for subsequent call processes. It can offer location services.
User Agent
A user agent is a logical entity that initiates or receives SIP requests.
Currently, CSOFTX3000 supports SIP URLs in the format of E.164 number@IP address:port.
For example:
Sip:8613301080001@127.0.0.1:5060;
Message Function
100 Try.
180 Ring.
181 Calls are being forwarded.
182 Queue.
183 A reliable provisional response.
200 OK.
Status
Method Request-URI SIP-Version
line
Call-ID: value
From: value
To: value
Cseq: value
Max-Forwards: value
Content-Length: value
Content-Type: value
.......
CRLF
Message
SDP
body
The Request-Line begins with a method token, followed by the Request-URI identifying the
peer URI and the SIP-Version identifying the protocol version, and ending with a CRLF.
Single space (SP) characters separate the elements.
Methods contain the following request message names:
z INVITE
z ACK
z OPTIONS
z BYE
z CANCEL
z REGISTER
The message header of a request message can be a general header, a request header, or an
entity header. The order of message header parameters is not fixed. Each parameter consists of
its name followed by a colon and a value. The value and colon are separated by a space.
A message header ends with a CRLF, followed by a message body.
Figure 14-1 only shows some parameters possibly contained in the message header of a request
message.
Parameter Descriptions
The following describes some common parameters in the message header of a request
message.
z Call-ID
This field uniquely identifies a SIP call. A Call-ID is generally in such a format as
Call-ID:local-id@host
The "host" is a host domain name or an IP address. The "local-id" is a unique identifier
within "host". Call-IDs are case-sensitive.
z From
Request and response messages must contain a From general-header field, indicating the
initiator of a request message. A server copies the field from a request message to its
response message. This field is generally in such a format as
From: display-name <SIP-URL>;tag=xxxx
The "display-name" is characters rendered by a human-user interface. The system must
use the display name "Anonymous" if the identity of the client is to remain hidden.
The "tag" may appear in the From field of a request message. It must be present when
two instances of a user sharing a SIP address make call invitations with the same Call-ID.
The "tag" value must be globally unique. The user maintains the same tag throughout the
call identified by the Call-ID.
z To
This field specifies the recipient of a request message, with the same syntax as the From
field. Request and response messages must contain a To general-header field.
In SIP, the combination of Call-ID, From, and To fields identify a call leg.
z Command sequence (Cseq)
Clients must add the CSeq general-header field to every request message. A CSeq field
in a request contains the request method and a decimal sequence number unique within a
Call-ID.
The initial value of a sequence number is arbitrary. Consecutive request messages that
differ in request methods, headers, or bodies but have the same Call-ID must contain
monotonically increasing and contiguous sequence numbers. Retransmissions of the
same request message carry the same sequence number.
A server copies the CSeq value from a request message to its response message.
ACK and CANCEL request messages must contain the same CSeq value as that in the
corresponding INVITE request message, whereas a BYE request message must have a
higher sequence number.
A server remembers the highest sequence number for any INVITE request message with
the same Call-ID value. The server responds to, and then discards, any INVITE request
message with a lower sequence number.
z Via
This field is generally in such a format as
Via:sent-protocol sent-by;via-params comment
Where,
This field can appear in INVITE, ACK, and REGISTER request messages, and in 1xx,
2xx, and 3xx response messages. It provides a URL where a user can be reached for
further communications.
INVITE and ACK request messages contain Contact fields indicating from which
location a request message originates. This allows the called subscriber to send future
request messages, such as BYE, directly to the caller rather than through a series of
proxy servers.
This field is generally in such a format as
Contact:name-addr;q=value;action= “proxy” |
“redirect”;expires=value;extension-attribute
The "name-addr" form is the same as that in the To and From fields. The "q" value
ranges from 0 to 1. Higher values indicate higher preference. The "action" parameter is
only applicable to REGISTER request messages. It indicates whether a server expects
future requests to the client for the server proxy or redirection service.
If this parameter is not specified, the action taken depends on server configuration. The
"expires" parameter indicates how long a uniform resource identifier (URI) is valid. This
parameter can be a number indicating seconds or a quoted string containing a SIP-date.
The "extension-attribute" is an extension name.
An example of the Contact field is:
Contact: <Sip:66500002@191.169.1.110:5061>;q=0.7;expires=3600
z Max-Forwards
This field limits the number of times for which a request message is allowed to be
forwarded.
Each proxy server or gateway recipient of a request message containing a Max-Forwards
field must check and update the value of the field before forwarding the request. The
initial value is 70. It is subtracted by 1 every time a request message traverses a proxy
server or gateway.
If the received value is zero (0) and the request message does not reach its destination
address, the server returns 483 (too many hops) and terminates this request.
The purpose of setting this field is to prevent consuming proxy server resources in the
case of loop during message transfer.
This field is generally in such a format as
Max-Forwards: decimal integrals
z Allow
This field lists the set of methods supported by proxy servers.
An example of the Allow field is:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
z Content-Length
This field indicates the size of a message-body, in decimal number of octets.
Applications use this field to indicate the size of a message-body to be transferred.
If TCP serves as the transport protocol, the message header must contain this field.
An empty line separating a message header and a message body is beyond the scope of
the Content-Length. Any Content-Length greater than or equal to zero is a valid value. If
no body is present in a message, the Content-Length header field must be set to zero.
This field is generally in such a format as
Content-Length: decimal number of octets
z Content-Type
This field indicates the media type of the message-body sent to the recipient. If the
message-body is not null, it must contain the Content-Type field.
An example of the Content-Type field is:
Content-Type: application/sdp
z Expires
This field gives the time after which the message content expires.
v: 0
o: HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.1.116
s: Sip Call
c: IN IP4 191.169.1.95
t: 0 0
m: audio 30000 RTP/AVP 8 0 4 18
a: rtpmap:8 PCMA/8000
a: rtpmap 0 PCMU/8000
a: rtpmap 4 G723/8000
a: rtpmap 18 G729/8000
From: value
To: value
Cseq: value
Max-Forwards: value
Content-Length: value
Content-Type: value
.......
CRLF
Message
SDP
body
A Status-Line consists of a SIP protocol version, a Status-Code, and its associated textual
phrase (Reason-Phrase). The Status-Code is a 3-digit integer code that indicates the type of a
request message. The Reason-Phrase gives a short textual description of the Status-Code.
The Status-Code includes 1xx, 2xx, 3xx, 4xx, 5xx, and 6xx, respectively defining six types of
SIP response messages. For full definitions, see section 14.2.2 "Response Messages".
The parameters in the header of a response message are the same as those in a request
message header. For details, see section 14.3.1 "Request Message Structure".
Mapping includes:
z ISUP-SIP message mapping
Gateways must generate a specific ISUP message for each SIP message received.
Conversely, gateways can also generate a specific SIP message for each ISUP message
received. SIP-T specifies the rules that govern the mapping between ISUP and SIP
messages. For example, an IAM must be sent on receipt of an INVITE, a REL for BYE,
and so on.
A mapping between ISUP and SIP messages can be as follows:
IAM = INVITE
ACM = 180 RINGING
ANM = 200 OK
REL = BYE
RLC = 200 OK for BYE
z ISUP parameter-SIP header mapping
A SIP request message that is used to set up a call contains information that enables the
message to be correctly routed to its destination, for example, a called number. SIP-T
defines the procedure for mapping of information from ISUP to SIP. For example, the
called number in an ISUP IAM must be mapped onto the SIP "To" header field.
CM_SERVICE_REQ
ASS_REQ
ASS_CMP
INVITE
100 Trying
180 Ringing
200 OK
ACK
CLEAR_REQ
BYE
CLEAR_CMD
9. If the calling subscriber hooks on, the CSOFTX3000 receives a CLEAR_REQ. At the
time, it sends a BYE to the called office and a CLEAR_CMD to the BSS at the calling
side. On receipt of the BYE, the called office sends a 200 for BYE to CSOFTX3000.
The BSS sends a CLEAR_CMP to confirm the completion of calling party disconnect.
10. If the called subscriber hooks on, the called office sends a BYE to the local
CSOFTX3000. On receipt of the BYE, the local CSOFTX3000 returns a 200 for BYE.
Meanwhile, it sends a CLEAR_CMD to the BSS at the calling side. The BSS returns a
CLEAR_CMP.
IAM
INVITE
IAM
100 Trying
ACM
180 Ringing
ACM ANM
200 OK
ANM
ACK
REL
BYE
REL
RLC
200 OK
RLC
6. CSOFTX3000 A extracts the ACM from the received 180 Ringing and forwards the
ACM to LS A. LS A receives the ACM. The calling PSTN subscriber hears ring back
tones.
7. If the called PSTN subscriber hooks off, LS B sends an ANM to CSOFTX3000 B.
CSOFTX3000 B preserves the received ANM in a 200 OK that it sends to CSOFTX3000
A.
8. CSOFTX3000 A extracts the ANM from the received 200 OK and forwards the ANM to
LS A.
9. CSOFTX3000 A sends an ACK to CSOFTX3000 B, acknowledging receipt of the final
message from CSOFTX3000 B in response to the INVITE.
10. At this time, both parties can communicate through an established bidirectional signaling
path.
11. If the calling PSTN subscriber hooks on, LS A sends a REL to CSOFTX3000 A.
CSOFTX3000 A preserves the received REL in a BYE message body that it sends to
CSOFTX3000 B.
12. CSOFTX3000 B extracts the REL from the received BYE and forwards the REL to LS
B.
13. On receipt of the REL, LS B sends busy tones to the called PSTN subscriber. If the
calling PSTN subscriber hooks on, LS B sends a RLC to CSOFTX3000 B.
14. CSOFTX3000 B preserves the received RLC in a 200 OK message body that it sends to
CSOFTX3000 A.
15. CSOFTX3000 A extracts the RLC from the received 200 OK and forwards the RLC to
LS A.