Session Initiation Protocol – SIP

SIP trunking configuration step

 Contents –

- Session Initiation Protocol

- SIP User Agents

- SIP message Headers example

- SIP registration

- Simple SIP session establishment

- SIP Call with a Proxy Server

- SIP Servers ( Proxy Server, Forking Proxy, Redirect Server& Registrar

Server )

- SIP Request Messages ( INVITE, REGISTER, BYE, ACK, CANCEL &

OPTIONS, Subscribe, Notify, Publish, REFER )
 INVITE = Establishes a session.
 ACK = Confirms an INVITE request.
 BYE = Ends a session.
 CANCEL = Cancels establishing of a session.
 REGISTER = Communicates user location (host name, IP).
 OPTIONS = Communicates information about the capabilities of the calling and receiving SIP phones.
 PRACK = Provisional Acknowledgement.
 SUBSCRIBE = Subscribes for Notification from the notifier.
 NOTIFY = Notifies the subscriber of a new event.
 PUBLISH = Publishes an event to the Server.
 INFO = Sends mid session information.
 REFER = Asks the recipient to issue call transfer.
 MESSAGE = Transports Instant Messages.
 UPDATE = Modifies the state of a session.

- SIP Header Fields

- SIP Response Messages

- Session Description Protocol

- Media Transport Protocol ( RTP& RTCP )

- DTMF Transport
**InformationalPoints

SIP – Session Initiation Protocol

 SIP developed to set up, modify, and tear down multimedia sessions
 Main signalling functions of the protocol are as follows –
- Location of an end point
- Contacting an end point to determine willingness to establish a session
- Exchange of media information to allow a session to be established
- Modification of existing media sessions
- Teardown of existing media sessions.
SIP User Agents –
 SIP-enabled end device is called a SIP user agent (UA)
 UA takes direction or input from a user and acts as an agent on their behalf
to set up and tear down media sessions with other UA.
 UA must be capable of establishing a media session with another UA.
 UA must maintain the state on calls that it initiates or participates in, which
includes the local and remote tags, Call-ID, local and remote CSeq header
fields.
 Even after a call has been terminated, the call state must be maintained by a
user agent for at least 32 seconds in case of lost messages in the call tear
down.
 During a session,a user agent will usually operate as both a UAC and a UAS.
 UAs typically register with a proxy server in their domain.

** A re-INVITE is used to change the session parameters of an existing call which uses the
same Call-ID and tags as the original INVITE/200 OK exchange, but the CSeq is incremented
because it is a new request.
SIP message Headers example-

TAGS

Tags are really quite simple, but require a bit of explanation. The goal of a tag is to work with the Call-ID to
make an entire dialog unique no matter how many times a session might be forked. Actually, I should have
said tags since there are two. There is the local tag (From tag) which is assigned by the sender of a message
or the UAC. There is also the remote tag (To tag) which is assigned by the final recipient of the message or
the UAS (User Agent Server). The UAC puts its tag in the From header and the UAS puts its tag in the To
header. So, when a message leaves a UAC it has one tag in the From header and there is no tag in the To
header. When a UAS receives that message and responds back with a SIP response (e.g. 180 Ringing), it then
adds a tag to the To header. If multiple clients received the original message then they would all add their
own specific tag values. In other words, all those SIP messages will have the same From tag, but depending
on who is responding, there will be different To tags. Does this make sense? If not, here is a dumbed down
call flow that might explain it better:

Andrew sends:
INVITE [email protected]

To: [email protected]

From: [email protected]; tag = [email protected]

Mary’s smart phone SIP client responds with:

180 Ringing

To: [email protected]; tag = [email protected]

From: [email protected]; tag = [email protected]

Mary’s PC SIP client responds with:

180 Ringing

To: [email protected]; tag = [email protected]

From: [email protected]; tag = [email protected]

P-asserted : use to hide user information may be

display as unknown numner
And it work only in trusted proxies
For other purpose like billing, CDR

P=Private

v=0

o=Andrew 2890844526 2890844526 IN IP4 10.120.42.3

s= SDP Blog

c=IN IP4 10.120.42.3

t=0 0

m=audio 49170 RTP/AVP 0 8 18 96

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:97 iLBC/8000

m=video 51372 RTP/AVP 31 32

a=rtpmap:31 H261/90000

Call Flow Information:

Call Flow: Call Hold/Resume
The Call flow diagram above explains the Call Hold/Resume feature implemented with the Call Flow Direction
Attributes.

1. A 2-way call is established from GW-A to GW-B through the IMG using normal call
messaging procedures.
2. GW-A wants to put the call on hold. GW-A sends a Re-INVITE message to the IMG
with the a=sendonly line in the SDP. This tells the IMG that GW-A is in a send-only
mode and will not receive RTP/RTCP data.
3. The IMG then sends a 200 OK response with the a=recvonly line indicating that it
will only receive RTP/RTCP data and not transmit RTP/RTCP data packets to GW-A.
At this point, GW-A can only transmit to IMG.
4. The IMG then sends a Re-INVITE message to GW-B with the c=0.0.0.0 and
a=inactive in the SDP. By sending these two messages, the IMG effectively puts
the call on hold.
5. GW-B responds with a 200 OK telling the IMG it is now on hold. There is no voice
path between IMG and GW-B.
 6. GW-A then wants to take the call off hold and resume the call. It sends a Re-
INVITE to the IMG with the line a=sendrecv telling the IMG it is now in a
send/receive mode and the call can resume.
7. The IMG responds with 200 OK message with the a=sendrecv line in its SDP.
8. The IMG then sends a Re-INVITE to GW-B with the same a=sendrecv message in
its SDP. GW-A responds with 200 OK and a=sendrecv in the SDP.
9. At this point the call resumes and RTP/RTCP data begin flowing again.

SIP-T (RFC3372) is advanced version of SIP which support to carry ISUP message over

SIP to SIP-T/SIP-I Message Mapping

Below is a mapping of SIP to SIP-T/SIP-I messages. The ISUP messages are inserted into the SIP message as a
RAW API message.

SIP Message SIP-T Message

INVITE INVITE (IAM)
180 Ringing 180 Ringing (ACM/CPG)
183 Progress 183 Progress (ACM/CPG)
200 OK 200 OK (ANM/CON)
BYE BYE (REL)
200 OK BYE 200 OK BYE (RLC)
4xx, 5xx, 6xx 4xx, 5xx, 6xx (REL)

