Further thoughts here on ipv4/v6 dual stacked servers.
Once I solved the pinging problem, I still didn't solve the problem that
calls wouldn't go through when they had to be relayed around through
paths that crossed IP families.
For example IPv4 phone calls to proxy
proxy forwards to dual-stack PBX via IPv6
pbx sends new call back to proxy via IPV6 heading to SIP trunk on ipv4
proxy sends call via ipv4 to sip trunk...
eventually in all this stuff, you're going to get a situation where
opensips tries to reuse a socket and can't send because it's got the
wrong kind of socket (wrong address family). The result is an error like:
Oct 22 23:03:15 orbit2 /usr/sbin/opensips[15818]:
ERROR:core:proto_udp_send:
sendto(sock,0x7f99be07f380,737,0,0x7ffc04b0f3c0,16): Network is
unreachable(101) [x.x.x.x:5060]
Oct 22 23:03:15 orbit2 /usr/sbin/opensips[15818]: ERROR:core:msg_send:
send() to x.x.x.x:5060 for proto udp/1 failed
I personally think that "mhomed" should do this right, but my testing
indicated it didn't in 2.3.1 deb packages from opensips APT repository.
Instead what I have is a special "fixup" type route on request and reply
which tries to figure out what address we're about to send to, and then
forces the right socket. It seems bug prone, and I've had to debug it a
lot the last day or so. I still don't know what happens when I try to do
several transformations and one of them fails... like
$var(thefam) = $(ru{uri.host}{ip.resolve}{ip.pton}{ip.family})
sometimes gives:
Oct 22 23:21:40 orbit2 /usr/sbin/opensips[15971]:
WARNING:core:do_assign: no value in right expression at
/etc/opensips/opensips.cfg:621
I'm not sure why
Things maybe are working now, but I REALLY think mhomed should be looked
at in the context of dual stack.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
