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,
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
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@evaristesys.com wrote:
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/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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.
Thank you Alex.
On 18 August 2015 at 14:06, Alex Balashov abalashov@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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.
-
Alex Balashov -
David Cunningham