13 Jun
2009
13 Jun
'09
8:17 p.m.
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(a)aliax.net>
14 Jun
14 Jun
5:20 p.m.
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
15 Jun
15 Jun
10:21 a.m.
Nils Ohlmeier schrieb:
Hi,
Am 14.06.2009 2:17 Uhr, schrieb Iñaki Baz Castillo:
It could also be implemented by using transformations. Just add a base64
transformation and append_to_reply()
regards
klaus
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.
10:25 a.m.
2009/6/15 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
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(a)aliax.net>
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()
11:22 a.m.
Iñaki Baz Castillo schrieb:
2009/6/15 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
How do you get the original request *untouched* (no ;received param and so)?
$mb ?
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() 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
11:30 a.m.
2009/6/15 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Great!
Great too.
Ok, I will try to implement it, thanks a lot :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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;
} 
18 Jun
18 Jun
4:23 a.m.
New subject: [Kamailio-Users] [OT] SIP ALG Detector released
Hello,
On 06/15/2009 05:22 PM, Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
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.he…
base64 would be nice to add as transformation anyhow.
Cheers,
Daniel
2009/6/15 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
How do you get the original request *untouched* (no ;received param
and so)?
$mb ?
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() 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
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)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/
4:31 a.m.
New subject: [Kamailio-Users] [OT] SIP ALG Detector released
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/
19 Jun
19 Jun
9:35 a.m.
New subject: [Kamailio-Users] [OT] SIP ALG Detector released
2009/6/18 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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(a)aliax.net>
10:37 a.m.
New subject: [Kamailio-Users] [OT] SIP ALG Detector released
On 06/19/2009 03:35 PM, Iñaki Baz Castillo wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
2009/6/18 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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
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.
5681
days inactive
5686
days old
9 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Nils Ohlmeier