Subject: [Sip] Outbound: Stunning who?

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Jul 2006 23:16:42 -0400

I was chatting with folks about this debate on when it is okay to 
send STUN messages.
An interesting point was raised.

In describing the STUN processing (section 7.1) the draft says "When 
a URI is created that refers to a SIP device that supports STUN as 
described in this section, the keepalive URI parameter, as defined in 
Section 10 MUST be added to the URI, with a value of 'stun'.  This 
allows a UA to inspect the URI to decide if it should attempt to send 
STUN requests to this location."
Presumably, the URI under discussion here is the same URI as 
discussed earlier, namely the sip URI of the outbound proxy.  This is 
consistent with the discussion on the list about the use of 
supported: outbound indicating support for STUN.  supported: outbound 
is put in a response by the outbound proxy (registrar.)

However, the document is quite clear that a normal deployment is one 
with an edge proxy between the UAC and the outbound proxy.  If I 
understand right, the outbound proxy URI points to the outbound 
proxy, not the edge proxy.  And the supported header is put on by the 
outbound proxy, not the edge proxy.

The only problem is that if the UAC sends STUN packets, in the 
presence of an edge proxy, those STUN packets will be addressed to, 
and (if they arrive) be consumed by the edge proxy.  In other words, 
the entity which needs to support STUN is not the entity identified 
by the URI with the keepalive=stun parameter, nor is it the entity 
which placed the support: outbound in the header.  Whatever one 
thinks about the safety of sending STUN based on a configured 
parameter, that configuration ought to relate to the server to which 
the STUN is being sent.

As far as I can tell, the desire for and verification of STUN usage 
ought to be a matter between the UAC and the edge proxy, and ought 
not be tied up with the outbound URI or the behavior of the outbound proxy.

Feel free to tell me I have missed the point,
Joel

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 11 Jul 2006 09:28:15 +0200

Joel,

see inline

Regards,

Jeroen

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 11, 2006 5:16 AM
Subject: [Sip] Outbound: Stunning who?

>I was chatting with folks about this debate on when it is okay to send STUN 
>messages.
> In describing the STUN processing (section 7.1) the draft says "When a URI 
> is created that refers to a SIP device that supports STUN as described in 
> this section, the keepalive URI parameter, as defined in Section 10 MUST 
> be added to the URI, with a value of 'stun'.  This allows a UA to inspect 
> the URI to decide if it should attempt to send STUN requests to this 
> location."
> Presumably, the URI under discussion here is the same URI as discussed 
> earlier, namely the sip URI of the outbound proxy.  This is consistent 
> with the discussion on the list about the use of supported: outbound 
> indicating support for STUN.  supported: outbound is put in a response by 
> the outbound proxy (registrar.)
>
> However, the document is quite clear that a normal deployment is one with 
> an edge proxy between the UAC and the outbound proxy.  If I understand 
> right, the outbound proxy URI points to the outbound proxy, not the edge 
> proxy.  And the supported header is put on by the outbound proxy, not the 
> edge proxy.
>

An "outbound proxy URI" would refer to the outbound proxy, which can be 
either an edge proxy or a "home proxy" (ie the proxy associated with the 
registrar). The URI that is being talked about in section 7.1 refers to a 
"SIP device [...] as describe in this section", which "include a Registrar 
and an Edge proxy". It purposefully leaves both options open.

Interestingly, early drafts of RFC3263 defined an "outbound proxy" as "a 
specific server, independent of the URI", but the term was removed from the 
final version of that RFC.

Section 2.1 of the outbound draft should really include a definition of 
"outbound proxy", but the intention is that it can mean both depending on 
deployment. The supported header is inserted by the *registrar*, which is 
(associated with) the outbound proxy if there are no edge proxies.

I think for clarity, we should also come up with a term for the "proxy 
associated with the registrar" (and add that to section 2.1 too)

> The only problem is that if the UAC sends STUN packets, in the presence of 
> an edge proxy, those STUN packets will be addressed to, and (if they 
> arrive) be consumed by the edge proxy.  In other words, the entity which 
> needs to support STUN is not the entity identified by the URI with the 
> keepalive=stun parameter, nor is it the entity which placed the support: 
> outbound in the header.  Whatever one thinks about the safety of sending 
> STUN based on a configured parameter, that configuration ought to relate 
> to the server to which the STUN is being sent.
>
> As far as I can tell, the desire for and verification of STUN usage ought 
> to be a matter between the UAC and the edge proxy, and ought not be tied 
> up with the outbound URI or the behavior of the outbound proxy.
>

Edge proxies *are* outbound proxies, the "home proxy" is the outbound proxy 
when there are no edge proxies

---

From: David R Oran <[email-masked]>
Date: Tue, 11 Jul 2006 07:21:22 -0400

> see inline
[snip]
>> presence of an edge proxy, those STUN packets will be addressed  
>> to, and (if they arrive) be consumed by the edge proxy.  In other  
>> words, the entity which needs to support STUN is not the entity  
>> identified by the URI with the keepalive=stun parameter, nor is it  
>> the entity which placed the support: outbound in the header.   
>> Whatever one thinks about the safety of sending STUN based on a  
>> configured parameter, that configuration ought to relate to the  
>> server to which the STUN is being sent.
>>
>> As far as I can tell, the desire for and verification of STUN  
>> usage ought to be a matter between the UAC and the edge proxy, and  
>> ought not be tied up with the outbound URI or the behavior of the  
>> outbound proxy.
>>
>
> Edge proxies *are* outbound proxies, the "home proxy" is the  
> outbound proxy when there are no edge proxies
>
Needless to say, I find this incredibly confusing. It's clear Joel  
does too. I wonder how many other people are wandering around in this  
maze as badly as I am.