SIP-ISUP interworking[edit]
SIP-I, or the Session Initiation Protocol with encapsulated ISUP, is a protocol used to create, modify, and terminate
communication sessions based on ISUP using SIP and IP networks. Services using SIP-I include voice, video
telephony, fax and data. SIP-I and SIP-T[28] are two protocols with similar features, notably to allow ISUP messages to be
transported over SIP networks. This preserves all of the detail available in the ISUP header, which is important as there
are many country-specific variants of ISUP that have been implemented over the last 30 years, and it is not always
possible to express all of the same detail using a native SIP message. SIP-I was defined by the ITU-T, whereas SIP-T
was defined via the IETF RFC route.[29]
 Active time – t=0 0
 0 = Session start time
 0 = Session stop time

Code 0 = PCMU , and the µ law (u-law) is used in American PCM system

Code 8 = PCMA A Law (a-law) is used mainly in European PCM systems

Code 3 = GSM

Code 18 = G729

G723 = 4

Code 101 = DTMF

Code H263 = 90000

m=audio 54874 RTP/AVP 96 97 8 0
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:97 PCMU-WB/16000

0 711U=64 kbps same for 8 711A

4= 723.1 6.4 Kbps or 5.3 kb/s

8 = 729 8 Kbps

Video h.263
V.17, V.27, V.29TDM code for fax

SIP registration –
 A registrar server, also known as a registration server, accepts SIP REGISTER
requests.
 The contact information from the request is then made available to other SIP servers
(proxies and redirect servers).
 To header field contains the name of the resource being registered, and the Contact
header fields contain the contact or device URIs.
 It creates a temporary binding between the address of record (AOR) URI in the To
and the device URI in the Contact header field.
 Heisenberg sends a SIP REGISTER request to a type of SIP server known as a registrar
server.
 SIP registrar server receives the message and uses the information in the request to
update the database used by proxies to route SIP requests.
 The registrar binds the SIP URI of Heisenberg and the IP address of the device in a
database that can be used.
 When a proxy server with access to the database receives an INVITE request
addressed to Heisenberg’s URI (i.e., an incoming call), the request will be proxied to
the Contact URI of the currently registered device.

 To header field contains the URI that is being registered.

** SIP URI in the Contact address is stored by the registrar.

 expires=3600 means how long the registration is valid.

 Registration is typically performed automatically on initialization of a SIP device and
at regular intervals.
 When 401 received as unathorise
 Authorization: Digest username="36602", realm="example.com",
Simple SIP session establishment –
VIA - first header field following the start line shown is a Via header field.

- Each SIP device that originates or forwards a SIP message stamps its own address in a Via
header field, usually written as a host name that can beresolved into an IP address using a
DNS query.

- The Via header field contains the SIP version number (2.0), a “/”, then UDP for UDP
transport, a space, the hostname or address, a colon, then a port number (in this example
the “well-known” SIP port number 5060)

Max-Forwards - It is initialized to some large integer and decremented by each SIP server, which
receives and forwards the request, providing simple loop detection.

To and From - show the originator and destination of the SIP request.SIP requests are routed based
on the Request-URI instead of the To URI.

- This is because the Request-URI can be changed and rewritten as a request is forwarded, while the
To URI generally stays the same. When a name label is used, as in this example, the SIP URI is
enclosed in brackets <>.

Call-ID - it is an identifier used to keep track of a particular SIP session.The originator of the request
creates a locally unique string.

 In addition to the Call-ID, each party in the session also contributes a random identifier,
unique for each call, called as tags.
 Are included in the To and From header fields as the session is established.
  The initial INVITE shown contains a From tag but no To tag.
 The initiator of the session that generates the establishing INVITE generates the unique Call-
ID and From tag.
 In the response to the INVITE, the user agent answering the request will generate the To tag.
 The combination of the local tag, remote tag & the Call-ID uniquely identifies the established
session, known as a dialog.

** Dialog identifier is used by both parties to identify this call because there could be multiple calls
set up between them.

CSeq - It contains a number, followed by the method name, INVITE as here. This number
incremented for each new request sent.

** Via, Max-Forwards, To, From, Call-ID, and CSeq header fields represent the minimum required
header field set in any SIP request message.

Contact - IT contains the SIP URI of a user agent (UA). This URI can be used to route messages
directly to UA.

Subject - This optional Subject header field is present in this example. It is not used by the protocol,
but could be displayed during alerting to aid the called party in deciding whether to accept the call.

Content-Type & Content-Length - header fields indicate that the message body is Session
Description Protocol or SDP and contains 158 octets of data.

**This media information is needed because SIP makes no assumptions about the type of media
session to be established— the caller must specify exactly what type of session (audio, video,
gaming) that he wishes to establish.

INVITE is an example of a SIP request message

- 180 Ringing is an example of a SIP response message. This message sent in response to the
INVITE.
- 180 message indicates that the called party, has received the INVITE and alerting is taking
place.
- It could be ringing a phone, a flashing message on a screen, or any other method of
attracting the attention of the called party.

** 1XX - Informational responses are used to convey noncritical information about the progress of
the call.
** To and From header fields in SIP are defined to indicate the direction of the request, not the
direction of the message.

- Since Tesla initiated this request, all responses to this INVITE will read To: Marconi From:
Tesla.

180 Ringing response has the following structure

* The To header field now contains a tag that was generated by Marconi.

- When the B end, decides to accept the call (i.e., the phone is answered), a 200 OK response
is sent. The 200 OK is an example of a success class response.

200 OK message body contains Marconi’s media information:

- Final step is to confirm the media session with an acknowledgment request.

- It means that A end has successfully received B end response.
- The exchange of media information allows the media session to be established using
another protocol: RTP in this example.
  This example also shows the client-server nature of the SIP protocol.
 SIP-enabled device must contain both SIP user agent server and SIP user agent client
software—during a typical session, both are needed.

BYE request is sent by Marconi to terminate the media session:

- Via header field in this example is populated with Marconi’s host address and contains a
new transaction identifier since the BYE is considered a separate transaction from the INVITE
or ACK transactions shown previously.

- The To and From header fields reflect that this request is originated by Marconi, as they are
reversed from the messages in the previous transaction.

