DNS SRV not honored in 3.2.0

Bug #360961 reported by Mikael B
2
Affects Status Importance Assigned to Milestone
Ekiga
Unknown
High
opal (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: ekiga

Ekiga attempts to connect to port 5060 of the FQDL provided although valid NAPTR and SRV records point to port 5080. The same FQDL has worked correclty on earlier Ekiga versions as well as the 3.2.0 previously found in a PPA. I have the same setup working on a range of clients. Ekiga is the only client having trouble with it.

Hostname is fs.voip.consoll.no which based on DNS views in BIND points to port 5080. You will get 5060 from the internet.

dig -t NAPTR fs.voip.consoll.no

; <<>> DiG 9.4.2 <<>> -t NAPTR fs.voip.consoll.no
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38398
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 6

;; QUESTION SECTION:
;fs.voip.consoll.no. IN NAPTR

;; ANSWER SECTION:
fs.voip.consoll.no. 3600 IN NAPTR 20 0 "s" "SIP+D2T" "" _sip._tcp.fs.voip.consoll.no.
fs.voip.consoll.no. 3600 IN NAPTR 30 0 "s" "SIP+D2U" "" _sip._udp.fs.voip.consoll.no.
fs.voip.consoll.no. 3600 IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.fs.voip.consoll.no.

;; AUTHORITY SECTION:
consoll.no. 3600 IN NS ns2.consoll.no.
consoll.no. 3600 IN NS slave.banetele.no.
consoll.no. 3600 IN NS ns1.consoll.no.

;; ADDITIONAL SECTION:
fs1.voip.consoll.no. 3600 IN A 10.100.4.192
ns1.consoll.no. 3600 IN A 10.100.2.51
ns2.consoll.no. 3600 IN A 10.100.2.52
_sips._tcp.fs.voip.consoll.no. 3600 IN SRV 10 0 5061 fs1.voip.consoll.no.
_sip._tcp.fs.voip.consoll.no. 3600 IN SRV 10 0 5080 fs1.voip.consoll.no.
_sip._udp.fs.voip.consoll.no. 3600 IN SRV 10 0 5080 fs1.voip.consoll.no.

dig -t SRV _sip._udp.fs.voip.consoll.no

; <<>> DiG 9.4.2 <<>> -t SRV _sip._udp.fs.voip.consoll.no
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48920
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;_sip._udp.fs.voip.consoll.no. IN SRV

;; ANSWER SECTION:
_sip._udp.fs.voip.consoll.no. 3600 IN SRV 10 0 5080 fs1.voip.consoll.no.

;; AUTHORITY SECTION:
consoll.no. 3600 IN NS ns1.consoll.no.
consoll.no. 3600 IN NS ns2.consoll.no.
consoll.no. 3600 IN NS slave.banetele.no.

;; ADDITIONAL SECTION:
fs1.voip.consoll.no. 3600 IN A 10.100.4.192
ns1.consoll.no. 3600 IN A 10.100.2.51
ns2.consoll.no. 3600 IN A 10.100.2.52

;; Query time: 7 msec
;; SERVER: 10.100.2.51#53(10.100.2.51)
;; WHEN: Tue Apr 14 10:48:09 2009
;; MSG SIZE rcvd: 198

The problem must be reported upstream if that's where the problem lies. The problem might even be OPAL. I haven't been able to compile Ekiga from source so I'm unable to verify this.

What's interesting is that the REGISTER goes to 5060 while subsequent requests seem to go to 5080. REGISTERs should also go to 5080. On my FreeWITCH server 5080 is a profile only used for RFC1918 addresses (our network) and 5060 is facing the internet. I am sitting on an RFC1918 address on the LAN.

Attached is a log showing that REGISTER goes to 5060 while SUBSCRIBE goes to 5080.

Revision history for this message
Mikael B (mikaelbje) wrote :
Revision history for this message
Mikael B (mikaelbje) wrote :
Revision history for this message
Mikael B (mikaelbje) wrote :
Yannick Defais (sevmek)
affects: ekiga (Ubuntu) → opal (Ubuntu)
Changed in ekiga:
status: Unknown → Invalid
Yannick Defais (sevmek)
Changed in opal (Ubuntu):
status: New → Confirmed
Revision history for this message
Eugen Dedu (eugen-dedu) wrote :

This bug has been fixed (with some comments) upstream.

Changed in ekiga:
importance: Unknown → High
status: Invalid → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.