Hi Olle,
In the setups we has so far we haven't came across something like that
as the SIP routing is more strict/controlled (as in all production
setups :) ).
Nevertheless, IMO what you describe is not something new (or specific to
IPv6). It is a generic fallback between two TCP connections (the fact
that one of them is over IPv6 does not change how it should be handled).
RFC3263 + RFC3261 describes how a SIP entity should do failover between
multiple destination returned by DNS lookup. I guess we can extrapolate
it for the AAA records.
When comes to timers, from my experience, having the B timer to the
default values (64xT1) it is not something acceptable in real platform -
as you mentioned, the user experience will be a disaster in this case.
For TCP -> use small timeouts for connect ; for UDP and generic SIP ->
use small B timer . With these setting, the switching between 2
destination (A or AAA) will be relative fast.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 19.02.2016 11:21, Olle E. Johansson wrote:
On 17 Feb 2016, at 21:09, Bogdan-Andrei Iancu <bog...@opensips.org> wrote:
Hi Dave,
We (OpenSIPS project) had several systems deployed (including production) with
both IPv6 and IPv4, able to do bridging between the two networks at SIP level.
What exactly are you looking to be shared ?
The problem is this:
Set up two SIP servers on dual stack, add both A and AAAA records to the dns
name for them.
Block IPv6.
According to the old ways, a server setting up a connection to the buddy will
prefer IPv6. The question is how OpenSIPS handles this situation? How long will
it take until it switches over to IPv4?
This is what was observed in the world of HTTP and led to the Happy Eyeballs
ideas of how
to solve the problem. The solution was to simultaneously set up TWO connections
(remember
they are in the world of TCP) and judge which one got through first, close the
slowest one and continue. If IPv6 was blocked, the IPv4 connection would happen
quickly and the eyes of the user would stay happy. Web browsers implemented
this and we tested on World IPv6 day without
an issue reported.
We have the same issues with SIP, but with standard T1 settings it will take up
to 32 seconds until we fail, and in best case try over the other protocol.
That’s not acceptable for a SIP call.
You can get some ideas from my slideshare presentations:
- http://www.slideshare.net/oej/sipforum-sip-ipv6-discussion-slides (from 2012)
- http://www.slideshare.net/oej/sip-ipv6-time-for-action (from 2011)
(Mentions OpenSIPS :-) )
Please continue to ask if you have other questions.
Maybe we should set up a testbed like the one we have at SIPit events for all
implementors of SIP servers and clients to test with?
Regardless, set up tests and please tell us what happens. If you solved this
issue - how
did you do it?
/O
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 17.02.2016 21:42, Dale R. Worley wrote:
In the IETF Sipcore working group, we're starting work on "Happy
Eyeballs for SIP", getting systems that use both IPv4 and IPv6 to work
well, even in situations where connectivity in IPv6 is not assured. We
expect that the changes to the SIP specifications will be small or none,
but that there are a number of best practices that can be recommended to
improve user experience.
I'm asking here to find out if anyone has implementation experience in
this area that they'd be willing to share.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
