Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ...

[Cullen Jennings <fluffy at cisco.com>]

On Aug 8, 2006, at 7:38 AM, Rohan Mahy wrote:

> We had a very long discussion in Montreal about discovery and  
> validation of a SIP outbound proxy server's ability to receive STUN  
> requests.  While the vast majority of the room was comfortable that  
> "keepalive=stun" in a URI was a sufficient indicator that an  
> outbound proxy supports SIP and STUN over the same port, a small  
> but extremely vocal minority had significant problems with this  
> assumption.

Just so we are clear on the when this could be a problem....

For any UA that is automatically configured, this is unlikely to  
every be a problem. What we are talking about here is UA where some  
human types in the configuration information to the UA. Even though  
they were told to enter example.com as the outbound proxy, they  
decide to enter example.com;keep-alice=stun because perhaps they saw  
that in some other system. Their device sends a stun packet and gets  
black listed. Note that any services that blacklists after receiving  
a single STUN packet with a spoofed IP address is going to be trivial  
to totally DOS so I don't believe this sort of thing will deploy buts  
let continue down this case. So the user UA does not work. It also  
would not have worked if they typed in elpmaxe.com (example  
backwards). What do they do? read a web page, phone tech support, I  
have no idea but they do whatever they do when they configure the  
outbound proxy information correction. Eventually they find out to  
remove the keep-alive=stun and their phone starts working.

For these reasons, I don't think this whole problem is not a huge  
deal. However, if people do think it is a big deal, the obvious  
solution to it is send and OPTIONS message to find out if the server  
supports this.  Most people don't seem to think this is enough of a  
problem to warrant and additional RTT when a UA boots. We can come up  
with other possible solutions to this too (as there are at least  
three others on this same thread).

The meta question is simple - we had pretty strong consensus on this  
in the meeting. How long do we really want to spend delaying this  
draft to find alternative solutions to this problem. Clearly the  
answer different based on how serious a problem you think it is.

It would be really great if the authors, chairs, and people that feel  
strongly could have a conference call on this.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip