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 <abalas...@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
>
--
David Cunningham, Voisonics
http://voisonics.com/
USA: +1 213 221 1092
UK: +44 (0) 20 3298 1642
Australia: +61 (0) 2 8063 9019
_______________________________________________
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
