IPSec using Security Agreement (in 3GPP R5)

In this post I will try to explain how security mechanisms are negotiated between an IMS Client and the Proxy CSCF (only SIP headers) and how to setup SAs using Linux IPSec tools.
The main purpose of Security agreement is to agree on which mechanisms, algorithms or security parameters to use.

There are five main mechanisms used in VoIP networks:

1. digest
2. tls
3. ipsec-ike
4. ipsec-man
5. ipsec-3gpp

We will focus on 3GPP IPSec because the IMS makes it mandatory.

The security mechanism to use is known after the negotiation between the IMS Client and the Proxy CSCF succeeds. This negotiation is performed during the IMS registration and authentication procedures.

Three new SIP header fields have been defined, namely Security-Client, Security-Server and Security-Verify.

Call Flow

IMS Client         P-CSCF              S-CSCF

|                    |                  |

|----(1)REGISTER---->|                  |

|                    |                  |

|                    |---(2)REGISTER--->|

|                    |                  |

|                    |<-----(3) 401 ----|

|                    |                  |

|<----(4) 494/401----|                  |

|                    |                  |

|<==IPSec in place==>|                  |

|                    |                  |

|----(5)REGISTER---->|                  |

|                    |----(6)REGISTER-->|

|                    |                  |

|                    |<---(7) 200 OK----|

|<---(8) 200 OK------|                  |

|                    |                  |

In step (1) the IMS Client sends an unprotected registration request including the security-client header. The Client must indicate that it is able to negotiate security mechanism by adding “Require” and “Proxy-Require” headers. The security-client header includes two ports (client and server ports) that the client wants to negotiate with the proxy CSCF.

In step (2) the Proxy CSCF forwards the request to the Serving CSCF.

In step (3) the Serving CSCF (registrar) challenges the Proxy CSCF. The 401 response is sent to the Proxy CSCF (challenge parameters are under WWW-Authenticated header). The Serving CSCF must include the security-server header.

In step (4) the Proxy CSCF forwards the 401/494 response to the IMS Client. At this stage the Proxy CSCF opens the IPsec security association (SA) for the IMS Client. The IMS Client also setup a SA (this is a temporary SA).

The lifetime of the created SA (between the IMS Client and the Proxy CSCF) is equal to the value of reg-await-auth timer.

In step (5) the IMS Client sends a new registration (to the Proxy CSCF) request including its credentials and copies the content of security-server header to the security-verify header. Before forwarding the request to the Serving CSCF, the Proxy CSCF will check that the previous security-server header and the security-verify headers (added by the IMS Client) are the same. If these values are different, the Proxy CSCF sends an error message to the IMS Client and terminates the created SAs.

In step (6) the Proxy CSCF forwards the request to the Serving CSCF.

In step (7) the Serving CSCF authenticates the IMS Client, and responds with 200 OK.

In step (8) the Proxy CSCF forwards the response to the IMS Client. At this step new SAs will be created. The temporary SAs will be destroyed (or not) by the Proxy CSCF.

Messages

(1)
REGISTER sip:pcscf.open-ims.test SIP/2.0
Security-Client: ipsec-3gpp; alg=hmac-md5-96; spi-c=1111; spi-s=2222; port-c=5062; port-s=5064
Require: sec-agree
Proxy-Require: sec-agree

(4)
SIP/2.0 [494 Security Agreement Required / 401 Unauthorized]
Security-Server: ipsec-3gpp; q=0.1; alg=hmac-md5-96; spi-c=3333; spi-s=4444; port-c=5066; port-s=5068

(5)
REGISTER sip:pcscf.open-ims.test SIP/2.0
Security-Client: ipsec-3gpp; alg=hmac-md5-96; spi-c=1111; spi-s=2222; port-c=5062; port-s=5064
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-md5-96; spi-c=3333; spi-s=4444; port-c=5066; port-s=5068
Require: sec-agree
Proxy-Require: sec-agree

--> Captures done with Mercuro IMS Client.

Setting up SAs using Linux Tools

