[asterisk-bugs] [Asterisk 0014366]: Registration expiry not compatible with some ITSP

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14366 
====================================================================== 
Reported By:                Nick_Lewis
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14366
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 172234 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-29 11:49 CST
Last Modified:              2009-08-05 09:45 CDT
====================================================================== 
Summary:                    Registration expiry not compatible with some ITSP
Description: 
The configured registration expiry value is overwritten by the initial
expiry value from UAS. Subsequent registrations use the new value. This
prevents the UAS from changing its registration expiry value.

Some ITSP use changing registration periods to discover the NAT binding
period at the UAC. Their UAS will set it initially very low and keep
increasing it until they see that the src port number of the registration
has changed. This indicates the nat binding period. The ITSP will then use
an expiry period a little less than this so that the UAC is reregistering
at the minimum required to keep alive the nat binding. However the UAS will
never increase the expiry beyond that requested by the UAC. If the UAC uses
the initial UAS expiry instead of the configured value then the
registration expiry gets stuck at a ludicrously short period.

Issue 14185 contained a patch chan_sip.c-expiryrequest6.patch that dealt
with this in addition to getting the expiry parameter parsed but the
revision r172234 does not implement all of the patch
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014185 [patch] Setting registration expiry in ...
====================================================================== 

---------------------------------------------------------------------- 
 (0108652) Nick_Lewis (reporter) - 2009-08-05 09:45
 https://issues.asterisk.org/view.php?id=14366#c108652 
---------------------------------------------------------------------- 
Sorry the problem is now a bit more subtle than previously described and
only occurs if a 423 response is received to the outgoing register request.


RFC3261 states that the current register request may be retried with a
revised expiry value if it is rejected with a 423 code. It does not state
that the configuration of the expiry value may be changed for subsequent
registration requests.

Asterisk overwrites the r->expiry not only for the retry but also for
subsequent registrations until there is a reload. The value of r->expiry
varies unpredictably because reloads may happen at any time to modify
unrelated peers and registrations. Registration should behave in a
consistent way.

Another related problem is when the Min-Expires header contains a value
that is greater than max_expiry. In this case it is overwriting the
r->expiry with the Min-Expires value then overwriting it again with the
default_expiry value. This overwriting is done even though there is no
registration retry attempted. The correct r->expiry value is destroyed for
no purpose.

Since the problem is localized to function handle_response_register switch
case 423, I suggest that a variable be locally defined and used to restore
r->expiry e.g.

case 423:
 int configexpiry = r->expiry;
 r->expiry = ...
 ...
 ...
 ...
 r->expiry = configexpiry;
 break; 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-05 09:45 Nick_Lewis     Note Added: 0108652                          
======================================================================