Hello, Maybe the problem is that there is no ip address for fenet2.at. SER does SRV lookup and then normal A lookup for the name provided in SRV's RR. I cannot see from the code if there is used NAPTR, actually the function for parsing such a RR is present but such a lookup is not performed.

The name resolution is done using gethostbyname anyway, even it tries first SRV lookup or not.

Quoting Daniel-Constantin Mierla daniel@voice-system.ro:

Hello,

it should do SRV lookup and if it gets some RR it uses them. Try to watch the DSN traffic for you sip server with "ngrep port 53".

Also you can check with "host -t srv _sip._udp.fenet2.at" if the DNS server returns correctly the SRV records. Only in the case no SRV record is returned, the openser tries normal DNS lookup.

Another option is to set openser in debug mode (log_stderror=yes and debug=7) and watch the messages or send them to me to analyze them.

Daniel

On 09/01/05 22:45, 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

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Franz Edler writes:

Meanwhile I verified in my tests that t_relay only does an SRV lookup towards _sip._udp.<domain> and no NAPTR lookup as I expected. That means if I want to use TCP between two SIP servers I have to use t_relay_to_tcp(ip, port) explicitly in my configuration file and cannot use DNS data to control transport protocol selection.

without NAPTR support, perhaps easiest solution would be a configuration parameter telling which transport (udp or tcp) is the preferred one when doing the SRV query and if no reply is got, then the other transport would be queried.

-- juha

Hi Klaus,

1. openser does not do NAPTR lookups as defined in step 1 of 3263. It

starts with step 2 (SRV lookups)

Yes, I know meanwhile. But it only makes an SRV lookup for _sip._udp, not for _sip._tcp, if URI contains no transport parameter (as usual).

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

I indeed had a problem in my zone-file. Meanwhile the NAPTR records are there.

3. If the URI contains the transport=tcp paramter, SRV lookups for _tcp

will be done, otherwise _udp will be used.

Yes, this is what I observed. I did not try with a URI containing a transport parameter.

IMO, if no transport paprameter is present, openser should also try _tcp if _udp fails.

Yes. This is also my suggestion to be RFC 3263 compliant.

Regards Franz

Hi Bogdan,

may you point the section from RFC 3263 which says that? the best I found is "4.1 Selecting a Transport Protocol"

Yes exactly.

If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier "_sip" for SIP URIs and "_sips" for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server.

Therefore the first thing should be to look for NAPTR records. The next step (in case no NAPTR records are found) should be to look for SRV records for transport protocols, which the client supports. In case of a TCP enabled openser this should include _sip._tcp. Then the transport protocol decision should take into consideration the priority values across all SRV records, as you already mentioned.

This method enables comfortable control of transport protocols via DNS records without manually selecting protocols in configuration files.

That would be fine.

Regards Franz