[Devel] [ openser-Bugs-1494598 ] INFO:registrar:test_max_contacts: too many contacts for AOR

[SourceForge.net]

Bugs item #1494598, was opened at 2006-05-25 00:03
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1494598&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Closed
Resolution: None
Priority: 5
Submitted By: Norman Brandinger (goestelecom)
>Assigned to: Bogdan (bogdan_iancu)
Summary: INFO:registrar:test_max_contacts: too many contacts for AOR

Initial Comment:
There appears to be a problem registering a phone when
max_contacts is set to 1 as shown below:

modparam("registrar", "max_contacts", 1)


A SIP trace produced the following:

Contact:
<sip:8115 at 192.168.1.78:36355>;q=0.1;expires=80614;received="sip:public.ip.address:36355".
P-Registrar-Error: Too many registered contacts.
Server: OpenSer (1.1.0-dev19-tls (x86_64/freebsd)).


The register request has only a single contact (see
below) and the location table does not have an entry
for "8115".

REGISTER sip:openser SIP/2.0.
Via: SIP/2.0/UDP
192.168.1.78:40451;branch=z9hG4bK2ddad668b6bb4a45.
From: "xyz" <sip:8115 at openser>;tag=c3262ea0a9a9bddf.
To: <sip:8115 at openser>.
Contact: <sip:8115 at 192.168.1.78:40451>.
Supported: replaces.
Call-ID: d464edd74e1b66aa at 192.168.1.78.
CSeq: 100 REGISTER.
Expires: 180.
User-Agent: Grandstream BT110 1.0.7.11.
Max-Forwards: 70.
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
.


Regards,
Norm

----------------------------------------------------------------------

>Comment By: Bogdan (bogdan_iancu)
Date: 2006-05-25 12:14

Message:
Logged In: YES 
user_id=1275325

I've tested the same scenario and I found no problem. Maybe
in your case it's really about 2 contacts: as you see, the
request tries to upload the contact
sip:8115 at 192.168.1.78:40451 and in the negative reply, the
proxy says that the contact sip:8115 at 192.168.1.78:36355 is
already registered. Note that are different ports, so they
are different contacts.
Be very, very sure that your server location is really empty
- depending of the db_mod used by usrloc, discrepancies
between mem cache and table may appear (in mode 2). So use
"openserctl ul show" for a better checking.

regards,
bogdan

----------------------------------------------------------------------

Comment By: Norman Brandinger (goestelecom)
Date: 2006-05-25 01:05

Message:
Logged In: YES 
user_id=1372252

More testing showed the following:

* With an empty location table, the first registration of
the Grandstream completed successfully.  I may have been
mistaken with the initial assumption that there was no 8115
entry in the location table when this ticket was first created.

* Subsequent registration attempts from the Grandstream
failed as already noted.

* Multiple registrations from a Polycom (with multiple
unique identities) were successful.

* The traces show that the Polycom Contact header is as follows:

Contact: <sip:3036298345 at 192.168.1.72>;methods="INVITE, ACK,
BYE,...."

I suppose that it is possible the SIP implementation in the
Grandstream is faulty, however, the trace shows what appears
to be a valid register request.

Note that by increasing the max_contact to 2, the
Grandstream can re-register twice, and there are two entries
created in the location table.  Increasing max_contact to 2
and rebooting the Greadstream  allows for the creation 3
entries in the location table.

I've solved this problem.  Or more accurately learned about
the Grandstream "Use random port" setting.  When set to
"yes", a new entry is created in the location table
depending on what the Grandstream considers "random".  Whis
this setting as "no", only a single location table entry is
created.

The bottom line is that with max_contacts = 1, make sure
that the Grandstream "Use random port" is set to "no".

Regards,
Norm





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1494598&group_id=139143