Hello. I'm trying to make carrierroute work on default kamailio.cfg
first route:
FXS gw ->(NAT)->Kami->FS->PSTN
second route
FXS gw->(NAT)-> Kami->Mediant2000->E1->PSTN
First one works OK, but if second route triggers, the following disaster occurs (tshark dump) https://pastebin.com/00Ayty36
carrierroute is used as following https://pastebin.com/5J1atq00
What's wrong?
Hello 200 Ok couldnt reach somewhere. it is hard to understand what is going. YOu can use sngrep for tshark to understand better.
Maybe there is nat issue
https://github.com/irontec/sngrep/wiki/Installing-Binaries#centos--fedora--r...
-- View this message in context: http://sip-router.1086192.n5.nabble.com/carrierroute-and-failure-route-tp160... Sent from the Users mailing list archive at Nabble.com.
Hi,
On Thu, Aug 3, 2017 at 12:48 PM, Yu Boot yu@yu-boot.ru wrote:
First one works OK, but if second route triggers, the following disaster occurs (tshark dump) https://pastebin.com/00Ayty36
it's not really a disaster. The Mediant2000 sends out a reINVITE after the call was established. The client responds with a 200 OK, but then the ACK is sent to the wrong request URI. While in the reINVITE the request URI was "sip:200@172.16.0.158:5060;alias=1.2.176.33~5060~1", it is "sip:200@172.16.0.158:5060" later in the ACK.
My guess is you're record routing your packets even in loose routing. And you're not doing adding contact aliases there. I've seen before that clients then re-learn their route to the other side and fuck up loose routing.
You should only call record_route() in the initial call setup, never again after the 200 OK. Then you should be fine.
Regards, Sebastian
I use this in WITHINDLG to handle reINVITEs
else if ( is_method("INVITE") ) { record_route();
or T.38 fax behind NAT doesn't work at all.
03.08.2017 15:14, Sebastian Damm пишет:
Hi,
On Thu, Aug 3, 2017 at 12:48 PM, Yu Boot yu@yu-boot.ru wrote:
You should only call record_route() in the initial call setup, never again after the 200 OK. Then you should be fine.
Hi,
On Thu, Aug 3, 2017 at 3:45 PM, Yu Boot yu@yu-boot.ru wrote:
I use this in WITHINDLG to handle reINVITEs
else if ( is_method("INVITE") ) { record_route();or T.38 fax behind NAT doesn't work at all.
Actually that shouldn't be the case. I know, T.38 needs a reINVITE, too, but the record route information is supplied in the 200 OK. (If it isn't than that's what's broken.) The route information doesn't change with reINVITEs, so there's no need to record-route reINVITEs.
But if you really need the record-route there, then you need to call set_contact_alias() in the reply to your reINVITE. So you might have to add a different reply_route[reinvite] and set t_on_reply(reinvite) in the WITHINDLG route. But I really think that's not necessary.
Sebastian
Problem was magically solved by replacing t_relay in CR route by route (RELAY) :)
And finally a question. Can't find answer in Kami docs. What loose_route() proc actually does? Check some parameters, rewrite other parameters? I think real routing is performed by R-URI manipulations and t_relay to actually send created message, isn't it?
04.08.2017 13:26, Sebastian Damm пишет:
Hi,
On Thu, Aug 3, 2017 at 3:45 PM, Yu Boot yu@yu-boot.ru wrote:
I use this in WITHINDLG to handle reINVITEs
else if ( is_method("INVITE") ) { record_route();or T.38 fax behind NAT doesn't work at all.
Actually that shouldn't be the case. I know, T.38 needs a reINVITE, too, but the record route information is supplied in the 200 OK. (If it isn't than that's what's broken.) The route information doesn't change with reINVITEs, so there's no need to record-route reINVITEs.
But if you really need the record-route there, then you need to call set_contact_alias() in the reply to your reINVITE. So you might have to add a different reply_route[reinvite] and set t_on_reply(reinvite) in the WITHINDLG route. But I really think that's not necessary.
Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi,
On Fri, Aug 4, 2017 at 1:37 PM, Yu Boot yu@yu-boot.ru wrote:
Problem was magically solved by replacing t_relay in CR route by route (RELAY) :)
Okay, the only thing route(RELAY) does more is set the reply route. So maybe your replies were not correctly handled in first place. (And it does take care of the dialog handling, but I don't know whether that's important.)
And finally a question. Can't find answer in Kami docs. What loose_route() proc actually does? Check some parameters, rewrite other parameters? I think real routing is performed by R-URI manipulations and t_relay to actually send created message, isn't it?
Actually, it just removes the top Route header (itself) and takes the next Route header and places it's content into $du. When calling t_relay() after that, the request is sent on to $du (or $ru if it was the last hop before reaching the destination).
Documentation can be found here: https://www.kamailio.org/docs/modules/devel/modules/rr.html#loose-route-id
BR Sebastian
Played some time with sngrep and wireshark. All "working" solutions wors only with devices that ignore Contact and reply to Kami IP directly. Even with plain default kamailio.cfg relayed messages from NAtted device are with private address (and correct NATted alias) in Contact field. Is default cfg is broken? Kamailio 4.3
04.08.2017 15:26, Sebastian Damm пишет:
Hi,
On Fri, Aug 4, 2017 at 1:37 PM, Yu Boot yu@yu-boot.ru wrote:
Problem was magically solved by replacing t_relay in CR route by route (RELAY) :)
Okay, the only thing route(RELAY) does more is set the reply route. So maybe your replies were not correctly handled in first place. (And it does take care of the dialog handling, but I don't know whether that's important.)
Not related to the discussion, but very important:
* when replying, remove the SPAM word from the subject, otherwise will be dropped by spam filter on the server and mailing list manager. I understand that some emails servers insert the spam score to the subject, but if you see is not spam and decide to reply to mailing list, clean up the subject. Otherwise you will be blocked, because you also increase the risk that lists.kamailio.org email server will be blocked by other email servers.
Cheers, Daniel
On 04.08.17 15:27, Yu Boot wrote:
Played some time with sngrep and wireshark. All "working" solutions wors only with devices that ignore Contact and reply to Kami IP directly. Even with plain default kamailio.cfg relayed messages from NAtted device are with private address (and correct NATted alias) in Contact field. Is default cfg is broken? Kamailio 4.3
04.08.2017 15:26, Sebastian Damm пишет:
Hi,
On Fri, Aug 4, 2017 at 1:37 PM, Yu Boot yu@yu-boot.ru wrote:
Problem was magically solved by replacing t_relay in CR route by route (RELAY) :)
Okay, the only thing route(RELAY) does more is set the reply route. So maybe your replies were not correctly handled in first place. (And it does take care of the dialog handling, but I don't know whether that's important.)
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Gotcha! I've added fix_nated_contact() to [NATDETECT] route and now all messages UNTIL reinvite occurs are with correct NATed IP in "Contact" field.
Now I'm trying to make it work similiar way with reinvites. And I still don't understand, is default Kami config is somewhat broken or what.
route[NATDETECT] { #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else { if(is_first_hop())
#here we go
fix_nated_contact();
set_contact_alias(); } setflag(FLT_NATS); } #!endif return; }
04.08.2017 16:27, Yu Boot пишет:
Played some time with sngrep and wireshark. All "working" solutions wors only with devices that ignore Contact and reply to Kami IP directly. Even with plain default kamailio.cfg relayed messages from NAtted device are with private address (and correct NATted alias) in Contact field. Is default cfg is broken? Kamailio 4.3
04.08.2017 15:26, Sebastian Damm пишет:
Hi,
On Fri, Aug 4, 2017 at 1:37 PM, Yu Boot yu@yu-boot.ru wrote:
Problem was magically solved by replacing t_relay in CR route by route (RELAY) :)
Okay, the only thing route(RELAY) does more is set the reply route. So maybe your replies were not correctly handled in first place. (And it does take care of the dialog handling, but I don't know whether that's important.)
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi,
On Sat, Aug 5, 2017 at 7:00 PM, Yu Boot yu@yu-boot.ru wrote:
Gotcha! I've added fix_nated_contact() to [NATDETECT] route and now all messages UNTIL reinvite occurs are with correct NATed IP in "Contact" field.
while fix_nated_contact() may work in your scenario, it is generally a "bad variant" to use. The set_contact_alias() method is much less invasive. Depending on the client, it could reject reINVITEs or other in-call messages (like BYE) because the contact header initially sent differs from the request URI of the incoming message.
That's why set_contact_alias() only appends the real IP of the client, and handle_ruri_alias() takes care that the original contact is set correctly.
As said, if it works in your environment, everything is fine. Just be careful if you don't know what devices will be talking to your service.
BR Sebastian
Can you provide 100% working Kami config with correct NAT traversal and REINVITE please? -- Отправлено из myMail для Android понедельник, 07 августа 2017г., 13:08 +03:00 от Sebastian Damm damm@sipgate.de :
Hi,
On Sat, Aug 5, 2017 at 7:00 PM, Yu Boot < yu@yu-boot.ru > wrote:
Gotcha! I've added fix_nated_contact() to [NATDETECT] route and now all messages UNTIL reinvite occurs are with correct NATed IP in "Contact" field.
while fix_nated_contact() may work in your scenario, it is generally a "bad variant" to use. The set_contact_alias() method is much less invasive. Depending on the client, it could reject reINVITEs or other in-call messages (like BYE) because the contact header initially sent differs from the request URI of the incoming message.
That's why set_contact_alias() only appends the real IP of the client, and handle_ruri_alias() takes care that the original contact is set correctly.
As said, if it works in your environment, everything is fine. Just be careful if you don't know what devices will be talking to your service.
BR Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Here's full kamailio.cfg https://pastebin.com/EY4JXf8e
Any help what's wrong will be appreciated
Now the only problem is carrierroute to Mediant...
03.08.2017 15:14, Sebastian Damm пишет:
Hi,
On Thu, Aug 3, 2017 at 12:48 PM, Yu Boot yu@yu-boot.ru wrote:
First one works OK, but if second route triggers, the following disaster occurs (tshark dump) https://pastebin.com/00Ayty36
it's not really a disaster. The Mediant2000 sends out a reINVITE after the call was established. The client responds with a 200 OK, but then the ACK is sent to the wrong request URI. While in the reINVITE the request URI was "sip:200@172.16.0.158:5060;alias=1.2.176.33~5060~1", it is "sip:200@172.16.0.158:5060" later in the ACK.
My guess is you're record routing your packets even in loose routing. And you're not doing adding contact aliases there. I've seen before that clients then re-learn their route to the other side and fuck up loose routing.
You should only call record_route() in the initial call setup, never again after the 200 OK. Then you should be fine.
Regards, Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Sebastian Damm -
ycaner -
Yu Boot -
yu＠yu-boot.ru