- Tesla, however, is able to identify the dialog using the presence of the same local and
remote tags and Call-ID as the INVITE, and tear down the correct media session.
Confirmation response to the BYE is a 200 OK:

SIP Call with a Proxy Server –

- SIP URI is a name that is resolved to an IP address by using a SIP proxy server and DNS
lookups at the time of the call.

- A proxy server does not set up or terminate sessions, but sits in the middle of a SIP message
exchange, receiving messages and forwarding them.
 - SIP has two broad categories of URIs: ones that correspond to a user, and ones that
correspond to a single device or end point.

* User URI is known as an address of record (AOR). A request sent to AOR will require database
lookups and service, which can result in the request being sent to one or more end devices.

* Device URI is known as a contact, and typically does not require database lookups.

- - An AOR URI is usually used in To and From header fields, as this is the general way to reach
a person and is suitable for storing in address books.

- A device URI is usually used in a Contact header field and is associated with a particular user
for a shorter period of time.

- DNS lookup of Heisenberg’s SIP URI domain name (munich.de) is performed, which returns
the IP address of the proxy server proxy.munich.de, which handles that domain.

The INVITE is then sent to that IP address -

Schroedinger (wave.org) :: Heisenberg (munich.de)

This completes the two-step process of -

1. DNS lookup by user agent to locate the IP address of the proxy. Database lookup is performed by
the proxy to locate the IP address.

2. The INVITE is then forwarded to Heisenberg’s IP address with the addition of a second Via header
field stamped with the address of the proxy.
The presence of two Via header fi elds, Heisenberg knows that the INVITE has been routed through a
proxy server. After getting the INVITE,

180 Ringing response is sent by Heisenberg to the proxy –

- This response contains the Via header fields, and the To, From, Call-ID, and CSeq header
fields from the INVITE request.
- This response is then sent to the address in the first Via header field, proxy.munich.de.

* Notice that the To header field now has a tag added to it to identify this particular dialog.

- Only the first Via header field contains a received parameter, since the second Via header
already contains the literal IP address in the URI.
- Proxy receives the response, checks that the fi rst Via header field has its own address
(proxy.munich.de), uses the transaction identifier in the Via header to locate the transaction,
removes that Via header fi eld, then forwards the response to the address in the next Via
header field: IP address 100.101.102.103, port 5060.
The resulting response sent by the proxy to Schroedinger is –

- Use of Via header fields in routing and forwarding SIP messages reduces complexity in
message forwarding.
- Request required a database lookup but response requires no lookup because the routing is
embedded in the message in the Via header fields.
- This ensures that responses route back through the same set of proxies as the request.

Call is accepted by Heisenberg, who sends a 200 OK response –

Proxy forwards the 200 OK message to Schroedinger after removing the fi rst
Via header field –
 - Presence of the Contact header field with the SIP URI address of Heisenberg in the 200 OK
allows Schroedinger to send the ACK directly to Heisenberg,bypassing the proxy.

- This request, and all future requests, continue to use the tag in the To header field

- It shows that the proxy server is not really “in the call.
- It facilitates the two end points locating and contacting each other.
- This role of helping the two user agents locate each other is sometimes called rendezvous
and is a key function of the SIP protocol.

** A proxy server can force further messaging to route through it by inserting a Record-Route
header field.

- Note that the media is always end-to-end and not through the proxy.

- In SIP the path of the signaling messages is totally independent of the path of the media as the
separation of control channel and bearer channel.

Media session is ended when Heisenberg sends a BYE message –

Schroedinger confirms with a 200 OK response –

SIP Servers-
SIP servers are applications that accept SIP requests and respond to them.

Proxy Servers-
- SIP proxy server receives a SIP request from a user agent or another proxy and acts
on behalf of the user agent in forwarding or responding to the request.
- Proxy server typically has access to a database or a location service to aid it in
processing the request (determining the next hop).
- Proxy server can be either stateless or stateful.

>A stateless proxy server processes each SIP request or response based solely on the
message contents. Once the message has beenprocessed, and forwarded or
responded to, no information (such as dialog information) about the message is
stored.
> A stateless proxy never retransmits a message, and does not use any SIP timers.

>>A stateful proxy server keeps track of requests and responses received in the past,
and uses that information in processing future requests and responses.
 >> Astateful proxy server starts a timer when a request is forwarded. If no response
to the request is received within the timer period, the proxy willretransmit the
request, relieving the user agent of this task.

Forking Proxy –
A proxy server that receives an INVITE request, then forwards it to a number of locations at
the same time is called forking. It keeps track of each of the outstanding requests and the
response to each.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 45.2.32.1:5060 ;branch=z9hG4bK67865
Max-Forwards: 70
To: sip:[email protected]

From: A. N. Sarkovskii<sip:[email protected]>;tag=7643545

Call-ID: 0140092501
CSeq: 1 INVITE
Subject: Bifurcation Question
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: ...

The INVITE is received by the chaos.info proxy server, which forks to two user agents.

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 45.2.32.1:5060;branch=z9hG4bK67865
To: <sip:[email protected]>;tag=343214112
From: A. N. Sarkovskii<sip:[email protected]>;tag=7643545
Call-ID: 0140092501
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 45.2.32.1:5060;branch=z9hG4bK67865
To: <sip:[email protected]>;tag=a5ff34d9ee201
From: A. N. Sarkovskii<sip:[email protected]>;tag=7643545
Call-ID: 0140092501
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
The two responses are identical except for having different To tags and Contact URIs.
Finally, one of the two UAs answers and sends a 200 OK response.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 45.2.32.1:5060;branch=z9hG4bK67865
To: <sip:[email protected]>;tag=343214112
From: A. N. Sarkovskii<sip:[email protected]>;tag=7643545
Call-ID: 0140092501
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: ...

- A forking proxy server sends a CANCEL to the second UA to stop that phone alerting.

**If both UAs had answered, the forking proxy would have forwarded both 200 OK
responses back to the caller, who then would have had to choose which one, most likely by
accepting one and sending a BYE to the other.

** A 100 Trying response is a single hop only response.

** SIP session timer extension limits the time period over which astateful proxy must
maintain state information without a refresh re-INVITE.

Inthe initial INVITE request, a Session-Expires header field indicates a timer interval
after which stateful proxies may discard state information about the session.

