Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Daniel Lakeland
I have a situation where my "internal" phones can call each other, even
when one is registered via ipv4 and one via ipv6 (thanks to some
rewriting of the SDP and Asterisk as a media server)

However, when I do the following, I get lines like the following in the
syslogs:

Oct 20 20:52:50 orbit2 /usr/sbin/opensips[14070]:
ERROR:core:proto_udp_send:
sendto(sock,0x7fc96010bb90,455,0,0x7fc9600cb570,16): Network is
unreachable(101) [xxx.xxx.xxx.xxx:5070]
Oct 20 20:52:50 orbit2 /usr/sbin/opensips[14070]: ERROR:tm:msg_send:
send() to xxx.xxx.xxx.xxx:5070 for proto udp/1 failed
Oct 20 20:52:50 orbit2 /usr/sbin/opensips[14070]: ERROR:tm:t_uac:
attempt to send to 'sip:[hidden email]:5070' failed
Oct 20 20:52:51 orbit2 /usr/sbin/opensips[14070]:
ERROR:core:proto_udp_send:
sendto(sock,0x7fc96010bb90,455,0,0x7fc9600cb570,16): Network is
unreachable(101) [104
.237.158.242:5070]
Oct 20 20:52:51 orbit2 /usr/sbin/opensips[14070]: ERROR:tm:msg_send:
send() to xxx.xxx.xxx.xxx:5070 for proto udp/1 failed
Oct 20 20:52:52 orbit2 /usr/sbin/opensips[14070]:
ERROR:core:proto_udp_send:
sendto(sock,0x7fc96010bb90,455,0,0x7fc9600cb570,16): Network is
unreachable(101) [104
.237.158.242:5070]
Oct 20 20:52:52 orbit2 /usr/sbin/opensips[14070]: ERROR:tm:msg_send:
send() to xxx.xxx.xxx.xxx:5070 for proto udp/1 failed
Oct 20 20:52:54 orbit2 /usr/sbin/opensips[14070]:
ERROR:core:proto_udp_send:
sendto(sock,0x7fc96010bb90,455,0,0x7fc9600cb570,16): Network is
unreachable(101) [104
.237.158.242:5070]
Oct 20 20:52:54 orbit2 /usr/sbin/opensips[14070]: ERROR:tm:msg_send:
send() to xxx.xxx.xxx.xxx:5070 for proto udp/1 failed
Oct 20 20:52:58 orbit2 /usr/sbin/opensips[14070]:
INFO:dialog:reply_from_caller: terminating dialog ( due to timeout )
with callid = [[hidden email]]

heres how the call flows:

Phone 1 ----ipv4 TLS -----> Proxy <---ipv4 UDP----> Asterisk on port
5070 same server as proxy <---ipv6 UDP ---> Proxy <-- ipv4 UDP---> provider


I get a call with audio for about 30 seconds and then OpenSips sends
errors and the call aborts. The provider's sip trace just shows a "Bye"
from asterisk, so I guess the call is aborting on the "phone" leg

I just discovered the "mhomed" variable, but when I tried this, it still
aborts.
I've tried manually forcing the socket... but I think maybe I'm not
doing it in all the appropriate places. It may also be that this is a
Red Herring, as it seems like the messages *do* get delivered?


What I see in a sip_trace is that the only things being sent to the
xxx.xxx.xxx.xxx:5070 port are messages from the proxy to asterisk on the
Phone1 side of the call. Though since the sending blocks and aborts in
the logs, I'm not sure if the stuck messages hit the sip trace.

I'm running the "firehol" firewall and it's a VPS server, I can't seem
to figure out how to remove the nf_conntrack_nat module as this vps has
no knowledge of the kernel modules. (?? I am not that familiar with the
VPS kernel environment) the proxy should be able to talk to Asterisk,
and in fact, it seems like doing an asterisk sip trace that asterisk is
getting the messages...


On the Phone 1 leg I see:

INVITE
Session Progress from asterisk
OK from asterisk
Ack from phone1

etc both are hitting the proxy and the asterisk server I believe

Please note that *when I call direct to another local sip phone I have
no problems*

I'm tearing my hair out a bit here

Can anyone think why opensips would have trouble sending like this? Is
this something specific to VPS virtual networking stuff?

