SIP Core

Information about SIP, Servers and operations and client config

1. - What is SIP

SIP 

SIP RFC 3261 
SIP is an application-layer control protocol that can establish,
   modify, and terminate multimedia sessions (conferences) such as
   Internet telephony calls.  SIP can also invite participants to
   already existing sessions, such as multicast conferences.  Media can
   be added to (and removed from) an existing session.  SIP
   transparently supports name mapping and redirection services, which
   supports personal mobility [27] - users can maintain a single
   externally visible identifier regardless of their network location.

   SIP supports five facets of establishing and terminating multimedia
   communications:

      User location: determination of the end system to be used for
           communication;

      User availability: determination of the willingness of the called
           party to engage in communications;

      User capabilities: determination of the media and media parameters
           to be used;

      Session setup: "ringing", establishment of session parameters at
           both called and calling party;

      Session management: including transfer and termination of
           sessions, modifying session parameters, and invoking
           services.

   SIP is not a vertically integrated communications system.  SIP is
   rather a component that can be used with other IETF protocols to
   build a complete multimedia architecture.  Typically, these
   architectures will include protocols such as the Real-time Transport
   Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and
   providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC
   2326 [29]) for controlling delivery of streaming media, the Media
   Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling
   gateways to the Public Switched Telephone Network (PSTN), and the
   Session Description Protocol (SDP) (RFC 2327 [1]) for describing
   multimedia sessions.  Therefore, SIP should be used in conjunction
   with other protocols in order to provide complete services to the
   users.  However, the basic functionality and operation of SIP does
   not depend on any of these protocols.

   SIP does not provide services.  Rather, SIP provides primitives that
   can be used to implement different services.  For example, SIP can
   locate a user and deliver an opaque object to his current location.
   If this primitive is used to deliver a session description written in
   SDP, for instance, the endpoints can agree on the parameters of a
   session.  If the same primitive is used to deliver a photo of the
   caller as well as the session description, a "caller ID" service can
   be easily implemented.  As this example shows, a single primitive is
   typically used to provide several different services.

   SIP does not offer conference control services such as floor control
   or voting and does not prescribe how a conference is to be managed.
   SIP can be used to initiate a session that uses some other conference
   control protocol.  Since SIP messages and the sessions they establish
   can pass through entirely different networks, SIP cannot, and does
   not, provide any kind of network resource reservation capabilities.

   The nature of the services provided make security particularly
   important.  To that end, SIP provides a suite of security services,
   which include denial-of-service prevention, authentication (both user
   to user and proxy to user), integrity protection, and encryption and
   privacy services.

   SIP works with both IPv4 and IPv6.

More on RFC 3261 SIP

https://datatracker.ietf.org/doc/html/rfc3261

image.png

2.- SIP User Agents

User Agents

A SIP (Session Initiation Protocol) user agent is a software application that runs on a device and communicates with other devices using the SIP protocol. A user agent can act as a client, a server, or both.

There are two types of SIP user agents: User Agent Client (UAC) and User Agent Server (UAS).

A User Agent Client (UAC) is a SIP endpoint that initiates a SIP session. The UAC sends SIP requests to other SIP user agents, such as a User Agent Server (UAS), to establish a session. The UAC is responsible for generating the SIP requests, processing responses, and terminating the session.

A User Agent Server (UAS) is a SIP endpoint that responds to SIP requests. When a UAS receives a SIP request, it generates a SIP response that is sent back to the requesting user agent. The UAS is responsible for processing the SIP requests, generating the SIP responses, and maintaining the session.

Both UAC and UAS can be implemented as separate software applications or combined into a single application. For example, a softphone application can act as both a UAC and a UAS, allowing users to initiate and receive calls using SIP.

In addition to UACs and UASs, there are other types of SIP user agents, such as a Proxy Server, which forwards SIP messages between user agents, and a Redirect Server, which redirects SIP messages to other servers or user agents.

3.- SIP Addressing and URI

SIP Addressing

In SIP (Session Initiation Protocol), addressing is used to identify the endpoints of a SIP session. SIP addressing is based on the use of SIP Uniform Resource Identifiers (URIs), which are used to identify the SIP endpoints.

URI

A SIP URI (Uniform Resource Identifier) is a string of characters that identifies a SIP (Session Initiation Protocol) endpoint or user on the Internet or another IP network. It is similar to a URL (Uniform Resource Locator) that identifies a web page or resource, but instead of identifying a web page, a SIP URI identifies a user or device that can participate in a SIP session.

sip:user@domain.com

The sip: prefix indicates that this is a SIP URI. The user part of the URI identifies the user or device within the domain, and the domain.com part of the URI identifies the domain name of the endpoint.

In addition to the user and domain parts of the URI, SIP URIs can also contain other parameters, such as port numbers and transport protocols. For example, a SIP URI for an endpoint using the secure transport protocol over port 5061 would look like this:

sips:user@domain.com:5061;transport=TLS

SIP addressing can also include other elements such as the SIP message header fields, which provide additional information about the session, including the address of the sender and receiver, the type of session being initiated, and other session-specific information.

The SIP addressing scheme is flexible, allowing for the identification of a wide variety of SIP endpoints, including phones, softphones, SIP servers, and other SIP-capable devices.

Here are more examples of URI

sip:alice@domain.com - This SIP URI identifies a SIP endpoint with the username "alice" located at the domain "domain.com". This endpoint could be a softphone application running on Alice's computer or a physical SIP phone connected to the network.

sip:bob@192.168.1.100:5060 - This SIP URI identifies a SIP endpoint with the username "bob" located at the IP address "192.168.1.100" and using port 5060. This endpoint could be a physical SIP phone or a SIP server running on a computer.

sip:conference@domain.com;transport=tcp - This SIP URI identifies a SIP conference server located at the domain "domain.com" that uses the TCP transport protocol. Users could dial into this conference by sending SIP INVITE messages to this URI.

In all of these examples, the "sip:" prefix indicates that this is a SIP URI. The username (e.g. "alice", "bob", "conference") identifies the endpoint or resource being addressed, and the domain (e.g. "domain.com", "192.168.1.100") identifies the network location of the endpoint. In example 2, a port number is also specified. Additionally, example 3 demonstrates how SIP URIs can contain other parameters, in this case specifying the use of the TCP transport protocol.

 

The goal of SIP addressing is to identify SIP endpoints and resources on the network for routing SIP messages.

+-------------+                       +-------------+
| User A      |                       | User B      |
| SIP Address |                       | SIP Address |
| 192.0.2.1   |                       | 192.0.2.2   |
| SIP URI     |                       | SIP URI     |
| sip:userA@192.0.2.1:5060;transport=UDP | sip:userB@192.0.2.2:5060;transport=UDP |
+-------------+                       +-------------+
        |                                          |
        |  INVITE                                  |
        |  sip:userB@192.0.2.2:5060 SIP/2.0        |
        |  Via: SIP/2.0/UDP 192.0.2.1:5060         |
        |  From: sip:userA@192.0.2.1:5060;tag=1234 |
        |  To: sip:userB@192.0.2.2:5060            |
        |  Call-ID: 5678                           |
        |  CSeq: 1 INVITE                          |
        |  Contact: sip:userA@192.0.2.1:5060       |
        |  Content-Type: application/sdp           |
        |  Content-Length: 150                     |
        |                                          |
        |---------------------------------------->|
        |                                          |
        |  100 Trying                              |
        |  SIP/2.0 100 Trying                      |
        |  Via: SIP/2.0/UDP 192.0.2.2:5060         |
        |  From: sip:userA@192.0.2.1:5060;tag=1234 |
        |  To: sip:userB@192.0.2.2:5060;tag=5678   |
        |  Call-ID: 5678                           |
        |  CSeq: 1 INVITE                          |
        |  Content-Length: 0                       |
        |                                          |
        |<-----------------------------------------|
        |                                          |
        |  200 OK                                  |
        |  SIP/2.0 200 OK                          |
        |  Via: SIP/2.0/UDP 192.0.2.2:5060         |
        |  From: sip:userA@192.0.2.1:5060;tag=1234 |
        |  To: sip:userB@192.0.2.2:5060;tag=5678   |
        |  Call-ID: 5678                           |
        |  CSeq: 1 INVITE                          |
        |  Contact: sip:userB@192.0.2.2:5060       |
        |  Content-Type: application/sdp           |
        |  Content-Length: 150                     |
        |                                          |
        |<-----------------------------------------|
        |                                          |
        |  ACK                                     |
        |  sip:userB@192.0.2.2:5060 SIP/2.0        |
        |  Via: SIP/2.0/UDP 192.0.2.1:5060         |
        |  From: sip:userA@192.0.2.1:5060;tag=1234 |
        |  To: sip:userB@192.0.2.2:5060;tag=5678   |
        |  Call-ID: 5678                           |
        |  CSeq: 1 ACK

