Re: [Sipwitch-devel] SIP + RTP/RTCP Port Multiplexing

[David Sugar]

Port multiplexing is also an interesting possibility.  I think, at least
in theory, it could be fairly easy to separate sip messages from media
traffic.  We would only have to patch exosip2 for a new kind of callback
to do this.  This of course could still allow inter-operation with
existing sip services/servers/users like from iptel, as well as pure sip
backend devices like sip phones.  While a pure IAX solution would also
work, once you have to add devices that do not speak IAX natively, and
if you do so you are going to transcode media, and that means killing
end-to-end secure media paths that ZRTP/zrtp-like approaches depend on
and enable users to validate.  Each has tradeoffs...

If you locally have a an IAX switch (and even something like asterisk),
the tradeoff is not so bad even for transcoding, since the switch is
under your local control, and your also decoding audio at a nearby
workstation running a user agent anyway.  If your switch is hosted
remote, though, it becomes unacceptable as it effectively is a mitm
outside your immediate control.  If it is further provided by a third
party or cloud provider, it is a potential espionage tool.

We also did have an idea for a non-symetric (one way) media proxy design
in sipwitch itself that we were trying to develop, based somewhat on
what the h323 gatekeeper does.  Like gatekeeper it would depend on port
forwarding a fixed range of ports for NAT, but not all the code for it
is complete yet, let alone tested.  One thought at the time was to tie
it optionally to Linux kernel dynamic firewall rules, so that media
never has to be proxied through user space at all for NAT (saving
processing...), just packet forwarded in kernel space.  This made much
sense in a pure low cpu power router use case, like for example sitting
on a linksys with wrt.  Without additional help there simply has not
been much time to try developing and testing it, let alone debug it.

The idea of a pure and secure end-to-end IAX solution is also
intriguing.  Offhand, I think there would have to be an IAX ua that
supports zrtp-style user notifications, as well as extensions to IAX to
carry the extra info, though I think the fundamentals could support it.
 To do so securely with the ability of the user to verify requires more
than just media pass-through, though certainly the NAT issues are
simplified and standardized in ways that do make more sense, and
federation is not something you would have to force onto it, as we do by
creatively interpreting the SIP standard.  I saw work on things like the
iaxclient library kinda die out many years ago, though sflphone still
uses the last known working (now really old) version of it.

On 03/16/2013 05:42 PM, Alex M (Coyo) wrote:
> I apologize if this has been covered prior to this thread creation, but....
> 
> Is it possible to multiplex SIP and RTP/RTCP on a common port?
> 
> Might it additionally be possible to multiplex multiple RTP sessions on
> a common port along with the SIP control channel?
> 
> I realize that SIP is supposed to be a text-only and human-readable
> control protocol, but if we're using socks bytestream proxies and such
> on a server in a datacenter anyway, why not simplify it all, and run it
> over the same udp port, since it's not like we want anyone other than
> the participants and/or server admins observing the datastreams anyway?
> 
> Sure, we could use DTLS and ZRTP to preserve user privacy, but if we're
> already doing that, then what's the big deal with ensuring the protocol
> is human-readable? Once the telecommunications companies were done with
> SIP, it was no longer a simple protocol to implement.
> 
> Since we're using common libraries, and encrypting the datastreams, it
> seems to me that human-readability is no longer a valid concern. You can
> always use a debugging console if you wish to observe the content of SIP
> control channels and/or media channels, so why not?
> 
> Thank you in advance for spending valuable time, attention, and effort
> for reading and/or responding to this question. I do acknowledge the
> dispensation on my behalf, and it is appreciated.
>

dyfet.vcf
Description: Vcard