Hello all,
I've been trying to figure out a cleaner way to determine the next hop for a SIP message, mainly for use within the NATMANAGE route for multi-homed kamailio instances (with three or more network interfaces on the kamailio host).
So far I have achieved this with a series of nested ifs, depending on whether the message is a request or a response and by calculating the next hop based on the various headers (R-URI, Route) and variables ($T_req($Ri), $dd, ) involved in SIP routing.
A simpler way to do it, of course, would be to use the onsend_route, but that would most likely introduce an unnecessary overhead for all routed messages.
I recently noticed there a pseudovariable called $nh(key), and I believe I can use $nh(d) to the same effect. I understand however, that this works for requests only. Also, the description of this PV in the documentation reads as follows:
Return attributes of next hop for the SIP request. Address is taken from
dst_uri, if set, if not from new r-uri or original r-uri.
What is not clear to me is if this covers in-dialog requests with the Route header set as well. Does the inclusion of a route header set the dst_uri PV? And if yes, is it safe to rely on dst_uri during request processing or is it set only after completion of script processing?
Lastly, is there an analogue for SIP responses?
If not, is it safe to rely on first Via header to determine next hop for responses, or are there any other corner cases I need to heed?
Thanks in advance,
BR, George
"A simpler way to do it, of course, would be to use the onsend_route, but that would most likely introduce an unnecessary overhead for all routed messages."
What informs that assumption?
I suppose there is a measurable nonzero performance penalty to anything, but it should be negligible.
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Well, the "SIP routing with Kamailio" book by Daniel and Elena states:
"Defining the onsend_route should be done only if really needed, because it is executed for each request sent out, excluding the retransmissions."
Also, it similarly won't work for responses, only for requests...
On 13 April 2018 at 21:00, Alex Balashov abalashov@evaristesys.com wrote:
"A simpler way to do it, of course, would be to use the onsend_route, but that would most likely introduce an unnecessary overhead for all routed messages."
What informs that assumption?
I suppose there is a measurable nonzero performance penalty to anything, but it should be negligible.
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
That's probably true of any Kamailio functionality. :-) But point taken.
On April 13, 2018 2:09:10 PM EDT, George Diamantopoulos georgediam@gmail.com wrote:
Well, the "SIP routing with Kamailio" book by Daniel and Elena states:
"Defining the onsend_route should be done only if really needed, because it is executed for each request sent out, excluding the retransmissions."
Also, it similarly won't work for responses, only for requests...
On 13 April 2018 at 21:00, Alex Balashov abalashov@evaristesys.com wrote:
"A simpler way to do it, of course, would be to use the onsend_route,
but
that would most likely introduce an unnecessary overhead for all
routed
messages."
What informs that assumption?
I suppose there is a measurable nonzero performance penalty to
anything,
but it should be negligible.
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Sent via mobile, please forgive typos and brevity.
I guess you're right...
But if it is possible to do this with different means, I would prefer it...
I think I only miss the following points:
* Does $nh(d) work when the Route header enforces the next-hop in an in-dialog request? * Is it safe to determine next hop for responses by looking at the first Via header only, or are there exceptions to this?
BR, George
On 13 April 2018 at 21:20, Alex Balashov abalashov@evaristesys.com wrote:
That's probably true of any Kamailio functionality. :-) But point taken.
On April 13, 2018 2:09:10 PM EDT, George Diamantopoulos < georgediam@gmail.com> wrote:
Well, the "SIP routing with Kamailio" book by Daniel and Elena states:
"Defining the onsend_route should be done only if really needed, because it is executed for each request sent out, excluding the retransmissions."
Also, it similarly won't work for responses, only for requests...
On 13 April 2018 at 21:00, Alex Balashov abalashov@evaristesys.com wrote:
"A simpler way to do it, of course, would be to use the onsend_route,
but
that would most likely introduce an unnecessary overhead for all
routed
messages."
What informs that assumption?
I suppose there is a measurable nonzero performance penalty to
anything,
but it should be negligible.
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello all,
Just one last attempt at clearing the following points, if someone feels confident enough to answer:
* Does $nh(d) work when the Route header enforces the next-hop in an in-dialog request? * Is it safe to determine next hop for responses by looking at the first Via header only, or are there exceptions to this?
Thanks!
BR, George
On 13 April 2018 at 21:29, George Diamantopoulos georgediam@gmail.com wrote:
I guess you're right...
But if it is possible to do this with different means, I would prefer it...
I think I only miss the following points:
- Does $nh(d) work when the Route header enforces the next-hop in an
in-dialog request?
- Is it safe to determine next hop for responses by looking at the first
Via header only, or are there exceptions to this?
BR, George
On 13 April 2018 at 21:20, Alex Balashov abalashov@evaristesys.com wrote:
That's probably true of any Kamailio functionality. :-) But point taken.
On April 13, 2018 2:09:10 PM EDT, George Diamantopoulos < georgediam@gmail.com> wrote:
Well, the "SIP routing with Kamailio" book by Daniel and Elena states:
"Defining the onsend_route should be done only if really needed, because it is executed for each request sent out, excluding the retransmissions."
Also, it similarly won't work for responses, only for requests...
On 13 April 2018 at 21:00, Alex Balashov abalashov@evaristesys.com wrote:
"A simpler way to do it, of course, would be to use the onsend_route,
but
that would most likely introduce an unnecessary overhead for all
routed
messages."
What informs that assumption?
I suppose there is a measurable nonzero performance penalty to
anything,
but it should be negligible.
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Am Freitag, 4. Mai 2018, 16:25:06 CEST schrieb George Diamantopoulos:
Just one last attempt at clearing the following points, if someone feels confident enough to answer:
- Does $nh(d) work when the Route header enforces the next-hop in an
in-dialog request?
- Is it safe to determine next hop for responses by looking at the first
Via header only, or are there exceptions to this? [..]
Hello George,
I can't comment on the $nh(d) question right now, I would just test it.
About the next hop choosing for responses - its described in the standard:
https://tools.ietf.org/html/rfc3261#section-16.7 (part 9):
"[..] The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost Via header field value. [..]" Its a bit more complicated then this excerpt, have a look to the complete section.
Best regards,
Henning