4. - SIP Servers

SIP Servers

SIP Registration server

A SIP registration server is responsible for authenticating and registering SIP users or endpoints with a SIP server. It acts as a central database for storing user information, including their SIP addresses, phone numbers, IP addresses, and other relevant information. When a SIP user wants to make a call, they first register with the SIP registration server, which sends a notification to the SIP server that the user is available. The SIP server then routes the call to the appropriate user based on their SIP address. The SIP registration server is crucial for enabling SIP-based communications, as it allows SIP users to locate and communicate with one another over the internet.

When SIP UA Registers with a registrar it tells the registrar about its feature capabilities. This is really useful information for SIP devices to make contact with the UA.

SIP RE-Registration Server

A SIP re-registration server is a server that allows SIP devices to re-register their contact information periodically. SIP devices usually send registration requests to a SIP registration server to inform it of their current IP address and availability to receive calls. However, if the IP address of the SIP device changes or it becomes unavailable for some reason, the registration information needs to be updated. A re-registration server helps to automate this process by periodically sending a SIP re-registration request to the SIP devices. If the device responds with a new contact address, the registration server updates its records accordingly. This ensures that the SIP devices can always be reached by other users and devices in the network, even if their IP address changes or they go offline temporarily.

SIP Proxy Server

A SIP proxy server is an intermediary device that sits between SIP user agents (UAs) to facilitate communication between them. It receives SIP requests from one UA, inspects them, and forwards them to the appropriate destination UA. It can modify the request headers or body as necessary and may also provide services like call routing, load balancing, and security. A proxy server can be located within a private network or in the public domain.

Other examples of SIP Proxy
 Trapezoid Model

The SIP Proxy Trapezoid model is a reference model for SIP networks that defines the different types of SIP proxy servers and their relationships. The model consists of four layers: User Agents (UA), Proxy Servers, Redirect Servers, and Location Servers.

The UA layer contains user agents, which initiate SIP requests and responses. The Proxy Server layer includes stateful and stateless proxies, which act as intermediaries between UAs and other SIP entities. The Redirect Server layer includes servers that redirect SIP requests to other destinations based on specific rules.

The Location Server layer includes SIP location servers, which maintain information about the current location of UAs within the network. The trapezoid shape of the model represents the different levels of trust in the network, with the UA layer being the most trusted and the Location Server layer being the least trusted.

The SIP Proxy Trapezoid model is useful for understanding the different types of SIP proxy servers and their roles in the network. It can also help network administrators design and implement SIP networks that are secure and efficient.

image.png

Proxy mode

SIP server acts as an intermediary between clients in a SIP network. It receives SIP requests from one client and then forwards them to the appropriate destination client. The proxy server can manipulate the message headers and routing information to control the flow of the SIP messages. It can also provide services such as call routing, policy enforcement, security, and protocol translation. The proxy server can be stateful or stateless, depending on whether it maintains the state of the SIP transactions it handles. A stateful proxy server provides more advanced features and services but requires more resources to maintain the state information.

image.png

Proxy Redirect Mode

A server in proxy redirect mode acts as a middleman that receives a SIP request from a client and sends a redirect response to the client, which contains the address of the next hop server that the client should contact to complete the request. The proxy redirect server does not actively participate in the transaction beyond sending the redirect response. Instead, it relies on the client to initiate a new transaction with the next hop server specified in the redirect response. The proxy redirect server can be used to offload traffic from one server to another or to provide load balancing across multiple servers.

 

image.png

Types of Proxy Server

  1. Stateful proxy server: A stateful proxy server maintains the transaction state and message history for all transactions that pass through it. This allows it to make more informed routing decisions, but also requires more processing power and memory.

  2. Stateless proxy server: A stateless proxy server does not maintain any transaction state or message history. It simply forwards messages based on routing rules. This makes it faster and less resource-intensive, but also less flexible.

  3. Transaction Stateful: They store information about the SIP messages exchanged between the clients and servers and maintain the session state until the transaction is complete.

  4. B2BUA (Back-to-Back User Agent): A B2BUA is a type of SIP proxy server that acts as both a client and a server, allowing it to manipulate the SIP messages as they pass through it. This makes it useful for applications such as call forwarding, where the B2BUA can modify the destination of the call based on user preferences or availability.

SIP Location Server

Is a type of server in a SIP network that keeps track of the current location or address of SIP user agents (UAs) in the network. It is responsible for maintaining a database of user agent location information, which can be used by other SIP servers to locate and communicate with those user agents. The location server uses the SIP REGISTER method to receive location updates from the user agents and stores the information in a location database. When another SIP server needs to communicate with a user agent, it can query the location server for the user agent's current address and then forward messages to that address.

image.png

image.png

image.png

5. - SIP Clients

SIP Clients

SIP clients are software applications that run on devices such as computers, smartphones, or tablets and allow users to make and receive SIP-based voice, video, and messaging communications over the internet. They use SIP protocol to establish, maintain and terminate multimedia sessions between two or more parties. SIP clients can be standalone applications, web-based or integrated into other software such as email clients or instant messaging applications. Examples of SIP clients include softphones, web-based clients, and mobile apps.

They all need to be configured with parameters in order to register.

6. - SIP Messages

SIP messages are the communication units used by SIP endpoints to establish, modify, and terminate multimedia sessions. SIP messages are exchanged between SIP user agents, proxy servers, and redirect servers, and are used to initiate and control communication sessions between two or more parties. The messages consist of a request or response line, message headers, and a message body, and are used to exchange information about the session, including media types, codecs, addresses, and authentication credentials. SIP messages can be sent over UDP, TCP, or TLS transport protocols.

 

Here are some examples of a SIP message

SIP Invite Message

INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK123456789
From: Alice <sip:alice@example.com>;tag=987654321
To: Bob <sip:bob@example.com>
Call-ID: 123456789@192.168.1.100
CSeq: 1 INVITE
Contact: <sip:alice@192.168.1.100>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 100

v=0
o=- 123456789 123456789 IN IP4 192.168.1.100
s=Session
c=IN IP4 192.168.1.100
t=0 0
m=audio 5004 RTP/AVP 0
a=rtpmap:0 PCMU/8000

SIP OK Message

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK123456789;received=192.168.1.100
From: Alice <sip:alice@example.com>;tag=987654321
To: Bob <sip:bob@example.com>;tag=123456789
Call-ID: 123456789@192.168.1.100
CSeq: 1 INVITE
Contact: <sip:bob@192.168.1.101>
Content-Type: application/sdp
Content-Length: 100

v=0
o=- 123456789 123456789 IN IP4 192.168.1.101
s=Session
c=IN IP4 192.168.1.101
t=0 0
m=audio 5004 RTP/AVP 0
a=rtpmap:0 PCMU/8000

SIP Notify Message

NOTIFY sip:alice@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:5060;branch=z9hG4bK987654321
From: Bob <sip:bob@example.com>;tag=123456789
To: Alice <sip:alice@example.com>;tag=987654321
Call-ID: 987654321@192.168.1.101
CSeq: 1 NOTIFY
Event: message-summary
Subscription-State: terminated;reason=noresource
Content-Length: 0

SIP Prack Message

PRACK sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK123456789
From: Alice <sip:alice@example.com>;tag=987654321
To: Bob <sip:bob@example.com>;tag=123456789
Call-ID: 123456789@192.168.1.100
CSeq: 1 PRACK
Max-Forwards: 70
Content-Length: 0

7. - SIP Messages - Requests Methods

SIP request methods are used to initiate a request from a client to a server or from one server to another server in a distributed network. The SIP request methods are similar to HTTP methods and are used to perform different functions such as establishing, modifying, and terminating a session. Some of the common SIP request methods include:

INVITE
 Used to initiate a session or invite another user to participate in a session or session modification
ACK
 Sent by the client to confirm that it has received a final response to its INVITE request, ACK is only used with Invite requests including re-invites.
BYE
 Used to terminate an existing session.
CANCEL
 Used to cancel an outstanding request or pending request.
REGISTER
 Used by a client to register its contact address with a registrar server bby binding the Agent URI to an AOR (address of record) so the sip seerver knows the location of the user agent.
