14 Jun
2009
14 Jun
'09
3:17 a.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>
15 Jun
15 Jun
12:20 a.m.
New subject: [Kamailio-Users] [sr-dev] [OT] SIP ALG Detector released
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
12:28 a.m.
New subject: [Kamailio-Users] [sr-dev] [OT] SIP ALG Detector released
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(a)aliax.net>
5:21 p.m.
New subject: [Kamailio-Users] [sr-dev] [OT] SIP ALG Detector released
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.
5:25 p.m.
New subject: [Kamailio-Users] [sr-dev] [OT] SIP ALG Detector released
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()
6:22 p.m.
New subject: [Kamailio-Users] [sr-dev] [OT] SIP ALG Detector released
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
6:30 p.m.
New subject: [Kamailio-Users] [sr-dev] [OT] SIP ALG Detector released
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;
}
9:04 p.m.
New subject: [Kamailio-Users] [sr-dev] [OT] SIP ALG Detector released
El Lunes, 15 de Junio de 2009, Klaus Darilion escribió:
How do you get the original request untouched (no
;received param and so)?
$mb ?
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(a)aliax.net>
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;
}
16 Jun
16 Jun
12:35 a.m.
New subject: [Kamailio-Users] [sr-dev] [OT] SIP ALG Detector released
Iñaki Baz Castillo wrote:
El Lunes, 15 de Junio de 2009, Klaus Darilion
escribió:
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_len…
klaus
How do you get the original request untouched
(no ;received param and so)?
$mb ?
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? 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
11:23 a.m.
New subject: [Kamailio-Users] [sr-dev] [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/
11:31 a.m.
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
1:35 a.m.
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:
Thanks Daniel, I'll think about it in order to improve it.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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 :-).
4:35 p.m.
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>
5:37 p.m.
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.
5638
days inactive
5643
days old
13 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Nils Ohlmeier