18 Aug
2015
18 Aug
'15
6:22 a.m.
Hello,
We have a scenario like this:
SUA -> Kamailio with registrar module -> Asterisk
A call from the SUA is set up with SIP timers, and after 15 minutes
Asterisk sends a re-INVITE to Kamailio to forward on to the SUA. That
re-INVITE has a RURI with the address and port of the SUA at the time the
call started.
Now if the SUA re-registers after the call starts and before the re-INVITE,
and is on a new address or port number, then the re-INVITE never gets to
the phone.
Obviously Kamailio should send the re-INVITE to the new address/port, but
is not. The re-INVITE is routed using the lookup() function.
Can anyone suggest why this is happening?
Thanks in advance,
--
David Cunningham, Voisonics
http://voisonics.com/
USA: +1 213 221 1092
UK: +44 (0) 20 3298 1642
Australia: +61 (0) 2 8063 9019
18 Aug
18 Aug
6:42 a.m.
Hello,
On 08/17/2015 11:22 PM, David Cunningham wrote:
We have a scenario like this:
SUA -> Kamailio with registrar module -> Asterisk
A call from the SUA is set up with SIP timers, and after 15 minutes
Asterisk sends a re-INVITE to Kamailio to forward on to the SUA. That
re-INVITE has a RURI with the address and port of the SUA at the time
the call started.
Now if the SUA re-registers after the call starts and before the
re-INVITE, and is on a new address or port number, then the re-INVITE
never gets to the phone.
Obviously Kamailio should send the re-INVITE to the new address/port,
but is not. The re-INVITE is routed using the lookup() function.
Can anyone suggest why this is happening?
Reinvites are just ordinary in-dialog requests, and thus should be
routed as in-dialog requests, in the loose_route() section of the config
file, i.e.
if(has_totag()) {
if(loose_route()) {
if(!t_relay())
sl_reply_error();
exit;
} else {
if(is_method("ACK")) {
if(t_check_trans())
t_relay();
exit;
}
sl_send_reply("403", "Forbidden");
}
exit;
}
In-dialog requests (including reinvites) should _never_ be routed
dynamically, e.g. based on lookup(). For dialogs that are established
through the proxy and where the proxy requests to remain in the path of
in-dialog requests by adding a Record-Route header, the in-dialog
requests follow a strictly predetermined path that was computed at the
time of the establishment of the dialog. This is true of end-to-end ACKs
(for 2xx replies), reinvites, BYEs, etc.
Additionally, the Request URI of the in-dialog request should be equal
to the Contact URI of the remote party to the dialog. This is known as
the "remote target" in standards parlance. It is at the time of the
initial dialog-forming request routing that all NAT-related
considerations are computed, e.g. countermeasures for the difference
between the outward representations made by a party's Contact URI and
the actual network and transport-layer source from which the initial
request or reply originated.
So, in short, you shouldn't be doing anything other than the
abovementioned logic to route a reinvite, notwithstanding RTP pivoting
measures if using rtpproxy/rtpengine.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
7:01 a.m.
Apologies, you're right that the lookup() would not apply in this case.
So what, if anything, should Kamailio do in the case where a SUA's address
changes during a call?
On 18 August 2015 at 13:42, Alex Balashov <abalashov(a)evaristesys.com> wrote:
Hello,
On 08/17/2015 11:22 PM, David Cunningham wrote:
We have a scenario like this:
--
David Cunningham, Voisonics
http://voisonics.com/
USA: +1 213 221 1092
UK: +44 (0) 20 3298 1642
Australia: +61 (0) 2 8063 9019
SUA -> Kamailio with registrar module -> Asterisk
A call from the SUA is set up with SIP timers, and after 15 minutes
Asterisk sends a re-INVITE to Kamailio to forward on to the SUA. That
re-INVITE has a RURI with the address and port of the SUA at the time
the call started.
Now if the SUA re-registers after the call starts and before the
re-INVITE, and is on a new address or port number, then the re-INVITE
never gets to the phone.
Obviously Kamailio should send the re-INVITE to the new address/port,
but is not. The re-INVITE is routed using the lookup() function.
Can anyone suggest why this is happening?
Reinvites are just ordinary in-dialog requests, and thus should be routed
as in-dialog requests, in the loose_route() section of the config file, i.e.
if(has_totag()) {
if(loose_route()) {
if(!t_relay())
sl_reply_error();
exit;
} else {
if(is_method("ACK")) {
if(t_check_trans())
t_relay();
exit;
}
sl_send_reply("403", "Forbidden");
}
exit;
}
In-dialog requests (including reinvites) should _never_ be routed
dynamically, e.g. based on lookup(). For dialogs that are established
through the proxy and where the proxy requests to remain in the path of
in-dialog requests by adding a Record-Route header, the in-dialog requests
follow a strictly predetermined path that was computed at the time of the
establishment of the dialog. This is true of end-to-end ACKs (for 2xx
replies), reinvites, BYEs, etc.
Additionally, the Request URI of the in-dialog request should be equal to
the Contact URI of the remote party to the dialog. This is known as the
"remote target" in standards parlance. It is at the time of the initial
dialog-forming request routing that all NAT-related considerations are
computed, e.g. countermeasures for the difference between the outward
representations made by a party's Contact URI and the actual network and
transport-layer source from which the initial request or reply originated.
So, in short, you shouldn't be doing anything other than the
abovementioned logic to route a reinvite, notwithstanding RTP pivoting
measures if using rtpproxy/rtpengine.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:06 a.m.
It should not change during the call. The rules prohibit that. The only way to change the
remote target address within a dialog is, ironically, via a reinvite and/or response, but
that would need to come from the UA itself.
Your best bet to ensure that the NAT pinhole to the endpoint does not go away during the
call is some sort of keepalive, be it the NAT "ping" functionality of the
nathelper module or the in-dialog OPTIONS pings from the dialog module. That should keep
the NAT mapping refreshed.
If the endpoint still becomes unreachable, there's not much you can do. Nothing that
would conform to the protocol state machine, anyway. :-)
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my Nexus 10.
7:07 a.m.
Thank you Alex.
On 18 August 2015 at 14:06, Alex Balashov <abalashov(a)evaristesys.com> wrote:
It should not change during the call. The rules
prohibit that. The only
way to change the remote target address within a dialog is, ironically, via
a reinvite and/or response, but that would need to come from the UA itself.
Your best bet to ensure that the NAT pinhole to the endpoint does not go
away during the call is some sort of keepalive, be it the NAT "ping"
functionality of the nathelper module or the in-dialog OPTIONS pings from
the dialog module. That should keep the NAT mapping refreshed.
If the endpoint still becomes unreachable, there's not much you can do.
Nothing that would conform to the protocol state machine, anyway. :-)
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my Nexus 10.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
David Cunningham, Voisonics
http://voisonics.com/
USA: +1 213 221 1092
UK: +44 (0) 20 3298 1642
Australia: +61 (0) 2 8063 9019
7:09 a.m.
PS. In pondering these matters, it is useful to compartmentalise the idea of "address
to which request is sent" (logically) from "the network and transport-layer
destination (e.g. IP/port) used to reach the endpoint". In the case of NAT, they are
not one and the same.
The RURI stays equal to the Contact remote target. The network destination itself can be
whatever.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my Nexus 10.
3386
days inactive
3386
days old
5 comments
2 participants
participants (2)
-
Alex Balashov -
David Cunningham