OPTIONS
 Used by SIP User Agents (UAs) to query a server or another UA for its capabilities and determine what SIP methods and extensions it supports. It is a way for SIP UAs to discover what services are available from the server or UA and what methods can be used to access them. The OPTIONS method is usually sent without a request body, and the response from the server or UA will include information about its supported methods, extensions, and capabilities. The OPTIONS method is often used to determine if a server or UA is available and responsive, and to verify that it supports certain features before attempting to use them.
INFO
 The SIP INFO method is used to carry session-related control information that cannot be carried by other SIP methods. This method is used to send mid-session signaling information within an existing SIP session, such as DTMF (Dual Tone Multi-Frequency) digits or an update to session parameters. The INFO method does not modify the session state or the dialog state. It is a simple request/response method, where the recipient of the INFO message responds with a 200 OK message to acknowledge receipt of the message. The INFO message is commonly used in Voice over IP (VoIP) applications, particularly in interactive voice response (IVR) systems.
SUBSCRIBE
 Used to request notification of an event or set of events at a later time. An example can be requesting a notification when another person IM Presence details change. The server sends a SIP 200 OK response message to confirm the subscription, along with the current state of the event. The server then sends a NOTIFY message to the client whenever the event state changes. The NOTIFY message contains the updated state of the event and other relevant information.The client can unsubscribe from the event notifications by sending a SIP UNSUBSCRIBE request message to the server. The server sends a SIP 200 OK response message to confirm the unsubscription. The client can also renew the subscription by sending a new SUBSCRIBE request message before the subscription expires.
NOTIFY
 Used to notify that an event which was requested by an earlier SUBSCRIBE method has actually ocurred. It can also be used by a SIP server to NOTIFY a client of an event. The NOTIFY message contains a payload that describes the event, and it is sent in response to a subscription request made by the client using the SIP SUBSCRIBE method. The NOTIFY message is also used in the context of the SIP event notification framework, which allows for the subscription and notification of events using specific event packages. When a client receives a NOTIFY message, it can take appropriate action based on the information contained in the message.
REFER 
 Used to Transfer calls and also to contact external resources, the REFER message contains a URI identifying the new target for the call transfer. The server receiving the REFER message will create a new INVITE request to the new target and then try to establish a new call between the transferee and the new target. Once the new call is established, the server will send a SIP NOTIFY message to the transferor indicating the status of the call transfer. If the transfer is successful, the NOTIFY message will contain a 200 OK response. If the transfer is not successful, the NOTIFY message will contain a different response code indicating the reason for the failure.
PRACK
 Used to acknowledge the receipt of a provisional response (1xx) to a SIP INVITE request. PRACK is used to confirm that the user agent has received a provisional response and is ready to receive the final response for the request. Each provisional response (from a UAS - e.g. a 183 session in progress) is given a sequence number, carried in the RSeq header field in the response. THE PRACK messages (from the UAC) contain a RAck heeader field, which indicates the sequencee number of the provisional response that is beingg acknowledged. PRACK messages can be used in scenarios where reliability is important, such as when using SIP over unreliable transport protocols like UDP. PRACK messages can also include a body that contains an offer or an answer to a session description protocol (SDP) negotiation. The PRACK message is part of the SIP protocol and is defined in RFC 3262
UPDATE
 Used to modify the state of a session without creating a new one. It is typically used to update the session parameters such as media characteristics or session description. An UPDATE request is sent to the UAS that is involved in the session, and it includes the new session description with the updated parameters. The UAS responds with a 200 OK message, indicating that the session has been updated successfully. The UPDATE method is a reliable method and requires a reliable transport such as TCP. It can also be used to update the session timers or to cancel a pending offer.
SERVICE
 Can carry a Simple object access protocol (SOAP) message as it's payload. SOAP is a lightweight protocol that defines a framework for encoding request and response messages in XML.
BENOTIFY
 also known as Best Effort NOTIFY is used by Microsoft Lync, LCS and OCS communication products, unlike the notify method, BENOTIFY doesnt require a response as applications may no need a notify reesponse to a certain requeest thus reducing SIP signaling traffic. This is important for deployments with large numbers of clients per Lync, LCS, or OCS Server.
COMET
 Used to confirm that conditions to make the connection have been met, such as QoS requirements.

8. - SIP Messages - Response Codes

SIP response codes are made up of 3 digits, first digit in the code indicates the class of the response and the other two digits are used to represent a reason or 'reason phrase'.

 

1XX
 This is an informational response. The request was received and is still being processed
2XX
 A 2XX response is a success response, the action was received understood and accepted.
3XX
 A 3XX response is a redirection response, further action needs to be taken in order to complete the request.
4XX
 A 4XX response is a client error response, for some reason (such as bad syntax) the request cannot be fulfilled at this server.
5XX
 A 5XX response is a server error response, for some reason the server cannot fulfill a valid request.
6XX
 A 6XX response is a global error, the request being made is invalid at any server.

 

 

1xx = Informational SIP responses

2xx = Success responses

3xx = Redirection responses

4xx = Request failures

5xx = Server errors

6xx = Global failures

9. - SIP Header

A sip message looks like an HTTP message

here is an example of a SIP header.

 

INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: <sip:user@example.com>
From: "John" <sip:john@example.com>;tag=4234235
Call-ID: 985673242@192.168.0.10
CSeq: 1 INVITE
Contact: <sip:john@192.168.0.10:5060>
Content-Type: application/sdp
Content-Length: 142

v=0
o=- 2304919776 2304919776 IN IP4 192.168.0.10
s=SDP Seminar
c=IN IP4 192.168.0.10
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

This is an example of a SIP INVITE message, which is used to initiate a session between two SIP endpoints. The header contains various fields that provide information about the message, including the sender and recipient addresses, a unique call ID, the type of message, and any session description information in the SDP (Session Description Protocol) body.

Here is another example with more details

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
User-Agent: model300/7.6.9
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,NOTIFY,SUBSCRIBE
Allow-Events: talk,hold,refer
Session-Expires: 3600;refresher=uas
Content-Type: application/sdp
Content-Length: 142

 

Here is the 200 Response
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds;received=192.0.2.1;rport=5060
To: Bob <sip:bob@biloxi.com>;tag=9fxced76sl
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4:5060>
User-Agent: server500/2.0.3
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,NOTIFY,SUBSCRIBE
Allow-Events: talk,hold,refer
Session-Expires: 1800;refresher=uac
Record-Route: <sip:192.0.2.100;lr=on>
Content-Type: application/sdp
Content-Length: 238

v=0
o=bob 2890844526 2890844526 IN IP4 192.0.2.4
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

 

 

Remember that in the header the Via, From, To, Call-ID, CSeq are copied exactly from request.
TO and FROM are NOT swapped around in Request and Response headers!

Alice -> Bob:  INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>

10. - SIP SDP - Session Descripton Protocol

SIP SDP

SIP SDP stands for Session Description Protocol and is a protocol used to describe multimedia sessions for the purposes of session initiation, control, and management. In the context of SIP, SDP is typically used in the body of SIP messages to describe the characteristics of media streams being offered or negotiated in a SIP session. This includes information such as the type of media, codec, bandwidth, and IP addresses and ports for the media streams. SDP is an important part of the SIP protocol because it allows endpoints to negotiate and establish media sessions for audio, video, and other types of multimedia content.

There are a lot of fieldes availabble in SDP and some are mandatory (shown here in blue). New fields can be added as needed. if an agent doesn't understand a field it simply ignores it.

image.png

MIME

MIME stands for Multipurpose Internet Mail Extensions, which is a standard that extends the format of email messages to support text in character sets other than ASCII, as well as attachments of audio, video, images, and application programs. In the context of SIP SDP (Session Description Protocol), MIME is used to specify the media type and format of the SDP body in the SIP message. The MIME type for SDP is "application/sdp". The SDP body contains information about the media streams to be used for the session, such as the codecs, transport protocols, and media formats to be used. The MIME type allows the receiving endpoint to determine how to handle the SDP body in the SIP message.

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
User-Agent: BriaX 3.5.5 build 81887
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Allow-Events: presence, message-summary, refer, dialog
Session-Expires: 3600;refresher=uas
Content-Type: application/sdp
Content-Length: 283

v=0
o=- 123456 789012 IN IP4 pc33.atlanta.com
s=SIP Call
c=IN IP4 192.0.2.1
t=0 0
m=audio 49170 RTP/AVP 0 8 18 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
m=video 49172 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000

