[OpenSIPS-Users] Userloc, Registrar, and issues with location entries being removed and user agents ignore expires enforcing
Jesus Rodriguez
jesusr at voztele.com
Fri Apr 17 00:11:49 CEST 2009
Hello Bobby,
> Thanks, I think I got confused between min, max, and default and
> what it means in terms of the RFC. I now understand I can send a
> 4XX back for an interval too brief, etc, etc, but ultimately I need
> to rely upon nat keepalive on the end user or nat_ping to keep the
> pinhole open.
Yes, you have to use some keepalive method to keep the nat pinhole
open (nat_traversal or nathelper modules can do this).
Regards.
Saludos
JesusR.
>
> On Thu, Apr 16, 2009 at 5:28 PM, Jesus Rodriguez
> <jesusr at voztele.com> wrote:
> Hi Bobby,
>
> Do not use the modparam("registrar", "max_expires", 45)... this is
> replacing the expires sent by the UA (3600 seconds) to the maximum
> accepted by your proxy (45 seconds).
>
> To limit the number of simultaneous registered contacts use the
> max_contacts modparam.
>
> Saludos
> JesusR.
>
>
>
> We're having an issue with userloc, registrar, and entries being
> removed from the store.
>
> Some devices, if behind home consumer routers, can not keep the nat
> pinhole open long enough to actually receive calls if it's a very
> long duration (say, 3600 seconds). So, we try to enforce by the
> following:
>
> modparam("usrloc", "db_mode", 2)
> modparam("usrloc", "db_url",
> "dburl_here")
> modparam("registrar", "default_expires", 30)
> modparam("registrar", "min_expires", 15)
> modparam("registrar", "max_expires", 45)
>
> And the register message:
>
> U 2009/04/16 16:55:13.922594 1.2.3.4:1076 -> 4.3.2.1:5060
> REGISTER sip:4.3.2.1 SIP/2.0.
> Via: SIP/2.0/UDP 1.2.3.4:1085;branch=z9hG4bK-12b688e4;rport.
> From: "Extension" <sip:username at 4.3.2.1>;tag=91682ba296592d12o0.
> To: "Extension" <sip:username at 4.3.2.1>.
> Call-ID: f2edcb48-8f3ca203 at 10.0.4.13.
> CSeq: 50140 REGISTER.
> Max-Forwards: 70.
> Contact: "Extension" <sip:username at 1.2.3.4:1085>;expires=3600.
> User-Agent: Linksys/SPA941-5.1.8.
> Content-Length: 0.
> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER.
> Supported: replaces.
> .
>
> U 2009/04/16 16:55:13.922777 4.3.2.1:5060 -> 1.2.3.4:1076
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 1.2.3.4:1085;branch=z9hG4bK-12b688e4;rport=1076.
> From: "Extension" <sip:username at 4.3.2.1>;tag=91682ba296592d12o0.
> To: "Extension"
> <sip:username at 4.3.2.1>;tag=d956cb2540203ca43d36f1e0fd077845.d21c.
> Call-ID: f2edcb48-8f3ca203 at 10.0.4.13.
> CSeq: 50140 REGISTER.
> Contact: <sip:username at 1.2.3.4:1076>;expires=45;received="sip:1.2.3.4:1076
> ".
> Server: OSips SIP (1.4.5).
> Content-Length: 0.
>
>
> Opensips removes the contact from the database after the replied
> timer, which is 45 seconds -- however, the phone doesn't register
> again for 3600 seconds.
>
> We know that other technologies will simply store the entries in a
> database as stale, but lookups for that contact will work
> arbitrarily for an indefinite amount of time. I would like to limit
> the amount of contacts for each user to just one (we don't support
> multiple contacts or presence), but that as well in the issues seem
> to cause phones to deregister after the 45 second interval.
>
> Is there an option or a flag that I'm missing so that even though I
> want to enforce a default/min/max time, if the phone doesn't
> register in that period, the contact still lingers around in memory
> for a predefined amount of time?
>
>
> Thanks again for all your help.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
> Saludos
> JesusR.
>
> ------------------------------------
> Jesus Rodriguez
> VozTelecom Sistemas, S.L.
> jesusr at voztele.com
> http://www.voztele.com
> Tel. 902360305
> -------------------------------------
>
>
>
>
>
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr at voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
More information about the Users
mailing list