[SIPForum-discussion] Regarding Re-Register and min-expires

Gopalarathnam Sambasivan s.gopalarathnam at gmail.com
Tue Aug 7 12:18:45 UTC 2007


Hi Abhishek, All,
Thanks, My query is mainly for protecting the UAS from frequent re-register
bursts as RFC does not explicitly
state a method of handling this scenario case2. RFC just states that it is
the resposibility of UAC to refresh the
bindings and it  has to do so before the expires of the earlier register
(not when (duration)??).

Please let me know a mechanism for protecting UAS from re-register bursts.
I could not find a solution compliant with RFC.

Please do note that UAC need not be a SIP phone but a MGC which
serves several GWs (subscrs) using SIP.
consider every 1 min re- register (2hr expires) coming from UAC to UAS
(valid according 2 RFC) for all subscrs not in
call. Re-registers need to be sent before expiry to have bindings and have a
continuos service, which is a must from
UAC (MGC) perspective.

Case 2 is a client side error and correct possible error codes can be (But
these does not have the retry-after header)

    400 Bad Request
    406 Not Acceptable
    423 Interval Too Brief
    488 Not Acceptable Here

20.33 Retry-After

   The Retry-After header field can be used with a 500 (Server Internal
   Error) or 503 (Service Unavailable) response to indicate how long the
   service is expected to be unavailable to the requesting client and
   with a 404 (Not Found), 413 (Request Entity Too Large), 480
   (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603
   (Decline) response to indicate when the called party anticipates
   being available again.  The value of this field is a positive integer
   number of seconds (in decimal) after the time of the response.

   An optional comment can be used to indicate additional information
   about the time of callback.  An optional "duration" parameter
   indicates how long the called party will be reachable starting at the
   initial time of availability.  If no duration parameter is given, the
   service is assumed to be available indefinitely.

   Examples:

      Retry-After: 18000;duration=3600
      Retry-After: 120 (I'm in a meeting)


Best Regards,
Gopalarathnam.

On 8/7/07, Abhishek Mishra <abhishek.mishra at globallogic.com> wrote:
>
> Hi,
>
> Please see my comments inline.
>
> Kind Regards,
> -Abhishek
>
> On Tue, 2007-08-07 at 15:09, Gopalarathnam Sambasivan wrote:
> > Hello All,
> > Case1.
> > UAC sends a REGISTER with expires=1800 to UAS which has say
> > min-expires=3600.
> [Abhishek] I think Min-Expires: 3600 is too large value, anyways RFC
> does not disallow this value so it is OK.
> > UAS rejects the REGISTER with 423 (Interval Too Brief) with
> > min-expires=3600 - OK.
> > A retry of register with min-expires accepted by the server is
> > successful.
> >
> > Case2.
> > UAC sends a REGISTER with expires=7600 to UAS which has say
> > min-expires=3600.
> > There is no subscribe notify for subsequent registrations and hence
> > REGISTER is sent after
> > random time interval between 1 and expires.
> >
> > Say there is re- REGISTER s with expires=7600, coming every x secs
> > which is less than the
> > configured min-expires in the registrar.
> >
> > Question 1.
> > Can the server reject these frequent re-registers within registration
> > expiry with 423 response?
> > The min-expires seems to be available for the server to avoid flooding
> > of incoming registers.
> > But according to RFC3261 sec 10.3 it cannot be done. so what can be
> > done?
> > what is expected from perspective of UAS testing?
> [Abhishek] No, registrar cannot reject REGISTER with 423 for frequent
> registrations. Registrar can send 423 only if registration expiry is
> less than its configured value.
> >
> > Question 2.
> > From the perspective of UAC testing, can it be ensured that Re-
> > REGISTERS are sent only after min-expiry - 3600 on safer side and
> > before Expires - so that UAS will always treat the REGISTER without
> > overload?
> [Abhishek] Unfortunately it is implementation dependent. Usually sip
> phone sends registration refresh slightly before session expiry (or on
> session expiry).
> >
> > Thanks & Best Regards,
> > Gopalarathnam.
> >
> >
> > REGISTER which is repeated after every x secs < configured
> > min-expires:
> > ===========================================================
> > REGISTER sip:registrar.biloxi.com SIP/2.0
> >        Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> >        Max-Forwards: 70
> >        To: Bob <sip:bob at biloxi.com>
> >        From: Bob <sip:bob at biloxi.com>;tag=456248
> >        Call-ID: 843817637684230 at 998sdasdh09
> >        CSeq: 1826 REGISTER
> >        Contact: <sip:bob at 192.0.2.4>
> >        Expires: 7200
> >        Content-Length: 0
> >
> > Part from RFC3261 sec 10.3 Processing REGISTER Requests:
> > ==============================================
> >          The registrar MAY choose an expiration less than the
> > requested
> >          expiration interval.  If and only if the requested expiration
> >          interval is greater than zero AND smaller than one hour AND
> >          less than a registrar-configured minimum, the registrar MAY
> >          reject the registration with a response of 423 (Interval Too
> >          Brief).  This response MUST contain a Min-Expires header
> > field
> >          that states the minimum expiration interval the registrar is
> >          willing to honor.  It then skips the remaining steps.
> >
> >
> > ______________________________________________________________________
> > _______________________________________________
> > This is the SIP Forum discussion mailing list
> > TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> > Post to the list at discussion at sipforum.org
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070807/ed0a38b1/attachment-0002.html>


More information about the discussion mailing list