In this example, the header includes the following fields:

Expand to view Header description


The SDP message in the body of the request describes the media capabilities of the sender and includes the following information:

RTPMAP

In the context of SDP, RTPMAP (RTP Mapping) is an attribute used to map a particular codec to an RTP payload type number. RTP is the Real-time Transport Protocol, which is used to transmit audio and video over IP networks. RTP uses payload types to identify the format of the data being transmitted.

The RTPMAP attribute provides a way for the sender to signal the receiver about the payload type numbers and the corresponding codecs being used. The attribute specifies the encoding name, the clock rate of the codec, and the number of audio channels being transmitted.

The syntax for the RTPMAP attribute is as follows:

a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]

where:

Here is an example of an RTPMAP attribute for G.711 mu-law audio:

a=rtpmap:0 PCMU/8000

This specifies that payload type 0 is used for G.711 mu-law audio, with a clock rate of 8000 Hz.

Overall, RTPMAP is an important attribute in SDP as it allows the sender and receiver to negotiate and agree upon the codec to be used for transmitting the media.

All RTPMAP codecs


Payload type (PT) Name Type No. of channels Clock rate (Hz)[note 1] Frame size (byte) Default packet interval (ms) Description References
0 PCMU audio 1 8000 any 20 ITU-T G.711 PCM μ-Law audio 64 kbit/s RFC 3551
1 reserved (previously FS-1016 CELP) audio 1 8000     reserved, previously FS-1016 CELP audio 4.8 kbit/s RFC 3551, previously RFC 1890
2 reserved (previously G721 or G726-32) audio 1 8000     reserved, previously ITU-T G.721 ADPCM audio 32 kbit/s or ITU-T G.726 audio 32 kbit/s RFC 3551, previously RFC 1890
3 GSM audio 1 8000 20 20 European GSM Full Rate audio 13 kbit/s (GSM 06.10) RFC 3551
4 G723 audio 1 8000 30 30 ITU-T G.723.1 audio RFC 3551
5 DVI4 audio 1 8000 any 20 IMA ADPCM audio 32 kbit/s RFC 3551
6 DVI4 audio 1 16000 any 20 IMA ADPCM audio 64 kbit/s RFC 3551
7 LPC audio 1 8000 any 20 Experimental Linear Predictive Coding audio 5.6 kbit/s RFC 3551
8 PCMA audio 1 8000 any 20 ITU-T G.711 PCM A-Law audio 64 kbit/s RFC 3551
9 G722 audio 1 8000[note 2] any 20 ITU-T G.722 audio 64 kbit/s RFC 3551 - Page 14
10 L16 audio 2 44100 any 20 Linear PCM 16-bit Stereo audio 1411.2 kbit/s,[2][3][4] uncompressed RFC 3551, Page 27
11 L16 audio 1 44100 any 20 Linear PCM 16-bit audio 705.6 kbit/s, uncompressed RFC 3551, Page 27
12 QCELP audio 1 8000 20 20 Qualcomm Code Excited Linear Prediction RFC 2658, RFC 3551
13 CN audio 1 8000     Comfort noise. Payload type used with audio codecs that do not support comfort noise as part of the codec itself such as G.711, G.722.1, G.722, G.726, G.727, G.728, GSM 06.10, Siren, and RTAudio. RFC 3389
14 MPA audio 1, 2 90000 8–72   MPEG-1 or MPEG-2 audio only RFC 3551, RFC 2250
15 G728 audio 1 8000 2.5 20 ITU-T G.728 audio 16 kbit/s RFC 3551
16 DVI4 audio 1 11025 any 20 IMA ADPCM audio 44.1 kbit/s RFC 3551
17 DVI4 audio 1 22050 any 20 IMA ADPCM audio 88.2 kbit/s RFC 3551
18 G729 audio 1 8000 10 20 ITU-T G.729 and G.729a audio 8 kbit/s; Annex B is implied unless the annexb=no parameter is used RFC 3551, Page 20, RFC 3555, Page 15
19 reserved (previously CN) audio         reserved, previously comfort noise RFC 3551
25 CELLB video   90000     Sun CellB video[5] RFC 2029
26 JPEG video   90000     JPEG video RFC 2435
28 nv video   90000     Xerox PARC's Network Video (nv)[6][7] RFC 3551, Page 32
31 H261 video   90000     ITU-T H.261 video RFC 4587
32 MPV video   90000     MPEG-1 and MPEG-2 video RFC 2250
33 MP2T audio/video   90000     MPEG-2 transport stream RFC 2250
34 H263 video   90000     H.263 video, first version (1996) RFC 3551, RFC 2190
72–76 reserved           reserved because RTCP packet types 200–204 would otherwise be indistinguishable from RTP payload types 72–76 with the marker bit set RFC 3550, RFC 3551
77–95 unassigned           note that RTCP packet type 207 (XR, Extended Reports) would be indistinguishable from RTP payload types 79 with the marker bit set RFC 3551, RFC 3611
dynamic H263-1998 video   90000     H.263 video, second version (1998) RFC 3551, RFC 4629, RFC 2190
dynamic H263-2000 video   90000     H.263 video, third version (2000) RFC 4629
dynamic (or profile) H264 AVC video   90000     H.264 video (MPEG-4 Part 10) RFC 6184, previously RFC 3984
dynamic (or profile) H264 SVC video   90000     H.264 video RFC 6190
dynamic (or profile) H265 video   90000     H.265 video (HEVC) RFC 7798
dynamic (or profile) theora video   90000     Theora video draft-barbato-avt-rtp-theora
dynamic iLBC audio 1 8000 20, 30 20, 30 Internet low Bitrate Codec 13.33 or 15.2 kbit/s RFC 3952
dynamic PCMA-WB audio 1 16000 5   ITU-T G.711.1 A-law RFC 5391
dynamic PCMU-WB audio 1 16000 5   ITU-T G.711.1 μ-law RFC 5391
dynamic G718 audio   32000 (placeholder) 20   ITU-T G.718 draft-ietf-payload-rtp-g718
dynamic G719 audio (various) 48000 20   ITU-T G.719 RFC 5404
dynamic G7221 audio   16000, 32000 20   ITU-T G.722.1 and G.722.1 Annex C RFC 5577
dynamic G726-16 audio 1 8000 any 20 ITU-T G.726 audio 16 kbit/s RFC 3551
dynamic G726-24 audio 1 8000 any 20 ITU-T G.726 audio 24 kbit/s RFC 3551
dynamic G726-32 audio 1 8000 any 20 ITU-T G.726 audio 32 kbit/s RFC 3551
dynamic G726-40 audio 1 8000 any 20 ITU-T G.726 audio 40 kbit/s RFC 3551
dynamic G729D audio 1 8000 10 20 ITU-T G.729 Annex D RFC 3551
dynamic G729E audio 1 8000 10 20 ITU-T G.729 Annex E RFC 3551
dynamic G7291 audio   16000 20   ITU-T G.729.1 RFC 4749
dynamic GSM-EFR audio 1 8000 20 20 ITU-T GSM-EFR (GSM 06.60) RFC 3551
dynamic GSM-HR-08 audio 1 8000 20   ITU-T GSM-HR (GSM 06.20) RFC 5993
dynamic (or profile) AMR audio (various) 8000 20   Adaptive Multi-Rate audio RFC 4867
dynamic (or profile) AMR-WB audio (various) 16000 20   Adaptive Multi-Rate Wideband audio (ITU-T G.722.2) RFC 4867
dynamic (or profile) AMR-WB+ audio 1, 2 or omit 72000 13.3–40   Extended Adaptive Multi Rate – WideBand audio RFC 4352
dynamic (or profile) vorbis audio (various) (various)     Vorbis audio RFC 5215
dynamic (or profile) opus audio 1, 2 48000[note 3] 2.5–60 20 Opus audio RFC 7587
dynamic (or profile) speex audio 1 8000, 16000, 32000 20   Speex audio RFC 5574
dynamic mpa-robust audio 1, 2 90000 24–72   Loss-Tolerant MP3 audio RFC 5219 (previously RFC 3119)
dynamic (or profile) MP4A-LATM audio   90000 or others     MPEG-4 Audio (includes AAC) RFC 6416 (previously RFC 3016)
dynamic (or profile) MP4V-ES video   90000 or others     MPEG-4 Visual RFC 6416 (previously RFC 3016)
dynamic (or profile) mpeg4-generic audio/video   90000 or other     MPEG-4 Elementary Streams RFC 3640
dynamic VP8 video   90000     VP8 video RFC 7741
dynamic VP9 video   90000     VP9 video draft-ietf-payload-vp9
dynamic L8 audio (various) (various) any 20 Linear PCM 8-bit audio with 128 offset RFC 3551 Section 4.5.10 and Table 5
dynamic DAT12 audio (various) (various) any 20 (by analogy with L16) IEC 61119 12-bit nonlinear audio RFC 3190 Section 3
dynamic L16 audio (various) (various) any 20 Linear PCM 16-bit audio RFC 3551 Section 4.5.11, RFC 2586
dynamic L20 audio (various) (various) any 20 (by analogy with L16) Linear PCM 20-bit audio RFC 3190 Section 4
dynamic L24 audio (various) (various) any 20 (by analogy with L16) Linear PCM 24-bit audio RFC 3190 Section 4
dynamic raw video   90000     Uncompressed Video RFC 4175
dynamic ac3 audio (various) 32000, 44100, 48000     Dolby AC-3 audio RFC 4184
dynamic eac3 audio (various) 32000, 44100, 48000     Enhanced AC-3 audio RFC 4598
dynamic t140 text   1000     Text over IP RFC 4103
dynamic EVRC
EVRC0
EVRC1		 audio   8000     EVRC audio RFC 4788
dynamic EVRCB
EVRCB0
EVRCB1		 audio   8000     EVRC-B audio RFC 4788
dynamic EVRCWB
EVRCWB0
EVRCWB1		 audio   16000     EVRC-WB audio RFC 5188
dynamic jpeg2000 video   90000     JPEG 2000 video RFC 5371
dynamic UEMCLIP audio   8000, 16000     UEMCLIP audio RFC 5686
dynamic ATRAC3 audio   44100     ATRAC3 audio RFC 5584
dynamic ATRAC-X audio   44100, 48000     ATRAC3+ audio RFC 5584
dynamic ATRAC-ADVANCED-LOSSLESS audio   (various)     ATRAC Advanced Lossless audio RFC 5584
dynamic DV video   90000     DV video RFC 6469 (previously RFC 3189)
dynamic BT656 video         ITU-R BT.656 video RFC 3555
dynamic BMPEG video         Bundled MPEG-2 video RFC 2343
dynamic SMPTE292M video         SMPTE 292M video RFC 3497
dynamic RED audio         Redundant Audio Data RFC 2198
dynamic VDVI audio         Variable-rate DVI4 audio RFC 3551
dynamic MP1S video         MPEG-1 Systems Streams video RFC 2250
dynamic MP2P video         MPEG-2 Program Streams video RFC 2250
dynamic tone audio   8000 (default)     tone RFC 4733
dynamic telephone-event audio   8000 (default)     DTMF tone RFC 4733
dynamic aptx audio 2 – 6 (equal to sampling rate) 4000 ÷ sample rate 4[note 4] aptX audio RFC 7310
dynamic jxsv video   90000     JPEG XS video RFC 9134

