carrierroute and failure route

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

carrierroute and failure route

Yu Boot
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?



_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: carrierroute and failure route

ycaner
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--rhel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: carrierroute and failure route

Sebastian Damm-2
In reply to this post by Yu Boot
Hi,

On Thu, Aug 3, 2017 at 12:48 PM, Yu Boot <[hidden email]> 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
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ *SPAM* 5.1 ] Re: carrierroute and failure route

Yu Boot
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 <[hidden email]> wrote:
>
> You should only call record_route() in the initial call setup, never
> again after the 200 OK. Then you should be fine.
>


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ *SPAM* 5.1 ] Re: carrierroute and failure route

Yu Boot
In reply to this post by Sebastian Damm-2
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 [hidden email] 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 [hidden email],
it is [hidden email] 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
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ *SPAM* 5.1 ] Re: carrierroute and failure route

Sebastian Damm-2
In reply to this post by Yu Boot
Hi,

On Thu, Aug 3, 2017 at 3:45 PM, Yu Boot <[hidden email]> 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
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ *SPAM* 5.1 ] Re: carrierroute and failure route

Yu Boot
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 <[hidden email]> 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
> [hidden email]
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ *SPAM* 5.1 ] Re: carrierroute and failure route

Sebastian Damm-2
Hi,

On Fri, Aug 4, 2017 at 1:37 PM, Yu Boot <[hidden email]> 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

_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ *SPAM* 2.2 ] Re: [ *SPAM* 5.1 ] Re: carrierroute and failure route

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 <[hidden email]> 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
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: carrierroute and failure route

Daniel-Constantin Mierla-6
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 <[hidden email]> 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
> [hidden email]
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: carrierroute and failure route

Yu Boot
In reply to this post by Yu Boot
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 <[hidden email]> 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
> [hidden email]
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: carrierroute and failure route

Sebastian Damm-2
Hi,

On Sat, Aug 5, 2017 at 7:00 PM, Yu Boot <[hidden email]> 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
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[ *SPAM* 3.0 ] Re: [ *SPAM* 2.2 ] Re: carrierroute and failure route

Yu Boot


Can you provide 100% working Kami config with correct NAT traversal and REINVITE please?
--
Отправлено из myMail для Android

понедельник, 07 августа 2017г., 13:08 +03:00 от Sebastian Damm [hidden email]:

Hi,

On Sat, Aug 5, 2017 at 7:00 PM, Yu Boot <[hidden email]> 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
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Loading...