Here we suppose that:
- We are using Ubuntu (Linux Kernel 2.6 + KAME-tools)
- the Proxy-CSCF address is '192.168.0.10' and Mercuro IMS Client address is '192.168.0.11'
- for secure ports see above SIP capture
- protocol is esp
- algorithm is 'hmac-md5'
- encrypt-algorithm is 'des-ede3-cbc'
- mode is 'transport'
- confidentiality key is '123456789012123456789012' (see function f2345 in 3GPP milenage algorithms)
- integrity key is '1234567890123456' (see function f2345 in 3GPP milenage algorithms)

1. Install the tools

sudo apt-get install ipsec-tools

2. Edit /etc/ipsec-tools file and add the following script

#Incoming Requests [US <- PC]
spdadd 192.168.0.10/32[5066] 192.168.0.11/32[5064] udp -P in ipsec esp/transport//require;
add 192.168.0.10 192.168.0.11 esp 2222 -m transport -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Incoming Replies [UC <- PS]
spdadd 192.168.0.10/32[5068] 192.168.0.11/32[5062] udp -P in ipsec esp/transport//require;
add 192.168.0.10 192.168.0.11 esp 1111 -m transport -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Outgoing Requests [UC -> PS]
spdadd 192.168.0.11/32[5062] 192.168.0.10/32[5068] udp -P out ipsec esp/transport//unique:1;
add 192.168.0.11 192.168.0.10 esp 4444 -m transport -u 1 -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Outgoing Replies [US -> PC]
spdadd 192.168.0.11/32[5064] 192.168.0.10/32[5066] udp -P out ipsec esp/transport//unique:2;
add 192.168.0.11 192.168.0.10 esp 3333 -m transport -u 2 -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

3. Run the script

sudo /etc/init.d/setkey start

The same can be done under Windows vista using WFP(Windows Filtering Platform) API. For more information on How IPSec (in IMS context) feature could be implemented under Windows you can contact Mercuro Team at [tech dot mercuro -at- inexbee dot com].

For more information visit:
http://www.mercuro.net
http://www.ietf.org/rfc/rfc3329.txt
http://www.arib.or.jp/IMT-2000/V310Sep02/T63/Rel5/33/A33203-520.pdf
http://www.arib.or.jp/IMT-2000/V310Sep02/S3g/Rel5/24/24229-510.pdf
http://www.3gpp.org/FTP/TSG_SA/WG3_Security/TSGS3_24_Helsinki/Docs/PDF/S3-020385.pdf

Proxy and Service Route discovery in IMS

In this post I will try to explain how these two SIP extensions are used in IMS context and show differences between them.
Service Route discovery is an important mechanism in IMS context. The Service Route discovery mechanism usage is explained in RFC 3608 and 3GPP TS 24.229 and Path extension in RFC 3327.

Syntax

Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value)
sr-value = name-addr *( SEMI rr-param )
Path = "Path" HCOLON path-value *( COMMA path-value )
path-value = name-addr *( SEMI rr-param )

Usage

Header field          where   proxy ACK BYE CAN INV OPT REG

___________________________________________________________

Path                    R       ar   -   -   -   -   -   o

Path                   2xx      -    -   -   -   -   -   o

Service-Route          2xx      ar   -   -   -   -   -   o

The Service-Route header is inserted by the S-CSCF in the 200 (OK) responses to SIP REGISTER requests. The Service-Route header contains the S-CSCF SIP URI with a character string indicating the request type (mobile-originating or mobile-terminating). It is stored by the P-CSCF and associated to the registered public user identity. The UE MAY also store the value of the Service-Route header field in an association with the address-of-record for which the REGISTER transaction had registered a contact.
For example: <sip:orig@scscf.v4.ims.test:6060;lr>.

Support for the Path header extension MAY be indicated by a UA by including the option-tag "path" in a Supported header field. The Path header is inserted by the P-CSCF while forwarding REGISTER requests and contains its own SIP URI. This value is inserted by the P-CSCF to inform the S-CSCF where all terminating requests MUST be routed.
For example: <sip:term@pcscf.v4.ims.test:4060;lr>.
Both headers are only applicable to the 200 (OK) response of REGISTER requests and shall be supported by the P-CSCF (but shall not be supported by the MGCF or the BGCF).

