Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call.
From what we have analyzed, the problem is not so much due to the number
of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
Hello,
the long Via branch is because of using topoh module. Do you need that?
The alternatives would be:
- disable topoh module
- or configure the kernel to do udp defragmentation (should be default in modern linux)
- or switch to tcp/tls
- or try to use the new topos module in 4.4 -- not that it is not well tested and you should not go with it in production directly. Any issue encountered with topos should be reported on kamailio project on github and I will take care fixing them.
Cheers, Daniel
On 24/05/16 09:57, Laura wrote:
Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call. From what we have analyzed, the problem is not so much due to the number of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
for how long you got this 20req/second?
The module is not counting like continuous time, but more like traffic on each second, iirc.
Cheers, Daniel
On 24/05/16 13:11, Daniel-Constantin Mierla wrote:
Hello,
the long Via branch is because of using topoh module. Do you need that?
The alternatives would be:
disable topoh module
or configure the kernel to do udp defragmentation (should be
default in modern linux)
or switch to tcp/tls
or try to use the new topos module in 4.4 -- not that it is not
well tested and you should not go with it in production directly. Any issue encountered with topos should be reported on kamailio project on github and I will take care fixing them.
Cheers, Daniel
On 24/05/16 09:57, Laura wrote:
Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call. From what we have analyzed, the problem is not so much due to the number of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
ups .. wrong thread for the reply...
On 24/05/16 13:13, Daniel-Constantin Mierla wrote:
Hello,
for how long you got this 20req/second?
The module is not counting like continuous time, but more like traffic on each second, iirc.
Cheers, Daniel
On 24/05/16 13:11, Daniel-Constantin Mierla wrote:
Hello,
the long Via branch is because of using topoh module. Do you need that?
The alternatives would be:
disable topoh module
or configure the kernel to do udp defragmentation (should be
default in modern linux)
or switch to tcp/tls
or try to use the new topos module in 4.4 -- not that it is not
well tested and you should not go with it in production directly. Any issue encountered with topos should be reported on kamailio project on github and I will take care fixing them.
Cheers, Daniel
On 24/05/16 09:57, Laura wrote:
Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call. From what we have analyzed, the problem is not so much due to the number of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
honestly we only use the topoh modules for this
# topoh paramiters modparam("topoh", "mask_ip", "1.1.1.1")
Pratically we created a cluster and we use VRRP for HA of the service.. so we use topoh for menage the virtual IP on kamailio..
Is there any other way we could use for stop using topoh ?
Regards
Il 24/05/16 13:11, Daniel-Constantin Mierla ha scritto:
Hello,
the long Via branch is because of using topoh module. Do you need that?
The alternatives would be:
disable topoh module
or configure the kernel to do udp defragmentation (should be
default in modern linux)
or switch to tcp/tls
or try to use the new topos module in 4.4 -- not that it is not
well tested and you should not go with it in production directly. Any issue encountered with topos should be reported on kamailio project on github and I will take care fixing them.
Cheers, Daniel
On 24/05/16 09:57, Laura wrote:
Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call.
From what we have analyzed, the problem is not so much due to the number
of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Laura,
if it's just about advertising the IP, then you can simply do the following:
listen=udp:10.10.10.10:5060 advertise 11.11.11.11:5060 (http://www.kamailio.org/wiki/cookbooks/devel/core#listen)
which will put 11.11.11.11 instead of the own, local IP.
Thanks, Carsten
2016-05-24 14:40 GMT+02:00 Laura red_dra@plugit.net:
Hello,
honestly we only use the topoh modules for this
# topoh paramiters modparam("topoh", "mask_ip", "1.1.1.1")
Pratically we created a cluster and we use VRRP for HA of the service.. so we use topoh for menage the virtual IP on kamailio..
Is there any other way we could use for stop using topoh ?
Regards
Il 24/05/16 13:11, Daniel-Constantin Mierla ha scritto:
Hello,
the long Via branch is because of using topoh module. Do you need that?
The alternatives would be:
disable topoh module
or configure the kernel to do udp defragmentation (should be default in
modern linux)
or switch to tcp/tls
or try to use the new topos module in 4.4 -- not that it is not well
tested and you should not go with it in production directly. Any issue encountered with topos should be reported on kamailio project on github and I will take care fixing them.
Cheers, Daniel
On 24/05/16 09:57, Laura wrote:
Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call.
From what we have analyzed, the problem is not so much due to the number
of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Carsten,
you right about that.. without topoh module the branch is ok.
I did some test and all seem to work correctly.
I forgot to say that we used topoh for "mask" the real ip of the A-LEG customer over platform, and without the topoh modules
i can see all the real ip in the Via: records.
Any solution for that ?
Thanks
Laura
Il 24/05/16 14:58, Carsten Bock ha scritto:
Hi Laura,
if it's just about advertising the IP, then you can simply do the following:
listen=udp:10.10.10.10:5060 advertise 11.11.11.11:5060 (http://www.kamailio.org/wiki/cookbooks/devel/core#listen)
which will put 11.11.11.11 instead of the own, local IP.
Thanks, Carsten
2016-05-24 14:40 GMT+02:00 Laura red_dra@plugit.net:
Hello,
honestly we only use the topoh modules for this
# topoh paramiters modparam("topoh", "mask_ip", "1.1.1.1")
Pratically we created a cluster and we use VRRP for HA of the service.. so we use topoh for menage the virtual IP on kamailio..
Is there any other way we could use for stop using topoh ?
Regards
Il 24/05/16 13:11, Daniel-Constantin Mierla ha scritto:
Hello,
the long Via branch is because of using topoh module. Do you need that?
The alternatives would be:
disable topoh module
or configure the kernel to do udp defragmentation (should be default in
modern linux)
or switch to tcp/tls
or try to use the new topos module in 4.4 -- not that it is not well
tested and you should not go with it in production directly. Any issue encountered with topos should be reported on kamailio project on github and I will take care fixing them.
Cheers, Daniel
On 24/05/16 09:57, Laura wrote:
Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call.
From what we have analyzed, the problem is not so much due to the number
of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
see topos module, but that is only in 4.4 release and, again, you should do some tests as it is a module in its early phase of development.
Cheers, Daniel
On 24/05/16 15:40, Laura wrote:
Hi Carsten,
you right about that.. without topoh module the branch is ok.
I did some test and all seem to work correctly.
I forgot to say that we used topoh for "mask" the real ip of the A-LEG customer over platform, and without the topoh modules
i can see all the real ip in the Via: records.
Any solution for that ?
Thanks
Laura
Il 24/05/16 14:58, Carsten Bock ha scritto:
Hi Laura,
if it's just about advertising the IP, then you can simply do the following:
listen=udp:10.10.10.10:5060 advertise 11.11.11.11:5060 (http://www.kamailio.org/wiki/cookbooks/devel/core#listen)
which will put 11.11.11.11 instead of the own, local IP.
Thanks, Carsten
2016-05-24 14:40 GMT+02:00 Laura red_dra@plugit.net:
Hello,
honestly we only use the topoh modules for this
# topoh paramiters modparam("topoh", "mask_ip", "1.1.1.1")
Pratically we created a cluster and we use VRRP for HA of the service.. so we use topoh for menage the virtual IP on kamailio..
Is there any other way we could use for stop using topoh ?
Regards
Il 24/05/16 13:11, Daniel-Constantin Mierla ha scritto:
Hello,
the long Via branch is because of using topoh module. Do you need that?
The alternatives would be:
disable topoh module
or configure the kernel to do udp defragmentation (should be default in
modern linux)
or switch to tcp/tls
or try to use the new topos module in 4.4 -- not that it is not well
tested and you should not go with it in production directly. Any issue encountered with topos should be reported on kamailio project on github and I will take care fixing them.
Cheers, Daniel
On 24/05/16 09:57, Laura wrote:
Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call.
From what we have analyzed, the problem is not so much due to the number
of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel,
thanks for support, of course we'll plan to go over 4.4.x release and after that we'll test very well topos module. We'll give back to the specific list all datas of topos.
Cheers, Laura
Il 27/05/16 11:31, Daniel-Constantin Mierla ha scritto:
Hello,
see topos module, but that is only in 4.4 release and, again, you should do some tests as it is a module in its early phase of development.
Cheers, Daniel
On 24/05/16 15:40, Laura wrote:
Hi Carsten,
you right about that.. without topoh module the branch is ok.
I did some test and all seem to work correctly.
I forgot to say that we used topoh for "mask" the real ip of the A-LEG customer over platform, and without the topoh modules
i can see all the real ip in the Via: records.
Any solution for that ?
Thanks
Laura
Il 24/05/16 14:58, Carsten Bock ha scritto:
Hi Laura,
if it's just about advertising the IP, then you can simply do the following:
listen=udp:10.10.10.10:5060 advertise 11.11.11.11:5060 (http://www.kamailio.org/wiki/cookbooks/devel/core#listen)
which will put 11.11.11.11 instead of the own, local IP.
Thanks, Carsten
2016-05-24 14:40 GMT+02:00 Laura red_dra@plugit.net:
Hello,
honestly we only use the topoh modules for this
# topoh paramiters modparam("topoh", "mask_ip", "1.1.1.1")
Pratically we created a cluster and we use VRRP for HA of the service.. so we use topoh for menage the virtual IP on kamailio..
Is there any other way we could use for stop using topoh ?
Regards
Il 24/05/16 13:11, Daniel-Constantin Mierla ha scritto:
Hello,
the long Via branch is because of using topoh module. Do you need that?
The alternatives would be:
disable topoh module
or configure the kernel to do udp defragmentation (should be default in
modern linux)
or switch to tcp/tls
or try to use the new topos module in 4.4 -- not that it is not well
tested and you should not go with it in production directly. Any issue encountered with topos should be reported on kamailio project on github and I will take care fixing them.
Cheers, Daniel
On 24/05/16 09:57, Laura wrote:
Good morning list,
I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call.
From what we have analyzed, the problem is not so much due to the number
of entered Via: records but, by the fact that they contain a branch parameter extremely long.
Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B
Extract from SIP message sent from CARRIER A to K1
INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport.
Extract from SIP message sent from K1 to K2
INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: sip:192.168.158.42;lr;did=194.a0f1;nat=yes. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A.
Extract from SIP message sent from K2 to CARRIER B
INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: sip:192.168.127.244;lr;did=194.5122;nat=yes. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0.
Is there anyone here with the idea how to solve this problem ?
Best regards
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Carsten Bock -
Daniel-Constantin Mierla -
Laura