[OpenSIPS-Users] Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Daniel Lakeland dlakelan at street-artists.org
Mon Oct 23 02:44:11 EDT 2017


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.





More information about the Users mailing list