SIP 93/94 behavior non-spec, illogical
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SIPServer |
New
|
Low
|
Unassigned |
Bug Description
The wiki page here says the 93 login is required as the first message:
http://
If true, that is bad, because 93 is only defined for SIP2. That would prevent EG from supporting SIP v1 clients.
The 93/94 behavior is already non-spec, however. For example, the response to invalid terminal username or password is to drop the connection outright. That doesn't make sense, since we should at least return a 940 first. The client would never get a positive indication of login failure, and so might predictably attempt to reconnect and login with the same info again, forever.
Using a valid terminal username/password, but an invalid location code returns a "successful" 941, then drops the connection:
===
telnet localhost 8023
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: sip_01
password: sip_01
Login OK. Initiating SIP
9300CNsip_
941
Connection closed by foreign host.
===
So that's even worse, because we tell the client the login was "completely successful" and then drop them. They might be expected to reconnect using the same login string again, forever.
security vulnerability: | yes → no |
visibility: | private → public |
Changed in evergreen: | |
importance: | Undecided → Wishlist |
Changed in sipserver: | |
importance: | Undecided → Low |
This behavior appears to be different between the "RAW" connection method vs. telnet. The RAW behavior is more appropriate (and the 93 requirement fine there).
$ telnet localhost 6001 01|COsixxx| CPZZZ| 01|COsixxx| CPZZZ| 01|COsixxx| CPZZZ|
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
9300CNsip_
940
9300CNsip_
940
9300CNsip_
Connection closed by foreign host.