User agents must tear down the call after the expiration of the timer. The caller
can send re-INVITEs to refresh the timer.
Example –

INVITE sips:[email protected] SIP/2.0

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
Supported: timer
Session-Expires: 50
Max-Forwards: 70
To: Bob <sips:[email protected]>
From: Alice <sips:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sips:[email protected]>
Content-Type: application/sdp
Content-Length: 142

Redirect Servers –

- A type of SIP server that responds to, but does not forward, requests.
- It uses a database or location service to lookup a user.
- The location information, however, is sent back to the caller in a redirection class
response (3xx)
 - Notice that the ACK request reuses the same branch ID as the INVITE and the 302
response.
- As an ACK to a non-2xx final response is considered to be part of the same
transaction as the INVITE.
- Only an ACK sent in response to a 200 OK is considered a separate transaction with a
unique branch ID.
- Also, an ACK to a non-2xx final response is a hop-by-hop response, not an end-to-
end response

 This exchange completes this call attempt, so a new INVITE is generated with a new
Call-ID and sent directly to the location obtained from the Contact header field in the
302 response from the redirect server.

** A 180 Ringing response is not sent; instead, the 200 OK response is sent right away.
- Since 1xx informational responses are optional, this is a perfectly valid response by the UAS
if Heisenberg responded to the alerting immediately and accepted the call.
Registrar Servers -

- A registrar server, also known as a registration server, accepts SIP REGISTER

requests.
- The contact information from the request is then made available to other SIP servers
(proxies and redirect servers).
 - To header field contains the name of the resource being registered, and the Contact
header fields contain the contact or device URIs.
- It creates a temporary binding between the address of record (AOR) URI in the To
and the device URI in the Contact header field.

** The CANCEL method is a hop-by-hop request.

** A proxy receiving a CANCEL immediately sends a 200 OK response back to the sender and
generates a new CANCEL, which is then forwarded in the next hop to the same set of
destinations as the original request.

** An ACK to a 2xx response is generated by the end point, a 3xx, 4xx, 5xx, or 6xx response
is acknowledged on a hop-by-hop basis.

** ACK messages are only sent to acknowledge responses to INVITE requests *

SDP:

SIP Request Messages–

The types of SIP requests are called methods
 - INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS methods are the original six
methods in SIP.
- REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, UPDATE, INFO, and PRACK are other
methods.

- UA receiving a method/request it does not support replies with a 501 Not Implemented
response.
- These are case sensitive and conventionally use all uppercase.

INVITE –

- Itused to establish media sessions between user agents.

- It is similar to a Setup message in ISDN or an initial address message (IAM) in ISUP.
- Responses to INVITEs are always acknowledged with the ACK method.
- INVITE usually has a message body containing the media information of the caller.
- If an INVITE does not contain media information, the ACK contains the media
information of the UAC>> can also say as Delay Offer.
- If the media information contained in the ACK is not acceptable, then the called
party must send a BYE to cancel the session.
-
A CANCEL cannot be sent because the session is already established.

- A media session is considered established when the INVITE, 200 OK, and ACK
messages have been exchanged between the UAC and the UAS.
- A successful INVITE request establishes a dialog between the two user agents, which
continues until a BYE is sent by either party to end the session.

- An INVITE sent for an existing dialog references the same Call-ID as the original
INVITE and contains the same To and From tags. Sometimes called a re-INVITE, the
request is used to change the session characteristics or refresh the state of the
 dialog. The CSeq command sequence number is incremented so that a UAS can
distinguish the re-INVITE from a retransmission of the original INVITE.

- A re-INVITE must not be sent by a UAC until a final response to the initial INVITE has
been received—instead, an UPDATE request can be sent.

** An Expires header in an INVITE indicates to the UAS how long the call request is valid.

INVITE request with a SDP message body as -

INVITE sip:[email protected];user=phone SIP/2.0

Via: SIP/2.0/UDP salzburg.edu.at:5060;branch=z9hG4bK1d32hr4
Max-Forwards:70
To: <sip:[email protected];user=phone>
From: Christian Doppler <sip:[email protected]>
;tag=817234
Call-ID: 12-45-A5-46-F5-43-32-F3-C2
CSeq: 1 INVITE
Subject: Train Timetables
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE,
NOTIFY
Contact: sip:[email protected]
Content-Type: application/sdp
Content-Length: 195
v=0
o=doppler 2890842326 2890844532 IN IP4 salzburg.edu.at
s=-
c=IN IP4 50.61.72.83
t=0 0
m=audio 49172 RTP/AVP 97 98 0
a=rtpmap:97iLBC/8000
a=rtpmap:98 SPEEX/8000
a=rtpmap:0 PCMU/8000

REGISTER –

- It is used by a UA to notify a SIP network of its current Contact URI (IP address).
 - It is necessary, however, for a user agent to register to receive incoming calls from
proxies that serve that domain.
- To header contains the SIP URI of the AOR (address of record) of the user agent that
is being registered.
- The From contains the SIP URI of the sender of the request, usually the same as the
To header.
-

BYE --

- It is used to terminate an established media session.

- A BYE is sent only by UAs participating in the session, never by proxies or other third
parties.
- It is an end-to-end method, so responses are only generated by the other UA.
- A BYE cannot be used to cancel pending INVITEs.

BYE sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP port443.hotmail.com:54212;branch=z9hG4bK312bc
Max-Forwards:70
To: <sip:[email protected]>;tag=63124
From: <sip:[email protected]>;tag=9341123
Call-ID: 34283291273
CSeq: 47 BYE
Content-Length: 0

ACK --

- It is used to acknowledge final responses to INVITE requests.

 - Final responses to all other requests are never acknowledged.
- CSeq number is never incremented for an ACK, but the CSeq method is changed to
ACK as UAS can match the CSeq number of the ACK with the number of the
corresponding INVITE.

** For 2xx responses, the ACK is end-to-end, but for all other final responses it is done on a
hop-by-hop basis when stateful proxies are involved.

- ACKs to 2xx responses allows a message body to be transported.

- ACK generated in a hop-by-hop acknowledgment will contain just a single Via header
with the address of the proxy server generating the ACK.

- A hop-by-hop ACK reuses the same branch ID as the INVITE since it is considered part
of the same transaction.
- A end-to-end ACK uses a different branch ID as it is considered a new transaction.

