"500 Internal Error" with body "NoMethodError: undefined method `<' for nil:NilClass"
jmillan opened this issue · 10 comments
From Emil Lenngren to the JsSIP mailing list:
Hi. When I login on JsSIP Tryit and try to register, I get an alert saying "Sip registration error. 500 Internal error". In the debug console in Chrome, I see the following:
SIP/2.0 500 Internal Error
Via: SIP/2.0/WS fheo1i09vdvq.invalid;branch=z9hG4bK3589954
From: "08xxxxxx" <sip:08xxxxxx@int.sipserver.alltele.se>;tag=mfhmpdgvan
To: <sip:08xxxxxx@int.sipserver.alltele.se>;tag=84b5c3d94d81
Call-ID: 1huc2enrs10na1dglbl8vo
CSeq: 81 REGISTER
Content-Length: 52
Content-Type: text/plain
Server: OverSIP/1.4.0.beta
NoMethodError: undefined method `<' for nil:NilClass
Since he was using the tryit.jssip.net platform, the logs remain at serverside
Error log found:
Jul 12 20:30:06 worker1 oversip-tryit[31448]: INFO: <SipEvents> [user] REGISTER from sip:08966522@int.sipserver.alltele.se (UA: JsSIP 0.3.7) to sip:int.sipserver.alltele.se via WS XX.XX.XX.XX : 52263
Jul 12 20:30:06 worker1 oversip-tryit[31448]: DEBUG: <SIP Request 5047814> applying outgoing Outbound support
Jul 12 20:30:06 worker1 oversip-tryit[31448]: DEBUG: <RFC3263 5047814> DNS NAPTR succeeded for 'int.sipserver.alltele.se'
Jul 12 20:30:06 worker1 oversip-tryit[31448]: DEBUG: <RFC3263 5047814> DNS SRV error resolving '_sip._udp.int.sipserver.alltele.se': dns_error_nxdomain
Jul 12 20:30:06 worker1 oversip-tryit[31448]: DEBUG: <Proxy to_servers 5047814> DNS result has multiple values, randomizing
Jul 12 20:30:06 worker1 oversip-tryit[31448]: ERROR: <launcher (master)> error raised during event loop and rescued by EM.error_handler:
Jul 12 20:30:06 worker1 oversip-tryit[31448]: ERROR: <launcher (master)>
undefined method `<' for nil:NilClass (NoMethodError)
/var/lib/gems/1.9.1/gems/oversip-1.4.0.beta/lib/oversip/sip/server_transaction.rb:238:in `receive_response'
/var/lib/gems/1.9.1/gems/oversip-1.4.0.beta/lib/oversip/sip/request.rb:45:in `reply'
/var/lib/gems/1.9.1/gems/oversip-1.4.0.beta/lib/oversip/sip/proxy.rb:302:in `no_more_targets'
/var/lib/gems/1.9.1/gems/oversip-1.4.0.beta/lib/oversip/sip/client.rb:349:in `try_next_target'
It looks like an issue performing RFC 3263 rules with the given domain "int.sipserver.alltele.se".
Well, something is wrong at DNS level for "int.sipserver.alltele.se" domain:
~# host -t naptr int.sipserver.alltele.se
int.sipserver.alltele.se has NAPTR record 1 0 "s" "SIP+D2U" "" _sip._udp.int.sipserver.alltele.se.
~# host -t srv _sip._udp.int.sipserver.alltele.se.
Host _sip._udp.int.sipserver.alltele.se. not found: 3(NXDOMAIN)
This is: "int.sipserver.alltele.se" has SIP SRV records ("SIP+D2U") but such a SRV record does not exist, so:
- There is a bug in the DNS settings for the "int.sipserver.alltele.se" domain which prevents RFC 3263 DNS procedures to success.
- There is also a bug in OverSIP as it should be ready for this case, and should:
- return 404 "Not Found".
- or try DNS A/AAAA for the domain.
Hi. Did you mean RFC 3263? I searched for RFC 3264 but found no relevant information. However, RFC 3263 is all about locating SIP servers.
I'm going to send a bug report to my SIP provider when I have all the info I need.
Yes, sorry, I meant RFC 3263 "Locating SIP Servers". I will update the text above.
@Emill: BTW you should fix your DNS records. Delete the NAPTR record for "int.sipserver.alltele.se" since it contains a "SIP+D2U" entry pointing to a SRV record that does not exist.
What is best: to add a _sip._udp.int.sipserver.alltele.se SRV record, or remove the NAPTR record?
It's not me but my SIP provider that is responsible for the DNS records, and I'm going to tell them what's wrong and how they should fix it.
I can also see in RFC 3263: "If a SIP proxy, redirect server, or registrar is to be contacted
through the lookup of NAPTR records, there MUST be at least three
records - one with a "SIP+D2T" service field, one with a "SIP+D2U"
service field, and one with a "SIPS+D2T" service field."
Does that mean they also need two more NAPTR records?
@Emill, please provide this info to your SIP provider:
Your SIP DNS records are wrong. The main domain "int.sipserver.alltele.se" has a NAPTR record:
~$ host -t naptr int.sipserver.alltele.se
int.sipserver.alltele.se has NAPTR record 1 0 "s" "SIP+D2U" "" _sip._udp.int.sipserver.alltele.se.
but there is not a SRV record for "_sip._udp.int.sipserver.alltele.se":
~$ host -t srv _sip._udp.int.sipserver.alltele.se.
Host _sip._udp.int.sipserver.alltele.se. not found: 3(NXDOMAIN)
In contrast, there is an ugly SRV record like this:
~$ host -t srv int.sipserver.alltele.se.
int.sipserver.alltele.se has SRV record 1 1 5060 int.sipserver.alltele.se.
This is really WRONG. The SRV record should exist for a subdomain "_sip._udp.int.sipserver.alltele.se", rather than for "int.sipserver.alltele.se". Please check RFC 3263 to understand it. In fact, section 4.1 of RFC 3263 clearly says:
As an example, consider a client that wishes to resolve
sip:user@example.com. The client performs a NAPTR query for that
domain, and the following NAPTR records are returned:; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.This indicates that the server supports TLS over TCP, TCP, and UDP,
in that order of preference. Since the client supports TCP and UDP,
TCP will be used, targeted to a host determined by an SRV lookup of
_sip._tcp.example.com. That lookup would return:;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com
You provider MUST delete the useless and wrong SRV record for "int.sipserver.alltele.se" and instead create a SRV record for "_sip._udp.int.sipserver.alltele.se".
And what about "If a SIP proxy, redirect server, or registrar is to be contacted
through the lookup of NAPTR records, there MUST be at least three
records - one with a "SIP+D2T" service field, one with a "SIP+D2U"
service field, and one with a "SIPS+D2T" service field."
Does that mean they also need two more NAPTR records?