Sei sulla pagina 1di 69

SIP: Session Initiation Protocol

K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

Significato dei messaggi: DISCONNECT: Messaggio inviato dallutente che vuole terminare la comunicazione 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.

K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

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 dallautocommutatore dellutente 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.

K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

Significato dei messaggi: REL (Release): Messaggio inviato dallutente che vuole terminare la comunicazione 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.

K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

A confronto gli standard di segnalazione e le codifiche audio nelle reti a circuito PSTN ed a pacchetto VoIP.

K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

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 una o 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.
K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

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

K Labs S.r.l. all rights reserved

SIP: Session Initiation Protocol

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:mionome@mioDominio.it sip:mionome@151.8.2.1:5060 sip:+39-59-12345@mioGateway.com

K Labs S.r.l. all rights reserved

10

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

11

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

12

SIP: Session Initiation Protocol

Componenti principali di una rete VoIP basata sul protocollo di segnalazione SIP.

K Labs S.r.l. all rights reserved

13

SIP: Session Initiation Protocol

Larchitettura SIP prevede due componenti funzionali installati sugli User Agent: un client per effettuare le chiamate e un server per accettare le chiamate.

K Labs S.r.l. all rights reserved

14

SIP: Session Initiation Protocol

Note:

K Labs S.r.l. all rights reserved

15

SIP: Session Initiation Protocol

In figura vengono mostrate le relazioni tra le componenti funzionali per instradare una chiamata con segnalazione SIP.

K Labs S.r.l. all rights reserved

16

SIP: Session Initiation Protocol

Note:

K Labs S.r.l. all rights reserved

17

SIP: Session Initiation Protocol

Note:

K Labs S.r.l. all rights reserved

18

SIP: Session Initiation Protocol

Note:

K Labs S.r.l. all rights reserved

19

SIP: Session Initiation Protocol

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 your house, 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.
K Labs S.r.l. all rights reserved

20

SIP: Session Initiation Protocol

La prima cifra dello Status-Code definisce la classe della risposta, le ultime due cifre, il messaggio vero e proprio.

K Labs S.r.l. all rights reserved

21

SIP: Session Initiation Protocol

Note:

K Labs S.r.l. all rights reserved

22

SIP: Session Initiation Protocol

Note:

K Labs S.r.l. all rights reserved

23

SIP: Session Initiation Protocol

Servizio di registrazione REGISTER request: il client di si registra al Proxy Server per poter chiamare 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.

K Labs S.r.l. all rights reserved

24

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

25

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

26

SIP: Session Initiation Protocol

K Labs S.r.l. all rights reserved

27

SIP: Session Initiation Protocol

K Labs S.r.l. all rights reserved

28

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

29

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

30

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

31

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

32

SIP: Session Initiation Protocol

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:thisis@anonymous.invalid), 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.

K Labs S.r.l. all rights reserved

33

SIP: Session Initiation Protocol

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 To header 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.

K Labs S.r.l. all rights reserved

34

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

35

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

36

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

37

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

38

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

39

SIP: Session Initiation Protocol

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 where topologies are known by the UA.

K Labs S.r.l. all rights reserved

40

SIP: Session Initiation Protocol

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 a challenge. The proxy expects the calling party to calculate an MD5 response based on the nonce value.

K Labs S.r.l. all rights reserved

41

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

42

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

43

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

44

SIP: Session Initiation Protocol

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 UserAgent header field a configurable

K Labs S.r.l. all rights reserved

45

SIP: Session Initiation Protocol

Per RFC 3261, section 20.14: The Content-Length header field indicates the size of the messagebody, 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 streambased 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

K Labs S.r.l. all rights reserved

46

SIP: Session Initiation Protocol

Per RFC 3261, section 20.5: The Allow header field lists the set of methods supported by the UA generating 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.

K Labs S.r.l. all rights reserved

47

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

48

SIP: Session Initiation Protocol

Per RFC 3261, section 20.14: The Content-Type header field indicates the media type of the message-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).

K Labs S.r.l. all rights reserved

49

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

50

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

51

SIP: Session Initiation Protocol

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 has become the protocol of choice to describe a multimedia session and has been adopted by SIP, SGCP, MGCP, and MEGACO.

K Labs S.r.l. all rights reserved

52

SIP: Session Initiation Protocol

The version header describes changes to the SDP session. This is not used in SIP and it always 0.

K Labs S.r.l. all rights reserved

53

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

54

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

55

SIP: Session Initiation Protocol

This is the listening IP address for RTP and RTCP.

K Labs S.r.l. all rights reserved

56

SIP: Session Initiation Protocol

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

K Labs S.r.l. all rights reserved

57

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

58

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

59

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

60

SIP: Session Initiation Protocol

The packet interval, in this case 30 milliseconds.

K Labs S.r.l. all rights reserved

61

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

62

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

63

SIP: Session Initiation Protocol

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

K Labs S.r.l. all rights reserved

64

SIP: Session Initiation Protocol

Modem passthru is the transport of modem signals (modulation, error correction and compression) through a packet network using PCM encoded packets

K Labs S.r.l. all rights reserved

65

SIP: Session Initiation Protocol

Note:

K Labs S.r.l. all rights reserved

66

SIP: Session Initiation Protocol

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.

K Labs S.r.l. all rights reserved

67

SIP: Session Initiation Protocol

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

K Labs S.r.l. all rights reserved

68

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 packet contains 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, larger values 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 lasted as long as indicated by this parameter. The event may or may not have ended. For a sampling rate of 8000 Hz, this field is sufficient to express event durations of up to approximately 8 seconds.

K Labs S.r.l. all rights reserved

69

Potrebbero piacerti anche