Hello to all!
I need a little help with our ser installation (ser-2.0.0-rc1). The continuous groving up of our infrastructure and using even more codecs, causes the INVITE (udp) to be over 1500bytes. An external->incoming call to our proxy sip comes in with a size of ~1300 and will be forwarded to the end device (sua) over 1500. Ser is adding more than 200bytes in the udp packet. I can see 'INVITE' from ser to customer, but the INVITE is not answerred due the size. I'm sure about that, because in certain situations, deleting codec list the packet-size goes under the 1500bytes and all works. To main issue is from external calls to ser server to our customers. Calls started from customers to ser and then out are all ok. Now the question: Could the passage from UDP to TCP solve the issue? Could someone give me an example and how implement it into our ser configuration? The atteched configuration, ser on a mysql basis, is working well in expect the issue described.
Thank's a lot for your help!
Simon
On Sep 29, 2010 at 10:43, Simone Felici s.felici@mclink.eu wrote:
Hello to all!
I need a little help with our ser installation (ser-2.0.0-rc1). The continuous groving up of our infrastructure and using even more codecs, causes the INVITE (udp) to be over 1500bytes. An external->incoming call to our proxy sip comes in with a size of ~1300 and will be forwarded to the end device (sua) over 1500. Ser is adding more than 200bytes in the udp packet. I can see 'INVITE' from ser to customer, but the INVITE is not answerred due the size. I'm sure about that, because in certain situations, deleting codec list the packet-size goes under the 1500bytes and all works. To main issue is from external calls to ser server to our customers. Calls started from customers to ser and then out are all ok.
Most likely at some point the UDP packet has to be fragmented and since ser 2.0 doesn't clear the DF bit on linux, the first router that has to do the fragmentation will just drop the packet.
Now the question: Could the passage from UDP to TCP solve the issue?
It could, but it also could introduce other problems. I would use at least 2.1 with TCP (because of the async tcp support).
Could someone give me an example and how implement it into our ser configuration? The atteched configuration, ser on a mysql basis, is working well in expect the issue described.
The easiest way would be with a more recent version, either ser 2.1 or better sr 3.0 (http://sip-router.org/tarballs/sr/sr_3.0/) or the soon to be released 3.1 (next week). Note however that you will have to migrate the config file (but not the DB).
All the version above will make sure the DF bit is clear. They also have automatic fallback to tcp if the packet is too big (you only have to set udp_mtu and udp_mtu_try_proto in the config).
If you decide to stick with 2.0, then you could try reducing a bit the packet size, by turning off some of the options. For example I would add: - modparam("rr", "append_fromtag", 0) ( the fromtag is there only for debugging purposes) - comment out setavpflag("$rtp_proxy_node", "dialog_cookie") (since according to your config you don't use it anyway) - sip_warning = 0 (won't affect the INVITEs, but replies will be smaller)
You could also try to backport the DF fix to 2.0: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=f3a... It should be quite easy, since this is only a small addition.
Andrei
Thank you a lot for your answer! I'll try these modifications, starting from some tune on actual config of ser-2.0 to bring all working correctly and then ending with a test phase of the ser-3.0 version. I'll let you know if I should have some new issues.
Thank you!!!
Simon
Il 30/09/2010 18:02, Andrei Pelinescu-Onciul ha scritto:
On Sep 29, 2010 at 10:43, Simone Felicis.felici@mclink.eu wrote:
Hello to all!
I need a little help with our ser installation (ser-2.0.0-rc1). The continuous groving up of our infrastructure and using even more codecs, causes the INVITE (udp) to be over 1500bytes. An external->incoming call to our proxy sip comes in with a size of ~1300 and will be forwarded to the end device (sua) over 1500. Ser is adding more than 200bytes in the udp packet. I can see 'INVITE' from ser to customer, but the INVITE is not answerred due the size. I'm sure about that, because in certain situations, deleting codec list the packet-size goes under the 1500bytes and all works. To main issue is from external calls to ser server to our customers. Calls started from customers to ser and then out are all ok.
Most likely at some point the UDP packet has to be fragmented and since ser 2.0 doesn't clear the DF bit on linux, the first router that has to do the fragmentation will just drop the packet.
Now the question: Could the passage from UDP to TCP solve the issue?
It could, but it also could introduce other problems. I would use at least 2.1 with TCP (because of the async tcp support).
Could someone give me an example and how implement it into our ser configuration? The atteched configuration, ser on a mysql basis, is working well in expect the issue described.
The easiest way would be with a more recent version, either ser 2.1 or better sr 3.0 (http://sip-router.org/tarballs/sr/sr_3.0/) or the soon to be released 3.1 (next week). Note however that you will have to migrate the config file (but not the DB).
All the version above will make sure the DF bit is clear. They also have automatic fallback to tcp if the packet is too big (you only have to set udp_mtu and udp_mtu_try_proto in the config).
If you decide to stick with 2.0, then you could try reducing a bit the packet size, by turning off some of the options. For example I would add:
- modparam("rr", "append_fromtag", 0)
( the fromtag is there only for debugging purposes)
- comment out setavpflag("$rtp_proxy_node", "dialog_cookie") (since according to your config you don't use it anyway)
- sip_warning = 0 (won't affect the INVITEs, but replies will be smaller)
You could also try to backport the DF fix to 2.0: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=f3a... It should be quite easy, since this is only a small addition.
Andrei
On Sep 30, 2010 at 19:07, Simone Felici s.felici@mclink.eu wrote:
Thank you a lot for your answer! I'll try these modifications, starting from some tune on actual config of ser-2.0 to bring all working correctly and then ending with a test phase of the ser-3.0 version. I'll let you know if I should have some new issues.
I've just remember one more thing: try using consume_credentials() when proxy_authorize() (or radius_proxy_authorize) is successful. This will remove the auth. info from the packets (most likely if you forward them and the packets don't loop back through your proxy it is not needed anymore).
Speaking of radius_proxy_authorize(), you have a small script bug:
if (!radius_proxy_authorize("$domain_default")) {
xlog("L_INFO","LXLOG AUTHENTICATION: !proxy_authenticate"); if ($? == -2) {
...
$? is the return code of the last function, and in this case since you inserted that xlog() statement, $? will contain xlog() return value and not the one from radius_proxy_authorize().
You can further reduce the size by commenting out all the setavpflag(), but note that this will break rtpproxy/nat traversal (but you can do it the old style way, like in ser 0.9.9, without saving avps in RR).
Apart from that look at forwarded sip packets and see if you can spot useless headers. If you do you can always remove them, by using remove_hf(header_name).
If you try migrating to 3.0, check sip-router-oob.cfg or ser-oob.cfg (the name depends on how you install it). I think your config is based on the 2.0 version of it.
Andrei
Il 30/09/2010 19:47, Andrei Pelinescu-Onciul ha scritto:
On Sep 30, 2010 at 19:07, Simone Felicis.felici@mclink.eu wrote:
I've just remember one more thing: try using consume_credentials() when proxy_authorize() (or radius_proxy_authorize) is successful. This will remove the auth. info from the packets (most likely if you forward them and the packets don't loop back through your proxy it is not needed anymore).
Thank you Andrei for your help. Could you point me on the right place where apply the consume_credentials() based on my config?
In addiction, I've read I could remove the Media Description | Media Attribute part. That would be a lot of stuff. Is it true? And if, how?
I cannot start with 3.1 now, but I'm planning to do it. Meanwhile it's importanto to reduce the header enough since the new platform with 3.0 is ready.
Thank's a lot
Simon
On Oct 04, 2010 at 20:24, Simone Felici s.felici@mclink.eu wrote:
Il 30/09/2010 19:47, Andrei Pelinescu-Onciul ha scritto:
On Sep 30, 2010 at 19:07, Simone Felicis.felici@mclink.eu wrote:
I've just remember one more thing: try using consume_credentials() when proxy_authorize() (or radius_proxy_authorize) is successful. This will remove the auth. info from the packets (most likely if you forward them and the packets don't loop back through your proxy it is not needed anymore).
Thank you Andrei for your help. Could you point me on the right place where apply the consume_credentials() based on my config?
You have something like: if (!radius_proxy_authorize("$domain_default")) { .... drop; } -> here consume_credentials()
In addiction, I've read I could remove the Media Description | Media Attribute part. That would be a lot of stuff. Is it true? And if, how?
It depends on what you remove. You cannot remove the transport part for example. You could try removing some of the optional part.
You could do it with subst() (textops). E.g.: subst('/^i=.*$//g');
Andrei
-
Andrei Pelinescu-Onciul -
Simone Felici