Humm, no reply so far, may be because my email was very long and no body
bothered to read it all. Anyways, here is the shorter more direct version
of it. (including kamailio dev list, since question is rather technical).
Is it possible to implement a custom SIP transport in Kamailio script file
i.e. kamailio.cfg. The purpose is to allow experimentation with custom
encryption algorithms such as this,
https://github.com/mshary/itv
What we need is a couple of functions, one to receive incoming raw /
encrypted data received on SIP socket, which then can be parsed / decrypted
in kamailio.cfg (using e.g. LUA or PERL language modules etc.) and
afterwords feed to kamailio for usual processing (as if it was normal /
plain-text sip data received on sip socket). The second function to do the
opposite, it receives the normal / plain-text sip data that is ready to be
sent out from kamailio's core, encrypts it and then send it out to actual
destination.
In case above is not possible. Can i do it in kamailio's native code? Any
hooks / example code for reference?
Many thanks and kind regards for your help.
On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad <shaheryarkh(a)gmail.com>
wrote:
> Hi,
>
> As the mobile voip is getting more and more popular these days, there has
> been a strong opposition from GSM operators against mobile voip apps. They
> often use tactics like blocking voip ports, or detect and block voip
> traffic and in some cases restricting udp traffic altogether to very low
> upload and download speeds. See below link for some details,
>
> http://www.linphone.org/eng/blog/linphone-over-3g.html
>
> While not all the problems can be solved right now (especially the
> limiting udp traffic, since RTP always uses udp transport) I was wondering
> if we can at least handle the sip related problems. The most important of
> them is SIP traffic detection. While some forks would suggest using TCP/TLS
> to encrypt SIP traffic, it has a few problems, e.g.
>
> 1. It requires somewhat high resources on mobile devices, so many low-end
> android phones simply can't use it.
>
> 2. There is possibility that encryption signature may identify it as SIP
> traffic. There exists firewalls (often deployed in middle eastern
> countries) which have huge database of encryption signatures and patterns
> which although may not decrypt the sip packet but at least identify it as
> sip packet and block it.
>
> Also with rough agencies of evil empires spying over millions of users
> worldwide makes the current encryption standards pretty much pointless, at
> least in terms of user privacy and network security. So there is a strong
> need to experiment with new ideas and concepts to regain internet freedom.
> Some of such ideas are,
>
> 1. Convert sip traffic which is plain text to binary format just before
> transmitting it and revert it to plain text upon reception.
>
> 2. XOR the sip traffic (pretty much same as binary sip).
>
> 3. Use some very lightweight but effective / non-standard encryption
> algorithm, e.g.
>
> https://github.com/mshary/itv
>
> All these ideas require that SIP server such as Kamailio is able to adopt
> to these, preferably with minimal or no change in native code. The NoSIP
> module seems an interesting module in this regard. It provides all traffic
> it thinks is not the SIP traffic to configuration script, where we can do
> our own parsing and do whatever we want with it. I have two questions about
> this,
>
> 1. If parsed message is SIP, we can we send it back to kamailio core to
> get it processed as if it is a normal SIP message received by kamailio?
>
> 2. Can this module or any other module available in kamailio, that can
> provide us full sip packet that is about to be transmitted over sip socket,
> so we can "encode" it just before it is sent to next hop?
>
> I know this would be like writing a SIP transport in kamailio script which
> would be very tough if not impossible to implement in native core. But it
> will really help in winning the modern mobile voip challenges.
>
> Thank you.
>
>
>
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Alekzander Spiridonov (alekz)
Attached to Project - sip-router
Summary - PARAM_STR vs STR_PARAM
Task Type - Improvement
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - As a follow-up for mailing thread "PARAM_STR vs STR_PARAM". The last bunch of patches.
Plz remove #define STR_PARAM PARAM_STRING from sr_module.h if everything is ok.
One or more files have been attached.
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=455
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hello,
At 1&1 we have spotted an issue related to the cdr_extra parameters: for
more than 10 string cdr_extra parameters, the addresses used by the new
parameters overwrite the previous ones (this did not happen in 3.1, but
is reproducible since at least 3.3).
I attached a patch that implements a solution where we allocate memory
for the cdr extra params with pkg_malloc() and free it once it is no
longer needed.
Daniel, if there is no comment related to this solution, I will commit
the patch.
Thank you,
Lucian Balaceanu
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#454 - Crash in core when freeing shm dup'ed request
User who did this - Daniel-Constantin Mierla (miconda)
----------
Thanks, go ahead and commit your patch. Somehow I had in mind From is parsed before creating transaction, but can be only its URI -- I have to check the sources.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=454#comment1565
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#454 - Crash in core when freeing shm dup'ed request
User who did this - Hugh Waite (hugh.waite)
----------
(gdb) frame 5
#5 0x000000000054fea1 in clean_hdr_field (hf=0x7fd11837aa18) at parser/hf.c:114
114 free_to(hf->parsed);
(gdb) p *hf
$18 = {type = HDR_FROM_T, name = {
s = 0x7fd11837a7b6 "From: <sip:nm@nm>;tag=root\r\nTo: <sip:nm2@nm2>\r\nCall-ID: 1-9712(a)127.0.0.1\r\nCSeq: 42 OPTIONS\r\nMax-Forwards: 15\r\nContent-Length: 0\r\nContact: <sip:nm@nm>\r\nAccept: application/sdp\r\n\r\n", len = 4},
body = {s = 0x7fd11837a7bc "<sip:nm@nm>;tag=root\r\nTo: <sip:nm2@nm2>\r\nCall-ID: 1-9712(a)127.0.0.1\r\nCSeq: 42 OPTIONS\r\nMax-Forwards: 15\r\nContent-Length: 0\r\nContact: <sip:nm@nm>\r\nAccept: application/sdp\r\n\r\n", len = 20},
len = 28, **parsed = 0x7fd12559ee28**, next = 0x7fd11837aa58}
In the shared memory structure, **parsed = 0x7fd12559ee28** which is in pkg memory.
I did a different test by adding 'xlog("L_WARN", " From tag is $ft")' to the cfg file. Because this forces parsing of the from body before duplicating, it did not cause a crash.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=454#comment1564
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.