I thought this whole effort was about managing transport connections  
from UAs to the "SIP cloud" such that the user doesn't lose service  
because SIP routing can't figure out how to get requests destined for  
the UA to the proxy that happens to have the transport connection to  
the UA at this moment.

If I'm misinformed on this, I suspect some other folks are too.

>> Feel free to tell me I have missed the point,
If you missed the point, I missed the point...

I'll quickly comment that when I looked over outbound again last  
night, I got the distinct impression that MOST of the complexity is  
due to trying to solve one particular use case - the UA wants to  
maintain transport connections to proxies in different domains and be  
able to receive calls whichever of the connections (and hence  
whichever of those doimains) happens to be working.

I once worked out a pretty simple scheme (at least one I think is  
much simpler than outbound) for the case where all that's needed is  
redundant transport connectivity to the UA from proxies in the same  
edge proxy farm. (I described this to Dean late last night and I  
think he got it, so maybe there's somebody else who shared my  
hallucination here).

Dave Oran.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Jul 2006 08:07:36 -0400

Your description below of the entities involved, and of the outbound 
proxy being an edge proxy or a home proxy is technically correct.  An 
Outbound proxy may be an edge proxy.  But as I read the document, 
there may be an edge proxy which is not an outbound proxy in between.

The draft talks about the outbound set, and about the registration 
being targeted at the elements of the outbound set.
As such, the elements of the outbound set (the outbound proxies, the 
URIs that are known to the UAC) are clearly the registrars.  The 
draft explicitly introduces the notion that the edge proxy may be 
between the UAC and the registrar.  The registrar is the entity who 
fills in supported: outbound.  Not edge proxy.

It is true that the definitions section states that the outbound 
proxy set are the proxies with which the UAC will attempt to maintain 
a direct flow.  But it states that these are "often Edge 
Proxies".  Presumably, they are sometimes not edge proxies.  When 
they are not edge proxies, there presumably is an edge proxy between 
the UAC and the outbound proxy.

The whole wording makes it clear that one registers with the elements 
of the outbound set.

Yours,
Joel M. Halpern

PS: If Outbound is really supposed to be about finding and using the 
first proxy, rather than the registrar, then that proxy ought to be 
the one that has to support outbound.  Alternatively (and more 
usefully), the mechanisms for supporting STUN ought to be tied to 
ones first proxy, rather than to ones registrar, while outbound talks 
about finding and talking to suitable registrars.

At 03:28 AM 7/11/2006, Jeroen van Bemmel wrote:
>Joel,
>
>see inline
>
>Regards,
>
>Jeroen
>
>----- Original Message ----- From: "Joel M. Halpern" <[email-masked]>
>To: <[email-masked]>
>>In describing the STUN processing (section 7.1) the draft says 
>>"When a URI is created that refers to a SIP device that supports 
>>STUN as described in this section, the keepalive URI parameter, as 
>>defined in Section 10 MUST be added to the URI, with a value of 
>>'stun'.  This allows a UA to inspect the URI to decide if it should 
>>attempt to send STUN requests to this location."
>>discussed earlier, namely the sip URI of the outbound proxy.  This 
>>is consistent with the discussion on the list about the use of 
>>supported: outbound indicating support for STUN.  supported: 
>>outbound is put in a response by the outbound proxy (registrar.)
>>
>>However, the document is quite clear that a normal deployment is 
>>one with an edge proxy between the UAC and the outbound proxy.  If 
>>I understand right, the outbound proxy URI points to the outbound 
>>proxy, not the edge proxy.  And the supported header is put on by 
>>the outbound proxy, not the edge proxy.
>
>An "outbound proxy URI" would refer to the outbound proxy, which can 
>be either an edge proxy or a "home proxy" (ie the proxy associated 
>with the registrar). The URI that is being talked about in section 
>7.1 refers to a "SIP device [...] as describe in this section", 
>which "include a Registrar and an Edge proxy". It purposefully 
>leaves both options open.
>
>Interestingly, early drafts of RFC3263 defined an "outbound proxy" 
>as "a specific server, independent of the URI", but the term was 
>removed from the final version of that RFC.
>
>Section 2.1 of the outbound draft should really include a definition 
>of "outbound proxy", but the intention is that it can mean both 
>depending on deployment. The supported header is inserted by the 
>*registrar*, which is (associated with) the outbound proxy if there 
>are no edge proxies.
>
>I think for clarity, we should also come up with a term for the 
>"proxy associated with the registrar" (and add that to section 2.1 too)
>
>>and (if they arrive) be consumed by the edge proxy.  In other 
>>the entity which placed the support: outbound in the 
>>header.  Whatever one thinks about the safety of sending STUN based 
>>on a configured parameter, that configuration ought to relate to 
>>the server to which the STUN is being sent.
>>