FMTP

The "fmtp" (format parameters) attribute in SDP (Session Description Protocol) is used to describe the format parameters of a media stream, specifically for codecs that support dynamic negotiation of parameters. It specifies the media format parameters as a set of parameter name-value pairs, separated by semicolons.

The format of the "fmtp" attribute is as follows:

a=fmtp:<format> <parameter_name>=<value>;<parameter_name>=<value>;...

For example, the "fmtp" attribute for the H.264 video codec may look like:

a=fmtp:120 profile-level-id=42801E; packetization-mode=1; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==

In this example, the <format> value is 120 (which is the format number for H.264). The <parameter_name> values include "profile-level-id", "packetization-mode", and "sprop-parameter-sets", and their corresponding <value>s are "42801E", "1", and "Z0IACpZTBYmI,aMljiA==", respectively. These parameters provide information such as the profile and level of the codec, the packetization mode, and the parameter sets required for decoding the video stream.

The "fmtp" attribute is typically used in conjunction with the "rtpmap" attribute to describe media formats that use RTP (Real-time Transport Protocol) for transmission.

This is a SIP response to an INVITE request shown above. It has a status code of 200 OK, indicating that the request was successful. The Via header indicates the path that the request followed. The To header contains the tag that identifies the current dialog. The From header contains the tag that identifies the previous dialog. The Call-ID header is used to identify the call. The CSeq header contains the sequence number and method of the request. The Contact header specifies the address where the response should be sent. The Content-Type header indicates that the body of the message is in SDP format. The SDP message body includes connection information, timing information, and media information for both audio and video. In this response, some codecs have been removed from both audio and video streams.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
To: Bob <sip:bob@biloxi.com>;tag=2482893830n
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4:5060>
Content-Type: application/sdp
Content-Length: 204

v=0
o=- 123456 789012 IN IP4 192.0.2.4
s=SIP Call
c=IN IP4 192.0.2.1
t=0 0
m=audio 49170 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
m=video 49172 RTP/AVP 31
a=rtpmap:31 H261/90000

Multiple M Lines

In SIP SDP, multiple "m=" lines can be included in a single SDP message to provide information about multiple media streams within a session. Each "m=" line corresponds to a different type of media, such as audio, video, or data. The "m=" line specifies the transport protocol and port number to be used for that particular media stream, as well as the format of the media data being transmitted. Each "m=" line can also have its own set of media-level attributes, such as the RTP payload types being used for different codecs, or the clock rate of the media data. By including multiple "m=" lines in a single SDP message, a SIP session can support multiple media streams simultaneously.

image.png

11. - SIP SDP - Changing Session Parameters

In SIP SDP, the session parameters can be changed during the lifetime of a session by sending a re-INVITE message. A re-INVITE is an INVITE message sent within an established session that is used to modify session attributes.

When a re-INVITE message is sent, it includes a new SDP offer that specifies the updated session parameters. The remote party can then respond with a new SDP answer that acknowledges the changes or rejects them. The re-INVITE can be used to update media session attributes such as codecs, media formats, bandwidth, and transport protocols, as well as session-level attributes such as session name, session description, and session timing.

Re-INVITEs are commonly used in scenarios where a user wants to add or remove media streams from an established session, change the codec or format of an existing media stream, or modify other session parameters. The use of re-INVITEs provides a flexible mechanism for session negotiation and management in SIP-based communication systems.

Other methods that will change or update SDP parameters

  1. INVITE with new SDP: When a new INVITE is sent with a new SDP, it indicates that the session parameters are being updated.

  2. UPDATE: The UPDATE method can be used to modify the session parameters without terminating the session. It carries a new SDP message that describes the updated parameters.

  3. Re-INVITE: A Re-INVITE can be sent by either the caller or the callee to modify the session parameters. It is similar to the INVITE method, but it is sent while the call is in progress.

  4. INFO: The INFO method can be used to send non-INVITE related information during a call. It can also be used to modify the session parameters by carrying a new SDP message.

These methods can be used to update session parameters such as codec types, media ports, IP addresses, bandwidth, and other attributes defined in the SDP.

Putting a call on Hold example

Here a call is placed on hold and re-invite messages are sent

image.png

the SDP message is updated with a=sendonly and the IP is changed to 0.0.0.0, remote user updates his sdp with 200 ok and puts himself on  a=recvonly, here user in left will send (send only) music on hold and remote (in receive only mode) will hear music)

when unhold user on left will send new invite with his IP 192.168.100.102 and rtpmap a=sendrecv, remote user will respond with 200 ok and change mode to a=sendrecv, this will reestablish audio both ways.

image.png

there are multiple ways of messages when placing a call on hold example below

image.png

image.png

In SIP and SDP, putting a call on hold is achieved by the initiator of the hold sending a re-INVITE message to the other party with an SDP offer that indicates the call is being put on hold. The SDP offer typically sets the media streams to inactive state by setting the port to 0 and the IP address to 0.0.0.0.

For example, suppose Alice wants to put Bob on hold during a call. Alice would send a re-INVITE message to Bob with an SDP offer indicating that the audio and/or video streams are inactive, like so:

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact: <sip:alice@pc33.atlanta.com>
User-Agent: BriaX 3.5.5 build 81887
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Allow-Events: presence, message-summary, refer, dialog
Session-Expires: 3600;refresher=uas
Content-Type: application/sdp
Content-Length: 218

v=0
o=- 123456 789012 IN IP4 pc33.atlanta.com
s=SIP Call
c=IN IP4 0.0.0.0
a=sendonly
t=0 0
m=audio 0 RTP/AVP 0
m=video 0 RTP/AVP 31

