<div dir="ltr"><div dir="ltr">On Sat, Nov 23, 2019 at 9:37 PM Philipp Schöning <<a href="mailto:schoening.p@gmail.com">schoening.p@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">On IMS networks P-CSCF usually operate stateful, therefore a registration is always bound to a specific node.<div><br><div>When RFC3263 is used for a list of possible SIP-Servers/P-CSCF, this list of servers might change, if a DNS-based loadbalancing is used.</div></div><div><br></div><div>Asterisk is not taking the statefulness of SIP-Servers (and therefore of the registration) into consideration and is immediately sending SIP Requests to the new SIP-Server of the DNS result.</div><div><br></div><div>AudioCodes introduced with Firmware 7.20 a feature called 'Registrar Stickiness' which does the following:</div><div><br></div><div>[1] Enable = Enables the Register Stickiness feature. The device always routes SIP requests of a registered Account to the same registrar server to where the last successful REGISTER request was routed. In other words, once initial registration of the Account to one of the IP addresses in the Proxy Set (associated with the Account's Serving IP Group) is successful (i.e., 200 OK), binding ("stickiness") occurs to this specific address (registrar). All future SIP requests (e.g., INVITEs, SUBSCRIBEs and REGISTER refreshes) whose source and destination match the Account are sent to this registrar only. This applies until the registrar is unreachable or registration refresh fails, for whatever reason<br></div><div><br></div><div>Additionally there is a setting for the 'Registrar Search Mode':</div><div><br></div><div>■ [1] According to IMS Specifications = For the initial registration request, the device performs DNS resolution if the address of the Proxy Set is configured as an FQDN. It then attempts to register to one of the listed DNS-resolved addresses (or configured IP addresses), starting with the first listed address and then going down the list sequentially. If an address results in an unsuccessful registration, the device immediately tries the next address (without waiting any retry timeout). The device goes through the list of addresses until an address results in a successful registration. If registration is unsuccessful for all addresses, the device waits a configured retry time and then goes through the list again. Once initial registration is successful, periodic registration refreshes are performed as usual. In addition to the periodic refreshes, immediate register refreshes are done upon the following triggers according to the IMS specification:</div><div>✔ The device receives a SIP 408, 480, or 403 response from the Serving IP Group in response to an INVITE.<br></div><div>✔ The transaction timeout expires for an INVITE sent to the Serving IP Group.</div><div>✔ The device receives an INVITE from the Serving IP Group from an IP address other than the address to which it is currently registered. In this case, it also rejects the INVITE with a SIP 480 response. If the device's physical Ethernet link to the proxy goes down, the device re-registers this Account with the proxy when the link comes up again. Re-registration occurs even if proxy keep-alive is disabled.<br></div><div><br></div><div><a href="https://www.audiocodes.com/media/13258/mediant-800-msbr-users-manual-ver-72.pdf" target="_blank">https://www.audiocodes.com/media/13258/mediant-800-msbr-users-manual-ver-72.pdf</a><br></div><div>Page 475 ff.</div><div><br></div><div>Is it possible to enforce those two behaviours via settings in Asterisk? Or is this impossible in the current Asterisk architecture?<br></div></div></blockquote><div><br></div><div>There are no settings to enable this, as it is not functionality that anyone has worked on or added to Asterisk for PJSIP.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Senior Software Developer</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at</font> <a href="http://www.sangoma.com/" style="color:rgb(17,85,204)" target="_blank">www.sangoma.com</a></div></div></div></div></div></div></div></div>