Call Flow

IMS Client         P-CSCF             ICSCF                  S-CSCF

|                    |                  |                       |

|----(1)REGISTER---->|                  |                       |

|                    |                  |                       |

|<----(2)401---------|                  |                       |

|                    |                  |                       |

|----(3)REGISTER---->|                  |                       |

|                    |                  |                       |

|<----(4)200---------|                  |                       |

|                    |                  |                       |

|----(5)SUBSCRIBE--->|                  |                       |

|                    |                  |                       |

|<----(6)200---------|                  |                       |

|                    |                  |                       |

|----(7)REGISTER---->|                  |                       |

|                    |                  |                       |

|<----(8)200---------|                  |                       |

|                    |                  |                       |

|----(9)REGISTER---->|                  |                       |

|                    |                  |                       |

|<----(10)200--------|

1-The UE sends the initial REGISTER request without Service-Route header and includes the option-tag "path" in the Supported header field. Before forwarding this request to the I-CSCF, the P-CSCF will add its SIP URI in the Path header to inform the S-CSCF where to route terminating requests.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq: 901 REGISTER

2-The P-CSCF sends an authentication challenge (401/407) to the UE. This response already contains Path header added by the P-CSCF in step 1.

SIP/2.0 401 Unauthorized - Challenging the UE
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
CSeq: 901 REGISTER

3-The UE sends a new registration request with authentication information.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq: 902 REGISTER

4-The P-CSCF forwards the 200 OK (from the S-CSCF) response and stores the Service-Route value. At this point the Service-Route value is associated to the registered public user identity. In UE side the Service-Route value is also saved to be reused in next requests.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 902 REGISTER

5-The UE try a first presence subscription (watcher info package). New Route header MUST be added to all initial requests. This header contains the P-CSCF address, plus the associated S-SCSCF URI (Service Route) learnt during Service Route discovery.

SUBSCRIBE sip:mamadou@v4.ims.test SIP/2.0
Route: <sip:v4.ims.test:4060;lr=true;transport=tcp>,<sip:orig@scscf.v4.ims.test:6060;lr>
Event: presence.winfo
CSeq: 301 SUBSCRIBE

6-The P-CSCF forwards the response to the UE. You can notice that we new Record-Route header. This header contains that dialog routes.

SIP/2.0 200 OK
Record-Route: <sip:mo@scscf.v4.ims.test:6060;lr>,<sip:mo@pcscf.v4.ims.test:4060;lr>
CSeq: 301 SUBSCRIBE

7-UE initiated reregistration. MUST not contain headers Path or Service-Route.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq:903 REGISTER

8-Reregistration response. This response contains both Path and Service-Route headers.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 903 REGISTER

9-UE initiated deregistration. MUST not contain headers Path or Service-Route.

REGISTER sip:v4.ims.test SIP/2.0

Supported: path
Contact: <sip:[::::]:1010>;expires=0
CSeq:90 4 REGISTER

10-Deregistration response.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 903 REGISTER

Conclusion

Requests	Routes
Initial REGISTER	None
REREGISTRATION	None
DEREGISTRATION	None
Initial requests (except REGISTER)	P-CSCF and Service Routes
Early* dialogs without dialog routes	P-CSCF and Service Routes
Early* dialogs with dialog routes	Dialog Routes
Confirmed* dialogs	Dialog Routes

(*) A dialog is in the "early" state when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates.
Be careful:
- PUBLISH request does not create dialog
- SUBSCRIBE, INVITE, … requests create dialog

New Release of Mercuro IMS Client (4.0.1011)

The latest Beta release of Mercuro IMS Client(Version 4.0.1011) is now available for download at http://www.mercuro.net/.
This release comes with a lot of fixes and improvements. Here is a non-exhaustive list:

