[asterisk-dev] LI handling in asterisk

Holger Freyther holger at moiji-mobile.com
Fri Aug 4 00:00:20 CDT 2017


Good Morning,

my customer is using Asterisk as a SBC and I help them to upgrade from an older version to a newer one. They run a modified version of Asterisk e.g. to support German Lawful Interception requirements and it is their desire and mine to reduce the amount of patches. We think that others might have similar requirements and I would like to discuss how to design such a feature and get it integrated.

I had posted[1] to the asterisk-user mailinglist before but for our convenience let me repeat the requirements, my analysis of existing interfaces and the way it is currently done.



Legal requirements:

* Raw RTP (no transcoding, header and payload as is)
* Direction (did it arrive at asterisk or was it sent to it. Where did it come from)
* End indication once the call has been cleared



Existing asterisk support:

app_chanspy can be used to forward audio. There is support for output only but not input only. The biggest issue is that the audio comes _after_ transcoding, the RTP header is lost and the remote peer is unknown.

Next I looked at the framehooks. They provide me with the raw audio payload but I have lost the RTP header, and the IP of the remote. Reconstruction them is problematic (besides asterisk rtp engine containing some of the key values received) from a legal point of view (e.g. there might be rtp extensions that were discarded).

As far as I can tell neither the audiohooks nor the framehooks are suitable for the requirements that I listed above. Do I miss something?


What is done by the customer right now:

There is an AMI command to register interest in a SIP Call-Id (the mime header value). If there is an active call with this id LI will be activated and if a call is incoming the id will be checked against pending requests.

For the actual LI part the RTP is wrapped in a small header including a sessionId (registered by the command), the direction (e.g. in, out, end, start), the peer ip and port followed by the rtp packet.

The actual leak implementation is done by modifying the rtp_engine interface like...

struct ast_rtp_engine {
...
	int (*leak_rtp)(int fd, const struct ast_sockaddr *sa);

and then modifying the asterisk rtp_engine to duplicate the payload before it is sent out and after it was received from a socket. It is triggered from within chan_sip/pjsip (but that would have to move somewhere else)



Hpw to move forward here? Could the framehooks be extended to include the on-wire received/sent messages as well? Could the ast_frame be extended to hold more information? Is the modification of the rtp_engine a first step (as this would allow to build a module like app_chanspy).


looking forward for comments

	holger


[1] http://lists.digium.com/pipermail/asterisk-users/2017-July/291739.html


More information about the asterisk-dev mailing list