NAT traversal using STUN and TURN

WebRTC : Web-based real-time communications is a gamechanger for real-time communication systems. WebRTC is one such open-source, royalty-free, unencumbered browser-based platform using the browser’s embedded media application programming interface (API). It allows developers to add custom JavaScript & HTML5 to control the media setup and flow. WebRTC has enabled developers to build apps, sites, widgets, plugins and extensions capable of delivering simultaneous audio, video, data, and screen-sharing capability in a peer to peer fashion.

Issues accross Networks : But something which escapes our attention is how media is traversing across the network. Of course, the webrtc sessions run smoothly when both the peers are on the open public internet without any restrictions or firewall blocks. But the real problem begins when one of the peers is behind a Corporate/Enterprise network or using a different Internet service provider with some security restrictions. In such a case the normal ICE capability of WebRTC is not sufficient to set up a bidirectional media streaming setup. For network restriction what is required is a NAT ( Network Address Traversal) mechanism that performs address discovery.

NAT and ICE Solution : STUN and TURN server protocols handle session initiations with handshakes between peers in different network environments. In the case of a firewall blocking a STUN peer-to-peer connection, the system fallback to a TURN server which provides the necessary traversing mechanism through the NAT.

Lets study from the start ie ICE.


Network Address Translation provides a mapping of internal to external IP addresses. This helps in network address modification for packets which in transit accross a tarfic routinig node such as inter networks.

A private address on the inside of the NAT is mapped to an external public address. Port address translation (PAT) resolves conflicts that arise when multiple hosts happen to use the same source port number to establish different external connections at the same time.

Some ways to acheive this

  • Application Layer Gateway (ALG) 
  • Interactive Connectivity Establishment ( ICE )
  •  UPnP Internet Gateway Device Protocol
  • propertiary SIP based Session Border Controller, so on

Lets us just look at ICE in detail which is the default implementation for WebRTC

What is ICE and why is it used ?

ICE (Interactive Connectivity Establishment )  framework ( mandatory by WebRTC standards  ) find network interfaces and ports in Offer / Answer Model to exchange network based information with participating communication clients. ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN)

ICE is defined by RFC 5245 – Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols.

Sample WebRTC offer holding ICE candidates :

type: offer, sdp: v=0
o=- 3475901263113717000 2 IN IP4
t=0 0
a=group:BUNDLE audio video data
a=msid-semantic: WMS dZdZMFQRNtY3unof7lTZBInzcRRylLakxtvc
m=audio 9 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4
a=rtcp:9 IN IP4
a=fingerprint:sha-256 F1:A8:2E:71:4B:4E:FF:08:0F:18:13:1C:86:7B:FE:BA:BD:67:CF:B1:7F:19:87:33:6E:10:5C:17:42:0A:6C:15
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
m=video 9 RTP/SAVPF 100 116 117 96
c=IN IP4
a=rtcp:9 IN IP4
a=fingerprint:sha-256 F1:A8:2E:71:4B:4E:FF:08:0F:18:13:1C:86:7B:FE:BA:BD:67:CF:B1:7F:19:87:33:6E:10:5C:17:42:0A:6C:15
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
m=application 9 DTLS/SCTP 5000
c=IN IP4
a=fingerprint:sha-256 F1:A8:2E:71:4B:4E:FF:08:0F:18:13:1C:86:7B:FE:BA:BD:67:CF:B1:7F:19:87:33:6E:10:5C:17:42:0A:6C:15
a=sctpmap:5000 webrtc-datachannel 1024

Notice the ICE candidates under video and audio. Now take a look at the SDP answer

type: answer, sdp: v=0
o=- 6931590438150302967 2 IN IP4
t=0 0
a=group:BUNDLE audio video data
a=msid-semantic: WMS R98sfBPNQwC20y9HsDBt4to1hTFeP6S0UnsX
m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4
a=rtcp:1 IN IP4
a=fingerprint:sha-256 7B:9A:A7:43:EC:17:BD:9B:49:E4:23:92:8E:48:E4:8C:9A:BE:85:D4:1D:D7:8B:0E:60:C2:AE:67:77:1D:62:70
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
m=video 1 RTP/SAVPF 100 116 117 96
c=IN IP4
a=rtcp:1 IN IP4
a=fingerprint:sha-256 7B:9A:A7:43:EC:17:BD:9B:49:E4:23:92:8E:48:E4:8C:9A:BE:85:D4:1D:D7:8B:0E:60:C2:AE:67:77:1D:62:70
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
m=application 1 DTLS/SCTP 5000
c=IN IP4
a=fingerprint:sha-256 7B:9A:A7:43:EC:17:BD:9B:49:E4:23:92:8E:48:E4:8C:9A:BE:85:D4:1D:D7:8B:0E:60:C2:AE:67:77:1D:62:70
a=sctpmap:5000 webrtc-datachannel 1024
address discovery for global IP:portallocates its own address as interface to the client
binary protocolextension of STUN
doesnt stay in path after connectionstays in path after connection.
tunnels and relays media
higher priority lower priority
server and peer reflexive ICE candidates relay ICE candidates
Failed WebRTC ICE Conection
succesfull STUN Connection
ICE candidate grid

Call Flow for STUN protocol exchange

Client -> Server : binding request with attributes – CHANGE-REQUEST

Server -> Cient : binding response with attributes – MAPPED-ADDRESS, RESPONSE-ORIGIN, OTHER-ADDRESS, XOR-MAPPED-ADDRESS

STUN call flow for WebRTC Offer Answer
STUN call flow for WebRTC Offer Answer
WebRTC STUN binding request
WebRTC STUN Binding success response

