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 ICESolution : 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.
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
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.
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.
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.
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.
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.
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.
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)
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.
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
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 .
References :
RFC 3489 STUN – Simple Traversal of User Datagram Protocol (UDP)Through Network Address Translators (NATs)
RFC 5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism
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);
httpEndpoint.setVideoFormat(vc);
AudioCaps ac= new AudioCaps(AudioCodec.PCMU, 65536);
httpEndpoint.setAudioFormat(ac);
webRtcEndpoint.connect(httpEndpoint);
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();
rtpEndpoint.processAnswer(requestRTPsdp);
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
WebRTC Stream and object URL of the blob containing VP8 media
Kurento WebRTC Endpoint bridge to generate SDP
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();
rtpEndpoint.processAnswer(requestRTPsdp);
// write the SDP conector to an external file
PrintWriter out = new PrintWriter("/tmp/test.sdp");
out.println(requestRTPsdp);
out.close();
HttpGetEndpoint httpEndpoint = new HttpGetEndpoint.Builder(pipeline).build();
PlayerEndpoint player = new PlayerEndpoint.Builder(pipeline, requestRTPsdp).build();
httpEndpoint.connect(rtpEndpoint);
player.connect(httpEndpoint);
// Playing media and opening the default desktop browser
player.play();
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
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
End result : wowza doesnt not recognize the WebRTC SDP and play the video : deformed media
screenshot of playing from a SDP file
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
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
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
but refuses to be played by VLC , ffplay and even wowza . The error generated with
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
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 :
RFC7742: WebRTC Video Processing and Codec Requirements
RFC 7874: WebRTC Audio Codec and Processing Requirements
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.
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.
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)
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 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.”
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.
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.
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.
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.
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
Training
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
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 brokeringand service interaction functionality for SS7 and IMS networks.
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.
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
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
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…
Develop a SCE ( Service Creation Environment ) to addresses all aspects of lifecycle of a Service, right from creation/development, orchestration, execution/delivery, Assurance and Migration/Upgrade of services.
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 is a widely adopted application layer protocol used in VoIP calls and confernecing applciations and in IMS architeture or pure packet switched networks .
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
Description
REGISTER
A Client use this message to register an address with a SIP server
INVITE
A 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.
ACK
This is used only for INVITE indicating that the client has received a final response to an INVITE request
CANCEL
This is used to cancel a pending request
BYE
A User Agent Client use this message to terminate the call
OPTIONS
This is used to query a server about its capabilities
Response Message
Code
Category
Description
1xx
Provisional
The request has been received and processing is continuing
2xx
Success
An ACK, to indicate that the action was successfully received, understood, and accepted.
3xx
Redirection
Further action is required to process this request
4xx
Client Error
The request contains bad syntax and cannot be fulfilled at this server
5xx
Server Error
The server failed to fulfill an apparently valid request
6xx
Global Failure
The 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-Length – an octet (byte) count of the message body.
Content-Disposition
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
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
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
Encryption
Expires – when msg content is no longer valid
Mandatory SIP headers
INVITE sip:altanai@domain.comSIP/2.0
Via: SIP/2.0/UDP host.domain.com:5060
From: Bob
To: Altanai
Call-ID: 163784@host.domain.com
CSeq: 1 INVITE
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
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
or
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 isi.edu “Session parameter ‘foo’ not understood” Warning: 301 isi.edu “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.
limit the time period over which a stateful proxy must maintain state information. options
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
sessionname ( 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.
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 172.31.90.251
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 > [/ ]
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>
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
User-Agent:nbspMatrixSwitch
Date: Thu, 22 Dec 2005 18:38:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 x.x.x.x
s=session
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
The aobve exmaple indicates that the request has to be compressed using SigComp
transport-param
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.
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.
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.
sip:alice@atlanta.com;maddr=239.255.255.1;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
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 host.domain.com:5060
From: Bob<sip:bob@domain.com>
To: Altanai<sip:altanai@domain.com>
Call-ID: 163784@host.domain.com
CSeq: 1 INVITE
Via, From, To, Call-ID , and CSeq are copied exactly from request
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
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.
Telecom R & D 