A stateful proxy receiving an ACK message must determine whether or not the ACK should
be forwarded downstream to another proxy or user agent.

Is the ACK a hop-by-hop ACK or an end-to-end ACK ?

This is done by comparing the branch ID for a match pending transaction branch IDs. If there
is not an exact match, the ACK is proxied toward the UAS. Otherwise, the ACK is for this hop
and is not forwarded by the proxy.
CANCEL –

- It is used to terminate pending INVITEs.

 - It can be generated by either user agents or proxy servers provided that a 1xx
response containing a tag has been received, but no final response has been
received.
- CANCEL is a hop-by-hop request and receives a response generated by the next
stateful element.
- CSeq is not incremented for this method so that proxies and user agents can match
the CSeq of the CANCEL with the CSeq of the pending INVITE to which it
corresponds.

* CANCEL only has meaning for an INVITE since only an INVITE may take several seconds (or
minutes) to complete. All other SIP requests complete immediately.

- A proxy does not wait for responses to the forwarded CANCEL requests, but
responds immediately.
- UA confirms the cancellation with a 200 OK response to the CANCEL and replies to
the INVITE with a 487 Request Terminated response.

OPTIONS –

- it is used to query a user agent or server about its capabilities and discover its
current availability.

* A proxy never generates an OPTIONS request.

- Response to OPTIONS request can contain Allow, Accept, Accept-Encoding, Accept-

Language, and Supported headers indicating its capabilities.
- Feature tags (such as audio, video, and isfocus should be included with the Contact
header field.

OPTIONS sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP cavendish.kings.cambridge.edu.uk
;branch=z9hG4bK1834
Max-Forwards:70
To: <sip:[email protected]>
From: J.C. Maxwell <sip:[email protected]>
;tag=34
Call-ID: 747469e729acd305
CSeq: 29 OPTIONS
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP cavendish.kings.cambridge.edu.uk;tag=512A6
;branch=z9hG4bK0834 ;received=192.0.0.2
To: <sip:[email protected]>;tag=432
From: J.C. Maxwell <sip:[email protected]>
;tag=34
Call-ID: 747469e729acd305
CSeq: 29 OPTIONS
Contact: <sip:[email protected]>;audio;video
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, REFER
Supported: replaces, join
Accept-Language: en, de, fr
Content-Type: application/sdp
Content-Length: 170
v=0
o=jc 2590845378 2590945578 IN IP4 tutors.cam.ac.uk
s=-
c=IN IP4 tutors.cam.ac.uk
t=0 0
m=audio 32852 RTP/AVP 96 0
a=rtpmap:96 SPEEX/8000
a=rtpmap:0 PCMU/8000
m=video 82852 RTP/AVP 34
a=rtpmap:34 H263/90000

Methods - REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, UPDATE, INFO, and PRACK are
left to cover

https://www.researchgate.net/figure/The-use-of-SUBSCRIBE-and-NOTIFY-SIP-
messages_fig6_281805500

SIP Header Fields –

Allow –

- it is used to indicate the methods supported by the UA or proxy server sending the
response.

Allow: INVITE, ACK, BYE, INFO, OPTIONS, CANCEL

Call-ID -
- It is mandatory in all SIP requests and responses.
- It is part of the dialog used to uniquely identify a call between two user agents.
- A Call-ID is always created by a user agent and is never modified by a server.

Call-ID: 34a5d553192cc35
Call-ID: 44fer23ei4291dekfer34231232

Contact –

- It is used to convey a URI that identifies the request originator.

- It must be present in INVITE requests and 200 OK responses to invitations.
- Contact header fields may also be present in 1xx, 2xx, 3xx & 485 responses but Only
in a REGISTER request, a special Contact:*, along with an Expires:0
- It may contain a display name that can be in quotes. If a display name is present, the
URI will be enclosed in <>.
- It may contain a feature tag, which can be used to indicate the capabilities of the
device identified by the Contact URI.

Example - feature tag isfocus is used to indicate that the URI in the Contact header field is a
conference URI.

** isfocus is a SIP UA that hosts a particular instance of a conference, called a “bridge” or

MCU in other protocols.

SIP/2.0 200 OK
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83;received=192.0.2.4
To: <sip:[email protected]>;tag=733413
From: Carol <sip:[email protected]>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:[email protected]>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog, conference
Accept: application/sdp, application/conference-info+xml,
message/sipfrag
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...

CSeq -
 - It is a required header field in every request.
- It contains a decimal number that increases for each request.
- Exception for CANCEL and ACK requests, which use the CSeq number of the INVITE
request to which it refers.

Date -
- It is used to convey the date when a request or response is sent.
* SIP only supports the use of the GMT time zone (Date: Fri, 13 Oct 1998 23:29:00 GMT)

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:[email protected]>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568

Expires -
- It is used to indicate the time interval in which the request or message contents are
valid.
- When present in an INVITE request, the header field sets a time limit on the
completion of the INVITE request.
- Once the session is established, the value from the Expires header fi eld in the
original INVITE has no effect.
- It may contain a SIP date or a number of seconds.

Expires: 60
Expires: Fri, 15 Apr 2000 00:00:00 GMT

From –
 - It indicates the originator of the request.
- It may contain a tag used to identify a particular call.
-

Record-Route –
- It is used to force routing through a proxy for all subsequent requests in a session
(dialog) between two UAs.
- A proxy inserting its address into a Record-Route header field and forces future
requests to include a Route header field containing the address of the proxy that
forces this proxy to be included.

Record-Route: <sip:proxy1.carrier.com;lr>, <sip:fi rewall33.corporation.com;lr>

Record-Route: sip:139.23.1.44;lr

Subject -It is used to indicate the subject of the media session.

To -
- It is a required header field in every SIP message used to indicate the recipient of the
request.
- Any response generated by a proxy must have a tag added to the To header field.

* The To header field URI is never used for routing—the Request-URI is used for this
purpose.

Via –
 - It is used to record the SIP route taken by a request and is used to route a response
back to the originator.
- UA generating a request records its own address in a Via header field.
- It contain protocol name, version number, and transport (SIP/2.0/UDP, SIP/2.0/TCP,
etc.) and may contain port numbers and parameters such as received, rport, branch,
maddr, and ttl.
- A received tag is added to a Via header field if a UA or proxy receives the request
from a different address than that specified in the top Via header field.

* If an rport tag is included in a Via in a request, a proxy will insert the port the request was
received on and use this port for routing the response.
* This indicates that a NAT or firewall proxy is in the message path.

P-Asserted-Identity -
- It is used between trusted proxies to assert the identity of a UA that has been
authenticated using some means.
- A UA receiving a request from a proxy that it trusts will typically render the value in a
P-Asserted-Identity header field to the user as a “Verified Caller ID” as opposed to a
From header value which is unverified.
- A proxy receiving a P-Asserted-Identity from another proxy that it does not trust will
remove the header field.

P-Asserted-Identity: <sip:[email protected]>

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
To: <sip:[email protected]>
From: "Anonymous" <sip:[email protected]>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:[email protected]>
P-Asserted-Identity: tel:+14085264000

Max-Forwards –
- It is used to indicate the maximum number of hops that a SIP request may take.
- A proxy receiving the header fi eld with a value of zero discards the message and
sends a 483 Too Many Hops response back to the originator.
- The suggested initial value is 70 hops.

Max-Forwards: 10

Session-Expires –
- It is used to specify the expiration time of the session.
- To extend the session, either UA can send a re-INVITE or UPDATE with a new
Session-Expires header field.
- At the expiration of the interval in the Session-Expires, either UA may send a BYE and
call-stateful proxies may destroy any state information.

Session-Expires: 3600

Content-Language –

- It indicate the language of a message body. It contains a language tag, which

identifies the language.

Content-Language: en

Content-Length -
- It is used to indicate the number of octets in the message body. A Content-Length: 0
indicates no message body.

Content-Length: 0

Content-Type -
 - It is used to specify the Internet media type in the message body.
- If this header fi eld is not present, application/sdp is assumed.

Content-Type: application/sdp

SIP Response Messages –

 - SIP response is a message generated by a UAS or a SIP server to reply to a request
generated by a UAC.

1) 1XX Informational / Provisional -

- 1xx, is used to indicate call progress.
- These are end-to-end responses and may contain message bodies, except 100 Trying
response.
- The first 1XX response received by the UAC confirms receipt of the INVITE.
- 1XX responses are optional—a UAS can send a final response without first sending an 1XX
response.
- final responses to an INVITE receive an ACK to confirm receipt.
- 1XX provisional responses are not acknowledged, except when using the PRACK method.

100 Trying -
> It is a hop-by-hop request. It is never forwarded and may not contain a message body.
> It does not contain a To tag and hence does not create an early dialog.

180 Ringing -
> It is used to indicate that the INVITE has been received by the user agent and alerting is
taking place.
> When the UA answers immediately, a 200 OK is sent without a 180 Ringing; this scenario is
called the “fast answer” case in telephony.

181 Call is Being Forwarded -

> It is used to indicate that the call has been handed off to another end point
The difference between 181 and 3xx level forwarding is that 181 indicates
proxy level forwarding while 3xx response is mostly used in UA level
forwarding

182 Call Queued -

> It is used to indicate that the INVITE has been received and will be processed in a queue.
183 Session Progress -
> It indicates that information about the progress of the session (call state) may be present
in a message body or media stream.
> It is an end-to-end response and establishes a dialog (must contain a To tag and Contact).
> It allow a UAC to hear a ring tone, busy tone, or recorded announcement in calls through a
gateway into the PSTN.

2) 2XX Success -
- It indicate that the request has succeeded or has been accepted.

200 OK -
> It used to accept a session invitation, it will contain a message body containing the media
properties of the UAS.
> It used in response to other requests, it indicates a successful completion or receipt of the
request.

202 Accepted -
> It indicates that the UAS has received and understood the request, but that the request
may not have been authorized or processed by the server.
> It is commonly used in responses to SUBSCRIBE.

204 No Notification -
> It is used in response to a SUBSCRIBE request that was successful but no notifi cation
associated with the request will be sent.

3) 3XX Redirection -
- It is sent by a SIP server acting as a redirect server in response to an INVITE,
- A UAS, can send a redirection class response to implement certain types of call forwarding
features.
- UAC can be configured to automatically generate a new INVITE upon receipt of a
redirection class response without requiring user intervention.
- To prevent looping, the server must not return any addresses contained in the request Via
header fi eld, and the client must check the address returned in the Contact header field.

300 Multiple Choices -

> This response contains multiple Contact header fields, which indicate that the location
service has returned multiple possible locations for the sip in the Request-URI.

301 Moved Permanently -

> It contains a Contact header fi eld with the new permanent URI of the called party. The
address can be saved and used in future INVITE requests.
302 Moved Temporarily -
> It contains a URI that is currently valid but is not permanent.
> the Contact header field should not be cached across calls unless an Expires header field is
present, in which case the location is valid for the duration of the time specified.

305 Use Proxy -

> It contains a URI that points to a proxy server who has authoritative information about the
calling party.

380 Alternative Service -

> It returns a URI that indicates the type of service the called party would like. An example
might be a redirect to a voicemail server.

4) 4XX Client Error –

- It is used by a server or UAS to indicate that the request cannot be fulfilled as it was
submitted.
- These responses will require user intervention before a new request can be generated.

400 Bad Request -

> It indicates that the request was not understood by the server.
> Might be a request that is missing required header fi elds such as To, From, Call-ID or cSeq.
> It is also used if a UAS receives multiple INVITE requests (not retransmissions) for the same
Call-ID.

401 Unauthorized -
> It indicates that the request requires the user to perform authentication.

403 Forbidden -
> It is sent when the server has understood the request, found the request to be correctly
formulated, but will not service the request.
> It is used to deny a request.

404 Not Found -

> It indicates that the user identified by the sip URI in the Request-URI cannot be located by
the server, or that the user is not currently signed on with the user agent.

405 Method Not Allowed -

> It indicates that the server or user agent has received and understood a request but is not
willing to fulfill the request.

406 Not Acceptable -

>it indicates that the request cannot be processed due to a requirement in the request
message.
> Accept header field in the request did not contain any options supported by the UAS.
407 Proxy Authentication Required -
> It sent by a proxy indicates that the UAC must first authenticate itself with the proxy
before the request can be processed.
> The response should contain information about the type of credentials required by the
proxy in a Proxy- Authenticate header fi eld.

