RE: [reSIProcate] DNS question
Dave,
Thanks for the response. The application is constructing the Via header
using an V4 IP address within a test environment.
So Via: SIP/2.0/UDP 10.0.0.1;branch=...
However the AoR in the INVITE is constructed using a sip url
INVITE sip:user@xxxxxxxxxxxxxxx
The stack performs DNS on the Target, user@xxxxxxxxxxxxxxx, and gets a srv
record back indicating the target can be reached via TCP. The stack then
sends the request for transmission via TCP, however the contents of the
message in the 'Via' header are not changed.
My question then is should the application perform DNS independently of the
stack to ascertain the transport prior to constructing the 'Via' header? The
application is acting as a UAC in this scenario.
Looking at the RFC....
8.1.1.7 Via
The Via header field indicates the transport used for the
transaction
and identifies the location where the response is to be sent. A
Via
header field value is added only after the transport that will be
used to reach the next hop has been selected (which may involve the
usage of the procedures in [4]).
Which indicates that the application should perform DNS prior to
constructing the SIP message. If I have to send a INVITE from the
application should I perform DNS on the target before creating the message
and submitting it to the stack?
Regards,
Rob.
-----Original Message-----
From: Dale R. Worley [mailto:dworley@xxxxxxxxxxx]
Sent: 13 January 2006 15:24
To: Resiprocate-devel
Subject: Re: [reSIProcate] DNS question
On Fri, 2006-01-13 at 12:05 +0000, Robert Mansfield wrote:
> Should the application use DNS procedures to ascertain the transport
> to reach the next hop prior to sending the message to the sip stack?
> I've run a test whereby I've submitted a INVITE request using "UDP" in
> the construct of the Via header. The DNS lookup for the target returns
> with a TCP record so the message is sent out via TCP but the text of
> the message still indicates UDP. Is this valid?
I assume what you mean is that your INVITE has a header that looks like:
Via: SIP/2.0/UDP host.example.com;branch=...
But that the DNS SRV records for host.example.com only provide a TCP
contact.
I would say that the SIP agent sending the INVITE is erroneous, much as if
host.example.com had no DNS records but it was using that name in the Via.
I say this because the sender of the message is asserting that responses
should be sent to "host.example.com" via UDP, but DNS is configured such
that there *no* UDP contacts for "host.example.com".
Whatever strategy the recipient uses should be considered to be attempts to
recover from erroneous input. It would probably be better for the recipient
to just drop the transaction, as that will tend to force the users to
diagnose the situation and correct the problem with the sender.
Dale
_______________________________________________
resiprocate-devel mailing list resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel