[SIPForum-discussion] Clarification on Processing Register Requests

Andrew Yu jazzaddict at gmail.com
Mon Jun 4 11:23:42 UTC 2007


Dear Members,

I'm working on an interop issue between my sbc & an CPE on regards to 
SIP register binding timer, this problem occurred after the SBC vendor 
has performed a software upgrade in the SBC.

The CPE is configured to re-register every 60secs.

SIP Signal flow
CPE -------Register (Expires 60)----------> Registrar
CPE <-------200 OK (Expires 59)---------- Registrar
CPE -------Register (Expires 59)----------> Registrar
CPE <-------200 OK (Expires 58)---------- Registrar
CPE -------Register (Expires 58)----------> Registrar
CPE <-------200 OK (Expires 57)---------- Registrar
CPE -------Register (Expires 57)----------> Registrar
CPE <-------200 OK (Expires 56)---------- Registrar
.
.
.

This goes on until the CPE hits Register expires 0, which it is actually 
de-registering itself when that happen. the CPE vendor states & with 
reference to SIP RFC3261 section 10.3, and the CPE is just processing 
accordingly to the RFC, while the SBC vendor says that the CPE should 
ignore the expires. So...who's right and who's wrong? The weirdest thing 
is that this doesn't affect CPE from another vendor, Cisco/Linksys PAP2 
that are out in the field.

RFC3261 Section 10.3

7. The registrar now processes each contact address in the Contact
         header field in turn.  For each address, it determines the
         expiration interval as follows:

         -  If the field value has an "expires" parameter, that value
            MUST be taken as the requested expiration.

         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.

         Allowing the registrar to set the registration interval
         protects it against excessively frequent registration refreshes
         while limiting the state that it needs to maintain and
         decreasing the likelihood of registrations going stale.  The
         expiration interval of a registration is frequently used in the
         creation of services.  An example is a follow-me service, where
         the user may only be available at a terminal for a brief
         period.  Therefore, registrars should accept brief
         registrations; a request should only be rejected if the
         interval is so short that the refreshes would degrade registrar
         performance.


      8. The registrar returns a 200 (OK) response.  The response MUST
         contain Contact header field values enumerating all current
         bindings.  Each Contact value MUST feature an "expires"
         parameter indicating its expiration interval chosen by the
         registrar.  The response SHOULD include a Date header field.

Here are things I'll like to clarify with:

   1. Why does the registrar decrement the requested expiration (x-1),
      is this a standard practice for processing register requests?
   2. I'll like confirmation that the CPE is doing the right thing by
      accepting the registrar expiration timing.
   3. Is there any reason that Cisco/Linksys doesn't go with the
      registrar expiration timing in 200 OK?
   4. Should the CPE allow itself to sent register expires = 0?
   5. The CPE is configured to re-register every 60secs, should it
      refreshes it's binding every 60secs or accept registrar expiration
      timing?

Please advice, thanks alot.

Andrew





More information about the discussion mailing list