[SR-Users] Kamailio Via: header issue

Fri May 27 11:31:46 CEST 2016

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

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