05 - SIP Session Initiation Protocol

8/6/2019 05 - SIP Session Initiation Protocol

1/69

SIP: Session Initiation Protocol

K Labs S.r.l. all rights reserved 1


2/69



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.


3/69



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.


4/69




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.


5/69



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.


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.


6/69




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.


7/69



A confronto gli standard di segnalazione e le codifiche audio nelle reti

a circuito PSTN ed a pacchetto VoIP.


8/69



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.


9/69



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.


10/69



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]

sip:[email protected]:5060

sip:[email protected]


11/69



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.


12/69



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.


13/69



Componenti principali di una rete VoIP basata sul protocollo di

segnalazione SIP.


14/69



Larchitettura SIP prevede due componenti funzionali installati sugli

User Agent: un client per effettuare le chiamate e un server per

accettare le chiamate.


15/69



Note:


16/69



In figura vengono mostrate le relazioni tra le componenti funzionali

per instradare una chiamata con segnalazione SIP.


17/69



Note:


18/69



Note:


19/69



Note:


20/69



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.


21/69



La prima cifra dello Status-Code definisce la classe della risposta, le

ultime due cifre, il messaggio vero e proprio.


22/69



Note:


23/69



Note:


24/69



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.


25/69



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.


26/69



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.


27/69




28/69




29/69



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.


30/69



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.


31/69



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.


32/69



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.


33/69



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.


34/69



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.


35/69



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.


36/69



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.


37/69



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.


38/69



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.


39/69



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.


40/69



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.


41/69



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.


42/69



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.


43/69



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.


44/69



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.


45/69



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


46/69



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


47/69




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.


48/69



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.


49/69




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).


50/69



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.


51/69



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.


52/69



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.


53/69



The version header describes changes to the SDP session. This is not

used in SIP and it always 0.


54/69



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.


55/69



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.


56/69



This is the listening IP address for RTP and RTCP.


57/69



This is the start and end time of this session. Often this is ignored.


58/69



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.


59/69



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.


60/69



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.


61/69



The packet interval, in this case 30 milliseconds.


62/69



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.


63/69



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.


64/69



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


65/69



Modem passthru is the transport of modem signals (modulation,

error correction and compression) through a packet network using

PCM encoded packets


66/69



Note:


67/69



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.


68/69



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


69/69


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

Documents

05 - SIP Session Initiation Protocol