Dear All,
I would like to exposed a situation where, a NAPTR query should have been
sent instead of an A record query.
Steps
-----
1. Device A register with PROXY at example.org WITHOUT any port specified
in the request-URI or via
a) NTA layer sends NAPTR query to resolve the example.org FQDN.
b) NTA layer gets TWO (2) records NAPTR (IP1 with Priority 10 and IP2
with priority of 20) for that FQDN.
c) A REGISTER request is sent to IP1 (highest priority) using the first
record.
d) Proxy acknowledge... Device is registered and everything is good!
2. Device A makes a call to x...@example.org WITHOUT any port specified in
the request-URI or via
a) NTA layer sends an A Query to resolve example.org FQDN.
b) NTA layer gets TWO (2) records (without Priority) for that FQDN.
c) A INVITE request is sent to a randomly pick IP associated with the A
response.
d) ...
Problem
--------
The INVITE request should have generated a NAPTR query since there is no
port specified by the application for the request-URI. However, the stack
provides default values with are used later when trying to resolve the
FQDN again. Since there is no A record associated with NAPTR response,
there is no cached information and the request is placed to the DNS server
to retrieve a record. However, there is no priority associated with A
record and the calls randomly go to one of the destination even if the
NAPTR record is still valid (no expired).
Source of the problem
----------------------
The function outgoing_resolve() checks if orq->orq_tpn->tpn_port is set or
if orq->orq_tpn->tpn_proto is set to "*". When it's tpn_port is set or
tpn_proto == "*", the NAPTR query is prevented by setting
orq->orq_agent->sa_use_naptr to "0"! This means a A query would sent
instead of using the cached NAPTR record.
Even if the application doesn't specify the port in request-URI, the code
in nta.c tries to set it to something. If it happens that the url_type ==
url_sip then, the tpn_port would be assigned to SIP_DEFAULT_SERV and
tpn_proto is set to "*". By doing so, NAPTR response from a previous query
is simply ignored causing a new DNS query to be performed.
Potential work around
----------------------
I went modifying the function outgoing_resolve() in nta.c by commenting
the following code section and solved my problem:
// if (sr->sr_tpn->tpn_port)
// sr->sr_use_naptr = 0, sr->sr_use_srv = 0;
// /* RFC3263:
// If [...] a transport was specified explicitly, the client performs
an
// SRV query for that specific transport,
// */
// else if (strcmp(tpname, "*") != 0)
// sr->sr_use_naptr = 0;
However, it seems that the code is in place to address the section 4.2 of
the RFC3263. In the case I am dealing with, the port and proto are set by
the stack automatically which bypass the NAPTR usage in that case. By
doing so, it makes the request fall under the section 4.2 umbrella which
should not be the case.
Question
---------
Anyone has experienced something similar? Is there is a clean fix for this
problems?
Regards,
Louis Guindon
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