When Bob receives this message, he can either accept the hold request by sending a 200 OK response, or reject it by sending a 486 Busy Here response. If he accepts it, he will send a 200 OK response with his own SDP answer indicating that the media streams have been set to inactive state, like so:

SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
To: Bob <sip:bob@biloxi.com>;tag=2482893830n
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact: <sip:bob@192.0.2.4:5060>
Content-Type: application/sdp
Content-Length: 102

v=0
o=- 123456 789012 IN IP4 192.0.2.4
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
a=recvonly
m=audio 0 RTP/AVP 0
m=video 0 RTP/AVP 31

Once the hold has been established, Alice and Bob can either resume the call by sending another re-INVITE message with an SDP offer indicating that the media streams are active, or terminate the call by sending a BYE message.

INVITE and reINVITE

In a SIP message, the type of message (e.g. INVITE, BYE, REGISTER, etc.) is specified in the first line, which is called the request line or status line. For example, in an INVITE message, the request line would start with "INVITE".

In the case of a re-INVITE message, it will also have the same request line format starting with "INVITE", but it will typically include additional headers such as "Call-ID", "From", "To", "CSeq" and "Max-Forwards". These headers provide information about the ongoing call session, allowing the recipient to identify it as a re-INVITE message and determine how to handle it appropriately.

It's also important to note that a re-INVITE message is always sent within an established SIP session and it typically contains a new SDP offer, which updates the media parameters of the session.

on the example below we can see the first 2 options are an Invite, to distinguish them we can look at the CSeq: number, they both are 1

the third attempt its a reINVITE as is using a different CSeq number.

image.png

In the next example, Alice sends two INVITEs with different branch IDs but the same CSeq number of 1 and 2 respectively. Bob can respond to each of these INVITEs with a different branch ID but the same CSeq number of 1 and 2 respectively.

After the call has been established, Alice sends a re-INVITE with a new branch ID and a CSeq number of 3 to

INVITE sip:bob@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK-1234-5678
Max-Forwards: 70
To: Bob <sip:bob@192.0.2.1>
From: Alice <sip:alice@192.0.2.3>;tag=8765
Call-ID: 1234abcd@192.0.2.2
CSeq: 1 INVITE
Contact: <sip:alice@192.0.2.2>
Content-Type: application/sdp
Content-Length: 123

v=0
o=- 123456 789012 IN IP4 192.0.2.2
s=SIP Call
c=IN IP4 192.0.2.2
t=0 0
m=audio 3456 RTP/AVP 0 8

INVITE sip:bob@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK-1234-5678
Max-Forwards: 70
To: Bob <sip:bob@192.0.2.1>
From: Alice <sip:alice@192.0.2.3>;tag=8765
Call-ID: 1234abcd@192.0.2.2
CSeq: 1 INVITE
Contact: <sip:alice@192.0.2.2>
Content-Type: application/sdp
Content-Length: 123

v=0
o=- 123456 789012 IN IP4 192.0.2.2
s=SIP Call
c=IN IP4 192.0.2.2
t=0 0
m=audio 3456 RTP/AVP 0 8

RE-INVITE sip:bob@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK-3456-7890
Max-Forwards: 70
To: Bob <sip:bob@192.0.2.1>
From: Alice <sip:alice@192.0.2.3>;tag=8765
Call-ID: 1234abcd@192.0.2.2
CSeq: 3 RE-INVITE
Contact: <sip:alice@192.0.2.2>
Content-Type: application/sdp
Content-Length: 123

v=0
o=- 123456 789012 IN IP4 192.0.2.2
s=SIP Call
c=IN IP4 192.0.2.2
t=0 0
m=audio 3456 RTP/AVP 0 8

12. - SIP Mobility

SIP Mobility

SIP Call Forking 

SIP call forking is a mechanism used to distribute incoming calls to multiple endpoints simultaneously. SIP call forking can be done in two modes: sequential and parallel.

SIP Call Forking - Parallel

In parallel call forking, the incoming call is sent to all specified endpoints at the same time, and the first endpoint that answers the call receives it. This is useful when you want to make sure that the call is answered as quickly as possible, or if you want to distribute the call load across multiple endpoints.

image.png

SIP Call Forking - Sequential

SIP call forking sequential is a call distribution method in which a SIP request is forwarded to multiple destinations sequentially. The request is first sent to the first destination in the list and if it fails to respond or rejects the request, the request is forwarded to the next destination in the list until a successful response is received. This is typically used for applications such as call hunting or sequential ring groups, where a call is routed to a group of users in a pre-defined order.

image.png

In this example a user Graham makes a call to Linda at vocale@voipuser.org, and the user answer on both devices we will have one conversation and 2 call legs (RFC 2543) or dialogs will  (RFC 3261)

image.png

Dialog trace example

The dialog below is based in previous  figure, a dialog is identified by a call identifier, local tag and remote tag

When Graham calls Linda in the dialog below we can see the following:

image.png

image.png

If we were to trace the mobile phone, Linda phone tag will be the same the mobile number will have the same SIP URI but it will have its own unique tag, this help to separate the dialogs from each other.

image.png

Dialogs and 'transactions'

Now that the dialog is established, tags are in place, we are talking, from here we can hold, unhold and do any other transactions we've like but all transactions made will be part of the established dialog (or call leg)

image.png

Branch ID

A "branch ID" is a unique identifier that is used to identify a particular SIP transaction within a call. Each SIP message in a transaction has a unique branch ID that is generated by the user agent sending the message. This branch ID is included in the Via header of the SIP message, and is used to match the response message with the original request message. The branch ID allows SIP to be stateful, meaning that it can keep track of the progress of a call and route subsequent messages to the correct destination. When a SIP message is sent, the branch ID is generated by the sender, and it is typically a random string of characters that is unique for each message. The branch ID is included in the Via header of the message, along with other information such as the transport protocol and the IP address of the sender.

image.png

RFC 3261 specifies that the branch ID parameter for SIP requests should begin with the string "z9hG4bK" (note that the "K" is uppercase). This is a recommended convention to ensure that the branch ID is globally unique. The "z9hG4bK" string is a fixed prefix that serves as a unique identifier for SIP requests, while the remainder of the branch ID is typically generated randomly or by hashing the request contents. Using a fixed prefix allows SIP elements to quickly identify and process SIP requests that belong to the same transaction.

SIP Call Forward - No Answer

SIP call forwarding no answer is a feature that allows incoming calls to be forwarded to another number if the call is not answered after a set number of rings or a certain period of time. This feature is useful when the recipient is unavailable or unable to answer the call.

When an incoming call arrives at a SIP user agent, the user agent will first attempt to answer the call. If the call is not answered after a predetermined number of rings or a specific period of time, the user agent can forward the call to another SIP user agent or phone number.

To implement SIP call forwarding no answer, a user agent must support the SIP call forwarding feature and be configured with the appropriate settings. The user agent must also have access to a SIP proxy or registrar that can handle the call forwarding request.

The SIP call forwarding no answer feature can be configured in various ways. For example, the forwarding number can be specified in the user agent's configuration, or it can be dynamically entered by the user during the call forwarding process. The number of rings or time period before forwarding can also be configured to meet the user's needs.

Overall, SIP call forwarding no answer is a useful feature that helps ensure that important calls are not missed, even if the recipient is unavailable or unable to answer the call.


image.png

SIP Call Forward to Voicemail

SIP call forwarding to voicemail is a feature that allows a call to be automatically redirected to a voicemail box when the call is not answered within a certain amount of time. This is useful when a caller is unable to reach the intended recipient and wants to leave a message.

When a call is forwarded to voicemail, the call is routed to the voicemail system instead of the intended recipient's phone. The voicemail system then answers the call and prompts the caller to leave a message, which is stored in the recipient's voicemail box.

To configure SIP call forwarding to voicemail, the user can set a "no answer" or "unavailable" timer on their phone or PBX. When the timer expires, the call is automatically forwarded to the voicemail system. The user can also configure their voicemail box to send an email or text message notification when a new voicemail is received.

SIP call forwarding to voicemail can be a useful tool for businesses and individuals who want to ensure that important messages are not missed. It allows callers to leave messages even if the recipient is unavailable, and provides a convenient way for the recipient to check their messages at a later time.

image.png

Here is an example of a call forward no answer