THanks !



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Daniel Lakeland
On 10/20/2017 09:49 PM, Daniel Lakeland wrote:

> I have a situation where my "internal" phones can call each other,
> even when one is registered via ipv4 and one via ipv6 (thanks to some
> rewriting of the SDP and Asterisk as a media server)
>
> However, when I do the following, I get lines like the following in
> the syslogs:
>
> Oct 20 20:52:50 orbit2 /usr/sbin/opensips[14070]:
> ERROR:core:proto_udp_send:
> sendto(sock,0x7fc96010bb90,455,0,0x7fc9600cb570,16): Network is
> unreachable(101) [xxx.xxx.xxx.xxx:5070]
> Oct 20 20:52:50 orbit2 /usr/sbin/opensips[14070]: ERROR:tm:msg_send:
> send() to xxx.xxx.xxx.xxx:5070 for proto udp/1 failed
...

Ok, it was a long night, it's almost 1am here, but I have figured this
out. I was creating my dialog with

create_dialog("pPB")

what was happening is that the pinger was trying to ping both an IPv6
address, and an IPv4 address... and probably reusing a socket where it
wasn't able to ping the ipv4 address... so it timed out and killed the
call from the middle right at 30 or so seconds.

By creating my dialog as

create_dialog()

without the pinging... the call continues just fine.

It seems that this "bug" is triggered where I have an outgoing call that
forwards to asterisk, asterisk then starts a new call by contacting the
proxy at its IPv6 address... and the proxy then needs to ping both ipv4
and ipv6 addresses.

the pinger should somehow decide which socket to ping over based on the
address family it needs to ping...



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Daniel Lakeland
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Răzvan Crainea-2
Hi, Daniel!

My assumption is that have double Record Routing[1] disaabled. That's
why it seems OpenSIPS is not figuring out corrrectly the outbound
interface for sequential messages. Could you send a SIP trace done on
the OpenSIPS server (privately if posting here is an issue)?

This also explains the 30 seconds timeout - if asterisk is not receiving
the ACK within 30 seconds, it closes the call.


[1] http://www.opensips.org/html/docs/modules/2.3.x/rr.html#idp5519008

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

On 10/23/2017 09:44 AM, Daniel Lakeland wrote:

> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Daniel Lakeland
On 10/23/2017 06:11 AM, Răzvan Crainea wrote:
> Hi, Daniel!
>
> My assumption is that have double Record Routing[1] disaabled. That's
> why it seems OpenSIPS is not figuring out corrrectly the outbound
> interface for sequential messages. Could you send a SIP trace done on
> the OpenSIPS server (privately if posting here is an issue)?
>
> This also explains the 30 seconds timeout - if asterisk is not
> receiving the ACK within 30 seconds, it closes the call.

I haven't explicitly disabled this in the script. I'm using a script
built on the standard residential script... by now it's moderately
different.

The 30 second timeout was because of create_dialog("PpB") and the pings
were not being sent out the correct socket so it wasn't receiving
replies and OpenSips was killing the call from the middle. (I have
packet traces and logs that show this).

The only parameter I have for rr module is

modparam("rr", "append_fromtag", 0)

which I believe was put there by the template as I have no idea what it
means and so I wouldn't have put it there myself.

I do see two record route headers in one example sip-trace that I just
looked at. The outgoing call is heading from asterisk via ipv6 to the
proxy and then via ipv4 to the sip trunk... record route headers look like

Record-Route: <sip:x.x.x.x;r2=on;lr;did=0f2.6185fc54>
Record-Route: <sip:[2600:blablablablamyhost];r2=on;lr;did=0f2.6185fc54>

Showing that indeed Opensips has recorded itself twice in the route.

Thanks for taking some time with this!
Dan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Daniel Lakeland
On 10/23/2017 07:51 AM, Daniel Lakeland wrote:

> On 10/23/2017 06:11 AM, Răzvan Crainea wrote:
>> Hi, Daniel!
>>
>> My assumption is that have double Record Routing[1] disaabled. That's
>> why it seems OpenSIPS is not figuring out corrrectly the outbound
>> interface for sequential messages. Could you send a SIP trace done on
>> the OpenSIPS server (privately if posting here is an issue)?
>>
>> This also explains the 30 seconds timeout - if asterisk is not
>> receiving the ACK within 30 seconds, it closes the call.