SIP/2.0 407 Proxy Authorization Required

Via: SIP/2.0/UDP discrete.sampling.org:5060;branch=z9hG4bK6563
;received=65.64.140.198;rport=17234
From: Shannon <sip:[email protected]>;tag=59204
To: Schockley<sip:[email protected]>;tag=142334
Call-ID: adf8gasdd7fl d
CSeq: 1 INVITE
>>> Proxy-Authenticate: Digest realm=”sampling.org”, qop=”auth”,
nonce=”9c8e88df84df1cec4341ae6cbe5a359”,
opaque=””, stale=FALSE, algorithm=MD5
Content-Length: 0

408 Request Timeout -

> It is sent when an Expires header field is present in an INVITE request and the specified
time period has passed.

INVITE sips:[email protected] SIP/2.0

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
Supported: timer
Session-Expires: 50
Max-Forwards: 70
To: Bob <sips:[email protected]>
From: Alice <sips:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sips:[email protected]>
Content-Type: application/sdp
Content-Length: 142

> A stateful proxy can send this response after the request transaction times out without
receiving a final response.

415 Unsupported Media Type -

> It is sent by a user agent indicates that the media type contained in the INVITE request is
not supported.

422 Session Timer Interval Too Small -

> It is used to reject a request containing a Session-Expires header field with too short an
interval.
480 Temporarily Unavailable -
> It indicates that the request has reached the correct destination, but the called party is not
available for some reason.

483 Too Many Hops -

> It indicates that the request has been forwarded the maximum number of times as set by
the Max-Forwards header in the request.

484 Address Incomplete -

> It indicates that the Request-URI address is not complete.

486 Busy Here -

487 Request Terminated -

> It can be sent by a UA that has received a CANCEL request for a pending INVITE request.
> A 200 OK is sent to acknowledge the CANCEL, and a 487 is sent in response to the INVITE.

488 Not Acceptable Here -

> It indicates that some aspect of the proposed session is not acceptable and may contain a
Warning header field indicating the exact reason.

5) 5XX Server Error –

This class of responses is used to indicate that the request cannot be processed because of
an error with the server.

500 Server Internal Error -

> It indicates that the server has experienced some kind of error that is preventing it from
processing the request.
>client can retry the request again at this server after several seconds.

501 Not Implemented -

> It indicates that the server is unable to process the request because it is not supported.

502 Bad Gateway -

> It is sent by a proxy that is acting as a gateway to another network, and indicates that
some problem in the other network is preventing the request
from being processed.

503 Service Unavailable -

> It indicates that the requested service is temporarily unavailable.

504 Gateway Timeout -

> It indicates that the request failed due to a timeout encountered in the other network to
which that the gateway connects.
6) 6XX Global Error –

- This response class indicates that the server knows that the request will fail wherever it is
tried.
- Only a server that has definitive knowledge of the user identified by the Request-URI in
every possible instance should send a global error class response.
Session Description Protocol (SDP)
- It contains the following information about the media session:
- IP address (IPv4 or IPv6 address or host name);
- RTP profile (usually RTP/AVP although there are others such as RTP/SAVP);
- Port number (used by UDP or TCP for transport);
- Media type (audio, video, interactive whiteboard, and so forth);
- Media encoding scheme (PCM A-Law, MPEG II video, and so forth).

-- In addition, SDP contains information about the following:

• Subject of the session;
• Start and stop times;
• Contact information about the session.

- SDP message is composed of a series of lines, called fields.

- SDP was not designed to be easily extensible. The only way to extend or add new
capabilities to SDP is to define a new attribute type.
Example -

v=0
o=johnston 2890844526 2890844526 IN IP4 43.32.1.5
s=IETF Update
i=This broadcast will cover the latest from the IETF
u=http://www.sipstation.com
e=Alan Johnston [email protected]
p=+1-314-555-3333 (Daytime Only)
c=IN IP4 225.45.3.56/236 (** IP address that will be sending the media packets)
b=CT:144
t=2877631875 2879633673
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 23422 RTP/AVP 31
a=rtpmap:31 H261/90000

v= It contains the SDP version number

o= It contains information about the originator of the session and session identifiers.
o=username session-id version network-type address-type address

s= It contains a name for the session.

i= It contains information about the session.

u= It contains a uniform resource indicator (URI) with more information about the session.

e= It contains an e-mail address of the host of the session.

p= It contains a phone number. The phone number should be given in globalized format,
beginning with a +, then the country code, a space or −, then the localnumber. Either spaces
or - are permitted as spacers in SDP. A comment may be present inside brackets( ).

c= It contains information about the media connection.

c=network-type address-type connection-address

b= It contains information about the bandwidth required.

b=modifier:bandwidth-value
** CT is used for multicast session to specify the total bandwidth that can be used by all
participants in the session.
** AS is used to specify the bandwidth of a single site. The BW value parameter is the
specified number of kilobytes per second.

t= It contains the start time and stop time of the session.

t=start-time stop-time
k= fi eld was used to carry encryption keys // a=crypto or a=key-mgt should be used

m= It contains information about the type of media session.

m=media port transport format-list
* media parameter is either audio, video, text, application, message, image, or control
* port parameter contains the port number
* transport contains the transport protocol or the RTP profi le used
* format-list contains more information about the media. Usually, it contains media payload
types defined in RTP audio video profiles.

Attributes ---

a= It contains attributes of the preceding media session.

It used to extend SDP to provide more information about the media.

m=audio 49430 RTP/AVP 0 6 8 99

a=rtpmap:0 PCMU/8000
a=rtpmap:6 DVI4/16000
a=rtpmap:8 PCMA/8000
a=rtpmap:99iLBC
Attributes can be either session level or media level in SDP.

- Session level means that the attribute is listed before the first media line in the SDP.
If this is the case, the attribute applies to all the media lines below it.

- Media level means it is listed after a media line. In this case, the attribute only applies to
this particular media stream.

SDP can include both session level and media level attributes. If the same attribute appears
as both, the media level attribute overrides the sessionlevel attribute for that particular
media stream

Example, the caller Tesla wants to set up an audio and video call with two possible audio
codecs and a video codec in the SDP carried in the initial INVITE -

