[SIPForum-discussion] 答复: (瑞星提示-此邮件可能是垃圾邮件)[SIPForum-discussion] Clarification on Processing Register Requests

Mon Jun 4 12:57:29 UTC 2007

Hi all,

The blue items are my thinkings.

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?

Ans: I never see such things:-). But I also have nothing to say it wrong.

   2. I'll like confirmation that the CPE is doing the right thing by

      accepting the registrar expiration timing.

     Ans: I don’t think so, if the response of the REGISTER is 200 OK,
don’t change the expires value.

   3. Is there any reason that Cisco/Linksys doesn't go with the

      registrar expiration timing in 200 OK?

Ans: The Cisco/Linksys doesn’t get the expires from the 200 OK, because the
response of the REGISTER is 200 OK, no need to change the current expires
value.

   4. Should the CPE allow itself to sent register expires = 0?

   Ans: Of course yes. The expires=0 means de-Register.

   5. The CPE is configured to re-register every 60secs, should it

      refreshes it's binding every 60secs or accept registrar expiration

      timing?

   Ans: I think RFC3261-10.2.4 Refreshing Bindings section gives the answer.

-----邮件原件-----
发件人: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.
org] 代表 Andrew Yu
发送时间: 2007年6月4日 19:24
收件人: discussion at sipforum.org
抄送: Raymond Tun; Andrew Yu; Janice
主题: (瑞星提示-此邮件可能是垃圾邮件)[SIPForum-discussion] Clarification on
Processing Register Requests

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.