- Add P-Preferred-Identity for non-REGISTER dialogs and standalone
transactions
- Add loop detection on PUBLISH and SUBSCRIBE to deal with
mis-configured proxies
- Add support full support for rport parameter when registering
- Add pre-authorization of public identity in pres-rules to enable
self-presence awareness
- Add support for Do Not Disturb
- Add support for Auto-Answering in Voice/Visio calls
- Enhance shutdown time when closing the client (connected or not)
- Fix the route headers for non-REGISTER dialogs and standalone transactions
- Fix the handling of multiple Contact bindings
- Fix the handling of multiple P-Associated-Uri headers
- Fix the malformed fmtp parameter for iLBC and Speex codecs
- Fix the User-Agent string for XCAP request
- Fix the mis-saving of extended properties when using OMA Directory
discovery
- Fix the focus activation when receiving an INVITE request
- Fix a crash when using OMA Directory discovery with multiple document
per AUID
- Fix a crash when watcher-info document has no xmlns attribute
- Fix a crash when an Uri does not have a scheme in presence document
- Fix a crash when an INVITE has an incomplete Uri
- Fix a crash when an header contains an odd number of quotes.
- ....

your feedback is welcomed (http://feedback.mercuro.net/).

New Release of Mercuro IMS Client (4.0.899)

The latest Beta release of Mercuro IMS Client(Version 4.0.899) is now available for download at http://www.mercuro.net/.
This release comes with a lot of fixes and improvements. Here is a non-exhaustive list:

- Change default document names in XDM (WARN: it can potentially breaks existing configuration)
- Add support for expiration negotiation in REGISTER (3GPP TS-24.229)
- Add full support for "qop" authorization attribute (RFC-2617)
- Add support for Uri negotiation in XDM RLS Services (RFC-4825)
- Add message waiting indication event package support (RFC-3842)
- Add support for XCAP Capabilities retrieval (RFC-4825)
- Add support for OMA XCAP Directory (OMA-TS-XDM_Core-V1_1)
- Add support for '423 Interval Too Brief' responses (RFC-3261)
- Add SHA-1 hash computation in 'file-selector' header for MSRP file transfers (IETF draft-ietf-mmusic-file-transfer-mech)
- Add meaningful status bar to make long-lasting operation bearable
- Fix missing authorization header in initial REGISTER (3GPP TS-24.229)
- Fix invalid PUBLISH request when dealing with 401/407 responses
- Fix authorization handling in MSRP dialogs (401/407 challenges)
- Fix invalid presence rules document when dealing with authorizations
- Fix a crash when making a call to a bogus Uri
- Fix minor UI problems

Mercuro IMS Client is in beta stage and has been tested with many IMS Core (provided by our technical partners). To improve interoperability between Mercuro IMS Client and your IMS Core/Client we are willing to give you some help and tips (send us a mail to [tech dot mercuro -at- inexbee dot com]).

For more information about Mercuro IMS Client visit http://www.mercuro.net/.

New Release of Mercuro IMS Client (4.0.864)

The latest Beta release of Mercuro IMS Client(Version 4.0.864) is now available for download at http://www.mercuro.net.
This release comes with a lot of fixes and improvements. Here is a non-exhaustive list:

- Add new audio and video codecs (GSM, Speex, Theora, etc)
- Full screen mode support
- Add the ability to choose the codecs used during Voice/Visio calls
- Add a better validation of Uri values
- Add ability to set custom XDMS documents
- Add a dialog box when a connection error occurs
- Add an anonymous crash report sending to ease feedback
- Add a DTMF sound feedback
- Fix a crash when running under Microsoft Remote Desktop
- Fix a crash when making a Voice call with IMS Communicator
- Fix the jitter buffer for a better sound quality
- Fix the session rejection with IM SIMPLE Session
- Fix the ugly noise when playing the ring tones
- Fix label alignment under Windows Vista
- Fix the tab-stop order of various screens
- ...

For more information about Mercuro IMS Client visit http://www.mercuro.net.

3GPP P-Headers

The Third Generation Partnership Project (3GPP) has defined some additional SIP P-headers ('P' stands for private or proprietary) to use in IMS (Release 5 requirements on SIP) context.

These headers are:

1. The P-Associated-URI header
2. The P-Called-Party-ID header
3. The P-Visited-Network-ID header
4. The P-Access-Network-Info header
5. The P-Charging-Function-Addresses header
6. The P-Charging-Vector header

In next posts I will explain how these headers are used in both UAC and UAS side.

For more information visit http://www.ietf.org/rfc/rfc3455.txt

Rich Communication Suite phase 1

RCS (Rich Communication Suite) is a join industry effort aiming to speed up the evolution of mobile phone communication towards rich communication. The RCS initiative includes network operators, network and device vendors (Orange, Telecom Italia, Telefonica, TeliaSonera, Ericsson, Nokia Siemens Networks, Nokia, SK Telecom, Sony Ericsson and Samsung).

The main purpose of RCS is to allow interoperability between network vendors and software editors.

RCS phase 1 defines 4 main features:

1. Enhanced Address Book (Service capabilities, presence contacts information, Video Call, …)
2. Content Sharing (Video Share, Image Share, …)
3. File Transfer (based on OMA Simple 1.0 specifications)
4. Converged Messaging (base on OMA Simple 1.0 specifications)

The RCS Initiative has defined a core feature set, developed reference implementations of the services and conducted interoperability testing in multi-vendor environment.

In next posts I will introduce all features mentioned above and explain how they are used in IMS Clients (Mercuro).

References:
http://en.wikipedia.org/wiki/Rich_Communication_Suite
http://www.nokiasiemensnetworks.com/global/Press/Press+releases/news-archive/Rich_Communication_Suite_Initiative.htm

Free IMS Clients

• IMSDroid, for Android
• iDoubs, for iOS (iPhone, iPad and iPod Touch)
• The UCT IMS Client is available under the GPL (open source)
• The IMS Communicator is available under the GPL (open source)
• FOKUS' OpenIC (Open IMS Client) is available only commercially. Yet, there is also a free binary OpenIC_Lite version available right here

Seagull : [3GPP, TISPAN, CableLabs] Multi-protocol traffic generator

We all know that it's very difficult to find an IMS client that support a wide array of protocols defined in IMS specifications (3GPP, TISPAN, CableLabs). In addition, only OpenIc and Mercuro IMS client support MSRP (both IM and file transfer). The first cost 25 000 $ and the second is in beta stage (very promising).
Seagull is the answer to how you can make tests using such protocols.

Primarily aimed at IMS (3GPP, TISPAN, CableLabs) protocols (and thus being the perfect complement to SIPp for IMS testing), Seagull is a powerful traffic generator for functional, load, endurance, stress and performance/benchmark tests for almost any kind of protocol.

Seagull supports currently the following protocols:

• Diameter base ( RFC 3588) and any Diameter relating application - IMS Cx, Dx, Ro, Rf, Sh over TCP or SCTP or TLS over IPv4 or IPv6.
• TCAP ITU and ANSI and any protocol over TCAP (Camel, GSM MAP, IS41, Win, ...) either over SS7 (E1/T1) or SIGTRAN. For that, it relies on HP OpenCall SS7.
• XCAP over HTTP over IPv4
• HTTP over IPv4
• H248/Megaco ASCII form over UDP or TCP or SCTP/IPv4
• Radius (subset) over IPv4.

For more information visit http://gull.sourceforge.net/

The 3Gdb Home Subscriber Server(HSS)

This is an implementation of the HSS network element within an IP Multimedia Subsystem (IMS) Core Network (CN).
This project implements the (IMS) database schema described in 23.008 Subscriber Data, the procedures in 29.228 Signaling and the algorithms in 35.206 MILENAGE. It is based upon Release 7.
It is represented below (red background) inside an IMS Core Network.

Another well-known HSS: FOKUS Home Subscriber Server (FHoSS), used in OpenIMSCore.

Reference: http://code.google.com/p/hss/
For more information visit http://www.3gdb.org/doc/overview-summary.html

Mercuro IMS Client

INEXBEE announces the availability of the free version of Mercuro IMS Client. The Mercuro IMS Client is fully compliant with the main 3GPP IMS, RCS (Rich Communication Suite) and OMA specifications.

Mercuro IMS Client is one of the most complete 3GPP IMS softphone and features:

• GSMA RCS features (Enhanced Address Book, Enhanced Messaging, Content Sharing, SMS/MMS messaging and File Transfer)

• SIP/SigComp
• IPv4 and IPv6 networks
• UDP, TCP and TLS transports
• IPSec/TLS Security agreement
  
• Secure 3GPP IMS registration with Digest MD5, AKA-v1
  and AKA-v2
• Private extension headers for 3GPP
• Service-Route discovery
• DNS NAPTR/DHCP Discovery
• Supports provisional response acknowledgements (PRACK)
  
• Unified Contact List Management using XCAP
  
• Presence Rules support using XCAP
  
• Subscribe to reg event and winfo -watcher info-
  
• Incoming/outgoing Voice calls
• Incoming/outgoing Video calls (QCIF, CIF)
• QoS Preconditions
  
• SIP Session Timers
  
• DTMF (Inband DTMF or SIP INFO messages)
• Converged Messaging (OMA-TS-SIMPLE_IM-V1_0-20080903-C)
• IM Conference (MSRP)
• MMS Messaging (MSRP/SMIL)
• 3GPP SMS Messaging (RP-DATA)
• Unified Presence Management (OMA-TS-Presence_SIMPLE-V1_1-20080627-A)
• Multi-codec support (G711, GSM, iLBC, SPEEX, DVI4, L16, AMR, H.263, H.264, ...)
• MSRP file transfer
  
• ... and many other features related to 3GPP IMS or OMA specifications
  

Branding:

• You can include your company name, slogan and logo
• Fully customizable user interface
• Use Mercuro IMS Client as Framework (C++, C# or VB.NET) to develop your own IMS service or client (Only Windows XP/2000/Vista are supported)
  
• ...
  

Hep/Support/Consultancy:

• Offer support to those having difficulties running or using Mercuro IMS Client/ Framework
  
• Tips to help you test Mercuro IMS Client interoperability with other IMS or SIP clients
• Building an IMS Network with Open Source Tools (OpenIMSCore, OpenXcap, OpenSER, Mobicents, ...) and Mercuro IMS Client
• ...
  

Another well-known IMS Clients :

• FOKUS' OpenIC (Full version is available only commercially)
• UCT IMS Client (Free)
  
• IMS Communicator (Free)
  

For more information about Mercuro IMS Client you can visit http://www.mercuro.net or http://imsclient.blogspot.com a blog totally dedicated to Mercuro.

MyLivio the new web based telephony

Yesterday I was looking for how to make call from pc2phone or pc2pc without installing any software on my computer when I came across this web based telephony. It is based on flash technology for audio transport and SIP signaling protocol to manage calls.

Its name is MyLivio

MyLivio was developed by a French company called INEXBEE.

Before using this service you must register on their web site (free-of-charge). When the registration is done you will get link button which you can add in your email signature (Microsoft Outlook, yahoo …), blog, web site, ebay, myspace …

If someone wants to call you on your mobile phone he clicks on this link button.

Advantages

- Registration is free and you have 10 free minutes per month (not sure if it’s per day or month *you can check it yourself on their web site*)
- Very beautiful and easy to use web site
- Fast activation (no need to wait days or hours)
- Fully compliant with RFC 3261

Inconvenients

- Bad voice quality
- Work only for French registered mobile phones
- Poor user guide
- No video support
- Web page with lot of ads
- No way to use the flashphone from mobile device or PDA

Another well-known web based telephones -> Ribbit, Tringme or Flashphone

If you know other web based telephony feel free to complete the list

New Version of UCT IMS Client

The latest version of the UCT IMS Client v. 1.0.12 is now available for download. The main new features are support of MSRP (only message transfer support and not yet fully compatible with the RFC 4975), RTSP (I haven’t tested this feature so all feedbacks will be useful) and EPG for UCT advanced IPTv.