Skip to content
This repository has been archived by the owner on Aug 14, 2020. It is now read-only.

undefined method `transport' #64

Open
wackazong opened this issue Dec 11, 2014 · 8 comments
Open

undefined method `transport' #64

wackazong opened this issue Dec 11, 2014 · 8 comments

Comments

@wackazong
Copy link

I have a strange issue. When I connect with sipML5 from a web browers to the oversip websocket server via www on port 10443 all is fine if the SIP server I am contacting is not on the same server as oversip. If it is, then I get this error:

Dec 11 18:08:01 ip-172-31-38-164 oversip[22840]: ERROR: undefined method transport' for #<OverSIP::SIP::RFC3263::MultiTargets:0x000000030e0d78> (NoMethodError)#012/usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb:374:inuse_target'#12/usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb:345:in try_next_target'#012/usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb:328:inrfc3263_succeeded'#12/usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb:255:in `check_dns_cache'

@ibc
Copy link
Member

ibc commented Dec 11, 2014

I have a strange issue. When I connect with sipML5 from a web browers to the oversip websocket server via www on port 10443 all is fine if the SIP server I am contacting is not on the same server as oversip.

I need more detail on this. What do you mean with "not on the same server as oversip"?

@wackazong
Copy link
Author

I logged target just before the error as "target #{target}"

When its working it is displayed as

Dec 12 00:19:46 ip-172-31-38-164 oversip[27969]: NOTICE: target udp:188.226.136.215:5060

When not it is displayed as

Dec 12 00:19:12 ip-172-31-38-164 oversip[27969]: NOTICE: target [#<struct OverSIP::SIP::RFC3263::Tar
get transport=:udp, ip="54.154.38.67", ip_type=:ipv4, port=5060>]

Does that help?

@ibc
Copy link
Member

ibc commented Dec 12, 2014

Definitely the second one is wrong since the Target class (defined in rfc3263.rb) is:

    class Target
      def to_s
        if self[2] == :ipv4
          "#{self[0]}:#{self[1]}:#{self[3]}"
        else
          "#{self[0]}:[#{self[1]}]:#{self[3]}"
        end
      end
    end

Please let me know in which exact file/line you added the "target" log above. Was it in your own server.rb file? May you add such a log in line 373 of /usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb?

@wackazong
Copy link
Author

It's exactly at that spot.

@wackazong
Copy link
Author

I have two SIP servers listening on the same URL with two different A records. This seems to be the problem. Even with NAPTR and SRV records deactivated, the problem still occurs. If I remove one A record and only leave one, it works.

@ibc
Copy link
Member

ibc commented Dec 12, 2014

So, must your OverSIP resolve such a domain (with two different A records) in order to route the received SIP request?

Anyhow this is a bug. Theoretically OverSIP does support multiple A records (as RFC 3263 mandates).

I need to reproduce it. I can create my own test domain with multiple A records and so on, but I need to replicate your same scenario. Please let me know more details. I will assume that:

  • SIPml5 client (I will test with JsSIP) sends a REGISTER to OverSIP with RURI pointing to "test.domain.org".
  • OverSIP is not responsible for such a domain so it resolves it in order to route it.
  • Such a domain has NOT NAPTR/SRV records, but just two different A records.
  • Error above happens.

Is that right?

BTW: can you reproduce it in http://tryit.jssip.net by entering there your SIP data?

@wackazong
Copy link
Author

Yes, its a domain with two A records and also NAPTR records. But the bug occurs regardless of whether I allow the use of NAPTR in proxies.conf

AFAIK:

  1. yes
  2. yes
  3. happens with and without NAPTR/SRV

BTW: yes, I can, just tried it. You should see it in the logs. I will send you an account via email.

If you could provide a patch, that would be great.

@wackazong
Copy link
Author

This only occurs when enabling NAPTR and SRV record support. NAPTR and SRV were enabled in the other proxy configs. Misunderstood the proxies.conf. If you enable NAPTR and SRV it should fail.

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: connection from the TLS tunnel 127.0.0.1:54904

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: running OverSIP::WebSocketEvents.on_connection()...

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: replying 101 "Switching Protocols"

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: received text frame: FIN=true, RSV1-3=false/false/false, payload_length=772

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: received WS message: type=text, length=772

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: INFO: [user] REGISTER from sip:UViljwt0hE7dWoB0Pt7MY@staging.sipheadstore.com (UA: IM-client/OMA1.0 sipML5-v1.2014.04.18) to sip:staging.sipheadstore.com via WSS 172.31.44.137 : 62314

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: applying outgoing Outbound support

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: DNS NAPTR succeeded for 'staging.sipheadstore.com'

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: DNS SRV succeeded for '_sip._udp.staging.sipheadstore.com'

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: DNS A succeeded for domain 'edge1.staging.sipheadstore.com'

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: DNS A succeeded for domain 'edge2.staging.sipheadstore.com'

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: DNS result has multiple values, randomizing

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: trying target 1 of 2: [#<struct OverSIP::SIP::RFC3263::Target transport=:udp, ip="54.194.12.167", ip_type=:ipv4, port=5060>]

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: DEBUG: performing Contact mangling (adding ;ov-ob Outbound param) for SIP Request K2GD8TyylORkFOUIB53fQ8ca37UPc6pc

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: NOTICE: LOG:

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: NOTICE: target [#<struct OverSIP::SIP::RFC3263::Target transport=:udp, ip="54.194.12.167", ip_type=:ipv4, port=5060>]

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: ERROR: <launcher (master)> error raised during event loop and rescued by EM.error_handler:

Dec 12 18:44:30 ip-172-31-38-164 oversip[4284]: ERROR: <launcher (master)> undefined method transport' for #<OverSIP::SIP::RFC3263::MultiTargets:0x000000035d7b60> (NoMethodError)#012/usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb:376:inuse_target'#12/usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb:345:in try_next_target'#012/usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb:328:inrfc3263_succeeded'#12/usr/local/rvm/gems/ruby-2.1.0/gems/oversip-2.0.0/lib/oversip/sip/client.rb:281:in `block in do_dns'

Dec 12 18:44:35 ip-172-31-38-164 oversip[4284]: DEBUG: no final response within 5 seconds => 100

Dec 12 18:44:35 ip-172-31-38-164 oversip[4284]: DEBUG: replying 100 "I'm alive"

Dec 12 18:44:35 ip-172-31-38-164 oversip[4284]: DEBUG: sending text frame: payload_length=417

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants