"500 Internal Error" with body "NoMethodError: undefined method `<' for nil:NilClass"

[jmillan]

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

[ibc]

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".

[ibc]

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:
  1. return 404 "Not Found".
  2. or try DNS A/AAAA for the domain.

[Emill]

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.

[ibc]

Yes, sorry, I meant RFC 3263 "Locating SIP Servers". I will update the text above.

[ibc]

@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.

[Emill]

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?

[ibc]

@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

[ibc]

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".

[Emill]

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?

[ibc]

@jmillan said:

Does that mean they also need two more NAPTR records?

Forget it. If the provider does not support SIP TCP/TLS it should not announce it in NAPTR. It "should" support it, or "MUST" support it. But if it does not, better not to announce it.