Razvan: thanks again for your time, your message encouraged me to turn
off all the force_send_socket stuff and just try mhomed. This worked,
sort of!

The problem is that there are multiple problems and so it's hard to
track down what's the main issue. At least now, there are no messages
about failure to send out a socket... but now there are problems still....

Some of these problems seem to be fixed by topology hiding. When I get a
call from an ipv4 ATA I topology hide, and then these ATAs don't see
ipv6 addresses they probably don't understand and then I don't get
messages from them with truncated garbage ip addresses in the request.

on the other hand, somehow doing that broke my SDP rewriting scheme....
so there is more to do, but still some progress. I would like to offer
up an ipv6/ipv4 dual-stacked tutorial for opensips once I've figured it
all out. It would be great if someone would be interested to review that
document for accuracy ;-)



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Răzvan Crainea-2
Hi, Daniel!

Sure, if you want to make a dual-stack tutorial for OpenSIPS, I'd be
more than welcome to review it.
In the meantime, let us know if we can help you making it more robust.

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

On 10/23/2017 09:57 PM, Daniel Lakeland wrote:

> On 10/23/2017 07:51 AM, Daniel Lakeland wrote:
>> On 10/23/2017 06:11 AM, Răzvan Crainea wrote:
>>> Hi, Daniel!
>>>
>>> My assumption is that have double Record Routing[1] disaabled.
>>> That's why it seems OpenSIPS is not figuring out corrrectly the
>>> outbound interface for sequential messages. Could you send a SIP
>>> trace done on the OpenSIPS server (privately if posting here is an
>>> issue)?
>>>
>>> This also explains the 30 seconds timeout - if asterisk is not
>>> receiving the ACK within 30 seconds, it closes the call.
>
> Razvan: thanks again for your time, your message encouraged me to turn
> off all the force_send_socket stuff and just try mhomed. This worked,
> sort of!
>
> The problem is that there are multiple problems and so it's hard to
> track down what's the main issue. At least now, there are no messages
> about failure to send out a socket... but now there are problems
> still....
>
> Some of these problems seem to be fixed by topology hiding. When I get
> a call from an ipv4 ATA I topology hide, and then these ATAs don't see
> ipv6 addresses they probably don't understand and then I don't get
> messages from them with truncated garbage ip addresses in the request.
>
> on the other hand, somehow doing that broke my SDP rewriting
> scheme.... so there is more to do, but still some progress. I would
> like to offer up an ipv6/ipv4 dual-stacked tutorial for opensips once
> I've figured it all out. It would be great if someone would be
> interested to review that document for accuracy ;-)
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Daniel Lakeland
On 10/24/2017 01:41 AM, Răzvan Crainea wrote:
> Hi, Daniel!
>
> Sure, if you want to make a dual-stack tutorial for OpenSIPS, I'd be
> more than welcome to review it.
> In the meantime, let us know if we can help you making it more robust.

Here are the current issues I'm considering:

1) How to deal with ipv4 only endpoints, ones that think that a
destination uri like sip:foo@[2001:1a36:2021:...]:5060 means that the
destination refers to user foo at host "[2001" on port 1 and yes this
seems to happen.

The current strategy I have because my total endpoint count is small, is
to list those endpoints by username in the script and detect when $ru
has that username, and do topology hiding... this works pretty well I
think, but it also requires SDP rewriting in case of IP type mismatch
(fortunately, Asterisk seems to listen on ipv4 and ipv6 udp sockets).
The general solution might be to first do a lookup, and then based on
whether $ru is now an IPv4 address or not, decide whether to topology
hide. My assumption is that ipv6 registered endpoints can handle both.

The issue is that when ipv6 is available, systems prefer it, and this
makes sense. So, when Asterisk has to originate a call, it calls the
proxy and the proxy is dual-stacked, so it calls via ipv6 and offers its
own ipv6 as contact and SDP contents. Without topology hiding, the proxy
passes this contact along to the ipv4 only ATA and the whole thing goes
kablooie when the ATA can't figure out what Asterisk is talking about.

