"Loose routing" of in-dialog requests is a complex, byzantine topic in SIP
proxy science. :-)
The highlights:
1. Requests which are scoped inside a "call" occur within a dialog -- e.g.
end-to-end ACK, INFO, BYE, etc.
This is to distinguish them from "initial" requests, which are subject to an
original routing decision. In contrast, in-dialog requests follow an
essentially predetermined (see #6) "route set".
The most salient characteristic of an in-dialog request is a ';tag=xxxxx'
parameter in the 'To' header. A tag will always be present in the 'From'
header, but is only present in the 'To' header on in-dialog requests;
2. In-dialog requests are, by default, directed to a Request URI that is equal
to the Contact URI of the other party. This implies that they would normally
flow around the proxy;
3. The Record-Route header added by the proxy to the initial INVITE changes
that. It says, "No, you need to shunt your in-dialog requests through me." The
Record-Route header is copied into the 200 OK that is sent back to the calling
party, so that it knows about the shunt, too.
4. There can be multiple Record-Route headers if multiple proxies are in the
path;
5. In the construction of an in-dialog request, the Record-Route headers are
turned into a stack of Route headers; these then traverse intermediate proxies,
with each proxy stripping off Route headers that refer to itself ("hey, that's
me!"), and forwarding the request to the next hop based on the next available
Route header.
Vitally, the Request URI is kept the same, and continues to match the remote
Contact URI; the Route hops only have the effect of changing the destination on
a practical (that is, network and transport) level;
6. The Contact URI at which a dialog party is targeted, known as the "remote
target", can be changed in a re-INVITE or UPDATE, which are known as "target
refresh" requests. These requests are better known for changing media
parameters, but this is another thing they can do, though it is seldom done;
In essence, loose_route() implements the logic behind #5.
The other parts of this whole stanza concern the relationship between ACKs and
transactions. The function t_check_trans() has very different behaviour that is
highly contextually sensitive, depending on what is being checked, and does
more than its name might imply:
https://kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.f.t_check_trans
-- Alex
> On Dec 14, 2022, at 6:19 PM, Jawaid Bazyar <[email protected]> wrote:
>
> Alex, that did it! Now to understand it 😊
> Thanks again,
> Jawaid
> From: Alex Balashov <[email protected]>
> Reply-To: "Kamailio (SER) - Users Mailing List" <[email protected]>
> Date: Wednesday, December 14, 2022 at 2:56 PM
> To: "Kamailio (SER) - Users Mailing List" <[email protected]>
> Subject: [SR-Users] Re: Failover - how does it work?
>
>
>> On Dec 13, 2022, at 10:09 PM, Jawaid Bazyar <[email protected]> wrote:
>>
>> That is working, however, on subsequent messages in the dialog (e.g., ACK,
>> INFO, BYE) the proxy tries the failed destination for each message.
>> Eventually it gets to the right place, but, is there a way to delete the
>> failed destination from the XAVP so this doesn't happen? Or just to force
>> subsequent messages in the transaction to use the same (working) destination?
>>
>> Sorry for all the questions, I'm a newbie!
>
> Not at all!
> Forcing subsequent in-dialog messages to go to the same destination is
> inherent to correct proxy behaviour; it just requires some additional logic
> that is part of typical Kamailio boilerplate. (You can only get away with
> having a 'minimalistic' config for so long. :)
> Check this out:
> https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L658-L698
> You'll want to put that near the top of your config, well before you handle
> any initial INVITEs.
> A simplified version that will work for your purposes:
> if(has_totag()) {
> if(loose_route()) {
> if(!t_relay())
> sl_reply_error();
> exit;
> } else if(is_method("ACK")) {
> if(t_check_trans()) {
> if(!t_relay())
> sl_reply_error();
> exit;
> }
> exit;
> }
> sl_send_reply("404", "Not here");
> }
> -- Alex
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
>
> __________________________________________________________ Kamailio - Users
> Mailing List - Non Commercial Discussions To unsubscribe send an email to
> [email protected] Important: keep the mailing list in the
> recipients, do not reply only to the sender! Edit mailing list options or
> unsubscribe: __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
