8/6/2019 05 - SIP Session Initiation Protocol
1/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 1
8/6/2019 05 - SIP Session Initiation Protocol
2/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 2
A confronto gli elementi funzionali e le architetture delle reti
telefoniche e VoIP. Nel primo caso si realizzano connessioni a banda
stretta e costante adatte al trasporto della voce codificata in PCM a
64kb/s. Nel secondo caso si sfrutta la connettivit a pacchetto delle
reti IP normalmente utilizzate per il trasporto del traffico Internet.
Naturalmente in queste condizioni necessario applicare diverse
politiche di gestione dei flussi audio rispetto al normale traffico IP.
8/6/2019 05 - SIP Session Initiation Protocol
3/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 3
Durante linstaurazione di una chiamata ISDN occorre una serie di messaggi
scambiati fra il chiamato, la rete e il chiamante.
Significato dei messaggi:
SETUP: inviato dallutente chiamante alla rete per chiedere la connessione con il
chiamato. Il messaggio attraversa la rete e viene consegnato al chiamato.
SETUP ACKNOWLEDGE: inviato dalla rete al chiamante. Indica che la richiesta si
connessione stata inoltrata verso il chiamato, ma mancano ancora delle
informazioni per il completamento della segnalazione.
CALL PROCEEDING: inviato dalla rete al chiamante. Indica che la richiesta di
connessione stata inoltrata verso il chiamato e che le informazioni sono sufficienti.
Dopo questa operazione la connessione gi realizzata.
ALERTING: inviato dal chiamato alla rete e dalla rete al chiamante. Informa della
disponibilit potenziale del chiamato a rispondere (squillo del telefono del
chiamato, tono sullapparecchio del chiamante).
CONNECT: inviato dal chiamato alla rete e dalla rete al chiamante quando il
chiamante risponde.
CONNECT ACKNOWLEDGE: ultimo messaggio inviato dalla rete al chiamato e
successivamente dal chiamante alla rete per notificare che la chiamata stata
correttamente eseguita.
Dopo questa procedura, il canale B (o i canali B) viene reso disponibile per la
conversazione pagante.
8/6/2019 05 - SIP Session Initiation Protocol
4/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 4
Significato dei messaggi:
DISCONNECT: Messaggio inviato dallutente che vuole terminare lacomunicazione alla rete e dalla stessa allutente opposto per
manifestare la volont di concludere la comunicazione.
RELEASE: Risposta affermativa dellutente opposto al messaggio di
Disconnect.
RELEASE COMPLETE: Messaggio di conferma della disconnessione
avvenuta in risposta ad un Release tra lutente con volont di
concludere e la rete e tra la rete e lutente opposto.
8/6/2019 05 - SIP Session Initiation Protocol
5/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 5
Durante linstaurazione di una chiamata ISDN occorre una serie di
messaggi scambiati fra il chiamato, la rete e il chiamante. Ora si
analizzano i messaggi scambiati tra i nodi di rete telefonica, gli
autocommutatori numerici, i quali utilizzano il protocollo di
segnalazione SS#7.
Significato dei messaggi:
IAM (Initial Address Message): inviato dallautocommutatore
dellutente chiamante alla rete per chiedere la connessione con il
chiamato. Il messaggio attraversa la rete e viene consegnato
allautocommutatore connesso al chiamato.
ACM (Address Complete Message): inviato dallautocommutatoredellutente chiamato alla rete. Informa della disponibilit potenziale
del chiamato a rispondere (squillo del telefono del chiamato, tono
sullapparecchio del chiamante).
ANM (Answer Network Message): inviato dal chiamato alla rete e
dalla rete al chiamante quando il chiamante risponde.
8/6/2019 05 - SIP Session Initiation Protocol
6/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 6
Significato dei messaggi:
REL (Release): Messaggio inviato dallutente che vuole terminare lacomunicazione alla rete e dalla stessa allutente opposto per
manifestare la volont di concludere la comunicazione.
RLC (Release Complete): Risposta affermativa dellutente opposto al
messaggio di rilascio.
8/6/2019 05 - SIP Session Initiation Protocol
7/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 7
A confronto gli standard di segnalazione e le codifiche audio nelle reti
a circuito PSTN ed a pacchetto VoIP.
8/6/2019 05 - SIP Session Initiation Protocol
8/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 8
SIP utilizza il protocollo di trasporto UDP, la porta standard la 5060.
Il protocollo SIP ha fondamentalmente le seguenti funzioni:
Invitare gli utenti a partecipare ad una sessione:
localizzare gli utenti
acquisire le preferenze degli utenti
negoziare le capabilities
trasportare una descrizione della sessione
Instaurare le connessioni di sessione
Gestire eventuali modifiche dei parametri di sessione
Rilasciare le parti
Cancellare la sessione in qualunque momento si desideri.
SIP un protocollo text-based, orientato al Web, simile ad HTTP, con una struttura
client-server. Per instaurare una sessione, avviene un three-way handshaking
(concettualmente simile a quello che avviene con il protocollo TCP). Alcune delle
caratteristiche importanti del protocollo SIP:
impiegabile sia in contesti client-server sia in contesti peer to peer.
facilmente estendibile e programmabile
lavora sia con server stateless sia con server stateful.
indipendente dal protocollo di trasporto.
Un messaggio SIP una richiesta o una risposta; una sequenza di una richiesta e unao pi risposte detta transazione: una transazione identificabile da un
transaction-ID, un identificativo che ne specifica la sorgente, la destinazione e il
numero di sequenza.
Il protocollo SIP supporta la mobilit ed dialog-oriented: un dialogo una
relazione persistente tra entit paritetiche che si scambiano richieste e risposte in
un contesto comune.
8/6/2019 05 - SIP Session Initiation Protocol
9/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 9
SIP supporta cinque elementi informativi per lavvio e la terminazione
di una connessione:
User location: determinazione degli end system usati nella
comunicazione;
User availability: identificazione della disponibilit delle parti ad
impegnarsi in una comunicazione;
User capabilities: identificazione di media e parametri utilizzati;
Session setup: avviso, instaurazione dei parametri di una sessione su
chiamate;
Session management: trasferimento e terminazione di una sessione,modifica dei parametri della sessione, e invocazione dei servizi.
SIP non un sistema per le comunicazioni integrato verticalmente,
ma piuttosto pu essere usato come componente in altri protocolli
IETF per costruire unarchitettura multimediale completa (di solito
includono il protocollo RTP per la comunicazione trasparente in real-
time e fornitura di feedback in QoS, oppure RTSP per il controllo della
consegna di contenuti in streaming). SIP non fornisce servizi, ma
primitive per implementarli. Per esempio esso pu individuare un
utente e consegnargli un oggetto opaco alla sua locazione corrente.
8/6/2019 05 - SIP Session Initiation Protocol
10/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 10
Gli utenti SIP sono risorse identificabili o localizzabili mediante URI o
URL che contengano informazioni sul dominio, sul nome-utente,
sull'host o il numero col quale l'utente partecipa alla sessione. Gli
indirizzi sono stile e-mail. Esempi fittizi possono ad esempio essere:
sip:[email protected]:5060
8/6/2019 05 - SIP Session Initiation Protocol
11/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 11
Un messaggio SIP costituito da un'intestazione e da un corpo
(rispettivamente detti header e body). A titolo esemplificativo,
consideriamo il seguente messaggio di Invite.
8/6/2019 05 - SIP Session Initiation Protocol
12/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 12
Lheader VIA indica il percorso che il chiamante chiede di seguire al
chiamato. Esso pu essere utilizzato per prevenire dei loop e
assicurare che le risposte compiano lo stesso percorso delle richieste.
La sintassi dellheader VIA specificata nellRFC 3261.
8/6/2019 05 - SIP Session Initiation Protocol
13/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 13
Componenti principali di una rete VoIP basata sul protocollo di
segnalazione SIP.
8/6/2019 05 - SIP Session Initiation Protocol
14/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 14
Larchitettura SIP prevede due componenti funzionali installati sugli
User Agent: un client per effettuare le chiamate e un server per
accettare le chiamate.
8/6/2019 05 - SIP Session Initiation Protocol
15/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 15
Note:
8/6/2019 05 - SIP Session Initiation Protocol
16/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 16
In figura vengono mostrate le relazioni tra le componenti funzionali
per instradare una chiamata con segnalazione SIP.
8/6/2019 05 - SIP Session Initiation Protocol
17/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 17
Note:
8/6/2019 05 - SIP Session Initiation Protocol
18/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 18
Note:
8/6/2019 05 - SIP Session Initiation Protocol
19/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 19
Note:
8/6/2019 05 - SIP Session Initiation Protocol
20/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 20
SIP Requests (Methods):
ACK: RFC3261 - The final response to an invite, sent when the response code from the UAS is
200 or greater.
BYE: RFC3261 - Tears down a call.
CANCEL: RFC3261 - Used to stop a ringing phone
INFO: RFC2976 - The intent of the INFO method is to allow for the carrying of session
related control information that is generated during a session. One example of such session
control information is ISUP and ISDN signaling messages used to control telephony call
services.
INVITE: RFC3261 - Sets up the call and usually includes SDP.
MESSAGE: RFC3428 - Carries instant messages
NOTIFY: RFC3265 - A message sent when a condition occurs such as a burglar broke into yourhouse, a person logged into your buddy list, its after midnight and your daughter is not
home, etc.
OPTIONS: RFC3261 - Queries a server about the methods it supports.
PRACK: RFC3262 - Provisional ACK, sent when requested via the 100rel option tag. Provides
reliability to 100 type responses.
Publish: RFC3262 - Publishes a UAs event state within the SIP Events framework, like instant
messaging presence information
REFER: RFC3515 - Directs a UA to a specified URL.
REGISTER: RFC3261 - Conveys information about a users location to a SIP server.
SUBSCRIBE: RFC3265 - SIP nodes can request notification from remote nodes indicating that
certain events have occurred.
UPDATE: RFC3311 - UPDATE allows a client to update parameters of a session (such as the set
of media streams and their codecs) but has no impact on the state of a dialog. In that sense,
it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been
completed. This makes it very useful for updating session parameters within early dialogs.
8/6/2019 05 - SIP Session Initiation Protocol
21/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 21
La prima cifra dello Status-Code definisce la classe della risposta, le
ultime due cifre, il messaggio vero e proprio.
8/6/2019 05 - SIP Session Initiation Protocol
22/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 22
Note:
8/6/2019 05 - SIP Session Initiation Protocol
23/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 23
Note:
8/6/2019 05 - SIP Session Initiation Protocol
24/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 24
Servizio di registrazione
REGISTER request: il client di si registra al Proxy Server per poterchiamare o essere chiamato attraverso la rete.
Esempio di registrazione: lutente invia una richiesta di registrazione al
Proxy Server.
Il Proxy Server conferma o rifiuta la registrazione allo User Agent.
8/6/2019 05 - SIP Session Initiation Protocol
25/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 25
In figura viene mostrata la procedura tipica di chiamata effettuata
attraverso un proxy server.
La segnalazione tra i due user agent viene mediata dal proxy server. Il
flusso audio/video viene gestito direttamente dai due user agent.
8/6/2019 05 - SIP Session Initiation Protocol
26/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 26
In figura viene mostrata la procedura tipica di chiamata effettuata
attraverso un proxy server.
La segnalazione tra i due user agent viene mediata dal proxy server. Il
flusso audio/video viene gestito direttamente dai due user agent.
8/6/2019 05 - SIP Session Initiation Protocol
27/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 27
8/6/2019 05 - SIP Session Initiation Protocol
28/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 28
8/6/2019 05 - SIP Session Initiation Protocol
29/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 29
The first line in a SIP request is the type of the transaction. In
this case, the start line is INVITE, which includes the name of
the called party (asterisk voice mail in this case) and the SIP
version. The newest version of SIP did not change the version
field so SIP remains SIP/2.0 (SIP version 2) at the time of this
writing.
8/6/2019 05 - SIP Session Initiation Protocol
30/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 30
The Via header field indicates the path taken by the request so far and
indicates the path that should be followed in routing responses. The
branch ID parameter in the Via header field values serves as a
transaction identifier, and is used by proxies to detect loops.
A Via header field value contains the transport protocol used to send
the message, the client's host name or network address, and possibly
the port number at which it wishes to receive responses.
Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
"TLS means TLS over TCP. When a request is sent to a SIPS URI, the
protocol still indicates "SIP", and the transport protocol is TLS.
The compact form of the Via header field is v.
8/6/2019 05 - SIP Session Initiation Protocol
31/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 31
A Via header field value can also contain parameters such as "maddr",
"ttl", "received", and "branch. For implementations compliant to this
specification, the value of the branch parameter MUST start with the
magic cookie "z9hG4bK.
8/6/2019 05 - SIP Session Initiation Protocol
32/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 32
A dialog contains certain pieces of state needed for further message
transmissions within the dialog. This state consists of the dialog ID, a
local sequence number (used to order requests from the UA to its
peer), a remote sequence number (used to order requests from its
peer to the UA), a local URI, a remote URI, remote target, a boolean
flag called "secure", and a route set, which is an ordered list of URIs.
The route set is the list of servers that need to be traversed to send a
request to the peer. A dialog can also be in the "early state, which
occurs when it is created with a provisional response, and then
transition to the "confirmed" state when a 2xx final response arrives.
For other responses, or if no response arrives at all on that dialog, the
early dialog terminates.
8/6/2019 05 - SIP Session Initiation Protocol
33/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 33
The From header field indicates the logical identity of the initiator of
the request, possibly the user's address-of-record. Like the To header
field, it contains a URI and optionally a display name. It is used by SIP
elements to determine which processing rules to apply to a request
(for example, automatic call rejection). As such, it is very important
that the From URI not contain IP addresses or the FQDN of the host
on which the UA is running, since these are not logical names.
The From header field allows for a display name. A UAC SHOULD use
the display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:[email protected]), if the
identity of the client is to remain hidden.Usually, the value that populates the From header field in requests
generated by a particular UA is pre-provisioned by the user or by the
administrators of the user's local domain. If a particular UA is used by
multiple users, it might have switchable profiles that include a URI
corresponding to the identity of the profiled user. Recipients of
requests can authenticate the originator of a request in order to
ascertain that they are who their From header field claims they are.
The From field MUST contain a new "tag parameter, chosen by the
UAC.
8/6/2019 05 - SIP Session Initiation Protocol
34/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 34
The To header field first and foremost specifies the desired "logical"
recipient of the request, or the address-of-record of the user or
resource that is the target of this request. This may or may not be the
ultimate recipient of the request. The To header field MAY contain a
SIP or SIPS URI, but it may also make use of other URI schemes like
the tel URL (RFC 2806), when appropriate. All SIP implementations
MUST support the SIP URI scheme. Any implementation that
supports TLS MUST support the SIPS URI scheme. The To header field
allows for a display name.
A UAC may learn how to populate the To header field for a particular
request in a number of ways. Usually the user will suggest the Toheader field through a human interface, perhaps inputting the URI
manually or selecting it from some sort of address book. Frequently,
the user will not enter a complete URI, but rather a string of digits or
letters. It is at the discretion of the UA to choose how to interpret this
input.
A request outside of a dialog MUST NOT contain a To tag; the tag in
the To field of a request identifies the peer of the dialog. Since no
dialog is established, no tag is present.
8/6/2019 05 - SIP Session Initiation Protocol
35/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 35
A dialog is the peer-to-peer SIP relationship between two UAs. A
dialog is created as the call is being set up so that subsequent
messages can reference a specific session.
Analogy: Imagine babysitting a dozen three-year olds. You have a
dialog already existing with each child, so if one screams, you know
exactly who did it.
A UA names a dialog using a dialog ID, which consists of a Call-ID
value, a local tag and a remote tag. T he local tag at one UA is
identical to the remote tag at the peer UA.
8/6/2019 05 - SIP Session Initiation Protocol
36/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 36
The Call-ID header field acts as a unique identifier to group together a
series of messages. It MUST be the same for all requests and
responses sent by either UA in a dialog. It SHOULD be the same in
each registration from a UA.
In a new request created by a UAC outside of any dialog, the Call-ID
header field MUST be selected by the UAC as a globally unique
identifier over space and time unless overridden by method-specific
behavior. All SIP UAs must have a means to guarantee that the Call-ID
header fields they produce will not be inadvertently generated by any
other UA.
8/6/2019 05 - SIP Session Initiation Protocol
37/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 37
A dialog is the peer-to-peer SIP relationship between two UAs. A
dialog is created as the call is being set up so that subsequent
messages can reference a specific session.
Analogy: Imagine babysitting a dozen three-year olds. You have a
dialog already existing with each child, so if one screams, you know
exactly who did it.
A UA names a dialog using a dialog ID, which consists of a Call-ID
value, a local tag and a remote tag. T he local tag at one UA is
identical to the remote tag at the peer UA.
8/6/2019 05 - SIP Session Initiation Protocol
38/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 38
A dialog can also be in the "early state, which occurs when it is
created with a provisional response, and then transition to the
"confirmed" state when a 2xx final response arrives. For other
responses, or if no response arrives at all on that dialog, the early
dialog terminates.
8/6/2019 05 - SIP Session Initiation Protocol
39/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 39
The CSeq header field serves as a way to identify and order
transactions. It consists of a sequence number and a method. The
method MUST match that of the request. For non-REGISTER requests
outside of a dialog, the sequence number value is arbitrary. The
sequence number value MUST be expressible as a 32-bit unsigned
integer and MUST be less than 2**31. As long as it follows the above
guidelines, a client may use any mechanism it would like to select
CSeq header field values.
8/6/2019 05 - SIP Session Initiation Protocol
40/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 40
The Max-Forwards header field serves to limit the number of hops a
request can transit on the way to its destination. It consists of an
integer that is decremented by one at each hop. If the Max-Forwards
value reaches 0 before the request reaches its destination, it will be
rejected with a 483(Too Many Hops) error response.
A UAC MUST insert a Max-Forwards header field into each request it
originates with a value that SHOULD be 70. This number was chosen
to be sufficiently large to guarantee that a request would not be
dropped in any SIP network when there were no loops, but not so
large as to consume proxy resources when a loop does occur. Lower
values should be used with caution and only in networks wheretopologies are known by the UA.
8/6/2019 05 - SIP Session Initiation Protocol
41/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 41
A Proxy-Authenticate header field value contains an authentication
challenge.
The realm directive is required for all authentication schemes that
issue a challenge. The realm value (case-sensitive) defines the
protection space. These realms allow the protected resources on a
server to be partitioned into a set of protection spaces, each with its
own authentication scheme and/or authorization database. The realm
value is a string, generally assigned by the origin server, which may
have additional semantics specific to the authentication scheme.
The nonce value is a random value that is used only once as achallenge. The proxy expects the calling party to calculate an MD5
response based on the nonce value.
8/6/2019 05 - SIP Session Initiation Protocol
42/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 42
A Proxy-Authenticate header field value contains an authentication
challenge.
The response to the Proxy-Authenticate challenge is shown here
and is called the Proxy-Authorization. The response value shown
here is calculated using the MD5 algorithm and is based on the nonce
value sent to the calling UA. This way, the password is never sent over
the internet. Since the nonce value is always different for each call, a
replay attack will not be possible.
8/6/2019 05 - SIP Session Initiation Protocol
43/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 43
The Contact header field provides a SIP or SIPS URI that can be used
to contact that specific instance of the UA for subsequent requests.
The Contact header field MUST be present and contain exactly one
SIP or SIPS URI in any request that can result in the establishment of a
dialog. For the methods defined in this specification, that includes
only the INVITE request. For these requests, the scope of the Contact
is global. That is, the Contact header field value contains the URI at
which the UA would like to receive requests, and this URI MUST be
valid even if used in subsequent requests outside of any dialogs.
8/6/2019 05 - SIP Session Initiation Protocol
44/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 44
Per RFC 3261, section 20.19: The Expires header field gives the
relative time after which the message (or content) expires. The
precise meaning of this is method dependent. The expiration time in
an INVITE does not affect the duration of the actual session that may
result from the invitation. Session description protocols may offer the
ability to express time limits on the session duration, however. The
value of this field is an integral number of seconds (in decimal)
between 0 and (2**32)-1, measured from the receipt of the request.
8/6/2019 05 - SIP Session Initiation Protocol
45/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 45
Per RFC 3261, section 20.41: The User-Agent header field contains
information about the UAC originating the request. Revealing the
specific software version of the user agent might allow the user agent
to become more vulnerable to attacks against software that is known
to contain security holes. Implementers SHOULD make the User-
Agent header field a configurable
8/6/2019 05 - SIP Session Initiation Protocol
46/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 46
Per RFC 3261, section 20.14:
The Content-Length header field indicates the size of the message-body, in decimal number of octets, sent to the recipient. Applications
SHOULD use this field to indicate the size of the message-body to be
transferred, regardless of the media type of the entity. If a stream-
based protocol (such as TCP) is used as transport, the header field
MUST be used. The size of the message-body does not include the
CRLF separating header fields and body. Any Content-Length greater
than or equal to zero is a valid value. If no body is present in a
message, then the Content-Length header field value MUST be set to
zero
8/6/2019 05 - SIP Session Initiation Protocol
47/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 47
Per RFC 3261, section 20.5:
The Allow header field lists the set of methods supported by the UAgenerating the message.
All methods, including ACK and CANCEL, understood by the UA MUST
be included in the list of methods in the Allow header field, when
present. The absence of an Allow header field MUST NOT be
interpreted to mean that the UA sending the message supports no
methods. Rather, it implies that the UA is not providing any
information on what methods it supports.
Supplying an Allow header field in responses to methods other than
OPTIONS reduces the number of messages needed.
8/6/2019 05 - SIP Session Initiation Protocol
48/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 48
The Supported: field lists new features supported by this UA that
are beyond the core SIP protocol described in RFC 3261. Since SIP is
constantly being extended, it is necessary for UAs to exchange
capabilities so that they may be forward and backward compatible.
Option tags are identified in RFCs that extend the core SIP protocol.
An easy reference of the latest option tags is found at www.iana.org.
A UA compliant with RFC 3261 MUST only include option tags
corresponding to standards-track RFCs. If empty, it means that no
extensions are supported.
The compact form of the Supported header field is k.
8/6/2019 05 - SIP Session Initiation Protocol
49/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 49
Per RFC 3261, section 20.14:
The Content-Type header field indicates the media type of themessage-body sent to the recipient. The Content-Type header field
MUST be present if the body is not empty. If the body is empty, and a
Content-Type header field is present, it indicates that the body of the
specific type has zero length (for example, an empty audio file).
8/6/2019 05 - SIP Session Initiation Protocol
50/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 50
In figura viene mostrato il caso in cui si utilizzi un Redirect Server al
posto di un Proxy Server. Esso interviene per la sola risoluzione
dellURI nellindirizzo IP dello UAS chiamato.
8/6/2019 05 - SIP Session Initiation Protocol
51/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 51
Il protocollo SDP utilizzato per descrivere la sessione multimediale al fine di
permettere le attivit: session announcement, session invitation, e altre forme
di inizializzazione di sessioni multimediali.
Il protocollo SDP fornisce un unico formato per la descrizione della sessione, non
incorpora protocolli di trasporto, pertanto utilizza il trasporto incluso nei protocolli
ai quali offre il suo servizio: Session Announcement Protocol, Session Initiation
Protocol, Real-Time Streaming Protocol, Electronic Mail usando lestensione MIME
e il protocollo Hypertext Transport Protocol.
Le principali informazioni fornite mediante il protocollo SDP sono:
Il tipo di informazioni trasportate (video, audio, etc)
Il tipo di trasporto utilizzato per le informazioni (RTP/UDP/IP,
H.320, etc)
Il formato dellinformazione (H.261 video, MPEG video, etc).
Le modalit di realizzazione delle sessioni:
Multicast address per media
Transport Port per media
Il protocollo SDP comunemente usato da SIP per descrivere gli attributi, le
capacit di chi partecipa alla sessione SIP.
Pu essere definito come funzionalit simili al protocollo H.245.
I parametri descritti sono incapsulati in richieste SIP come testo
ASCII - UTF-8.
8/6/2019 05 - SIP Session Initiation Protocol
52/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 52
SDP (Session Description Protocol) was initially designed to support
SAP. SDPs purpose is best described by example, so imagine that you
are surfing the web and you come across a web page containing
interesting multimedia items that you can click on and listen to or
watch. The web server now needs a method to pass multimedia
session description information to your PC so that it can connect to
the remote media server. In a sense, the web page you were visiting
was behaving much like a TV Guide magazine. All the media you may
select is presented there. Behind each of those items was SDP that
described to your PC how to connect to the media server.
Because SDP is so simple, compact, and amazingly thorough, it hasbecome the protocol of choice to describe a multimedia session and
has been adopted by SIP, SGCP, MGCP, and MEGACO.
8/6/2019 05 - SIP Session Initiation Protocol
53/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 53
The version header describes changes to the SDP session. This is not
used in SIP and it always 0.
8/6/2019 05 - SIP Session Initiation Protocol
54/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 54
The originator field serves two purposes. First, it is a globally unique
field that indicates the originator of the SDP. Secondly, it can carry
additional information by disassembling the tuple.
Incidentally, a tuple is a creative shortcut used by programmers to
create a unique identifier that if disassembled yields additional
meaning.
8/6/2019 05 - SIP Session Initiation Protocol
55/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 55
This usually means nothing to us. It is always s=- This made sense if
ABC was multicasting a TIVO message that LOST will be aired at a
different time. Since this is a telephone class, this has little value for
us.
8/6/2019 05 - SIP Session Initiation Protocol
56/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 56
This is the listening IP address for RTP and RTCP.
8/6/2019 05 - SIP Session Initiation Protocol
57/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 57
This is the start and end time of this session. Often this is ignored.
8/6/2019 05 - SIP Session Initiation Protocol
58/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 58
This is the listening port address and codecs supported by this call.
This is not the entire story, however. You must check for a sendonly,
recvonly, sendrecv, or inactive in the a= headers to see if this port is
actually functional.
8/6/2019 05 - SIP Session Initiation Protocol
59/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 59
The a=rtpmap maps a payload type identifier to a specific codec. RFC
1890 set up a sample mapping of payload numbers to actual CODEC
meaning, which seems to be surviving even to this day. Using the
process to map a meaning to each payload type makes RTP payload
identifiers future safe as newer and better codecs become available.
8/6/2019 05 - SIP Session Initiation Protocol
60/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 60
This was already explained in detail in the RTP section. This example
indicates that digits [0-D*#] and hookswitch flash can be conveyed
using RFC 2833 tactics.
8/6/2019 05 - SIP Session Initiation Protocol
61/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 61
The packet interval, in this case 30 milliseconds.
8/6/2019 05 - SIP Session Initiation Protocol
62/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 62
This is what we were looking for when we first read the m= header.
An indication of sendrecv means this UA is ready to process RTP on all
CODECs, simultaneously.
8/6/2019 05 - SIP Session Initiation Protocol
63/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 63
Scenario di una rete radiomobile integrata. Si notino le interfacce di
backbone 2G e 3G convergenti su una segnalazione basata su SIP-T e
su un trasporto basato su interfacce ATM o IP.
8/6/2019 05 - SIP Session Initiation Protocol
64/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 64
Modem relay involves demodulating the modem signal at ingress
gateway
Passing this data as packet data to terminating gateway
Re-modulating the data and passes it to the receiving modem
8/6/2019 05 - SIP Session Initiation Protocol
65/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 65
Modem passthru is the transport of modem signals (modulation,
error correction and compression) through a packet network using
PCM encoded packets
8/6/2019 05 - SIP Session Initiation Protocol
66/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 66
Note:
8/6/2019 05 - SIP Session Initiation Protocol
67/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 67
1. The Terminating GW detects a fax V.21 flag sequence and sends an
INVITE with T.38 details in the SDP field to the Originating GW or to
the SIP proxy server, depending on the network topology.
2. The Originating GW receives the INVITE message and sends back a
200 OK message.
3. The Terminating GW acknowledges the 200 OK message and sends
an ACK message direct to the Originating GW.
4. The Originating GW starts sending T.38 UDP packets instead of
VoIP UDP packets across the same ports.
5. At the end of the fax transmission, another INVITE message can be
sent to return to VoIP mode.
8/6/2019 05 - SIP Session Initiation Protocol
68/69
SIP: Session Initiation Protocol
K Labs S.r.l. all rights reserved 68
In TDM world, all voice traffic is sent as uncompressed 64Kbs PCM
streams; anything sent on that circuit is an untouched stream of bits;
(e.g., voice speech, modem tones, fax tones, and DTMF digits)
DSP (Digital Signal Processor) codecs designed to interpret human
speech, can distort DTMF tones (machine-tones)
High b/w codecs less likely to distort
Distortion causes problems with voicemail and IVR (Interactive
Voice Response) systems
8/6/2019 05 - SIP Session Initiation Protocol
69/69
SIP: Session Initiation Protocol
EVENT: The events are encoded as shown in figure.
E: If set to a value of one, the "end" bit indicates that this packetcontains the end of the event. Thus, the duration parameter above
measures the complete duration of the event.
R: This field is reserved for future use. The sender MUST set it to zero,
the receiver MUST ignore it.
VOLUME: For DTMF digits and other events representable as tones,
this field describes the power level of the tone, expressed in dBm0
after dropping the sign. Power levels range from 0 to -63 dBm0. The
range of valid DTMF is from 0 to -36 dBm0 (must accept); lower than -
55 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). Thus, largervalues denote lower volume. This value is defined only for DTMF
digits. For other events, it is set to zero by the sender and is ignored
by the receiver.
DURATION: Duration of this digit, in timestamp units. Thus, the event
began at the instant identified by the RTP timestamp and has so far