[SIPForum-discussion] Regarding Re-Register and min-expires
Andrew Yu
andrew at asiatel.com.sg
Mon Sep 3 16:59:21 UTC 2007
Hi Gopa,
I depends on how the UAS configured policy/behaviour when handling
misbehaving UAC that attempts to register at lower interval even after
423 response is sent. It is implementation dependent as mentioned
previously by Abhishek. For example, I configured my sip server to
response with 488 whenever UAC misbehave after 423. Any client-server
based is subjected to DOS attacks, and SIP-VoIP is not spared from this.
--
Cheers,
Asiatel Singapore Pte Ltd
Andrew Yu
19 Jalan Kilang Barat
#06-01, Acetech Centre
Singapore 159361
Tel: +65 6271 8233
Fax: +65 6274 4266
Gopalarathnam Sambasivan wrote:
> 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
> <mailto: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 <http://registrar.biloxi.com>
> SIP/2.0
> > Via: SIP/2.0/UDP bobspc.biloxi.com:5060
> <http://bobspc.biloxi.com:5060>;branch=z9hG4bKnashds7
> > Max-Forwards: 70
> > To: Bob <sip:bob at biloxi.com <mailto:sip:bob at biloxi.com>>
> > From: Bob < sip:bob at biloxi.com
> <mailto:sip:bob at biloxi.com>>;tag=456248
> > Call-ID: 843817637684230 at 998sdasdh09
> > CSeq: 1826 REGISTER
> > Contact: <sip:bob at 192.0.2.4 <mailto: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
> <http://sipforum.org/mailman/listinfo/discussion>
> > Post to the list at discussion at sipforum.org
> <mailto:discussion at sipforum.org>
> >
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
>
>
> __________ NOD32 2441 (20070807) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
More information about the discussion
mailing list