Kamailio is a SIP server which does not play any role by itself in media transmission path. this behaviour leads to media packets having to attempt to stream peer to peer between caller and callee which in turn many a times causes them to get dropped in absence of NAT management
To ensure that media stream is proxied via an RTP proxy kamailio can use RTP proxy module combined with a RTP proxy.
This setup also provides other benefits such as controlling media media , security , Load balancing between many rtp proxies ,bridge signalling between multiple network interfaces etc.
RTP Proxy module
Used to proxy the media stream .
RTP proxies that can be used along with this module are:
rtpproxy_disable_tout – when rtp proxy is disabled then timeout till when it doesnt connect
rtpproxy_tout – timeout to wait for reply
rtpproxy_retr – num of retries after timeout
nortpproxy_str – sets the SDP attribute used by rtpproxy to mark the message’s SDP attachment with information that it have already been changed. Default value is
“a=nortpproxy:yes\r\n”
and others like
“a=sdpmangled:yes\r\n”
timeout_socket (string)
ice_candidate_priority_avp (string)
extra_id_pv (string)
db_url (string)
table_name (string)
rtp_inst_pvar (string)
Functions
set_rtp_proxy_set(setid) – Sets the Id of the rtpproxy set to be used for the next unforce_rtp_proxy(), rtpproxy_offer(), rtpproxy_answer() or rtpproxy_manage() command
rtpproxy_offer([flags [, ip_address]]) – to make the media pass through RTP the SDP is altered. Value of flag can be 1 – append first Via branch to Call-ID when sending command to rtpproxy. 2 – append second Via branch to Call-ID when sending command to rtpproxy. See flag ‘1’ for its meaning. 3 – behave like flag 1 is set for a request and like flag 2 is set for a reply a – flags that UA from which message is received doesn’t support symmetric RTP. (automatically sets the ‘r’ flag) b – append branch specific variable to Call-ID when sending command to rtpproxy l – force “lookup”, that is, only rewrite SDP when corresponding session already exists in the RTP proxy i, e – direction of the SIP message when rtpproxy is running in bridge mode. ‘i’ is internal network (LAN), ‘e’ is external network (WAN). Values ie , ei , ee and ii x – shortcut for using the “ie” or “ei”-flags, to do automatic bridging between IPv4 on the “internal network” and IPv6 on the “external network”. Differentiated by IP type in the SDP, e.g. a IPv4 Address will always call “ie” to the RTPProxy (IPv4(i) to IPv6(e)) and an IPv6Address will always call “ei” to the RTPProxy (IPv6(e) to IPv4(i)) f – instructs rtpproxy to ignore marks inserted by another rtpproxy in transit to indicate that the session is already gone through another proxy. Allows creating a chain of proxies r – IP address in SDP should be trusted. Without this flag, rtpproxy ignores address in the SDP and uses source address of the SIP message as media address which is passed to the RTP proxy o – flags that IP from the origin description (o=) should be also changed. c – flags to change the session-level SDP connection (c=) IP if media-description also includes connection information. w – flags that for the UA from which message is received, support symmetric RTP must be forced. zNN – perform re-packetization of RTP traffic coming from the UA which has sent the current message to increase or decrease payload size per each RTP packet forwarded if possible. The NN is the target payload size in ms, for the most codecs its value should be in 10ms increments, however for some codecs the increment could differ (e.g. 30ms for GSM or 20ms for G.723). ip_address denotes the address of new SDP
such as : rtpproxy_offer(“FRWOC+PS”) is rtpengine_offer(“force trust-address symmetric replace-origin replace-session-connection ICE=force RTP/SAVPF”);
route {
...
if (is_method("INVITE"))
{
if (has_body("application/sdp"))
{
if (rtpproxy_offer()) t_on_reply("1");
} else {
t_on_reply("2");
}
}
if (is_method("ACK") && has_body("application/sdp")) rtpproxy_answer();
...
}
onreply_route[1] {
if (has_body("application/sdp")) rtpproxy_answer();
}
onreply_route[2] {
if (has_body("application/sdp")) rtpproxy_offer();
}
rtpproxy_answer([flags [, ip_address]])- rewrite SDP to proxy media , it can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
rtpproxy_destroy([flags]) – tears down RTP proxy session for current call. Flags are , 1 – append first Via branch to Call-ID 2 – append second Via branch to Call-ID b – append branch specific variable to Call-ID t – do not include To tag to “delete” command to rtpproxy thus causing full call to be deleted
unforce_rtp_proxy()
rtpproxy_manage([flags [, ip_address]]) – Functionality is to use predfined logic for handling requests If INVITE with SDP, then do rtpproxy_offer() If INVITE with SDP, when the tm module is loaded, mark transaction with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for rtpproxy_answer() If ACK with SDP, then do rtpproxy_answer() If BYE or CANCEL, or called within a FAILURE_ROUTE[], then call unforce_rtpproxy(). If reply to INVITE with code >= 300 do unforce_rtpproxy() If reply with SDP to INVITE having code 1xx and 2xx, then do rtpproxy_answer() if the request had SDP or tm is not loaded, otherwise do rtpproxy_offer() This function can be used from ANY_ROUTE.
rtpproxy_stream2uac(prompt_name, count) – stream prompt/announcement pre-encoded with the makeann command. The uac/uas suffix selects who will hear the announcement relatively to the current transaction – UAC or UAS. Also used for music on hold (MOH). Params : prompt_name – path name of the prompt to stream count – number of times the prompt should be repeated. When count is -1, the streaming will be in loop indefinitely until the appropriate rtpproxy_stop_stream2xxx is issued. Example rtpproxy_stream2xxx usage
if (is_method("INVITE")) { rtpproxy_offer(); if (is_audio_on_hold()) { rtpproxy_stream2uas("/var/rtpproxy/prompts/music_on_hold", "-1"); } else { rtpproxy_stop_stream2uas(); }; };
rtpproxy_stream2uas(prompt_name, count)
rtpproxy_stop_stream2uac()- Stop streaming of announcement/prompt/MOH
The MediaStreamTrack interface typically represents a stream of data of audio or video and a MediaStream may contain zero or more MediaStreamTrack objects.
The objects RTCRtpSender and RTCRtpReceiver can be used by the application to get more fine grained control over the transmission and reception of MediaStreamTracks.
Media Flow in VoIP systemMedia Flow in WebRTC Call
WebRTC compatible browsers are required to support Whie-balance , light level , autofocus from video source
Video Capture Resolution
Minimum WebRTC video attributes unless specified in SDP ( Session Description protocl ) is minimum 20 FPS and resolution 320 x 240 pixels.
Also supports mid stream resilution changes such as in screen source fromdesktop sharinig .
SDP attributes for resolution, frame rate, and bitrate
SDP allows for codec-independent indication of preferred video resolutions using a=imageattr to indicate the maximum resolution that is acceptable.
Sender must send limiting the encoded resolution to the indicated maximum size, as the receiver may not be capable of handling higher resolutions.
Dynamic FPS control based on actual hardware encoding
video source capture to adjust frame rate accroding to low bandwidth , poor light conditions and harware supported rate rather than force a higher FPS .
Stream Orientation
support generating the R0 and R1 bits of the Coordination of Video Orientation (CVO) mechanism and sharing with peer.
Audio level for speech transmission to avoid users having to manually adjust the playback and to facilitate mixing in conferencing applications.
Normalization is considering frequencies above 300 Hz, regardless of the sampling rate used. Can be adapted to avoid clipping, either by lowering the gain to a level below -19 dBm0 or through the use of a compressor.
GAIN calculation
If the endpoint has control over the entire audio-capture path like a regular phone the gain should be adjusted in such a way that an average speaker would have a level of 2600 (-19 dBm0) for active speech.
If the endpoint does not have control over the entire audio capture like software endpoint then the endpoint SHOULD use automatic gain control (AGC) to dynamically adjust the level to 2600 (-19 dBm0) +/- 6 dB.
For music- or desktop-sharing applications, the level SHOULD NOT be automatically adjusted, and the endpoint SHOULD allow the user to set the gain manually.
Media plane adaptation is done at the SBC for network carried media, it should be done for all network hosted media services which face peer-to-peer media.
The high-level architecture elements of WebRTC media streams consists of
Encryption, RTP Multiplexing, Support for ICE
Audio – Interworking of differing WebRTC and codec sets
Video – Use of VP8, Support for H.264
Data – Support of MSRP ( RCS standard for messaging over DataChannel API)
Direct connection to media servers and media gateways.
Use common codec set wherever possible to eliminate transcoding Use regionalized transcoding where common codec not available Real-time video transcoding is expensive and performance impacting.
On-going standards/device/network work needs to be done to expand common codec set. WebRTC codec standards have not been finalized yet. WebRTC target is to support royalty free codecs within its standards.
Media
WebRTC
legacy
Audio
G.711, Opus
G.711, AMR, AMR-WB (G.722.2)
Audio – Extended
G.729a[b], G.726
Video
VP8
H.264/AVC
Supporting common codecs between VoLTE devices and WebRTC endpoints requires one or more of the following:
Support of WebRTC codecs on 3GPP/GSMA
Support of 3GPP/GSMA codecs on WebRTC
WebRTC browser support of codecs native to the device
After considerable time( 10 minutes in my case ) the quality of the media stream adjust to network conditions and variations ( peaks and dips) flat out.
after some timeafter some time has passedafter some time
Data Channel API of Webrtc allows bidirectional communication of arbitrary data between peers. It uses the same API as WebSockets and has very low latency.
(+) DataChannel is p2p and is also ened to end encrypted leader to higher privacy
(+) build in security due to p2p transfer
(+) high throughput than text transfer via a messaging server
(+) lower latency as p2p transfer takes shortest route
SCTP is the protocol that opens connectiosn for peer to peer data channel support in WebRTC. It can be configured for reliability and ordered delivery. It provides flow and congestion control to the data messages.
Webrtc Changes bitrate , resolution and framerate dynamically to accomodate the network conditions, policy constraints or user equipment capability. Higher the bitrate, higher the media quality.
Birate of Audio Codecs
Lossey formats – iLBC (narrow band )13.33, 15.20 kbit/s – iSAC ( wideband) 10–52 kbit/s – GSM-EFR 12.2 kbit/s – AAC 8–529 kbit/s (stereo) – AMR-WB (G.722.2) 6.60, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, 23.85 kbit/s – Opus – 6–510 kbit/s(-) higher bitrate consumes more bandwidth (-) can cause congestion on network route
Telecom R & D 