Re: [Uri-review] [sipcore] Proposal: sip6 URI scheme

[Rick van Rein <[e-mail]>]

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:[e-mail] -- 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