Subject: [sipcore] Proposal: sip6 URI scheme

From: Rick van Rein <[email-masked]>
Date: Thu, 26 Apr 2012 09:27:25 +0000

Hello,

I am developing to get better support for SIP over IPv6.  One of the
problems that I have encountered is the interoperability between
endpoints that run only IPv4 or IPv6.  To solve this situations prior
to call setup, I am proposing a sip6 URI scheme.  Using this, end users
and their tools should have an easier time deciding whether or not to
use the URI.

A similar thing applies to enforced ZRTP --being sure before calling
that the call will be private-- and I combined that with the URI scheme
proposal, so as not to register more URI schemes than required.

Your feedback is kindly welcomed.

Best wishes,

Rick van Rein
OpenFortress

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 26 Apr 2012 11:22:27 +0200

> and their tools should have an easier time deciding whether or not to

A new URI scheme doesn't make any sense, since a SIP uri can be resolved to many different hosts using NAPTR/SRV records.

A phone that is dual stack can register with two contacts, one for each address family. ICE will take care of media handling.

/O

---

From: Rick van Rein <[email-masked]>
Date: Thu, 26 Apr 2012 09:37:07 +0000

Hello Olle,

> A new URI scheme doesn't make any sense, since a SIP uri can be resolved to many different hosts using NAPTR/SRV records.

This only helps with the SIP communication -- but it gives no certainty
about RTP.  Interoperability between IPv4-only and IPv6-only relating to
media can only be found when trying to setup a call, right?

> A phone that is dual stack can register with two contacts, one for each address family. ICE will take care of media handling.

There is no formal relation between the IP version used for SIP and used
for RTP.  This is what I am proposing to solve with sip6:

Thanks,
 -Rick

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 26 Apr 2012 11:30:52 +0200

2012/4/26 Rick van Rein <[email-masked]>:
> to call setup, I am proposing a sip6 URI scheme.

Hi Rick, I'm pretty sure that's not the way to go. As Olle pointed out
a SIP URI with domain could point, after RFC 3263 resolution, to many
transport:address:port, some of them could be IPv4 and others IPv6.

Your proposal would indeed break existing implementations.

If for example alice uses just IPv4 and bob just IPv6, and both use
and register in a proxy/registrar with IP dual stack, alice should be
able to call bob's AoR (sip:[email-masked]) without knowing that bob
is using IPv6 or not. This is already possible with current specs but
it would be not possible with your proposal.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 26 Apr 2012 11:32:53 +0200

> media can only be found when trying to setup a call, right?
But a URI scheme doesn't help here.
My softphone keeps moving between networks, some dual stack and some not.

> for RTP.  This is what I am proposing to solve with sip6:

The URI scheme is still WRONG. YOu might want to add a UA capability to the Contact registred.
That's something we should look into. Especially if you have a situation where a server needs to decide whether to force an RTP proxy or not.
According to the RFC the client should organize this itself with a TURN server, but in reality we might need to know on the server.

There's a separate SIPv6 mailing list operated by the SIP forum and a SIPv6 forum on Facebook if you want to join the discussion there too :-)

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 26 Apr 2012 11:32:43 +0200

> for RTP.  This is what I am proposing to solve with sip6:

A SIP UA could just use IPv4 for signaling and IPv4 and IPv6 for
media. SIP gateways usually use different address for signaling and
media.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 26 Apr 2012 11:36:29 +0200

Hi Rick,

[snip]
> for RTP.  This is what I am proposing to solve with sip6:

Why would you need that? If running in a dual stacked environment maybe some firewall policy won't allow your RTP packets to go out through IPv6 but they could go out through IPv4, ICE can pick the best path for media regardless of signaling.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Apr 2012 12:17:03 +0200

Hi,

Maybe you could describe the use-case you have in mind, and what you want to achieve, and then we can look at possible solutions.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rick van Rein
Sent: 26. huhtikuuta 2012 12:27
To: [email-masked]; [email-masked]
Subject: [sipcore] Proposal: sip6 URI scheme

Hello,

I am developing to get better support for SIP over IPv6.  One of the problems that I have encountered is the interoperability between endpoints that run only IPv4 or IPv6.  To solve this situations prior to call setup, I am proposing a sip6 URI scheme.  Using this, end users and their tools should have an easier time deciding whether or not to use the URI.

A similar thing applies to enforced ZRTP --being sure before calling that the call will be private-- and I combined that with the URI scheme proposal, so as not to register more URI schemes than required.

Best wishes,

Rick van Rein
OpenFortress

---

From: "Nataraju A.B" <[email-masked]>
Date: Thu, 26 Apr 2012 16:19:16 +0530

On Thu, Apr 26, 2012 at 3:07 PM, Rick van Rein <[email-masked]> wrote:

> Hello Olle,
>
> > A new URI scheme doesn't make any sense, since a SIP uri can be resolved
> to many different hosts using NAPTR/SRV records.
>
> > A phone that is dual stack can register with two contacts, one for each
> address family. ICE will take care of media handling.
>

[ABN] There is no need for any formal relation between signalling and
media. if you can share your use case you can get the useful replies.

Theoretically, it is acceptable to use different addressing schemes for
signalling and media. AFAIK, There is no constraint to use same IP version
for both media and signalling.

