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.
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
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 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 :)
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
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
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.
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 -
Iñaki Baz Castillo -
Klaus Darilion -
Nils Ohlmeier