The msrp is controlled from configuration file via actions in event_route[msrp:frame-in]. The module is a full, embedded MSRP relay, it does not require any external application nor library. It uses the core transport layer components, thus it benefits of the scalable and asynchronous TCP/TLS support implementation already existing in the project for many years now.
Kamailio, with msrp module loaded, can handle SIP and MSRP traffic received on the same port. But you can configure Kamailio as a stand alone instance to deal only with MSRP traffic, leaving the SIP traffic to another Kamailio instance. Also, another option is to configure Kamailio to listen on different TCP/TLS sockets (e.g., different ports or IP/network interfaces) and direct SIP and MSRP to different ports — then in the config file you can take care of filtering (dropping) inappropriate content on specific ports. With all this flexibility, you can choose a configuration that will not affect at all the routing of SIP messages with Kamailio.
The embedded MSRP relay, built on top of the SIP server, offers many benefits such as:
- reuse mature code tested over the past 10 years, msrp module itself being really small piece of code in regards to MSRP protocol
- MSRP is done over TCP/TLS, thus implicitly the forwarding is done asynchronously, offering great performances
- IPv4 and IPv6 support
- MSRP is for transmission of a SIP session content, going to be used by the SIP users in your UC platform — there is no need to manage a different user profile
- the configuration and MSRP routing is done via the same flexible language and format as for SIP traffic, you being in control of what is passing through your server
- access to all existing extensions that are related to SIP request routing, for example: IP address checking, flood detection, many database connectors, accounting, a.s.o.
- voice, video, screen sharing, etc. sessions with content communication via RTP
- end to end presence – this is purely SIP routing
- SIMPLE-based presence (aka, presence server or presence agent model) via presence* and pua* modules — user presence, dialog states notification (aka, blinking lamps), resource lists service (including OMA/RCS extensions), user location states notification and replication, audio/video conference mixer notifications, a.s.o.
- embedded XCAP server – management of user contact lists, presence policies, user agent configuration files, a.s.o. There is also an XCAP client extension
- embedded HTTP server – for admin and user interaction with the service via pure HTTP or XMLRPC requests
- embedded MSRP relay – for relaying and fine controlling of the message-based content of SIP sessions
- IRC-style instant messaging conference via imc module
- storage of instant messages for offline users and relay to them when they become again online via msilo module