Also, these are ipv4 endpoints, and so they need some NAT help. The
combination of topo hiding and NAT help can be an issue. But I think at
the moment it's working, nevertheless, it's something I need to sit down
with and read through the script and see what the right way to do it is,
rather than the hackery I have in place.

When the call originates at one of these ipv4 only endpoints, it seems
that Asterisk then creates replies that are ipv4 and so the problem
doesn't occur.

2) Getting audio across ipv4/ipv6 transitions is tricky. I'm using
Asterisk, though my ultimate goal is to switch to FreeSwitch as my
impression is it might work better for me. At the moment, Asterisk works
because I enable icesupport, and so it listens on ipv4 and ipv6. I don't
enable ICE negotiation on my endpoints, I just have OpenSips rewrite the
SDP to the appropriate one based on whether they're ipv4 or not. I do
this because ICE support is spotty and the ATAs can't do it, and the
softphones don't need it. But it's possible that ICE offerings are not
working with my outbound trunks.... sporadically (based on which carrier
my outbound trunk chooses in their least cost routing). So, for outbound
calls on the trunk, it's possible I need to remove ICE support... since
it's not needed there as their endpoints are IPv4 only, this may be
fine, but still it's a gotcha people should know about. It's not clear
to me whether Asterisk is being nice and other media servers might
refuse to simply accept input on any socket without a proper ICE
negotiation. In my opinion, ICE is dead in the water as first off it's
only needed in ipv4, but second there are too many ipv4 ATAs and things
that don't support it, and finally it's a temporary hack that will go
away some time late in 2019 when google's ipv6 adoption curve hits more
than 50% https://www.google.com/intl/en/ipv6/statistics.html that's
doubling every 15 months or something like that, so we'll probably see
40% ipv6 hits by some time early 2019 and the majority of everything
google does will be ipv6 sometime mid 2019 (note in the US we're already
at about 33% ipv6 to google). At that point ipv4 will be a minority
issue for consumers, and incentives to make major changes will switch sides.



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

Răzvan Crainea-2
Hi, Daniel!

1) I think you are absolutely right - if you have issues with phones
that misbehave when having IPv6 contact, topology_hiding is the
solution. There are several ways to determine whether an endpoint is
IPv6, so this should be easy to sort out.

2) Have you considered any methods to inform Asterisk that your callee
is IPv6 or IPv4? Perhaps if you manage to figure out what the final
destination is, you can control the IP that Asterisk adds in SDP, and
prevent it from advertising IPv6.
Also, did you consider using a media proxy? Something like RTPProxy set
in a bridging mode will solve your issue too.

Anyways, thanks for documenting your "adventure", I find it really
interesting.

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

On 10/24/2017 10:58 PM, Daniel Lakeland wrote:

