<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    I looked in the code and the expires is taken from contact header
    parameter if present. Maybe you can run in higher debug level and
    see if you can spot something in the log messages that can give a
    lead.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    On 6/2/11 9:23 PM, Andreas Granig wrote:
    <blockquote cite="mid:4DE7E343.1090509@sipwise.com" type="cite">
      <pre wrap="">Hi,

Found an interesting call-flow today where a client (pjsip) is behind
NAT and behaves like this during registration (kamailio-3.1.3):

REGISTER <a class="moz-txt-link-freetext" href="sip:somedomain.com">sip:somedomain.com</a>
Contact: <a class="moz-txt-link-rfc2396E" href="sip:me@10.0.0.7:2001;ob">&lt;sip:me@10.0.0.7:2001;ob&gt;</a>
Expires: 900

SIP/2.0 200 OK
Contact: <a class="moz-txt-link-rfc2396E" href="sip:me@10.0.0.7:2001;ob">&lt;sip:me@10.0.0.7:2001;ob&gt;</a>;expires=900;received=<a class="moz-txt-link-rfc2396E" href="sip:1.2.3.4:3001">"sip:1.2.3.4:3001"</a>

REGISTER <a class="moz-txt-link-freetext" href="sip:somedomain.com">sip:somedomain.com</a>
Contact: <a class="moz-txt-link-rfc2396E" href="sip:me@1.2.3.4:3001;transport=UDP;ob">&lt;sip:me@1.2.3.4:3001;transport=UDP;ob&gt;</a>
Contact: <a class="moz-txt-link-rfc2396E" href="sip:me@10.0.0.7:2001;ob">&lt;sip:me@10.0.0.7:2001;ob&gt;</a>;expires=0
Expires: 900

SIP/2.0 200 OK
Contact:
<a class="moz-txt-link-rfc2396E" href="sip:me@10.0.0.7:2001;ob">&lt;sip:me@10.0.0.7:2001;ob&gt;</a>;expires=900;received=<a class="moz-txt-link-rfc2396E" href="sip:1.2.3.4:3001">"sip:1.2.3.4:3001"</a>,
<a class="moz-txt-link-rfc2396E" href="sip:me@1.2.3.4:3001;transport=UDP;ob">&lt;sip:me@1.2.3.4:3001;transport=UDP;ob&gt;</a>;expires=900

So obviously the client is trying to unregister its private contact (for
whatever reason - probably to play nice with registrars not supporting
far-end NAT traversal), and tries to register the Contact with the
"received" address instead. Kamailio however ignores the ";expires=0"
for the private Contact and just saves both of them with the expiry
value given in the Expires header.

Taking the client behavior aside for now: is this the correct behavior
of the registrar module? In RFC3261 chapter 10.2.1.1 it says:

#+
There are two ways in which a client can suggest an expiration interval
for a binding: through an Expires header field or an "expires" Contact
header parameter. The latter allows expiration intervals to be suggested
on a per-binding basis when more than one binding is given in a single
REGISTER request, whereas the former suggests an expiration interval for
all Contact header field values that do not contain the "expires"
parameter.
#-

So I'd say that in my specific case "expires" Contact header param
(which is 0 for the binding having 10.0.0.7) should de-register this
particular binding, whereas the Expires header should be applied to the
second binding (having the 1.2.3.4) because it doesn't carry an
"expires" param.

Opinions on that one?

Andreas
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla -- <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda">http://twitter.com/miconda</a></pre>
  </body>
</html>