Re: [reSIProcate] Socket creation callback from ares_process.c
Ares doesn't have any dependencies on other resip libraries, and
bringing a define/header in from rutil would break this. However, I
understand your problem. Perhaps we should just pass a value of 0
(UNKNOWN_TRANSPORT) if the socket creation callback is called from the
DNS layer, as a quick and dirty solution. I'm not sure there is a use
case to set TOS values for DNS traffic anyway - and if there is, would
there be a need to differentiate between UDP and TCP based DNS
sockets?
Scott
On Thu, Nov 5, 2009 at 2:44 PM, Paul Kurmas <pkurmas@xxxxxxxxxxxxx> wrote:
> From ares_process.c function open_udp_socket, there’s a call made to the
> socket creation callback function registered with the SipStack object. This
> code reads:
>
> if(channel->socket_function)
>
> {
>
> channel->socket_function(s, 1, __FILE__, __LINE__);
>
> }
>
> The second argument is supposed to be the transport type… but “1” is NOT the
> transport type for UDP. Per …\rutil\TransportType.hxx, UDP is TransportType
> enumeration value 3. Can anyone speak to the history of this code & whether
> there’s a reason it’s not using the proper enumeration definition?
>
>
>
> A secondary question – short of looking at the file/line to figure the
> caller there is no way to identify the usage of the socket. We can’t count
> on the socket being bind()ed to a specific local port. We’re using the
> callback to apply a TOS setting appropriate for SIP traffic, but that value
> just isn’t appropriate for a DNS lookup. Perhaps the callbacks from the DNS
> code should use either (a) a different callback function, (b) a different
> argument for the transport type, or (c) another argument entirely for a
> usage (e.g. SIP, DNS, whatever).
>
>
>
> Any thoughts?
>
> PK
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>