Defect #2117
closed
Too many registered contacts: Prevent multiple Contacts being registered for the same IP/rinstance
0%
Description
- 10 registered contacts
- SIP/2.0 500 Service Unavailable error
- P-Registrar-Error: Too many registered contacts
This should be taken care of on the server side. For example, it should be able to compare the rinstance and replace old ones with the new ones.
IP grouped Contact header:
<sip:2233513173@192.168.254.10:1061;transport=tls;line=391tpzbw>;q=1;expires=31556;received="sip:92.254.51.247:1061;transport=tls", <sips:2233513173@192.168.254.12:58832;rinstance=7DA4013B;transport=tcp>;expires=84070;received="sip:92.254.51.247:58832;transport=tls", <sips:2233513173@192.168.254.12:58690;rinstance=7DA4013B;transport=tcp>;expires=74237;received="sip:92.254.51.247:58690;transport=tls", <sips:2233513173@192.168.254.12:58658;rinstance=7DA4013B;transport=tcp>;expires=61191;received="sip:81.23.228.129:5060;target=%73%69%70:%37%37.%31%37%33.%31%38%35.%34%34:%35%38%36%35%38%3b%74%72%61%6e%73%70%6f%72%74%3d%74%6c%73", <sips:2233513173@10.46.160.173:58629;rinstance=7DA4013B;transport=tcp>;expires=60133;received="sip:188.207.108.46:32424;transport=tls", <sips:2233513173@10.46.160.173:58620;rinstance=7DA4013B;transport=tcp>;expires=59370;received="sip:188.207.108.46:32408;transport=tls", <sips:2233513173@192.168.254.12:58625;rinstance=7DA4013B;transport=tcp>;expires=60059;received="sip:81.23.228.129:5060;target=%73%69%70:%37%37.%31%37%33.%31%38%35.%34%34:%35%38%36%32%35%3b%74%72%61%6e%73%70%6f%72%74%3d%74%6c%73", <sips:2233513173@192.168.254.12:58611;rinstance=7DA4013B;transport=tcp>;expires=59322;received="sip:81.23.228.129:5060;target=%73%69%70:%37%37.%31%37%33.%31%38%35.%34%34:%35%38%36%31%31%3b%74%72%61%6e%73%70%6f%72%74%3d%74%6c%73", <sips:2233513173@192.168.254.12:58595;rinstance=7DA4013B;transport=tcp>;expires=54368;received="sip:92.254.51.247:58595;transport=tls", <sips:2233513173@192.168.254.12:58591;rinstance=7DA4013B;transport=tcp>;expires=48594;received="sip:81.23.228.129:5060;target=%73%69%70:%37%37.%31%37%33.%31%38%35.%34%34:%35%38%35%39%31%3b%74%72%61%6e%73%70%6f%72%74%3d%74%6c%73"
The Snom contact registration is only once, and therefore declared ok:
<sip:2233513173@192.168.254.10:1061;transport=tls;line=391tpzbw>;q=1;expires=31556;received="sip:92.254.51.247:1061;transport=tls",
The 3G/UMTS/mobile link registration:
<sips:2233513173@10.46.160.173:58629;rinstance=7DA4013B;transport=tcp>;expires=60133;received="sip:188.207.108.46:32424;transport=tls", <sips:2233513173@10.46.160.173:58620;rinstance=7DA4013B;transport=tcp>;expires=59370;received="sip:188.207.108.46:32408;transport=tls",
should already be removed from its oldest registration (lowest expires) in my opinion.
The 3 registered contacts for Wi-Fi WAN link #1:
<sips:2233513173@192.168.254.12:58832;rinstance=7DA4013B;transport=tcp>;expires=84070;received="sip:92.254.51.247:58832;transport=tls", <sips:2233513173@192.168.254.12:58690;rinstance=7DA4013B;transport=tcp>;expires=74237;received="sip:92.254.51.247:58690;transport=tls", <sips:2233513173@192.168.254.12:58595;rinstance=7DA4013B;transport=tcp>;expires=54368;received="sip:92.254.51.247:58595;transport=tls",
should also be removed from its oldest registrations (lowest expires values) in my opinion.
And the 4 registrations for Wi-Fi WAN link number 2:
<sips:2233513173@192.168.254.12:58658;rinstance=7DA4013B;transport=tcp>;expires=61191;received="sip:81.23.228.129:5060;target=%73%69%70:%37%37.%31%37%33.%31%38%35.%34%34:%35%38%36%35%38%3b%74%72%61%6e%73%70%6f%72%74%3d%74%6c%73", <sips:2233513173@192.168.254.12:58625;rinstance=7DA4013B;transport=tcp>;expires=60059;received="sip:81.23.228.129:5060;target=%73%69%70:%37%37.%31%37%33.%31%38%35.%34%34:%35%38%36%32%35%3b%74%72%61%6e%73%70%6f%72%74%3d%74%6c%73", <sips:2233513173@192.168.254.12:58611;rinstance=7DA4013B;transport=tcp>;expires=59322;received="sip:81.23.228.129:5060;target=%73%69%70:%37%37.%31%37%33.%31%38%35.%34%34:%35%38%36%31%31%3b%74%72%61%6e%73%70%6f%72%74%3d%74%6c%73", <sips:2233513173@192.168.254.12:58591;rinstance=7DA4013B;transport=tcp>;expires=48594;received="sip:81.23.228.129:5060;target=%73%69%70:%37%37.%31%37%33.%31%38%35.%34%34:%35%38%35%39%31%3b%74%72%61%6e%73%70%6f%72%74%3d%74%6c%73"
may also be de-duped and registered without target "sip:77.173.185.44:58658;transport=tls".
Desired Contact:
<sip:2233513173@192.168.254.10:1061;transport=tls;line=391tpzbw>;q=1;expires=31556;received="sip:92.254.51.247:1061;transport=tls", <sips:2233513173@10.46.160.173:58629;rinstance=7DA4013B;transport=tcp>;expires=60133;received="sip:188.207.108.46:32424;transport=tls", <sips:2233513173@192.168.254.12:58832;rinstance=7DA4013B;transport=tcp>;expires=84070;received="sip:92.254.51.247:58832;transport=tls", <sips:2233513173@192.168.254.12:58658;rinstance=7DA4013B;transport=tcp>;expires=61191;received="sip:77.173.185.44:58658;transport=tls"
Updated by Adrian Georgescu over 11 years ago
- Status changed from New to Closed
The Groundwire SIP client is broken in many respects, not just this one and there is nothing in the server than can prevent such behaviour. The server cannot arbitrarily close valid registrations just because a new broken device creates new registrations instead of refreshing existing ones.
You should send these support requests to the manufacturer of the broken device, not to us.
Updated by Jiri Kral over 11 years ago
I must object to the statement "Groundwire SIP client is broken in many respects". The weird-looking huge URL-encoded Contact headers are being received from the server, not being generated by us. The multiple registrations are result of extremely long expiration time and probably also bad configuration: We have an option to remember registration state (default: on) and we also support fixed SIP listening port, as well as other advanced configuration options, like specifying a fixed value for Contact: header to make sure the registration is reused. In mobile environments, the network interfaces are changing rapidly and maintaining correct registration is quite a challenge.
The highly customizable configuration options of Groundwire app cause some users to change many values without deeply understanding their meaning. This is not primarily a problem of the app though. On the other hand, if you have any details about any broken functionality, I'll be keen to know about it.
Updated by Pro Backup over 11 years ago
The used Groundwire configuration is included in this wiki at [[http://projects.ag-projects.com/projects/sip2sip/wiki/SipDevicesAcrobitsGroundwire]] where:
Registration State
| Reuse | On |
| Adjust Via | Off |
And also tried with:
| Adjust Via | On |
without improvement.
Updated by Adrian Georgescu over 11 years ago
The contact headers returned by the server is the sum of all contacts sent by the clients. The server does not invent them, it just returns all registered contacts sent by the clients. If you client keeps adding them infinitely at some point the server will reject the requests as there is not difference between a DOS attack or a broken client.