v=0
o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org
s=-
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
m=video 49172 RTP/AVP 32
a=rtpmap:32 MPV/90000
Special Case—Call Hold -

One party in a call can temporarily place the other on hold (i.e., suspending the media
packet sending). This is done by sending an INVITE with an identical SDP to that of the
original INVITE but with a=sendonly attribute present. The call is made active again by
sending another INVITE with the a=sendrecv attribute present.

Static and Dynamic Payloads –

- Used to identify the media codec in the media line of SDP.

- Static payload types are considered static because a given payload number defined
in the specification always refers to that particular codec.

For example, PT 0 for audio always means G.711 PCM codec.

- The use of a=rtpmap attribute for static payloads is optional, although it is considered good
practice to include it.

-- Dynamic payload types are in the range of 96–127. Payloads in this range do not refer to a
particular codec; instead the required a=rtpmap attribute must be used to indicate the
payload.

-- Rules associated with the use of dynamic payloads in the SDP offer answer exchange are -

• Dynamic payloads must be negotiated with SDP.

• The a=rtpmap attribute is mandatory.
• Dynamic payload numbers cannot be redefined within a session.
• Dynamic payload numbers do not need to be the same in both directions of a bidirectional
session.

The last rule means that it is possible that payload 97 means one codec in one direction but
another codec in a different direction.
Media Transport Protocol –
a) Real-Time Transport Protocol (RTP)

- It is developed to enable the transport of real-time datagrams containing voice, video, or

other information over IP.
- RTP does not provide any quality of service over the IP network.
- RTP allows for the detection of some of the impairments introduced by an IP network, such
as:Packet loss :: Variable transport delay :: Out of sequence packet arrival :: Asymmetric
routing

* In terms of media quality, the 2 important factors are the packet loss rate and the end-to-
end latency.

- (RTP) is an application layer protocol that uses UDP for transport over IP.

RTP Header Contains –

- Version (V): This 2-bit fi eld is set to 2, the current version of RTP

- Padding (P): If this bit is set, there are padding octets added to the end of the packet to
make the packet a fixed length. This is most commonly used if the media stream is
encrypted.

- Extension (X): are defined by certain payload types

- CSRC count (CC): It contains the number of content source identifiers (CSRC). It is only used
by mixers that take multiple RTP streams and output a single RTP stream.

- Marker (M): This single bit is used to indicate the end of a complete frame in video, or the
start of a talk-spurt in silence-suppressed speech.

- Payload type (PT): 7-bit field defines the codec in use.

- Sequence Number: This 16-bit field is incremented for each RTP packet sent and is used to
detect missing/out of sequence packets.RTP allows detection of a lost packet by a gap in the
Sequence Number.

- Timestamp: This 32-bit field indicates in relative terms the time when the payload was
sampled. It allows the Rx to remove jitter and to play back the packets at the right interval
assuming sufficient buffering.

- Synchronization source identifier (SSRCI): This 32-bit field identifies the sender of the RTP
packet. At the start of a session, each participant chooses an SSRC number randomly.
- Contributing source identifier (CSRC): This fi eld is only present if the RTP packet is being
sent by a mixer, which has received RTP packets from a number of sources and sends out
combined packets.

* A continuous bit rate codec such as PCM will have a linearly increasing Timestamp.
* A variable bit rate codec, however, which sends packets at irregular intervals, will have an
irregularly increasing Timestamp, which can be used to play back the packets at the correct
interval.

>> RTP media sessions are unidirectional

*** A low bit rate codec that is optimized for transmitting vocal sounds will not transport
the superimposed sine waves of a DTMF signal without introducing significant noise, which
may cause the DTMF digit receiver to fail to detect the digit. As a result, it is useful to switch
to another codec when the sender detects a DTMF tone.

*** As an RTP packet contains the payload type, it is possible to change codecs on the fly
without any signaling information being exchanged between the UAs. Switching codecs in
general should probably not be done without a SIP signaling exchange (re-INVITE).

> In RTP, a translator is an element that converts the codec or sampling rate of an RTP
stream.
An RTP mixer is an element that combines multiple RTP streams into a single RTP stream in
a media specific way.

b) RTP Control Protocol (RTCP)

- It allows participants in an RTP session to send each other quality reports and statistics,
and exchange some basic identity information.
- RTCP traffic is all overhead & the bandwidth allocated to these messages remains fixed
regardless of the number of participants.

* For example, in a basic two-participant audio RTP session, the RTP/AVP profi le states that
RTCP packets are to be sent about every 5 seconds; forfour participants, RTCP packets can
be sent every 10 seconds.

- It gives feedback on the quality of the connection including information such as:
• Number of packets sent and received;
• Number of packets lost;
• Packet jitter.

* RTCP uses the next highest port from the RTP port
DTMF Transport -
- DTMF must be transported and supported for user signaling—for example, when entering
a personal identifi cation number (PIN), (IVR) systems, telephonebanking, and many other
systems use DTMF tones for signaling.

- It generates two superimposed sine waves at particular frequencies to send a particular

digit (0–9, *, #, or, less commonly, A–F).

- low bit rate codecs, which are optimized for encoding voice, often do not reliably encode
DTMF tones. As a result, there is a need to transport DTMF not as sine waves but as actual
digits.

* A payload known as telephone-events has been defined for transport over RTP.

Payload contains:

• Event: an octet used to encode the event such as the DTMF key pressed;
• End (E) bit: a bit used to indicate the end of the event;
• Reserved (R) bit: a bit reserved for future use, set to zero and ignored;
• Volume: 6 bits for the level of the tone in dBm0;
• Duration: 16 bits used for a timestamp for the event duration.

> When a user presses a DTMF key, or a gateway detects a DTMF tone in band, an RTP
telephone-events packet is created and sent.
- Marker (M) bit in the RTP header is set to indicate that this is the fi rst packet sent.

* Update RTP telephone-events are sent typically every 50 ms.

> When the key is released or the DTMF tone is no longer detected, a fi nal RTP
telephoneevent packet is created. The end (E) bit will be set and the duration fi eld will
contain the actual tone duration.
Mute Call Issue

If mute call pursue in the trunk it can reduce ACD

Solution for mute call

NAT port mismatch / Firewall block the call : Port forwarding

Codec Issues

TDm

Loop port issue mismatching tx rx