Subject: [SIP] NATs and firewalls: yet another approach?

From: Alberto Cuda <[email-masked]>
Date: Wed, 28 Feb 2001 15:19:32 +0100

Hi, 
I was looking for a workaround for the NAT/firewall
problem concerning RTP flows when the UA *knows* it
is not capable of creating a "good" SDP description.
In particular I was wondering if there's a way 
to avoid the deployment of a B2BUA and stick with a 
vanilla proxy. So the question is: what if UAs 
could "declare" in an header the address they'll need, 
in order to let SIP proxies allocate an address and 
return it to the sender? For instance, if "[email-masked]" 
wants to call "[email-masked]" the message flow could be:

[email-masked]    proxy.a.com        
      |                 |                
      |-------M1------->|                
      |<------M2--------|                
      |-------M3------->|                 

M1:
INVITE sip:[email-masked] SIP/2.0
...
Address-Request: 10.0.0.1:24445;transport=udp
...
c=IN IP4 10.0.0.1
...

M2:
SIP/2.0 4xx Address Needs Translation
...
Address-Request:
100.0.0.1:24445;transport=udp;map=163.162.3.19:1029;expires=3600
...

M3:
INVITE sip:[email-masked] SIP/2.0
...
Address-Request: 10.0.0.1:24445;transport=udp;map=163.162.3.19:1029
...
c=IN IP4 163.162.3.19
...

And so on. Of course this requires also a new request method 
to let the callee allocate its address[es] (it can't do it within
the INVITE transaction, because it can't receive a response from
the proxy). This new method could also be useful to reallocate the 
same addresses or if this operation requires some kind of
authentication. 

This SIP-extension should work even if the message body is not SDP, and
has
no side effects when one of the two peers does not understand it.
It works when there are one or more NATs and/or firewalls (if an RTP
proxy
is also deployed): it looks too good to be true. What I'm missing?

	Thanks in advance.
		Alberto.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor'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" in the body.