I don’t believe there is a bug here. Setting max contacts will not do anything to block a registration.
1 Like
I believe the one thing that hasn’t been explained to you. REGISTER != INVITE. A SIP device doesn’t not have to be registered in order to make an outbound call.
Registration tells the PBX where to send requests to the endpoint. It needs to know the Location of the endpoint contacts. That’s all it does. When you make an outbound call, that is a different process, there is an auth challenge during that process and it has nothing to do with the registration.
So, you setup an endpoint with a Max Contact of 2 and then program 10 devices with those creds. At any given time TWO of those 10 can have an active registration/location with the PBX meaning those two get incoming but ALL TEN can make outbound calls.
Please stop using making outbound calls as a test for this, it doesn’t mean anything.
nope, 8 others just can not register, server just reject their credentials
but if max contacts = 1, all 10 registering successful and ring all of 10 incoming/outgoing
What are you talk about?
You can check the question above
I was explaining to you the difference between REGISTER and INVITE. They aren’t related unless you do the work to make them related.
How about this? Show us some actual debugs. I want to see the contacts registered for the endpoint. I want to see an incoming call that rings non-registered devices. Show us this actually happening. We need to see the actual proof of what you are saying is happening is happening.
So far what you are saying, I can’t replicate any place.
You can find debug info in the above posts
There is no full debug info in the above posts. I see a bunch of snippets of lines from a debug but I don’t see a full debug that I was asking for. It’s been a month now so what I am asking for is complete and current debugging of this situation. I want to see the two contacts in which one shouldn’t exist and have been replaced. I want to see debugs of actual calls ringing contacts that you said had expired and are still getting incoming calls. FULL DEBUG/TRACES.
1 Like
What will the current debug logs give you, they are identical with the previous ones
let me explain:
Endpoint: 172/172 In use 2 of inf
InAuth: 172-auth/172
Aor: 172 1
Contact: 172/sip:[email protected]:59522;ob dc229895ea Avail 0.990
Channel: PJSIP/172-00034182/Dial Ring 00:00:09
Exten: s CLCID: "CID:XXXXXXXXXX" <XXXXXXXXXX>
Channel: PJSIP/172-00034061/Dial Up 00:19:12
Exten: s CLCID: "CID:XXXXXXXXXX" <XXXXXXXXXX>
here you can see 2 <Channels.> in use and <MaxContact.> for this extension 1
next you can see pjsip debug
01527 1649134892 * <== 192.168.12.97:64469 REGISTER sip:192.168.12.11 SIP/2.0
00137 1649134705 * <== 192.168.12.113:59522 REGISTER sip:192.168.12.11 SIP/2.0
00138 1649134705 * ==> 192.168.12.113:59522 SIP/2.0 401 Unauthorized
00140 1649134705 * ==> 192.168.12.97:64469 OPTIONS sip:[email protected]:64469;ob SIP/2.0
00141 1649134705 * ==> 192.168.12.113:59522 OPTIONS sip:[email protected]:59522;ob SIP/2.0
00145 1649134705 * ==> 192.168.12.113:59522 NOTIFY sip:[email protected]:59522;ob SIP/2.0
01535 1649134892 * ==> 192.168.12.97:64469 NOTIFY sip:[email protected]:64469;ob SIP/2.0
<--- History Entry 1527 Received from 192.168.12.97:64469 at 1649134892 --->
REGISTER sip:192.168.12.11 SIP/2.0
Via: SIP/2.0/UDP 192.168.12.97:64469;rport=64469;received=192.168.12.97;branch=z9hG4bKPj3553cf9a431044ec938e71a4768565d5
Max-Forwards: 70
From: "172" <sip:[email protected]>;tag=cebd8a2a1aaa4934b3d76dcb3048bc5e
To: "172" <sip:[email protected]>
Call-ID: eff1fc03fbe7482ca62f96ee47f2a92f
CSeq: 44123 REGISTER
User-Agent: MicroSIP/3.20.7
Contact: "172" <sip:[email protected]:64469;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0
Content-Length: 0
<--- History Entry 137 Received from 192.168.12.113:59522 at 1649134705 --->
REGISTER sip:192.168.12.11 SIP/2.0
Via: SIP/2.0/UDP 192.168.12.113:59522;rport=59522;received=192.168.12.113;branch=z9hG4bKPja167ad6396fc4bdf91fcccdb4f6a7971
Max-Forwards: 70
From: <sip:[email protected]>;tag=340af5f0ea2e46968905012acd13459a
To: <sip:[email protected]>
Call-ID: f24ab213a5a8472cb67a63bdd0f676bc
CSeq: 38812 REGISTER
User-Agent: MicroSIP/3.19.27
Contact: <sip:[email protected]:59522;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0
Content-Length: 0
<--- History Entry 138 Sent to 192.168.12.113:59522 at 1649134705 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.12.113:59522;rport=59522;received=192.168.12.113;branch=z9hG4bKPja167ad6396fc4bdf91fcccdb4f6a7971
Call-ID: f24ab213a5a8472cb67a63bdd0f676bc
From: <sip:[email protected]>;tag=340af5f0ea2e46968905012acd13459a
To: <sip:[email protected]>;tag=z9hG4bKPja167ad6396fc4bdf91fcccdb4f6a7971
CSeq: 38812 REGISTER
WWW-Authenticate: Digest realm="asterisk",nonce="1649134705/ac6873acac3c5710093562168460a1fc",opaque="642f860659719418",algorithm=md5,qop="auth"
Server: FPBX-16.0.19(16.24.1)
Content-Length: 0
you can see that second 172 peer was registered
if for some reason you need more debug info, please specify cli command and its arguments
So you have two MicroSIP devices registering to an AOR that only allows one contact. That is what I am seeing here and I asked why you have multiple devices trying to register to an AOR that should only have 1. This is two MicroSIP clients registering within 3 minutes of each other and I still don’t see you showing two contacts being registered.
How about we actually see something that is configured like pjsip show aor 172? And let’s stick with 172 since you haven’t shown consistent data in anything you’ve posted.
of course it will. that is what it is supposed to do.
You have a severe lack of understanding, and you are not listening to what the one person that is trying to help you is telling you to do.
This needs to be understood. If you have two devices registering with the same information and max contacts = 1, then they will fight over the registration and only the most recently registered will receive calls.
2 Likes
Aor: <Aor..............................................> <MaxContact>
Contact: <Aor/ContactUri............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================
Aor: 172 1
Contact: 172/sip:[email protected]:63339;ob 4e003c5a8f Avail 0.806
ParameterName : ParameterValue
======================================================
authenticate_qualify : false
contact : sip:[email protected]:63339;ob
default_expiration : 3600
mailboxes : 172@device
max_contacts : 1
maximum_expiration : 7200
minimum_expiration : 60
outbound_proxy :
qualify_frequency : 60
qualify_timeout : 3.000000
remove_existing : true
remove_unavailable : false
support_path : false
voicemail_extension :
please tell me what will be if I set max contacts = 2 ?
on third device MicroSIP will give an error incorrect username or password, which is not happening with contacts = 1
From what I am reading on this is that the expected behaviour with Max Channels is what you are getting when set to = 1
However for some reason you are experiencing different behaviour when Max Channel is set to 2 or above but you want this to be the same experience. I’m which case you need to raise a feature request. Giving an incorrect username password on registrations exceeding the Max Contacts isn’t the expected behaviour and is probably more of the bug but actually works for you want.
However I would suggest that what is needed is a feature that blocks any further registrations with a Max Contacts limit reached message.
I would add that whilst you can raise it as a feature request I’m not sure there would be much interest in spending engineer time on this edge case.
1 Like
OK, it really seems that people have a lack of understanding when it comes to registrar/location services. So when there is a max contact of 1 another contact registering can register and knock the other one offline. If you set it to 2 then two can register but a 3 is rejected. Yup, that is how it works.
As it was already pointed out in this thread, if your registration has an expire of 300 seconds the re-registration isn’t exactly at 300 seconds. If that was the case there would end up being a period of time with NO contacts registered because they would expire and then the registration would lag behind it. Because at 300 seconds the system will drop that location and wait for your device to send an update.
There is an expectation of ONE contact being active at all times. So if I am on my Bria and I leave my house, I am leaving my home network and as I move down the road my phone is going to jump from my home network to my cell network. I have a max contact of 1, the expiration isn’t for another 250 seconds but yet my phone is going to reregister on the network jump. So now I have a new registration coming in. Following the logic of the OP my registration after the network jump is going to be denied because 1 contact exists. It’s an invalid contact, in a minute or so Asterisk is going to mark is as UNREACHABLE and I am not getting calls.
However, because of how this all works in general (not just Asterisk), when I leave my house and my phone jumps networks with a max contacts of 1. When it jumps and re-registers my existing (AND STALE) contact location is dump and my new (AND ACTIVE) registration is stored.
Once you get over a single contact then you are going to see a different behavior. That is just how this works. There aren’t bugs and the only issue is the OP not understanding how these services work.
2 Likes
Thank you for your explanation, but once again you are trying to explain how the registration works, but I want to get an answer to a specific example, it would be more appropriate to explain about the “Max contact” option and why the logic changes when this value is changed
I imagine that 1 is treated as a special case because the only choices of action are replace or reject, and replace is most likely to be correct.
1 Like
This was explained. What are you still having an issue with?
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.