[Kamailio-Users] [OT] SIP ALG Detector released
Hi, as part of my personal battle against SIP ALG routers, I've created an utility to detect such routers: http://dev.sipdoc.net/wiki/sip-stuff/SIP-ALG-Detector It has two parts: client and server: Basically, the client node running into the LAN sends an INVITE to the server node (running in a host with public IP). The request could be modified by the LAN router if SIP ALG is enabled. The server encodes the received request in Base64 and appends it to the SIP response. The client receives the response, decodes the body and gets the request as it arrived to the server. Then it creates a diff between the original request and the the request the server node received. These differences are displayed in the screen. Both, UDP and TCP, tests are performed. The client node is coded in Ruby and should work in any operating system (if Ruby is installed). The server node is also coded in Ruby. For those interested in try it, I have a server node running in my personal server: 87.98.230.161:5060 You can test the client against my server. Feedback is welcome :) Regards. -- Iñaki Baz Castillo <ibc@aliax.net>
Hi, Am 14.06.2009 2:17 Uhr, schrieb Iñaki Baz Castillo:
Hi, as part of my personal battle against SIP ALG routers, I've created an utility to detect such routers:
http://dev.sipdoc.net/wiki/sip-stuff/SIP-ALG-Detector
It has two parts: client and server:
Basically, the client node running into the LAN sends an INVITE to the server node (running in a host with public IP). The request could be modified by the LAN router if SIP ALG is enabled. The server encodes the received request in Base64 and appends it to the SIP response. The client receives the response, decodes the body and gets the request as it arrived to the server. Then it creates a diff between the original request and the the request the server node received. These differences are displayed in the screen.
Both, UDP and TCP, tests are performed.
The client node is coded in Ruby and should work in any operating system (if Ruby is installed).
The server node is also coded in Ruby.
For those interested in try it, I have a server node running in my personal server: 87.98.230.161:5060 You can test the client against my server.
nice idea. Could be handy for techies. Even though I did not tried it yet I'm wondering why you/we need a special server for this? Wouldn't a sip-router module with this function an even better solution? Then every sip-router out there could offer this "service" under some special username. Greetings Nils
El Domingo, 14 de Junio de 2009, Nils Ohlmeier escribió:
nice idea. Could be handy for techies. Even though I did not tried it yet I'm wondering why you/we need a special server for this?
Wouldn't a sip-router module with this function an even better solution? Then every sip-router out there could offer this "service" under some special username.
Yes, it could be, but it was faster for me to implement it in Ruby rather than creating a new module for Kamailio/SIP-Router. -- Iñaki Baz Castillo <ibc@aliax.net>
Nils Ohlmeier schrieb:
Hi,
Am 14.06.2009 2:17 Uhr, schrieb Iñaki Baz Castillo:
Hi, as part of my personal battle against SIP ALG routers, I've created an utility to detect such routers:
http://dev.sipdoc.net/wiki/sip-stuff/SIP-ALG-Detector
It has two parts: client and server:
Basically, the client node running into the LAN sends an INVITE to the server node (running in a host with public IP). The request could be modified by the LAN router if SIP ALG is enabled. The server encodes the received request in Base64 and appends it to the SIP response. The client receives the response, decodes the body and gets the request as it arrived to the server. Then it creates a diff between the original request and the the request the server node received. These differences are displayed in the screen.
Both, UDP and TCP, tests are performed.
The client node is coded in Ruby and should work in any operating system (if Ruby is installed).
The server node is also coded in Ruby.
For those interested in try it, I have a server node running in my personal server: 87.98.230.161:5060 You can test the client against my server.
nice idea. Could be handy for techies. Even though I did not tried it yet I'm wondering why you/we need a special server for this? Wouldn't a sip-router module with this function an even better solution? Then every sip-router out there could offer this "service" under some special username.
It could also be implemented by using transformations. Just add a base64 transformation and append_to_reply() regards klaus
2009/6/15 Klaus Darilion <klaus.mailinglists@pernau.at>:
Wouldn't a sip-router module with this function an even better solution? Then every sip-router out there could offer this "service" under some special username.
It could also be implemented by using transformations. Just add a base64 transformation and append_to_reply()
How do you get the original request *untouched* (no ;received param and so)? Also, the reply should be "Content-Type: text/plain". -- Iñaki Baz Castillo <ibc@aliax.net>
Iñaki Baz Castillo schrieb:
2009/6/15 Klaus Darilion <klaus.mailinglists@pernau.at>:
Wouldn't a sip-router module with this function an even better solution? Then every sip-router out there could offer this "service" under some special username. It could also be implemented by using transformations. Just add a base64 transformation and append_to_reply()
How do you get the original request *untouched* (no ;received param and so)?
$mb ?
Also, the reply should be "Content-Type: text/plain".
{.. set_reply_body("$mb{s.base64}", "text/plain"); // \ // -> to be implemented // sl_send_reply("200","have fun"); exit; } klaus
2009/6/15 Klaus Darilion <klaus.mailinglists@pernau.at>:
How do you get the original request *untouched* (no ;received param and so)?
$mb ?
Great!
Also, the reply should be "Content-Type: text/plain".
{.. set_reply_body("$mb{s.base64}", "text/plain"); // \ // -> to be implemented // sl_send_reply("200","have fun"); exit; }
Great too. Ok, I will try to implement it, thanks a lot :) -- Iñaki Baz Castillo <ibc@aliax.net>
El Lunes, 15 de Junio de 2009, Klaus Darilion escribió:
How do you get the original request untouched (no ;received param and so)?
$mb ?
Also, the reply should be "Content-Type: text/plain".
{.. set_reply_body("$mb{s.base64}", "text/plain"); // \ // -> to be implemented // sl_send_reply("200","have fun"); exit; }
Hi Klaus, I remember now that it's not so easy: If the server encodes *all* the original received request in Base64 and sets it in the response body, it becomes a very very long line (no \r\n) and some routers *doing SIP ALG* will fail when processing it, so the client doesn't get the response. Confirmed with a Cisco router. So waht I do in the server I've coded, is separate the request headers and the request body, encode each part in Base64 and send two responses: a 180 containing the requests headers in the body (Base64) and a 500 containing the request SDP. For this to implement in a Kamailio/SR module, it will be required a pv to get the received headers and other for the received body, is it possible? -- Iñaki Baz Castillo <ibc@aliax.net>
Iñaki Baz Castillo wrote:
El Lunes, 15 de Junio de 2009, Klaus Darilion escribió:
How do you get the original request untouched (no ;received param and so)?
$mb ?
Also, the reply should be "Content-Type: text/plain". {.. set_reply_body("$mb{s.base64}", "text/plain"); // \ // -> to be implemented // sl_send_reply("200","have fun"); exit; }
Hi Klaus, I remember now that it's not so easy:
If the server encodes *all* the original received request in Base64 and sets it in the response body, it becomes a very very long line (no \r\n) and some routers *doing SIP ALG* will fail when processing it, so the client doesn't get the response. Confirmed with a Cisco router.
So waht I do in the server I've coded, is separate the request headers and the request body, encode each part in Base64 and send two responses: a 180 containing the requests headers in the body (Base64) and a 500 containing the request SDP.
For this to implement in a Kamailio/SR module, it will be required a pv to get the received headers and other for the received body, is it possible?
AFAIK there is no PV for the headers, but for the body: $rb. So, using transformations you can "calculate" the headers: $mb{s.substr,0,$mb{s.l}-$rb{s.len}-4} Maybe the length calculation must be done separately. You can also use $ml, $cl or the newly introduced PV for the real body length ($bs). http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#sip_message_leng... klaus
Hello, On 06/15/2009 05:22 PM, Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
2009/6/15 Klaus Darilion <klaus.mailinglists@pernau.at>:
Wouldn't a sip-router module with this function an even better solution? Then every sip-router out there could offer this "service" under some special username. It could also be implemented by using transformations. Just add a base64 transformation and append_to_reply()
How do you get the original request *untouched* (no ;received param and so)?
$mb ?
Also, the reply should be "Content-Type: text/plain".
{.. set_reply_body("$mb{s.base64}", "text/plain"); // \ // -> to be implemented
although it is more expensive from size point of view than base6, now you can use s.enconde.hexa: http://www.kamailio.org/dokuwiki/doku.php/transformations:devel#s.encode.hex... base64 would be nice to add as transformation anyhow. Cheers, Daniel
// sl_send_reply("200","have fun"); exit; }
klaus
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com/
Hello Inaki, On 06/14/2009 02:17 AM, Iñaki Baz Castillo wrote:
Hi, as part of my personal battle against SIP ALG routers, I've created an utility to detect such routers:
http://dev.sipdoc.net/wiki/sip-stuff/SIP-ALG-Detector
It has two parts: client and server:
Basically, the client node running into the LAN sends an INVITE to the server node (running in a host with public IP). The request could be modified by the LAN router if SIP ALG is enabled. The server encodes the received request in Base64 and appends it to the SIP response. The client receives the response, decodes the body and gets the request as it arrived to the server. Then it creates a diff between the original request and the the request the server node received. These differences are displayed in the screen.
Both, UDP and TCP, tests are performed.
The client node is coded in Ruby and should work in any operating system (if Ruby is installed).
The server node is also coded in Ruby.
For those interested in try it, I have a server node running in my personal server: 87.98.230.161:5060 You can test the client against my server.
thanks for it, sounds very useful. What I see missing here is the case when the alg screws the routing so the reply does not get back to phone (e.g., via replaced on the way out but not changed back for reply), so it might be good to have like an ack when the reply was received by the UA. Or maybe would be better to do the other way. The client sends the request encoded to the server, the server unecodes it, does the diff and decides whether it is a possible alg in the middle. I think it is very useful, as the server would also know alg presence state :-). Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com/
El Jueves, 18 de Junio de 2009, Daniel-Constantin Mierla escribió:
Hello Inaki,
On 06/14/2009 02:17 AM, Iñaki Baz Castillo wrote:
Hi, as part of my personal battle against SIP ALG routers, I've created an utility to detect such routers:
http://dev.sipdoc.net/wiki/sip-stuff/SIP-ALG-Detector
It has two parts: client and server:
Basically, the client node running into the LAN sends an INVITE to the server node (running in a host with public IP). The request could be modified by the LAN router if SIP ALG is enabled. The server encodes the received request in Base64 and appends it to the SIP response. The client receives the response, decodes the body and gets the request as it arrived to the server. Then it creates a diff between the original request and the the request the server node received. These differences are displayed in the screen.
Both, UDP and TCP, tests are performed.
The client node is coded in Ruby and should work in any operating system (if Ruby is installed).
The server node is also coded in Ruby.
For those interested in try it, I have a server node running in my personal server: 87.98.230.161:5060 You can test the client against my server.
thanks for it, sounds very useful. What I see missing here is the case when the alg screws the routing so the reply does not get back to phone (e.g., via replaced on the way out but not changed back for reply), so it might be good to have like an ack when the reply was received by the UA.
Or maybe would be better to do the other way. The client sends the request encoded to the server, the server unecodes it, does the diff and decides whether it is a possible alg in the middle.
I think it is very useful, as the server would also know alg presence state :-).
Thanks Daniel, I'll think about it in order to improve it. -- Iñaki Baz Castillo <ibc@aliax.net>
2009/6/18 Daniel-Constantin Mierla <miconda@gmail.com>:
thanks for it, sounds very useful. What I see missing here is the case when the alg screws the routing so the reply does not get back to phone (e.g., via replaced on the way out but not changed back for reply), so it might be good to have like an ack when the reply was received by the UA.
However, the test is done in the client, not in the server. This is, the ACK could tell the server that the reply was received, but if not, what to do?
Or maybe would be better to do the other way. The client sends the request encoded to the server, the server unecodes it, does the diff and decides whether it is a possible alg in the middle.
I was thinking about it, but it doesn't convince me since ALG's usually "require" a "common" INVITE request with common SDP body. If the INVITE sent by the client contains itself encoded, it wouldn't look a "common" request and the ALG could react in any exotic way :(
I think it is very useful, as the server would also know alg presence state :-).
That's would be a different approach. I decided to do the test just in the client, so an user testing it doesn't require access to the server. Also the server doesn't require to store results in DB and so. Regards. -- Iñaki Baz Castillo <ibc@aliax.net>
On 06/19/2009 03:35 PM, Iñaki Baz Castillo wrote:
2009/6/18 Daniel-Constantin Mierla <miconda@gmail.com>:
thanks for it, sounds very useful. What I see missing here is the case when the alg screws the routing so the reply does not get back to phone (e.g., via replaced on the way out but not changed back for reply), so it might be good to have like an ack when the reply was received by the UA.
However, the test is done in the client, not in the server. This is, the ACK could tell the server that the reply was received, but if not, what to do?
in this way the server would know that client is behind or not alg (with special header saying yes/no or due to timeout). So first I was thinking to extend so both client/server know the alg presence state. But this option requires to maintain some state in the server, then I came with the second idea to include the encoded content in the initial request (within one or more headers), so it stays request-reply approach. Basically, not all content has to be encoded, but several headers and body, e.g., via header, contact header, call-id and sdp body -- if these are not touched, then all should be ok. Cheers, Daniel
Or maybe would be better to do the other way. The client sends the request encoded to the server, the server unecodes it, does the diff and decides whether it is a possible alg in the middle.
I was thinking about it, but it doesn't convince me since ALG's usually "require" a "common" INVITE request with common SDP body. If the INVITE sent by the client contains itself encoded, it wouldn't look a "common" request and the ALG could react in any exotic way :(
I think it is very useful, as the server would also know alg presence state :-).
That's would be a different approach. I decided to do the test just in the client, so an user testing it doesn't require access to the server. Also the server doesn't require to store results in DB and so.
Regards.
-- Daniel-Constantin Mierla http://www.asipto.com/
participants (4)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Nils Ohlmeier