I'm using Siproxd 0.5.13-1 with Ekiga 2.0.3 on Debian Etch, where Siproxd is running on
my firewalling router and Ekiga is configured to use Siproxd as an outbound proxy.
In this setting, I had the issue that Siproxd wouldn't relay INVITEs, i.e. outbound
calls wouldn't go any further than the proxy.
After discussing this with Ekiga developers, making packet captures etc., it turned
out that outbound calls do work when Ekiga is given the ip adress of the router, but
not when given the internal DNS name of it.
More precisely, my router has the DNS name 'router' on my LAN, and this name resolves
on all LAN machines, also the router itself, to it's IP address 192.168.0.1. When
Ekiga is configured to use "192.168.0.1" as a proxy, outbound calls work, when configured
to use "router" as a proxy, they don't.
As it turned out, Ekiga includes a Route header into it's packages, of the form
Route: <sip:192.168.0.1:5060;lr>
resp.
Route: <sip:router:5060;lr>
and that seems to be the only difference in the packages sent to the router between
those respective configurations. I suspect hence that Siproxd simply doesn't resolve
that "router" name in the Route header, i.e. it decides it can't deal with it and
just doesn't relay the INVITEs.
Does this seem plausible? And is this a (known) bug? What should be done to fix this?
Thanks, regards, Bruno.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you provide a debug log (debuglevel = -1)? Please send it directly to my SF mail account.
I'm just thinking about it - why should the UA (Ekiga) add a Route header for the proxy? Route headers usually result from Record-Route headers that are inserted from proxies (or other SIP routing elements) that want to stay in the communication path.
However, RFC3261 mentions that such a route set may be (some kind of) pre-configured within the UA.
In case of siproxd this should not be required, as siproxd does insert Record-Route headers in passin g traffic, so the answer is supposed to be passing back via siproxd. Adding an additional Route header for siproxd potentially may cause problems.
Also, using an internal (private) IP address potentially may cause problems, not speaking of non fully-qualified domain names.
The UA should:
- use siproxd as *outbound proxy* (this guarantees all outgoing traffic is sent from UA to siproxd)
- not add Route headers for siproxd.
I don't know if your UA has the flexibility to disable the adding of these Route headers.
However, maybe I have to look a bit deeper into this, so if you could provide a extensive log file that would help me quite a lot (preferably including a REGISTER and incoming + outgoing INVITE dialog).
How did you implement your "internal DNS"? /etc/hosts entries? a real DNS Server?
Can it be resolved by a gethostbyname() call?
Does the Linux command 'host' resolve the name to an IP address? If you use an /etc/hosts based approach this will not work. Also using non fully qualified domain names *may* turn out to be problematic.
From your description, it seems that siproxd can not resolve the hostname 'router' to it's IP address. The debug log should give more info on what exactly happens.
/Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Could you provide a debug log (debuglevel = -1)? Please send it directly to my SF mail account.
Done.
> The UA should:
> - use siproxd as *outbound proxy* (this guarantees all outgoing traffic is sent from UA to siproxd)
> - not add Route headers for siproxd.
To one:
My Ekiga client is configured to use siproxd as outbound proxy. Not sure though
whether *all* traffic should go through it. Surely INVITEs should, and they do.
Don't know about other requests, like REGISTER, SUBSCRIBE etc., where I still have to
clarify whether they should go through the proxy in any case. AFAIK, a major feature
of SIP is that servers can and should step out of the way at various stages. If need
arises, I can provide wireshark packet dumps if you wish and want to know what's
going on in detail.
To two:
I also was under the impression that Route headers were generally assembled from
Record-Route entries alone. This is e.g. what the UA Twinkle seem to do. The Ekiga
head developer pointed me to RFC 3261, Section 8.1.1.1 though:
"When a provider wishes to configure a UA with an outbound proxy, it is
recommended that this be done by providing it with a pre-existing route
set with a single URI, that of the outbound proxy."
This doesn't explicitly mention the Route header, and I didn't examine the context
of that passage yet in detail, but it looks like the UA actively providing a Route
containing the proxy address seems to be in conformance with the RFC.
> I don't know if your UA has the flexibility to disable the adding of these Route headers.
It doesn't.
> How did you implement your "internal DNS"? /etc/hosts entries? a real DNS Server?
Answered in my mail. The router runs dnsmasq, which resolves names via ISP name servers
and /etc/hosts. So yeah, for the LAN it is a "real" DNS server. On the router itself
though, names are resolved from ISP DNS servers and from /etc/hosts, not from the
dnsmasq DNS server.
> Can it be resolved by a gethostbyname() call?
It can, anywhere in the LAN via DNS provided by dnsmasq running on the router.
And on the router itself, the resolver library resolves the name via /etc/hosts.
gethostbyname succeeds on all machines involved, as also detailed in my mail.
>Does the Linux command 'host' resolve the name to an IP address?
Not on the router of course, since the name isn't known to my ISP DNS servers.
"host" is a DNS tool. It doesn't use the resolver library proper, which also
consults /etc/hosts.
>If you use an /etc/hosts based approach this will not work.
Why is that? Doesn't siproxd use the resolver?
> Also using non fully qualified domain names *may* turn out to be problematic.
Well, OK. The issue persists though when I configure Ekiga with the internal FQDN
of the router as outbound proxy. So in this particular case, it makes no difference.
Thanks for helping, Bruno.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From the debug log:
[...]
11:55:44 utils.c:114 DNS lookup - from cache: interop.pingtel.com -> 65.220.123.162
11:55:44 route_processing.c:134 route_preprocess: checking topmost Route header
11:55:44 utils.c:176 gethostbyname(router) failed: h_errno=1 [Unknown host]
Bingo, doesn't resolve the host 'router'.
Are you running siproxd in a chroot jail? After having done some testing here I'm convinced that it is caused by the chroot jail - the real /etc/hosts file is not accessible there, so the hostname 'router' cannot be resolved.
My recommendation would be:
- if you required siproxd to tun in a chroot jail, make the hostname in question available
via DNS on the router as well.
- do not run siproxd in a chroot jail (but do use reduced user privs)
- quick and dirty: copy the /etc/hosts file into the chroot jail (symlinking will not work,
hardlinking does work)
Regards,
/Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem. Chrooting things will result in such effects that seem to be very strange - until you know what actually happens, then it just seems stupid...
I didn't see that one before, so I also learned something ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I'm using Siproxd 0.5.13-1 with Ekiga 2.0.3 on Debian Etch, where Siproxd is running on
my firewalling router and Ekiga is configured to use Siproxd as an outbound proxy.
In this setting, I had the issue that Siproxd wouldn't relay INVITEs, i.e. outbound
calls wouldn't go any further than the proxy.
After discussing this with Ekiga developers, making packet captures etc., it turned
out that outbound calls do work when Ekiga is given the ip adress of the router, but
not when given the internal DNS name of it.
More precisely, my router has the DNS name 'router' on my LAN, and this name resolves
on all LAN machines, also the router itself, to it's IP address 192.168.0.1. When
Ekiga is configured to use "192.168.0.1" as a proxy, outbound calls work, when configured
to use "router" as a proxy, they don't.
As it turned out, Ekiga includes a Route header into it's packages, of the form
Route: <sip:192.168.0.1:5060;lr>
resp.
Route: <sip:router:5060;lr>
and that seems to be the only difference in the packages sent to the router between
those respective configurations. I suspect hence that Siproxd simply doesn't resolve
that "router" name in the Route header, i.e. it decides it can't deal with it and
just doesn't relay the INVITEs.
Does this seem plausible? And is this a (known) bug? What should be done to fix this?
Thanks, regards, Bruno.
Could you provide a debug log (debuglevel = -1)? Please send it directly to my SF mail account.
I'm just thinking about it - why should the UA (Ekiga) add a Route header for the proxy? Route headers usually result from Record-Route headers that are inserted from proxies (or other SIP routing elements) that want to stay in the communication path.
However, RFC3261 mentions that such a route set may be (some kind of) pre-configured within the UA.
In case of siproxd this should not be required, as siproxd does insert Record-Route headers in passin g traffic, so the answer is supposed to be passing back via siproxd. Adding an additional Route header for siproxd potentially may cause problems.
Also, using an internal (private) IP address potentially may cause problems, not speaking of non fully-qualified domain names.
The UA should:
- use siproxd as *outbound proxy* (this guarantees all outgoing traffic is sent from UA to siproxd)
- not add Route headers for siproxd.
I don't know if your UA has the flexibility to disable the adding of these Route headers.
However, maybe I have to look a bit deeper into this, so if you could provide a extensive log file that would help me quite a lot (preferably including a REGISTER and incoming + outgoing INVITE dialog).
How did you implement your "internal DNS"? /etc/hosts entries? a real DNS Server?
Can it be resolved by a gethostbyname() call?
Does the Linux command 'host' resolve the name to an IP address? If you use an /etc/hosts based approach this will not work. Also using non fully qualified domain names *may* turn out to be problematic.
From your description, it seems that siproxd can not resolve the hostname 'router' to it's IP address. The debug log should give more info on what exactly happens.
/Thomas
Hi Thomas
> Could you provide a debug log (debuglevel = -1)? Please send it directly to my SF mail account.
Done.
> The UA should:
> - use siproxd as *outbound proxy* (this guarantees all outgoing traffic is sent from UA to siproxd)
> - not add Route headers for siproxd.
To one:
My Ekiga client is configured to use siproxd as outbound proxy. Not sure though
whether *all* traffic should go through it. Surely INVITEs should, and they do.
Don't know about other requests, like REGISTER, SUBSCRIBE etc., where I still have to
clarify whether they should go through the proxy in any case. AFAIK, a major feature
of SIP is that servers can and should step out of the way at various stages. If need
arises, I can provide wireshark packet dumps if you wish and want to know what's
going on in detail.
To two:
I also was under the impression that Route headers were generally assembled from
Record-Route entries alone. This is e.g. what the UA Twinkle seem to do. The Ekiga
head developer pointed me to RFC 3261, Section 8.1.1.1 though:
"When a provider wishes to configure a UA with an outbound proxy, it is
recommended that this be done by providing it with a pre-existing route
set with a single URI, that of the outbound proxy."
This doesn't explicitly mention the Route header, and I didn't examine the context
of that passage yet in detail, but it looks like the UA actively providing a Route
containing the proxy address seems to be in conformance with the RFC.
> I don't know if your UA has the flexibility to disable the adding of these Route headers.
It doesn't.
> How did you implement your "internal DNS"? /etc/hosts entries? a real DNS Server?
Answered in my mail. The router runs dnsmasq, which resolves names via ISP name servers
and /etc/hosts. So yeah, for the LAN it is a "real" DNS server. On the router itself
though, names are resolved from ISP DNS servers and from /etc/hosts, not from the
dnsmasq DNS server.
> Can it be resolved by a gethostbyname() call?
It can, anywhere in the LAN via DNS provided by dnsmasq running on the router.
And on the router itself, the resolver library resolves the name via /etc/hosts.
gethostbyname succeeds on all machines involved, as also detailed in my mail.
>Does the Linux command 'host' resolve the name to an IP address?
Not on the router of course, since the name isn't known to my ISP DNS servers.
"host" is a DNS tool. It doesn't use the resolver library proper, which also
consults /etc/hosts.
>If you use an /etc/hosts based approach this will not work.
Why is that? Doesn't siproxd use the resolver?
> Also using non fully qualified domain names *may* turn out to be problematic.
Well, OK. The issue persists though when I configure Ekiga with the internal FQDN
of the router as outbound proxy. So in this particular case, it makes no difference.
Thanks for helping, Bruno.
Hi Bruno,
From the debug log:
[...]
11:55:44 utils.c:114 DNS lookup - from cache: interop.pingtel.com -> 65.220.123.162
11:55:44 route_processing.c:134 route_preprocess: checking topmost Route header
11:55:44 utils.c:176 gethostbyname(router) failed: h_errno=1 [Unknown host]
Bingo, doesn't resolve the host 'router'.
Are you running siproxd in a chroot jail? After having done some testing here I'm convinced that it is caused by the chroot jail - the real /etc/hosts file is not accessible there, so the hostname 'router' cannot be resolved.
My recommendation would be:
- if you required siproxd to tun in a chroot jail, make the hostname in question available
via DNS on the router as well.
- do not run siproxd in a chroot jail (but do use reduced user privs)
- quick and dirty: copy the /etc/hosts file into the chroot jail (symlinking will not work,
hardlinking does work)
Regards,
/Thomas
You got it, my message and your's just crossed. Thanks a lot Thomas.
Sorry for not paying attention, my fault, pretty stupid error.
Kind regards, Bruno.
SOLVED.
siproxd apparently chroots to /var/lib/siproxd, which didn't
have that /etc/hosts file. Linking it in solved the issue.
Stupid me. Really sorry for troubling you.
Thanks for your help, kind regards, Bruno.
No problem. Chrooting things will result in such effects that seem to be very strange - until you know what actually happens, then it just seems stupid...
I didn't see that one before, so I also learned something ;-)