Hi Franz!
1. openser does not do NAPTR lookups as defined in step 1 of 3263. It starts with step 2 (SRV lookups)
2. Are you sure there are NAPTR records for your domain? $ dig fenet2.at NAPTR
; <<>> DiG 9.2.4 <<>> fenet2.at NAPTR ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60927 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
3. If the URI contains the transport=tcp paramter, SRV lookups for _tcp will be done, otherwise _udp will be used.
IMO, if no transport paprameter is present, openser should also try _tcp if _udp fails.
regards klaus
Franz Edler wrote:
Hi,
I have a question regarding the behavior of t_relay. When the proxy forwards a request for another domain using t_relay it does not use NAPTR and SRV records of the target-domain as stated in RFC3263 "Locating SIP Servers". Instead it expects a resolvable host-name for the domain-part or the URI.
The following example:
INVITE sip:andrea@fenet2.at
Causes the errors:
ERROR: mk_proxy: could not resolve hostname: "fenet2.at" ERROR: uri2proxy: bad host name in URI sip:andrea@fenet2.at ERROR: t_forward_nonack: failure to add branches
There are NAPTR and SRV RRs associated with domain "fenet2.at" but SER does not use these RRs. Why?
Are there any comments on this issue?
Regards Franz
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users