1. - Initial INVITE message from Alice to Bob

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP alice.example.com:5060;branch=z9hG4bKdf877ekj4
Max-Forwards: 70
From: <sip:alice@example.com>;tag=1928301774
To: <sip:bob@example.com>
Call-ID: 84@alice.example.com
CSeq: 1 INVITE
Contact: <sip:alice@example.com>
Content-Type: application/sdp
Content-Length: 142

v=0
o=alice 2890844526 2890844526 IN IP4 alice.example.com
s=-
c=IN IP4 alice.example.com
t=0 0
m=audio 49170 RTP/AVP 0

2. - Bob's 100 trying response

SIP/2.0 100 Trying
Via: SIP/2.0/UDP alice.example.com:5060;branch=z9hG4bKdf877ekj4
From: <sip:alice@example.com>;tag=1928301774
To: <sip:bob@example.com>
Call-ID: 84@alice.example.com
CSeq: 1 INVITE
Content-Length: 0

3. - Bob's ringing response

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP alice.example.com:5060;branch=z9hG4bKdf877ekj4
From: <sip:alice@example.com>;tag=1928301774
To: <sip:bob@example.com>;tag=1234567890
Call-ID: 84@alice.example.com
CSeq: 1 INVITE
Contact: <sip:bob@example.com>
Content-Length: 0

4. - Bob's call forward no answer response to Alice, Response is 302 Moved Temporarily and To and Contact are updated with new contact info.

SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP alice.example.com:5060;branch=z9hG4bKdf877ekj4
From: <sip:alice@example.com>;tag=1928301774
To: <sip:bob-new@example.com>;tag=1234567890
Call-ID: 84@alice.example.com
CSeq: 1 INVITE
Contact: <sip:bob-new@example.com>
Content-Length: 0

5. - Alice sends a new INVITE message to the new address bob-new@example.com provided by Bob in the previous response

INVITE sip:bob-new@example.com SIP/2.0
Via: SIP/2.0/UDP alice.example.com:5060;branch=z9hG4bKdf877ekj5
Max-Forwards: 70
From: <sip:alice@example.com>;tag=1928301774
To: <sip:bob-new@example.com>
Call-ID: 84@alice.example.com
CSeq: 2 INVITE
Contact: <sip:alice@example.com>
Content-Type: application/sdp
Content-Length: 142

v=0
o=alice 2890844526 2890844527 IN IP4 alice.example.com
s=-
c=IN IP4 alice.example.com
t=0 0
m=audio 49170 RTP/AVP 0

Call Forward to Voicemail

1. - Alice calls Bob's phone (sip:bob@example.com):

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact: <sip:alice@pc33.example.com>
User-Agent: BriaX 3.5.5 build 81887
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Allow-Events: presence, message-summary, refer, dialog
Session-Expires: 3600;refresher=uas
Content-Type: application/sdp
Content-Length: 218

v=0
o=- 123456 789012 IN IP4 pc33.example.com
s=SIP Call
c=IN IP4 192.0.2.1
t=0 0
m=audio 50000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 50002 RTP/AVP 31
a=rtpmap:31 H261/90000

2. - Bob's phone (sip:bob@example.com) rings, but he doesn't answer. After a timeout period, the call is forwarded to Bob's voicemail (sip:vm@example.com):

BYE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: <sip:bob@example.com>;tag=2482893830n
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 BYE
Contact: <sip:alice@pc33.example.com>
User-Agent: BriaX 3.5.5 build 81887
Reason: Q.850;cause=0
Content-Length: 0

INVITE sip:vm@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhdt
Max-Forwards: 70
To: <sip:vm@example.com>
From: Alice <sip:alice@example.com>;tag=1928301775
Call-ID: a84b4c76e66710
CSeq: 314162 INVITE
Contact: <sip:alice@pc33.example.com>
User-Agent: BriaX 3.5.5 build 81887
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Allow-Events: presence, message-summary, refer, dialog
Session-Expires: 3600;refresher=uas
Content-Type: application/sdp
Content-Length: 164

v=0
o=- 123456 789013 IN IP4 pc33.example.com
s=SIP Call
c=IN IP4 192.0.2.1
t=0 0
m=audio 50000 RTP/AVP 0
a=rtpmap:0 PCMU/

13. - SIP Proxies, Gateways and SIP Routing

Proxies and SIP routing

Stateless proxy: forgets about the SIP request once it has been forwarded. As the transaction is quick and simple, these scale very well to cope with a lot of requests and can also be very fast. They are very well suited to the core of a SIP network but they cannot provide services such as call forking.

image.png

Stateful proxy: By knowing the state of a transaction a stateful proxy can provide many more services such as call forking as the example shows below.

image.png

Via and Record-Route

Some of the most important elements of a SIP message are VIA and Record-Route they help prevent loops and can govern the path the SIP message takes, it is worth nothing that no all SIP providers take full advantage of these records and any wireshark/ethereal traces you may take can differ depending on the SIP provider and SIP phones or PBX you are using at the time.

image.png

VIA details

Via records are added to a SIP message as follow

image.png

If Proxy - Redirect Servers are used, once the INVITE transaction is accomplished, User Agents will know each others direct IP addresses (from the contact field) and carry out the subsequent transactions bypassing the intermediary proxies. This will mean less number of VIA entries than if the Proxy maintains the Call State, also VIA headersa re useed by Proxies to see if any 'Looping' of the message has occurred. if they received a message that includes their own IP address in a VIA record a 482 (loop detected) response is returned to the sender.

Routing Examples 1

image.png

Now this Invite will travel to the PSTN

image.png

Next is the 200 OK received from the PSTN phone

image.png

Now our Phone will send an ACK, the message needs to end up at the gatway so we can see the following

This process is known as Loose Routing <sip:172.20.40.4;lr=on we can see lr is displayed on the Route record, sometimes we see lr=on but this is not required as part of the RFC326 so simply lr is use.

image.png

Record-Route defined

There are so many records when sending a 'Request' message, which is used?

First it will use Route, then Contact (if there is no Route), From (if there is no Contact, 

The Record-Route header is added into requests from UA clients by proxy servers that want to be in the path of follow on request or the same call-id value. The UA client will then use the entries to route subsequent requests and the details from Record-Route are copied into the responses under the Route header. Note: not all proxies will add their details into the header

Contact Headers determine the destination placed in the Request-URI for the following requests and can be used to bypass proxies that do not have an entry in the Record-Route header.

From Headers are used for following requests from the UAS to the UAC if there is no Contact of Record-Route header.


Session Policies

In SIP, session policies are used to control and enforce rules and restrictions on sessions between SIP user agents. Session policies can be applied to various aspects of a session, such as call routing, media handling, security, and resource allocation.

For example, a session policy can specify that calls from a certain group of users should always be routed through a specific SIP proxy, or that media streams must be encrypted using a certain algorithm. Session policies can also be used to enforce restrictions on bandwidth usage or to limit the duration of a session.

SIP session policies are typically implemented using a combination of configuration settings and network devices such as firewalls, routers, and session border controllers (SBCs). These devices can be configured to inspect SIP messages and apply policy rules based on the contents of those messages.

Session policies can be useful in a variety of SIP deployment scenarios, such as in enterprise networks where security and compliance are important, or in service provider networks where quality of service (QoS) and resource allocation are critical. By enforcing policy rules, session policies help to ensure that sessions are conducted in a secure and reliable manner, while also optimizing the use of network resources.

image.png

SIP Gateways

There is a common misconception of what a gateway does, have a look at the slide below, the IP address of this router is also common known as default gateway, is not a gateway its the default router.

The SIP/PSTN gateway actually converts SIP signalling and VoIP traffic to a different format ready for the PSTN - It is actually carrying out 'Real' Gateway functions.

image.png

The main purpuse of the SIP/PSTN gateway to the PSSTN is to provide Signalling and Media conversion between the SIP and PSTN networks, here you can see the SIP/SDP messages hit the signaling gateway and convert the signaling to ISDN and RTP packets hit the media gateway for voice.

image.png

Gateway Location and routing with TRIP

image.png

image.png

image.png

14. - SIP SDP - MIME

Mime was defined to provide a way of attaching different document/file types to email messages, SIP takes advante of this existing standard by using it to inform a UA what content is present in a SIP message.

Content-Type: <type>/<subtype>

Content-Type: image/gif

As you have already seen Content-Type: application/SDP tell us that the MIME content of the SIP message is the application layer protocol SDP. THE UA then (if supporting SDP) can interpret the SDP information in the message to find out details such as Codecs supported in the 'Inviting Agent' and Port numbers for responses etc.

image.png

A sip message can actually contain multiple mime parts, on the previous image wee can see the following

Content-Type:multipart/mixed; boundary=boundary1 

the first Content-type:application/sdp belongs to an SDP MIME message, there is also a second Content-type: image/gif which could be an image of a business card, a photograph, etc.

  


15. - SIP and the PSTN

 

Here our SIP phone dial the number of a PSTN device, the proxy will send the invite onto the SIP/PSTN Gateway that will next sent the proper setup message to the PSTN switch then to the telephone.

A PRACK 183 inform the SIP phone of the progress of the call setup and setup an Early Media (RTP)

Once the PSTN phone start ringing the alerting 180 Ringing messages are sent back to our SIP phone along with the 200 OK

Our SIP phone will response with an ACK then the media will start to flow, it is up to the SIP/PSTN gateway to convert the media from RTP to TDM and viceversa

image.png

In more detail 01216896815, the SIP proxy uses the location services and determines the number is on the PSTN it then passes the invite to the SIP/PSTN Gateway which thenn by the PSTN Switch goes to Grahams phone. The detail on the next image shows the INVITE along with the contact details and SDP information

image.png

Some other sample SIP Codes re: SIP to PSTN call setup attemps are 

Here is an example of a PSTN to SIP Call Flow

image.png

Early Media

To overcome a few problems that arise due to the two different systems such as SIP and the PSTN trying to work together, a concept called 'Early Media' has been introduced

Early media is not required on standard PSTN calls as when a number is dialed a media channel is established so that the caller can hear the ringing tone of the remote device, This also gives companies the opportunity to replace ringing media with corporate messages or other instructions for the caller before they get to speak to a real person.

Clipping is a problem where if a person using a PSTN phone answer their phoene adn starts talking straight away without Early Media the SIP phone that is calling them will miss the first part of the conversation as it hasn't yet received a 200 ok message to enable it to setup the RTP media path.

Early media also allows Busy Tone and other announcements to be played to the caller even though the called phone has not been picked up.

image.png

Early Offer / Delayed Offer

With Early offer the invite sends the SDP to being voice inmediately 

image.png

With delayed  offer Invite goes without SDP allowing the other end select a codec to use, if available it will reply with an ACK SDP to begin media.

image.png

SIP Bridging or SIP-T is a framework that can enable SIP networks to carry legacy telephone signals across an IP based network to another legacy network, This would have a dramatic effect on long distance call charges which is great for end users but of course there are technical issues that need to be addressed.

The legacy SS7 ISUP messages have to be interrogated by the SIP/PSTN gateway and then the information that will help SIP proxies to route the SIP messages is built into the SIP header, while othert ISUP information added as a MIME message body, to ensure that the body is closed to 'unwanted' parties snooping on the network it can be encrypted and this is discussed in the security module course.

SIP INFO is another SIP-T approach or method that is used for in-call ISUP signaling across an IP network.

In essence SIP-T must provide translation beteen protocols and providee feature transparency across PSTN to SIP to PSTN interconnections.

 

image.png

ISUP and SIP messages

image.png

ISDN User part (ISUP) to SIP codes

 

image.png

Here is an example of a PSTN to PSTN via SIP

image.png

 

ISUP Encapsulation / SDP also known as SIP Bridging

If this is all that a client requires, then all of the ISUP information can be held in the body of the SIP message and the details such as To: From: Contact, etc. never changes as these just relates to the SIP gateway addresses, an example of the SDP portion of the SIP message (mime/isup) is below, This way any ISUP information that cannot be mapped to SIP will be retained and in this case, secured as well.

image.png

 

image.png

 

SIP and DTMF

As well as DTMF Dialling tones there are a lot more tonees and events that need to be considered when carrying them across a SIP/VoIP network

DTMF Tones

image.png

image.png

Standard subscriber line tones

image.png

Country specific subscriber line tones

image.png

Trunk Events

image.png

 

Different types of DTMF


DTMF RFC 2833 example

image.png

 

SIP INFO DTMF example

image.png

 

 

Summary

 

16. - SIP and B2BUA Back to Back User Agent

Thee B2BUA its a standalone proxy when it receives a request process the request just as thee intended destination UA Server would, it repackage the request and act as a UA client then generates a new request and send this to the destination, the B2BUA will maintain the complete call state and continue to send request and responses on which its involved, in essence it own the session.

image.png

 

A B2BUA implementation would make it easier to offer the following, you just have to choose your B2BUA carefully

 

17 .- SIP Security

 

Authentication and Authorization

Proxy Authentication – when user needs to be authenticated proxy responses with a 407, sending a string nonce, user encrypt the password using nonce and MD5, and send back the invite including the hash with the password encrypted, it’s decrypted by the server.
401 unauthorized is a response to register messages 
Once authentication has been made, authorization will determine what an authenticated person can do.
128 bit MD5 mechanism is proven to flawed.
SHA-1 at 160 bits is a little more secure but has issues, hence the development of SHA-2 that can produce hash sizes of up to 512 bits.
SHA-3 is currently in development and promises larger hash sizes and no flaws in the algorithm.d is defined in RFC 3262..

image.png

 

Encryption


 There are many types of malicious attacks:
    • VoIP interception, modification and replay
    • Conversation eavesdropping
    • Dictionary attacks
    • Telephone number harvesting
    • DOS and DDOS attacks
    • SPIT and SPAM
    • Flood attacks

image.png

image.png

 

Certificate authorities manages the certificates for some companies.


SIP with TLS only secures signaling, but no audio or other media, SRTP needs to be used to encrypts audio.
SSL (Secure Sockets Layer) first introduced via the Netscape browser, v3 introduced certificate support and SHA-1 support (http, ftp, smtp use it).
TLS has replaced SSL, RFC 5246 TLS 1.2
TLS is based on a shared secret known only to the server and the client, ensure that all SIP signaling messages are encrypted, work on an end to end basis where all systems between the UAs must support TLS or the call will fail. Can work on a hop by hop basis but this requires a new TLS session established between each point on the network.

If security/encryption along the whole path is needed to the end destination the use the sip address type of sips:
Crypto - RFC 4568
RFC 4474 – Caller ID Identity 
RFC 6347 and 5763 – DTLS/SRTP
S/MIME (Secure Multipurpose Internet Mail Extensions) – was developed so emails can be encrypted and also digitally signed for proof of sender (only the sender needs a certificate and associated encryption keys) (for email encryption both sender and recipient require certificates), SIP has adopted S/MIME standard to enable it to encrypt SDP body parts to ensure information privacy, SIP headers are encrypted using TLS.
sRTP can generate encryption keys between two UA without the need of a certificate authority.
IPSec is a heavyweight solution as it requires a PKI to be in place:
    • Adds a lot of overhead in the encapsulation process
    • Is tended to be implemented in a lot of VPN

Attacks and Responses

Attacks

Response

RFC 4475 - SIP Torture test messagees

Ethical Hacking

NIST National INstitutes of Standards and Technology

Use Strong autheentication such as SHA-1 or MD5

Use TLS end to end encryption or even an IPSec connection.

Dont use softphone in a security sensitive network as the PC runs on usually vulnerable OS attack.

18. - SIP - Firewall NAT and SBC

 

Issues to Address

Protection of your network is vital if connected to the internet, Private addressing on the internal network can cause problems when using SIP through a NAT (network address translation service), NAPT also introduces another set of problems and finally SIP has a firewall to content with.

 

Firewalls

Corporate and personal firewalls are usually placed at the wedge of the network to act as a perimeter device that can permit traffic leaving and entering thenetwork, usually all traffic originating from within a network is allowed out and traffic from outside is allowed in, firewalls usually allow traffic such as HTTP and SMTP to enter the network, firewalls that are not SIP aware will probably block all SIP traffic and it may be the case that the RTP packets will be blocked as well.

 

NAT

Private addressing on the internal network can cause problems wueh using SIP through a NAT

Full-cone NAT

image.png

Restricted Cone NAT

image.png

Port Restricted NAT

image.png

 

NAT Symmetric

image.png

 

NAPT Introduces another set of problemsimage.png

Problems with NAT are caused because of the hostile environment made for the lack of standardize behaviors and controls in NATs solutions.

STUN (Simple Transversal of UDP)

How it works

Problems

image.png

image.png

image.png

TURN (Traversal Using Relays around NAT)

image.png

 

Interactive Connectivity Establishment (ICE)

image.png


UPnP

image.png

image.png


RTP Problem

 

Solving the RTP problem