[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