Re: [Sip] Outbound Issues: slides 3 and 4

[Cullen Jennings <fluffy at cisco.com>]

Adding a bit more at bottom...

On Aug 8, 2006, at 1:02 PM, Dean Willis wrote:

> On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote:
>
> > The specific proposal works like this.  A UAC which has an  
> > outbound URI indicating with ;keepalive=stun that the next hop can  
> > support STUN messages on the SIP port, needs to verify the first  
> > hop supports STUN before sending any STUN messages. The UAC sends  
> > its first SIP message to the next hop with a Proxy-Require: sip- 
> > stun.  If the URI was correct (STUN was supported), and the first- 
> > hop is an intermediary, the first-hop removes the Proxy-Require  
> > and forwards the SIP request (probably a REGISTER request) along  
> > adding no additional delay.  A positive response to a REGISTER or  
> > OPTIONS with Supported: outbound and no error counts as positive  
> > confirmation that either the registrar supports STUN or expects to  
> > never receive a request without getting it from an outbound proxy  
> > which did not complain about the Proxy-Require [1]. If the UAC was  
> > misconfigured (the first-hop intermediary does not support STUN  
> > keepalives), either the first hop will reject the SIP request (if  
> > it is an intermediary), or the registrar will not include an  
> > indicator that it supports outbound (if the first hop was the  
> > registrar).
>
> Cullen suggested an alternate possibility that might work.
>
> I'll try and paraphrase:
>
> A UAC which has an outbound URI indicating with ;keepalive=stun  
> that the next hop can support STUN messages on the SIP port needs  
> to verify the first hop supports STUN before repeatedly sending  
> STUN messages.  The UAC may initially try sending STUN messages to  
> the SIP port of the first hop node. If the UAC does not receive a  
> correct STUN response (within some timer?)  then it must assume  
> that this mode does not support STUN, and proceed without using  
> STUN until it has some evidence that the first-hop node might have  
> changed, in which case it retries the STUN requests as per the  
> initial attempt.
>
> I think it's probably okay to stun a server a few times before  
> deciding it doesn't like being stunned -- after all, the primary  
> risk is one of slowing down service for the user doing the  
> stunning, not shutting down the server being stunned. What I object  
> to is a specification that says you go on stunning it indefinitely,  
> perhaps millions of times over the course of an association, with  
> no way to discover that you really shouldn't be stunning it.
>
> Set phasers on "stun", Mr. Sulu!
>
> --
> Dean


What I was trying to accomplish here was a solution that:

1) you don't send a STUN request until you receive a successful  
response to the register, this lets you know the device you are about  
to send a stun request to is "up"

2) you send a small number of stun requests and if you don't get any  
response, then you conclude that the server does not support stun and  
you stop stunning it

As I mention on another email in this thread, I don't think it will  
be practical to blacklist an IP after a single stun packet so I think  
this solution could probably work.

_______________________________________________
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