> On 10/24/2017 01:41 AM, Răzvan Crainea wrote:
>> Hi, Daniel!
>>
>> Sure, if you want to make a dual-stack tutorial for OpenSIPS, I'd be
>> more than welcome to review it.
>> In the meantime, let us know if we can help you making it more robust.
>
> Here are the current issues I'm considering:
>
> 1) How to deal with ipv4 only endpoints, ones that think that a
> destination uri like sip:foo@[2001:1a36:2021:...]:5060 means that the
> destination refers to user foo at host "[2001" on port 1 and yes this
> seems to happen.
>
> The current strategy I have because my total endpoint count is small,
> is to list those endpoints by username in the script and detect when
> $ru has that username, and do topology hiding... this works pretty
> well I think, but it also requires SDP rewriting in case of IP type
> mismatch (fortunately, Asterisk seems to listen on ipv4 and ipv6 udp
> sockets). The general solution might be to first do a lookup, and then
> based on whether $ru is now an IPv4 address or not, decide whether to
> topology hide. My assumption is that ipv6 registered endpoints can
> handle both.
>
> The issue is that when ipv6 is available, systems prefer it, and this
> makes sense. So, when Asterisk has to originate a call, it calls the
> proxy and the proxy is dual-stacked, so it calls via ipv6 and offers
> its own ipv6 as contact and SDP contents. Without topology hiding, the
> proxy passes this contact along to the ipv4 only ATA and the whole
> thing goes kablooie when the ATA can't figure out what Asterisk is
> talking about.
>
> Also, these are ipv4 endpoints, and so they need some NAT help. The
> combination of topo hiding and NAT help can be an issue. But I think
> at the moment it's working, nevertheless, it's something I need to sit
> down with and read through the script and see what the right way to do
> it is, rather than the hackery I have in place.
>
> When the call originates at one of these ipv4 only endpoints, it seems
> that Asterisk then creates replies that are ipv4 and so the problem
> doesn't occur.
>
> 2) Getting audio across ipv4/ipv6 transitions is tricky. I'm using
> Asterisk, though my ultimate goal is to switch to FreeSwitch as my
> impression is it might work better for me. At the moment, Asterisk
> works because I enable icesupport, and so it listens on ipv4 and ipv6.
> I don't enable ICE negotiation on my endpoints, I just have OpenSips
> rewrite the SDP to the appropriate one based on whether they're ipv4
> or not. I do this because ICE support is spotty and the ATAs can't do
> it, and the softphones don't need it. But it's possible that ICE
> offerings are not working with my outbound trunks.... sporadically
> (based on which carrier my outbound trunk chooses in their least cost
> routing). So, for outbound calls on the trunk, it's possible I need to
> remove ICE support... since it's not needed there as their endpoints
> are IPv4 only, this may be fine, but still it's a gotcha people should
> know about. It's not clear to me whether Asterisk is being nice and
> other media servers might refuse to simply accept input on any socket
> without a proper ICE negotiation. In my opinion, ICE is dead in the
> water as first off it's only needed in ipv4, but second there are too
> many ipv4 ATAs and things that don't support it, and finally it's a
> temporary hack that will go away some time late in 2019 when google's
> ipv6 adoption curve hits more than 50%
> https://www.google.com/intl/en/ipv6/statistics.html that's doubling
> every 15 months or something like that, so we'll probably see 40% ipv6
> hits by some time early 2019 and the majority of everything google
> does will be ipv6 sometime mid 2019 (note in the US we're already at
> about 33% ipv6 to google). At that point ipv4 will be a minority issue
> for consumers, and incentives to make major changes will switch sides.
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior on ipv4 / ipv6 dual stack server with/without mhomed

dlakelan


On October 26, 2017 2:26:14 AM PDT, "Răzvan Crainea" <[hidden email]> wrote:
>Hi, Daniel!
>
>1) I think you are absolutely right - if you have issues with phones
>that misbehave when having IPv6 contact, topology_hiding is the
>solution. There are several ways to determine whether an endpoint is
>IPv6, so this should be easy to sort out.
>
>2) Have you considered any methods to inform Asterisk that your callee
>is IPv6 or IPv4? Perhaps if you manage to figure out what the final
>destination is, you can control the IP that Asterisk adds in SDP, and
>prevent it from advertising IPv6.
>Also, did you consider using a media proxy? Something like RTPProxy set


Re figuring out in asterisk where to route call. I do not think this solution is easily possible due to mobile clients, those that can be sometimes v4 and sometimes v6. All my endpoints register to the proxy and not asterisk, so asterisk can not know ahead of time how they are connected.

I suppose I could branch a register over to asterisk, but I think it's easier and more reliable to have opensips topo hide and rewrite the sdp. Asterisk with icesupport= yes will accept audio on any interface... It's a hack but a good option to keep moving part count down 😀

When it comes to adding media proxy, it seems this could work but also adds a component which Asterisk is capable of doing on it's own. If needed I will do this. Actually my favorite solution is to use freeswitch instead of asterisk, and to run it on site at locations with v4 only atas etc. They then talk to the switch on site using private ips and the switch speaks to the internet and opensips across the NAT using dedicated port forwarding range for RTP or ipv6 as available. I'm considering a small SBC like raspberry pi to run freeswitch. Mobile clients with dual stack then simply register directly to my opensips on a VPS rather than through a local site freeswitch.

Another advantage is to offload transcoding from the VPS where asterisk currently runs. Timing issues in the VPS can be noticeable, particularly transcoding opus to g711 for the v4 atas to talk to mobile smartphones. Or mobile smartphones to POTS trunks. Another reason to prefer freeswitch, as it has fuller opus support.


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users