It is very well possible to publish the IPV6 media address (in SDP) whereas
IPv4 is being used for SIP signalling purposes.

>
>
> Thanks,
>  -Rick
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

-- 
Thanks,
Nataraju A.B.

---

From: Rick van Rein <[email-masked]>
Date: Thu, 26 Apr 2012 11:16:35 +0000

Hello all,

Thanks for your feedback.

> Maybe you could describe the use-case you have in mind, and what you want
> to achieve, and then we can look at possible solutions.

I am thinking of direct media connections between SIP callers, after setup
of a call from ENUM entries, or perhaps freenum.org, or to one's hosted SIP
proxy under a domain name, e.g. sip:[email-masked] -- these schemes
are part of the promise that SIP holds for telephony over the Internet.

Direct calls are ideally served with IPv6.  But as long as there is no way
to infer if a service is IPv6-only, there will be a practical need to support
IPv4 as well, so as to avoid failed call setups due to inavailability of a
caller-assumed transport.  With IPv4 as an always-present fallback, there
is no real reason to implement IPv6 as well.  Specifically, for IPv6 as
the connecting protocol between the caller's side and the callee's side.
Everyone is waiting for everyone else.

IPv6 however, is very useful for direct calls over the Internet, as it
has no problems with NAT (only with firewalls, which is easily solved)
and so it never requires an RTP proxy.  RTP proxies are potentially
problematic for a number of reasons:
 - efficiency: RTP traffic may pass through more hops than needed
 - quality: Call quality may suffer from extra media indirections
 - complexity: setting up a private RTP proxy is not straightforward
 - freedom: most end-users will be dependent on an external party's RTP proxy
 - facilities: external RTP proxies may not support all media wishes
   (think of high-bandwidth video or the deaf's realtime-text protocol)
 - privacy: external RTP proxies are often regulated into tapping phone calls

Having a separate indication of SIP over IPv6 clearly states the opposite
situation; there is no need to attempt IPv4 on setups, and so it makes
no sense to use such URIs on any implementation but an IPv6-capable one.
This may include tools that setup IPv6 over a tunnel to create the call.

Please note that nothing prohibits proxies to handle both sip6: and sip:
URIs, and perhaps translate them to each other's format.  The only thing
that would be required, is that such a proxy would use IPv6 only on the
sip6: side, so it may end up being an RTP proxy as well -- but only for
the local end, where a peer has not implemented SIP over IPv6 yet.  The
lookup of a sip6: party is an IPv6-only process, which means that the
default has shifted from SIP over IPv4 to SIP over IPv6, whenever possible.

A new URI scheme is not the only way to accomplish this; in fact, anything
in the syntax of a sip: URI would do it.  The reason why I proposed a URI
scheme is that it works well in browsers etc. that generally choose a
handler application based on the URI scheme; it would not start a sip:
handler if it failed to recognise a ?transport=udp-ipv6 annotation, and it
could usually be configured to start a different handler for sip6: without
knowing anything about the SIP protocol (a protocol handler could register
for handling the sip6: URI and another could register for the sip: URI,
in case of a mobile platform).  These are pragmatic considerations only,
but they made me wish for a URI scheme.

FWIW, I've engineered beta-level solutions that make it possible in
all common usecases to use SIP over IPv6, and IPv6 alone.  Information on
that can be found on http://devel.0cpm.org/ -- mostly work in progress.

Thanks to all for your feedback,

Best wishes,

Rick van Rein
OpenFortress

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Apr 2012 17:47:06 -0700

> Sent: Thursday, April 26, 2012 2:27 AM

It's a layering violation, and -- worse -- will cause far more harm
than it could possibly help.  Please don't do this.

http://tools.ietf.org/html/rfc6157 describes how SIP is expected to
support IPv6, and transition from IPv4-only to dual-stack to IPv6-only
with the least amount of harm.  It works over NAT64 and NAT46, too
(SIP6, if deployed, can't), and NAT64 will be necessary for IPv6-only
endpoints to access IPv4-only endpoints, such as being deployed by
T-Mobile USA's IPv6-only service, Swisscom's IPv6-only trial, and
probably other mobile operators and, some day, eventually wireline
operators.

If RFC6157 fails, which is why you are proposing SIP6, you need
to back up and explain to everybody the failure of RFC6157.

-d

---

From: Rick van Rein <[email-masked]>
Date: Fri, 27 Apr 2012 05:29:33 +0000

Hello,

> than it could possibly help.  Please don't do this.

Thanks all for looking into this proposal.  It is clear that it will not
gain wide acceptance, and should not be taken any further.

I'm withdrawing the proposal.

Best wishes,
 -Rick

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Apr 2012 07:50:39 -0700

> From: Rick van Rein [mailto:[email-masked]]
> Sent: Thursday, April 26, 2012 10:30 PM
> To: Dan Wing
> Cc: 'Rick van Rein'; [email-masked]; [email-masked]
> Subject: Re: [sipcore] Proposal: sip6 URI scheme
> 
> Hello,
> 

I do like the attention to IPv6, though -- don't get me wrong!  I
expect ICE is sufficient to find a working IPv6 or working IPv4
media path, and choosing between them.  If it is deficient, please
point it out, as ICE is being used by WEBRTC on the Internet (where
the IPv4/IPv6 address selection problem will be more severe than
within controlled networks).

-d