Subject: Re: [SIP] NAT, SOCKS 5 proxies, win proxies

From: John Lazzaro <[email-masked]>
Date: Thu, 8 Feb 2001 17:00:12 -0800

[email-masked] writes:
> a) SIP and RTP should be able to work from a single UDP port.

This basic idea can work -- sooner or later I hope to write up
a SIP B2BUA I've implemented for multi-party conference 
initialization that takes this route, mostly following the
"Activision" techniques described in the recent "Protocol
Complications with NAT" RFC. The ugliest aspect of this is
that unless you also want to multiplex RTP and RTCP on the
same UDP port, you need to have parallel SIP sessions going
on two ports, on for the RTP port and one for the RTCP port.
In my SDP-specific implementation for the B2BUA, the NAT
information specified in the Activision algorithm gets 
embedded in SDP fmt lines by the SIP conference server,
which is another ugly aspect ... although I believe that
if the received tag for Via was a hostport, you might be able
to legally embed this NAT information in the SIP itself.

However, I think there's a big difference between "it can
be made to work" and "everyone should do it" -- using the
OS to do multiplexing is a pretty key concept in ALF, and
when you ignore it all sorts of bad things result.
One that immediately comes to mind -- you can't connect()
the socket on the client if you're using the Activision
algorithm in the multi-party case, since you're using the
same socket to send RTP to several parties, as well as 
the SIP conference B2BUA. The result is, you can't get
ICMP feedback to tell if you're UDP packets aren't being
listened to, and need to use timeouts exclusively ...

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.