[SR-Users] Kamailio Via: header issue

[Daniel-Constantin Mierla]

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 at 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 at 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 at 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 at 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

-- 
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160524/9cea7793/attachment.html>