WebRTC needs SDP Offer to be sent to B from A.
Client B uses this SDP offer to generate an SDP Answer for A.
The SDP ( as seen on chrome://webrtc-internals/ ) includes ICE candidates which map open ports in the firewalls.

However, in case both sides are symmetric NATs, the media flow gets blocked. For such a case TURN is used which tries to give a public IP and port mapped to internal IP and port. This relay path provides an alternative routing mechanism like a packet mirror. It can open a DTLS connection and use it to key the SRTP-DTLS media streams.

NAT types

Some types of NAT are described below

Full Cone ( Normal)

All requests from the same internal IP address and port are mapped to the same external IP address and port. It also allows external hosts to send packet to internal host by using the mapped external address.

Full cone ( credits wikipedia)

Restricted Cone

All requests from the same internal IP address and port are mapped to the same external IP address and port, but external hosts can send packet to internal host only if  internal host had previously sent a packet to that IP address.

Address Restricted cone ( credits wikipedia)

Port Restricted Cone

All requests from the same internal IP address and port are mapped to the same external IP address and port, but external hosts can send packet to internal host only if  internal host had previously sent a packet to that IP address and that port.

Port Restricted cone ( credits wikipedia)


All requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. Any traffic from same internal IP+port to a different destination uses a new mapping. Also external hosts which receives a packet can send a UDP packet back to internal host.

Symmetric NAT ( credits wikipedia).
Address and Port-Dependent Mapping (“APDM”) and APDF (Address and Port-Dependent Filtering).
Web Archieve 2018

Network Scenarios for NAT

In order to Understand this better consider various scenarios that determine the NAT Mapping Behavior one could run tests using cli or network analyzer tools and checking checking the XOR-MAPPED-ADDRESS value of the Binding Response message that the client receives

Mapping behaviour

  •  Endpoint-Independent Mapping NAT (EIM-NAT)
  • Address-Dependent Mapping NAT (ADM-NAT)
  • Address and Port-Dependent Mapping NAT (APDM-NAT)

Filtering behaviour

  • Endpoint-Independent Filtering NAT (EIF-NAT)
  • Address-Dependent Filtering NAT (ADF-NAT)
  • Address and Port-Dependent Filtering NAT (APDF-NAT)

Hole Punching

As long as one end of the connection is able to determine the dynamic association of thee other [arty by NAT and send data , hole punching can work.

Permissive NAT mapping techniques which map the same internal address/port consistently to an external address/port are suitable for hole punching such as full cone , address or port restricted NAT. However pure symmetric NAT have inconsistent destination specific port mapping and thus cannot do hole punching.

1 . No Firewall present on either peer. Both connected to open public internet

Diagrammatic representation of  this shown as follows :

WebRTC signalling and media flow on Open public network
WebRTC signalling and media flow on Open public network

In this case there is no restriction to signal or media flow and the call takes places smoothly in p2p fashion.

2.  Either one or both the peer ( could be many in case of multi conf call ) are present behind a firewall  or  restrictive connection or router configured for intranet

In such a case the signal may pass with the use of default ICE candidates or simple ppensource google Stun server such as

 { 'url': ""}]

Diagram :

WebRTC signalling when peers are behind  firewalls
WebRTC signalling when peers are behind firewalls

However the media is restricted resulting in a black / empty / no video situation for both peers  . To combat such situation a relay mechanism such as TURN is required which essentially maps public ip to private ips thus creating a alternative route for media and data to flow through .

WebRTC media flow when peers are behind NAT . Uses TURN relay mechanism
WebRTC media flow when peers are behind NAT . Uses TURN relay mechanism

Peer config should look like :

var configuration =  {
  iceServers: [
 { "url':"stun::"},
 { "url":"turn::"}

var pc = new RTCPeerConnection(configuration);

3. When the TURN server is also behind a firewall

The config file of the turn server need to be altered to map the public and private IP. The diagrammatic description of this is as follows :

WebRTC media flow when peers are behind NAT and TURN server is behind NAT as well . TURN config files bind a public interface to private interface address.
WebRTC media flow when peers are behind NAT and TURN server is behind NAT as well . TURN config files bind a public interface to private interface address .

References :

continue : Streaming / broadcasting Live Video call to non webrtc supported browsers and media players

This blog is in continuation to the attempts / outcomes and problems in building a WebRTC to RTP media framework that successfully stream / broadcast WebRTC content to non webrtc supported browsers ( safari / IE ) / media players ( VLC ).

Attempt 4: Stream the content to a WebRTC endpoint which is hidden in a video call . Pick the stream from vp8 object URL send to a streaming server

This process involved the following components :

  • WebRTC API : simplewebrtc on Chrome
  • Transfer mechanism from client to Streaming server:  webrtc media channel

Problems : No streaming server is qualified to handle a direct webrtc input and stream it on network .

Attempt 4.1 : Stream the content to a WebRTC endpoint . Do WebRTC Endpoint to RTP Endpoint bridge using Kurento APIs. 

Use the RTP port and ip address to input into a ffmpeg or gstreamer or VLC terminal command and out put a live H264 stream on another ip and port address .  

This process involved the following components :

  • API : Kurento
  • Transfer mechanism : HTML5 webrtc client -> application server hosting java -> media server -> application for webrtc media to RTP media conversation -> RTP player

Screenshots of attempts with Wowza to stream RTP from a IP and port


Problems : The stream was black which means 100% loss.

Lesson learned : RTP is not suitable for over the intgernet transmission especially with firewalls

Attempt 4.2 : Build a WebRTC Endpoint to Http endpoint in kurento and force the video audio encoding to be that of H264 and PCMU.

Code snippet for adding constraints to output media via pipeline and forcing choice of codecs( H264 for video and PCMU for audio ).

MediaPipeline pipeline = kurento.createMediaPipeline();
WebRtcEndpoint webRtcEndpoint = new WebRtcEndpoint.Builder(pipeline).build();
HttpGetEndpoint httpEndpoint=new HttpGetEndpoint.Builder(pipeline).build();

org.kurento.client.Fraction fr= new org.kurento.client.Fraction(1, 30);
VideoCaps vc= new VideoCaps(VideoCodec.H264,fr);

AudioCaps ac= new AudioCaps(AudioCodec.PCMU, 65536);


Alternatively one can opt to use gstreamer filter to force the output in raw format.

// basic media operation of 1 pipeline and 2 endpoints
MediaPipeline pipeline = kurento.createMediaPipeline();
WebRtcEndpoint webRtcEndpoint = new WebRtcEndpoint.Builder(pipeline).build();
RtpEndpoint rtpEndpoint = new RtpEndpoint.Builder(pipeline).build();

// adding Gstream filters
GStreamerFilter filter1 = new GStreamerFilter.Builder(pipeline, "videorate max-rate=30").withFilterType(FilterType.VIDEO).build();
GStreamerFilter filter2 = new GStreamerFilter.Builder(pipeline, "capsfilter caps=video/x-h264,width=1280,height=720,framerate=30/1").withFilterType(FilterType.VIDEO).build();
GStreamerFilter filter3 = new GStreamerFilter.Builder(pipeline, "capsfilter caps=audio/x-mpeg,layer=3,rate=48000").withFilterType(FilterType.AUDIO).build();

// connecting all poin ts to one another
webRtcEndpoint.connect (filter1);
filter1.connect (filter2);
filter2.connect (filter3);
filter3.connect (rtpEndpoint);

// RTP SDP offer and answer
String requestRTPsdp = rtpEndpoint.generateOffer();

End result : The output is still webm based and doesnt work on h264 clients.

Attempt 5  : Use a RTP SDP Endpoint ( ie a SDP file valid for a given session ) and use it to play the WebRTC media over Wowza streaming server

This process involved the following components

  1. WebRTC Stream and object URL of the blob containing VP8 media
  2. Kurento  WebRTC Endpoint  bridge to generate SDP
  3. Wowza Streaming server

Snippet used for kurento to generate a SDP file from WebRTC to RTP bridge

@RequestMapping(value = "/rtpsdp", method = RequestMethod.POST)
private String processRequestrtpsdp(@RequestBody String sdpOffer)
throws IOException, URISyntaxException, InterruptedException {

//basic media operation of 1 pipeline and 2 endpoinst
MediaPipeline pipeline = kurento.createMediaPipeline();
WebRtcEndpoint webRtcEndpoint = new WebRtcEndpoint.Builder(pipeline).build();
RtpEndpoint rtpEndpoint = new RtpEndpoint.Builder(pipeline).build();

//connecting all poin ts to one another
webRtcEndpoint.connect (rtpEndpoint);

// RTP SDP offer and answer
String requestRTPsdp = rtpEndpoint.generateOffer();

// write the SDP conector to an external file
PrintWriter out = new PrintWriter("/tmp/test.sdp");

HttpGetEndpoint httpEndpoint = new HttpGetEndpoint.Builder(pipeline).build();
PlayerEndpoint player = new PlayerEndpoint.Builder(pipeline, requestRTPsdp).build();

// Playing media and opening the default desktop browser;
String videoUrl = httpEndpoint.getUrl();
System.out.println(" ------- video URL -------------"+ videoUrl);

// send the response to front client
String responseSdp = webRtcEndpoint.processOffer(sdpOffer);

return responseSdp;

End result : wowza doesnt not recognize the WebRTC SDP and play the video

screenshot of wowza with SDP input

Screenshot from 2015-01-30 15:28:59

Attempt 5.1 : Use a RTP SDP Endpoint ( ie a SDP file valid for a given session ) and use it to play the WebRTC media over Default Ubuntu media player 

SDP file formed contains contents such as :

o=- 3631611195 3631611195 IN IP4
s=Kurento Media Server
c=IN IP4
t=0 0
m=audio 42802 RTP/AVP 98 99 0
a=rtpmap:98 OPUS/48000/2
a=rtpmap:99 AMR/8000/1
a=rtpmap:0 PCMU/8000
a=ssrc:2713728673 cname:user59375791@host-ad1117df
m=video 35946 RTP/AVP 96 97 100 101
a=rtpmap:96 H263-1998/90000
a=rtpmap:97 VP8/90000
a=rtpmap:100 MP4V-ES/90000
a=rtpmap:101 H264/90000
a=ssrc:93449274 cname:user59375791@host-ad1117df

End result : wowza doesnt not recognize the WebRTC SDP and play the video : deformed media

screenshot of playing from a SDP file

Screenshot from 2015-01-29 17:42:21

Attempt 5.2 : Use a RTP SDP Endpoint ( ie a SDP file valid for a given session ) and use it to play the WebRTC media over VLC using socket input

End result : nothing plays

screenshot of VLC connected to play from socket and failure to play anything

Screenshot from 2015-01-21 17:49:52

Attempt 5.3: Create a WebRTC endpoint and connected it to RTP endpoint via media pipelines . Also make the RTP SDP offer and answering the same . Play with ffnpeg / ffplay / gst playbin

String requestRTPsdp = rtpEndpoint.generateOffer();

Write the requestRTPsdp to a file and obtain a RTP connector endpoint with Application/SDP .It plays okay with gst playbin ( 10 secs without audio ). Successful attempt to play from a gst playbin

gst-launch -vvv playbin uri=file:///tmp/test.sdp 
donekurento streaming

but refuses to be played by VLC , ffplay and even wowza . The error generated with

ffmpeg -i test.sdp -vcodec copy -acodec copy -f mpegts output-file.ts


ffmpeg -re -i test.sdp -vcodec h264 -acodec mp3 -f mpegts "udp://"

End result : This results in “Could not find codec parameter for stream1 ( video:h263, none ) .Other errors types are , Could not write header for output file output file is empty nothing was encoded”

Error screenshots of trying to play the RTP SDP file with ffmpeg

ffmpeg error kurebto1
ffmpeg error kurebto2

Attempt 6 : Use a WebRTC capable media and streaming server ( eg Kurento )  to pick a live stream of VP8 .

Convert the VP8 to H264  ( ffmpeg / RTP endpoint )

Convert H264 to Mp4 using MP4 parser and pass to a streaming server  ( wowza)

End Result : yes it did work on mozilla but with considerable lag

Update : Thankfully the updates to WebRTC standards mandated the support for PCMU and AVC/H264 CB profile in the media stack of the browser thus solving the “from scratch buildup of transcoder between webrtc and non webrtc endpoints”.

  • Video Codecs : RFC 7742 specifies that all WebRTC-compatible browsers must support VP8 and H.264’s Constrained Baseline profile for video.
  • Audio Codecs : RFC 7874 specifies that browsers must support at least the Opus codec as well as G.711’s PCMA and PCMU formats.

The latest Webrtc specification lists a set of codecs which all compliant browsers are required to support which includes chrome 52 , Firefox , safari , edge.

References :

  1. RFC7742: WebRTC Video Processing and Codec Requirements
  2. RFC 7874: WebRTC Audio Codec and Processing Requirements

Read more about Webrtc Audio Video Codecs

SIP/VOIP transformation towards IMS (Total IP)

The telecommunications industry has been going through a significant transformation over the past few years. At the outset incumbent operators used to focus on mainly basic voice services and still remained profitable due to the limited number of players in the space and requirement of huge amounts as initial investment.

However, with the advent of competitive vendors, rise in consumer base, and introduction of cost effective IP based technologies a major revolution has come about. This has enabled operators to come out of their traditional business models to maintain and enhance subscriber base by providing better and cheaper voice, multimedia and data services in order to grab the biggest possible share in this multi- billion dollar industry.

The evolution in Telecom industry has been accelerating all the time. The Next-Generation Operators wants to keep pace with the rapidly changing technology by, adapting to market needs and looking at the system and business process from multiple perspectives concurrently. Communication Service Providers (CSPs) need to consider several factors in mind before proposing any solution. They need to deploy solutions which are highly automated, highly flexible, caters to customer needs coupled with ultra low operating costs.

Upgrading a softswitrch solutions to IMS

The Softswitch is decomposed into two logical components of a subscriber-facing unit and a PSTN-facing unit. 

  • Subscriber facing unit in Softswitch is upgraded to AGCF (Access Gateway Control Function) 
  • PSTN facing unit is upgraded to MGCF (Media Gateway Controller Function) to interwork with IMS as shown.

By separating the Softswitch into these components, the network can be more easily scaled for better overall network efficiencies. More AGCFs can be added as required, allowing the network to scale with an increase in subscribers. Similarly, More PSTN trunks can be added as traffic increases. Once PSTN and subscriber control functions are separated, the IMS elements, CSCF and BGCF functions can be introduced. BGCF is the interface for interconnecting IMS with legacy PSTN networks.

New SIP-based services can now be rapidly rolled out by deploying new Application Servers (AS) and its integrations to other SBC for UCC( unified communication and colloboartion ) systems. IMS has 3GPP specified ISC interface, which is a SIP-based interface for interfacing-to-application servers. Using these constructs, multiple application servers from multiple vendors can be interconnected over the IMS ISC interface.

Intelligent Networks( IN)

Telecom networks (2014) are made up of integrated service digital network (ISDN), the public switched telephone network (PSTN) ,the Public Land Mobility Network (PLMN) and many others. Intelligent networks (IN) ensures that call control is handed over to a control platform. The control platform determines how the establishment of this call shall continue. Applying IN to any of these networks has in common that call establishment is intercepted at a designated node in the network

By hosting new services on the new platform and combining new and old services CSP‟s aim to provide service bundles that would generate new revenue streams. This process is largely dependant on IMS ( IP Multimedia Subsystem ) architecture .

Transformation towards IMS (Total IP)
Transformation towards IMS (Total IP)

Optimization in operator landscape evolve as result of synergistic technologies that come together to address the innovation and cost optimization needs of operator for better user experience. In following sections different technological evolutions that are affecting overall operator ecosystems have been discussed with focus towards Service Layer.

Fixed/mobile convergence(FMC) with IMS

“Fixed Mobile Convergence is a transition point in the telecommunications industry that will finally remove the distinctions between fixed and mobile networks, providing a superior experience to customers by creating seamless services using a combination of fixed broadband and local access wireless technologies to meet their needs in homes, offices, other buildings and on the go.”

 Fixed-Mobile Convergence Alliance (FMCA)  2004

System can communicate over the cellular network, or act as a new endpoint on the IP network. Home Subscriber Server (HSS) manages subscriber data uniformly between the cellular and IP worlds. The Handoff Server runs on top of the ISC interface, and provides a seamless experience when subscribers move from the cellular network to a Wi-Fi network. The AGCF remains the functional centre of the network, but with the introduction of the HSS, has added the Cx and Sh interfaces defined by the IMS.

Legacy to IP transformation

This section broadly covered the aspects of migration from legacy IN solution to new age JAINSLEE framework based one. Applies to Legacy IN hosting voice based services mostly  such as VPN, Access Screening ,Number Portability, SIP-Trunking,Call Gapping.

Most operator environments have seen a rise in the number of service delivery platforms. Also complexity of telecom networks have increased manifold hence CSPs are facing multiple challenges. Increased efforts and costs are required for maintaining all the SDP platforms. These platforms are generally of different vendors and cater to different technologies thereby greatly increase chances of limiting the scalability and flexibility of the operator landscape. More effort required for sustaining the life cycle of the platform and challenges in integrating non compatible SDPs due to proprietary design have been stumbling blocks in the progress of CSPs across the world.

To overcome these challenges there is trend in the market to move towards SDP consolidation wherein instead of maintaining several SDPs with their proprietary design CSPs prefer maintaining a single or less number of SDPs having standardized interfaces.

SDP consolidation
SDP consolidation (1)
SDP consolidation (2)

As illustrated in the above figure there is a transition that is taking place in the industry towards consolidation of service delivery session control. This would provide a cost effective sustenance of existing applications and the rapid creation and deployment of new services leading to increased revenue recognition by CSPs.

  • Agile Development
  • Innovative services
  • open SOA based architectures
  • IN/NGN Platform and Services
  • Reuse of existing investments in legacy service platforms
  • low cost of new service development
  • faster time to market
  • Monetize investment in Network Infrastructure uplift – SIP trunking, VoLTE etc.

Services that should be covered  in the Scope of Migration from fixed line to IP telephony are:

  • Virtual Private Network (VPN) : An Intelligent Network (IN) service, which offers the functions of a private telephone network. The basic idea behind this service is that business customers are offered the benefits of a (physical) private network, but spared from owning and maintaining it.
  • Access Screening(ASC): An IN service, which gives the operators the possibility to screen (allow/barring) the incoming traffic and decide the call routing, especially when the subscribers choose an alternate route/carrier/access network (also called Equal Access) for long distance calls on a call by call basis or pre-selected.
  • Number Portability(NP) : An IN service allows subscribers to retain their subscriber number while changing their service provider, location, equipment or type of subscribed telephony service. Both geographic numbers and non-geographic numbers are supported by the NP service.


WebRTC based Unified Communication platform

Using WebRTC Solution for Delivering In Context Voice which provides new monetizing benefits to the Enterprise customers of Service Providers. This includes following components:

  • WebRTC Gateway for implementation for inter-connect with SIP Legacy
  • Enhancement of WebRTC Client with new features like Cloud Address Book, Conferencing & Social Networking hooks.
  • Cloud based solutions

Challenges in Migration to IMS  (Total IP )

Since long I have been advocating the benefits of migration to IMS  from a current fixed line / legacy/ proprietary VOIP / SS7 based system . However I decided to write this post on the challenges in migration to IMS system from a telecom provider’s view.  Though I could think of many , I have jot down the major 4 . they are as follows :

Data Migration challenges

  • Establishing a common data model definition
  • Data migration seamlessly
  • Configuration management
  • Extracting data from multiple sources and vendors , that includes legacy systems
  • Extracting data due to its large scale and volume


  • Creating an effective knowledge share and transfer for live operations
  • Training in fallback plans, standards and policies .

Customer impact

  • Minimized customer outage
  • Enhance customer experience by delivering quality services on schedule
  • Ensuring security of customer’s confidential data
  • Transfer of customer services without any impact.

Testing in replicated environment

  • Physical pre-transfer test
  • Reducing cycle time
  • Verification and validation at every change in data environment
  • Detect production issues early in the test -lifecycle

Fallback plans

  • Pilot program and real network simulation for ensuring preparedness
  • Tracking changes in new network


Service Broker Architecture for IN and IMS

Service Broker

We know that a Service broker is a service abstraction layer between the network and application layer in a telecom environment. SB( Service Broker ) can enable us to make use of existing applications and services from Intelligent Network’s SCP ( Service Control Point ), IMS’s Application Server as well as other sources in a harmonized manner.

Service brokers allow operators to selectively trigger and run multiple services on a single network. SB’s can manage the signalling interactions between the services in a centralised middleware layer, which sits between the network and the services layer. Example: The OpenCloud Service Interaction SLEE (SIS) provides service brokering and service interaction functionality for SS7 and IMS networks.

service broker

The service provider can combine the services from various sources written in various languages in numerous permutations and combinations. This saves the time, energy and reworks required to launch new services.
I have written a couple of posts before on Service Broker. Description of What is Service Broker, its definitions and application can be found below. This also defines service orchestration and harmonization.

Another post on Service Borker’s role and functions which mentions the service brokering role in network environment. But ofcourse it was a mere introduction. The following post clarifies the concept in greater light.

Advantages of using Service Broker vs Total Migration from In to IMS

I believe and it truly is a wonderful thing to make use of Service Broker while network migration from IN to IMS.The following architecture model depict the placement of Service Broker component in IN and IMS integrated environment .


The figure above portrays how a  service provider acts as a central Node for Services invocation and services composition. SB is responsible for Services Orchestration / Interaction , service development, third party integration and acts like a protocol gateway .

Let us discuss service broker in a full fleshed network’s structure . It includes the access network components and detailed core network components with the name of interfaces between all nodes.


The Applications as described by the above figure could be majorly of 4 types :

1. applications developed on a SIP application Server and invoked via SIP/ ISC

2. Applications developed over SIP servlets or JAINSLEE platform such as mobicents , Opencloud Rhino etc

3. Application developed on a SCP ( Service Control Point ) of a IN ( Intelligent Network ) . This is invoked via INAP CS1/CS1+ or CAP

4. Application developed on a J2EE server Invocated via http REST API like GSMA OneAPI such as

  • Call Control API for voice
  • Messaging API for SMS, MMS
  • localisation API

Provisioning via fixed/mobile brands «service profile» in Service Broker

Service Broker interfaces the core NGN ( next-generation networks ) and Core IMs ( IP multimedia subsystems ) via IN and SIP respectively. It is responsible to provide unform services to both endpoints such as-
subscription options
change/removal/ query options
data subscription / modification / removal / Interrogation

Provisioning via fixed/mobile brands & « service profile» in Service Broker
Provisioning via fixed/mobile brands & « service profile» in Service Broker

Architecture of SDP / Service Broker

Architecture of SDP / Service Broker
Architecture of SDP / Service Broker

OTT ( Over the Top ) Communication applications

Market trends are not in favour of Telecom Service /providers with increasing use of OTT ( Over The Top ) applications like WhatsApp, Facebook messenger, Google hangouts, skype, Viber, etc. OTT applications are often blamed to take a stake in voice traffic revenue by using IP calls where the telco could’ve charged based on its…

Harmonization of services between generations of telecommunication core layers

A communication system can be made up of many components which are individually undergoing evolution such as access layer generations, and core layer upgrades. Harmonized and uniform open standard-based service delivery platforms over legacy Proprietary codebase is the preferred choice for most service providers to save the investment in their infrastructure and programming while keeping…

SIP and SDP Messages Explained

SIP is a widely adopted application layer protocol used in VoIP calls and confernecing applciations and in IMS architeture or pure packet switched networks .

More on SIP , its packet structure , transaction and dialogs , loose and strict record routing , location service , near and far end nating , and commonly used SIP Call flows like Redirection , forking , click to Dial – in a new tab)

SIP Request and Repsosnes

Traditional SIP headers for Call setup are INVITE, ACK and teardown are CANCEL or BYE , however with more adoption newer methods specific to services were added such as :

MESSAGE Methods for Instant Message based services
SUBSCRIBE, NOTIFY standardised by Event notification extension RFC 3856
PUBLISH to push presence information to the network

Outlining the SIP Requests and Responses in tables below,

Request Message

Request Message


REGISTERA Client use this message to register an address with a SIP server
INVITEA User or Service use this message to let another user/service participate in a session. The body of this message would include a description of the session to which the callee is being invited.
ACKThis is used only for INVITE indicating that the client has received a final response to an INVITE request
CANCELThis is used to cancel a pending request
BYEA User Agent Client use this message to terminate the call
OPTIONSThis is used to query a server about its capabilities

Response Message




1xxProvisionalThe request has been received and processing is continuing
2xxSuccessAn ACK, to indicate that the action was successfully received, understood, and accepted.
3xxRedirectionFurther action is required to process this request
4xxClient ErrorThe request contains bad syntax and cannot be fulfilled at this server
5xxServer ErrorThe server failed to fulfill an apparently valid request
6xxGlobal FailureThe request cannot be fulfilled at any server

SIP headers

Display names

From originators sipuri

CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.

Contact – SIP URI that represents a direct route to the originator usually composed of a username at a fully qualified domain name (FQDN) , also IP addresses are permitted. The Contact header field tells other elements where to send future requests.

Max-Forwards -to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.


Content-Type – description of the message body.

Content-Type: application/h.323 
Content-Type: message/sip   
Content-Type: application/sdp

Content-Type: multipart/signed;
        micalg=sha1; boundary=boundary42

Content-Type: application/pkcs7-signature; name=smime.p7s

Content Encoding

Content-Encoding: text/plain

Content Language

Content-Language: en

Content-Length – an octet (byte) count of the message body.


describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS. It extends the MIME Content-Type

Disposition Types :

  • “session” – body part describes a session, for either calls or early (pre-call) media
  • “render” – body part should be displayed or otherwise rendered to the user.
  • “icon” – body part contains an image suitable as an iconic representation of the caller or callee
  • “alert” – body part contains information, such as an audio clip


Accept – acceptable formats like application/sdp or currency/dollars

Header field where proxy ACK BYE CAN INV OPT REG

Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c

An empty Accept header field means that no formats are acceptable.


Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c

Accept-Language : languages for reason phrases, session descriptions, or status responses carried as message bodies in the response.

Accept-Language: da, en-gb;q=0.8, en;q=0.7
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c

Tag globally unique and cryptographically random with at least 32 bits of randomness. identify a dialog, which is the combination of the Call-ID along with two tags ( from To and FROM headers )

Call-Id uniquely identify a session

contact – sip url alternative for direct routing


Expires – when msg content is no longer valid

Mandatory SIP headers

INVITE sip:altanai@domain.comSIP/2.0
Via: SIP/2.0/UDP
From: Bob
To: Altanai

Informational headers

Call-Info additional information for example, through a web page. The “card” parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA

Call-Info: ;purpose=icon, ;purpose=info

Contact: “Mr. Watson” ;q=0.7; expires=3600,
“Mr. Watson” ;q=0.1 m: ;expires=60

Priority indicates the urgency of the request as perceived by the client.
can have the values “non-urgent”, “normal”, “urgent”, and “emergency”, but additional values can be defined elsewhere

Subject: A tornado is heading our way!
Priority: emergency


Subject: Weekend plans
Priority: non-urgent

Subject summary or indicates the nature of call

Subject: Need more boxes
s: Tech Support

Supported enumerates all the extensions supported. can contain list of option tags, described

Supported: 100rel
k: 100rel

Unsupported features not supported

Unsupported: foo

User-Agent information about the UAC originating the request.

User-Agent: Softphone Beta1.5

Organization conveys the name of the organization to which the SIP element issuing the request or response belongs.

Organization: AltanaiTelecom Co.

Warning additional information about the status of a response.
List of warn-code

  • 300 Incompatible network protocol:
  • 301 Incompatible network address formats:
  • 302 Incompatible transport protocol:
  • 303 Incompatible bandwidth units:
  • 304 Media type not available:
  • 305 Incompatible media format:
  • 306 Attribute not understood:
  • 307 Session description parameter not understood:
  • 330 Multicast not available:
  • 331 Unicast not available:
  • 370 Insufficient bandwidth:
  • 399 Miscellaneous warning:
  • 1xx and 2xx have been taken by HTTP/1.1.

Warning: 307 “Session parameter ‘foo’ not understood”
Warning: 301 “Incompatible network address type ‘E.164′”

Authetication and Authorization related headers

Authentication-Info mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field.

Authentication-Info: nextnonce=”47364c23432d2e131a5fb210812c”

Authorization authentication credentials of a UA

Authorization: Digest username=”Alice”, realm=””, nonce=”84a4cc6f3082121f32b42a2187831a9e”, response=”7587245234b3434cc3412213e5f113a5432″

Proxy-Authenticate contains an authentication challenge.

Proxy-Authenticate: Digest realm=””,domain=””, qop=”auth”,
nonce=”f84f1cec41e6cbe5aea9c8e88d359″,opaque=””, stale=FALSE, algorithm=MD5


exponential back-off on re-transmissions 

Session Expire Header Feild

limit the time period over which a stateful proxy must maintain state information.

  • User agents must tear down the call after the expiration of the timer , or
  • aller can send re-INVITEs to refresh the timer, enabling a “keep alive” mechanism for SIP.

SDP (Session Description Protocol)

SIP can bear many kinds of MIME attachments , one such is SDP. It is a standard for protocol definition for exchange of media , metadata and other transport realted attributes between the particpants before establishing a VoIP call.

SDP session description is entirely textual using the ISO 10646 character set in UTF-8 encoding and described by application/SDP media type.

It should be noted that SDP itself does not incorporate a transport protocol and can be used with difference protocls like Session announcement proctols (SAP) , SIP , HTTP , Electronic MAIl MIME extension, RTSP etc.

In case of SIP SDP is encapsulated inside of SIP packet and use offer/answer model to convey information about media stream in multimedia session.

SDP body contains 2 parts : session based section starting with v= line and media bsesction starting with m= line
Media and Transport Information can contain type of media like video, audio , transport protocol like RTP/UDP/IP, H.320 and format of the media such as H.261 video, MPEG video, etc.

Session Description in SDP

protocol version ( v= ) protocol version mostly version 0

originator and session identifier ( o= )

o= < username > <session-id> <session-version> <net-type> <addr-type> <unicast address>
o=- 6476888576284874344 2 IN IP4

session name ( s=) and session information ( i= ) session name is textual and can contain empty space or even s=- but must not be empty. Session infomration is optional textual information about the session

URI of description ( u = )

Email Address and Phone Number (“e=” and “p=”)

Both are optional free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding

Nothe that if given the Phone numbers SHOULD follow international public telecommunication number specification ( ITU-T Recommendation E.164) and be preceded by a “+”. Spaces and hyphens may be used to split up a phone field to aid readability if desired.

e=Jane Doe
p=+1 617 555-6011

Connection Data ( c= ) connection information — not required if included in all media in which media specific connecion data override overall session connection data

c= <net-type> <addr-type> <connection-address>

c=IN IP4

If the session is multicast, the connection address will be an IP multicast group address . TTL shoudl be present in IPv4 multicast address .
If connection is unicast the address contains the unicast IP address of the expected data source or data relay or data sink .

Bandwidth ( b= ) interpreted as kilobits per second by default

b= <bwtype> : <bandwidth>

Encryption Keys ( k= ) Only is SDP is exchanged in secure and trusted channel, keys va be excahnged on this SDP field . Although this process is not recomended,

k= clear:< encryption key >
k= base64:< encoded encryption key >
k= uri:< URI to obtain key >
k= prompt

Attributes ( a= )

extends the SDP with values like flags

a=inactive , a=sendonly , a=sendrecv , a=recvonly

Mapping the Encoder Spec from

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

a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/48000
a=rtpmap:97 telephone-event/8000

Conferenec Type like “broadcast”, “meeting”, “moderated”, “test”,

a=type: < conf type>

Orientation portrait or landscape for whiteboard session

a=orient:  <orientation>

ICE candidates

a=rtcp-12133xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics

Frame per second for video


Quality between 0 – 10 ( 10 best still image , 5 default , 0 wrst )

a= quality: < quality >

Format specific Parameters

a=fmtp: <format> <parameters>
a=rtpmap:114 AMR-WB/16000/1
a=fmtp:114 mode-change-capability=2;max-red=220

a=rtpmap:113 AMR-WB/16000/1
a=fmtp:113 octet-align=1;mode-change-capability=2;max-red=220

a=rtpmap:102 AMR/8000/1
a=fmtp:102 mode-change-capability=2;max-red=220

a=rtpmap:115 AMR/8000/1
a=fmtp:115 octet-align=1;mode-change-capability=2;max-red=220

a=rtpmap:105 telephone-event/16000
a=fmtp:105 0-15

a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Time Description in SDP

Timing (t =)
time the session is active)

t=<start-time> <stop-time>

If the <stop-time> is set to zero, then the session is not bounded, though it will not become active until after the < start -time>.
If the <start-time> is also zero, the session is regarded as permanent.

t=0 0

Repeat Times ( r= )

zero or more repeat times for scheduling a session

r= <repeat interval> <active duration> <offsets from start-time>

time zone adjustments ( z = )

z= <adjustment time> <offset> <adjustment time> <offset> ….

useful for scejduling session during transation to daylightv saving to standard time and vice versa

Media Description in SDP

For RTP, the default is that only the even-numbered ports are used for data with the corresponding one-higher odd ports used for the RTCP belonging to the RTP session

m= <media> <port> <proto> <fmt> …

m=audio 20098 RTP/AVP 0 101

will stream RTP on 20098 and RTCP on 20099

For multiple transport ports pairs of RTP , RTCP stream are specified

m= <media> <port>/ <number of ports> <proto> <fmt> …

m=audio 20098/2 RTP/AVP 0 101
will stream one pair on RTP 20098 , RTCP 20099 and RTP 20100 , RTCP 20101

If non-contiguous ports are required, they must be signalled using a separate attribute like example, “a=rtcp:”

Additioan SDP features : In addition to normal unicast sessions , SDP can also convery multicast group address for media on IP multicast session. Private (encryption of SDP ) or public session are not treated differently by SDP and they are entorely a function of implementing mechanism like SIP or SAP. Optiopnal SDP params include URI , Categorisation “a=cat:” , Internationalisation etc

Example 1 : Typical Audio call SIP INVITE showing SIP headers in blue and SDP in green below

INVITEnbspsip:01150259917040@x.x.x.x SIP/2.0
 Via: SIP/2.0/UDP x.x.x.x:5060branch=z9hG4bK400fc6e6
 From: "123456789" ltsip:123456789@x.x.x.xgttag=as42e2ecf6
 To: ltsip:01150259917040@x.x.x.x.4gt
 Contact: ltsip:123456789@x.x.x.x4gt
 Call-ID: 2485823e63b290b47c042f20764d990a@x.x.x.x.x
 CSeq: 102 INVITE
 Date: Thu, 22 Dec 2005 18:38:28 GMT
 Content-Type: application/sdp
 Content-Length: 268

 o=root 14040 14040 IN IP4 x.x.x.x
 c=IN IP4 x.x.x.x
 t=0 0
 m=audio 26784 RTP/AVP 0 8 18 101
 a=rtpmap:0 PCMU/8000
 a=rtpmap:8 PCMA/8000
 a=rtpmap:18 G729/8000
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-16
 a=fmtp:18nbspannexb=no - - - -
 c=* (connection information - optional if included at session-level)
 b=* (bandwidth information)
 a=* (zero or more media attribute lines)

The above SDP shows 4 supported media codecs on audio stream which are 0 PCMU , 8 PCMA , 18 G729 and finally 101 used for telephone events . It also shows RTP/AVP as RTP profile and does not contain any m=cideo line which shows that this endpoint does not want a video call , only an audio one.

Example 2 : Video Vall SIP invite from Linphone

SIP URI Params

Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry defines URI params that can be sued along with SIP scheme


comp param

signalling compression of SIP messages;comp=sigcomp
Via: SIP/2.0/UDP;branch=z9hG4bK87a7;comp=sigcomp

The aobve exmaple indicates that the request has to be compressed using SigComp


SIP can use any network transport protocol. Parameter names are defined for UDP (RFC 768), TCP (RFC 761), and SCTP (RFC 2960).
For a SIPS URI, the transport parameter MUST indicate a reliable transport.

“transport=”  ( “udp” / “tcp” / “sctp” / “tls” / “ws” / other-transport );transport=tcp

maddr paarm

The server address ( detsiantion address , port , transport ) to be contacted for this user, overriding any address derived from the host field.

Although discouraged , maddr URI param has been used as a simple form of loose source routing. It allows a URI to specify a proxy that must be traversed en-route to the destination.


“user=”  ( “phone”  “ip”  “dialstring”  other-user );user=phone



“method=” Method;method=REGISTER?

annc-parameters (announcement)

sip‑ind  annc‑ind  “@”  hostport  annc‑parameters  uri‑parameters; \
; play=file://; \
; content-type=video/mpeg%3bencode%d3314M-25/625-50

sip-ind - “sip:” / “sips:”

annc-ind - “annc”

“;”  play‑param
[ “;”  delay‑param ]
[ “;”  duration‑param ]
[ “;”  repeat‑param ]
[ “;”  locale‑param ]
[ “;”  variable‑params ]
[ “;”  extension‑params ]

play-param – “play=”  prompt‑url

prompt-url – “/provisioned/”  announcement‑id

announcement-id = 1*( ALPHA / DIGIT )

content-param “content‑type=”  MIME‑type

VoiceXML Media Services

“voicexml=”  vxml-url ;  vxml-url follows the URI syntax

method-param – “method=”  ( “get” / “post” )

postbody-param- “postbody=”  token

ccxml-param – “ccxml=”  json‑value

aai-param- “aai=”  json‑value

json-value – false / null / true / object / array / number / string; \
voicexml=; \

dialog-params (prompt and collect)

DIALOG-URL = sip-ind  dialog-ind  “@”  hostport  dialog‑parameters

ttl-param (time-to-live)

ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP.;maddr=;ttl=15

cause param

“cause” EQUAL Status-Code
; 404 Unknown/Not available
; 486 User busy
; 408 No reply
; 302 Unconditional
; 487 Deflection during alerting
; 480 Deflection immediate response
; 503 Mobile subscriber not reachable
; 380 Service number translation   RFC 8119 – Section 2;;cause=486

SIP Responses

1xx—Provisional Responses

response that tells to its recipient that the associated request was received but result of the processing is not known yet which could be if the processing hasnt finished immediately. The sender must stop retransmitting the request upon reception of a provisional response.

100 Trying
180 Ringing : Triigers a local ringing at callers device
181 Call is Being Forwarded : Used before tranefering to another UA such as during forking or tranfer to voice mail Server

182 Queued

183 Session in Progress : conveys information . Headers field or SDP body has mor details about the call. Used in announcements and IVR + DTMF too by being followed by “Early media”.

199 Early Dialog Terminated

2xx—Successful Responses

final responses express result of the processing of the associated request and they terminate the transactions.

200 OK
202 Accepted
204 No Notification

3xx—Redirection Responses

Redirection response gives information about the user’s new location or an alternative service that the caller should try for the call. Used for cases when the server cant satisfy the call and wants the caller to try elsewhere . After this the caller is suppose to resend the request to the new location.

300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service

4xx—Client Failure Responses

negative final responses indicating that the request couldn’t be processed  due to callers fault , for reasons such as t contains bad syntax or cannot be fulfilled at that server.

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Conditional Request Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
417 Unknown Resource-Priority
420 Bad Extension
421 Extension Required
422 Session Interval Too Small
423 Interval Too Brief
424 Bad Location Information
428 Use Identity Header
429 Provide Referrer Identity
430 Flow Failed
433 Anonymity Disallowed
436 Bad Identity-Info
437 Unsupported Certificate
438 Invalid Identity Header
439 First Hop Lacks Outbound Support
470 Consent Needed
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
482 Loop Detected.
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
489 Bad Event
491 Request Pending
493 Undecipherable
494 Security Agreement Required

5xx—Server Failure Responses

negative responses but indicating that fault is at server’s side for cases such as server cant or doesnt want to respond the the request.

500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
580 Precondition Failure

6xx—Global Failure Responses

request cannot be fulfilled at any server with definitive information

600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable

Mandatory SIP headers in SIP respone

SIP/2.0 200 OK
Via: SIP/2.0/UDP
From: Bob<>
To: Altanai<>

Via, From, To, Call-ID , and  CSeq   are copied exactly from request

You can read more about SIP based Architecture here :SIP based architecture

Re-INVITE and Target-Refresh Request Handling

An INVITE request sent within an existing dialog is known as a re-INVITE. A re-Invite has an offer-answer exchange and can be used to do the following

  • change the session and/or dialog params
  • change the port to which media should be sent.
  • change the connection address or media type.
  • Hold/Release and SUSPEND/RESUME rtp streams (connection address is zero).
  • FAX (T.38 and Bypass).

Re-INVITE with SDP useCases

1.UAS rejects all changes in params in re-INVITE

Situtaion where UAC establishes audio only call
SDP1: m=audio 30000 RTP/AVP 0

but later wants to upgrade to video as well SDP:

m=audio 30000 RTP/AVP 0
m=video 30002 RTP/AVP 31

UAS configured to reject video streams, can reject this with a 4XX error and get ACK .
No changes to session are made

2. UAS receives re-INVITE for param but wants to accept few and reject others, it sends back SDP with acceptable changes with 200 OK

For instance UAC moves to high bandwidth access point and wants to update IP of media stream . It also wanst to add video stream

initial SDP

 m=audio 30000 RTP/AVP 0
c=IN IP4

new SDP in reINVITE

 m=audio 30000 RTP/AVP 0
c=IN IP4
m=video 30002 RTP/AVP 31
c=IN IP4

UAS returns a 200 (OK) response to accept IP but sets the port of the video stream to zero in its SDP to show rejected of video stream.

m=audio 31000 RTP/AVP 0
c=IN IP4
m=video 0 RTP/AVP 31

another example is when UAC wwants to add another audio codec and also add video stream to session

orignal SDP

m=audio 30000 RTP/AVP 0
c=IN IP4

re-invite SDP

 m=audio 30000 RTP/AVP 0 3
c=IN IP4
m=video 30002 RTP/AVP 31
c=IN IP4

again the UAS will optionally accept the some param canges like audio code but set video to null IP address

m=audio 31000 RTP/AVP 0 3
c=IN IP4
m=video 31002 RTP/AVP 31
c=IN IP4 

3. UAS receives re-INVITE but waits for user intervention

UAS receives re-INVITE to add video , but instead of rejecting , it prompts user to permit.

So UAS provides a null IPaddress instead of setting the stream to ‘inactive’ because inactive streams still need to exchange RTP Control Protocol (RTCP) traffic

 m=audio 31000 RTP/AVP 0
c=IN IP4
m=video 31002 RTP/AVP 31
c=IN IP4

Later if user rejects the addition of the video stream. Consequently, the UAS sends an UPDATE request (6) setting the port of the video stream to zero in its offer.

 m=audio 31000 RTP/AVP 0
c=IN IP4
m=video 0 RTP/AVP 31
c=IN IP4