Subject: RE: [Sip] Outbound-04 and proxy indicating support for STUN keepalives

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 29 Jun 2006 10:16:03 +0200

Hi again Erkki,

I think we are talking about separate things. You talk about being able to make sure proxies support outbound, while I am talking about a way for a proxy to indicate that it supports STUN NAT keep-alive :)

Regards,

Christer

-----Original Message-----
From: Christer Holmberg (JO/LMF) 
Sent: 29. kesäkuuta 2006 11:12
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] Outbound-04 and proxy indicating support for STUN keepalives

Hi Erkki,

The problem with Proxy-Require (Proxy-Require: keepalive) is that it would require ALL proxies in the path to support STUN, and I don't think we want that.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 29. kesäkuuta 2006 10:36
To: Christer Holmberg (JO/LMF); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Sip] Outbound-04 and proxy indicating support for STUN keepalives

Hi,

>>No, you are missing the semantics of keepalive=stun.  It is a token 
>>which is used by the UAC/STUN client to know that it can mux STUN and 
>>SIP traffic. The STUN server/UAS or proxy does nothing with this 
>>parameter.  The server knows that the the client support STUN if it 
>>sends a STUN request.

>Also, as I asked in another mail: would it be possible for the STUN 
>server, by inserting the keepalive parameter in the Path URI, to 
>indicate that IT supports STUN?
>
>I see no harm in allowing the server to indicate whether it supports 
>STUN or not, BEFORE the client starts sending STUN requests and figures 
>it out itself... [/CHH]

The following email in my opinion describes very well the reasons why outbound would need a way within SIP signalling to indicate if the contacted proxy actually supports STUN keepalives or not:
http://www1.ietf.org/mail-archive/web/sip/current/msg13802.html

Another reason for the indication is that the UA might derive the outbound-proxy-set from a URI got from DHCP or AOR of the user. In those cases is is not possible to get any keepalive=stun token along with the URI.

It seems that outbound-04 does not provide a solution for this issue and would call for a related update. 

The thread from end of March with name RE: [Sip] How to indicate during proxy discovery that a proxysupports"outbound" contains an extensive discussion of the subject. In the end Jeroen van Bemmel outlined the possible solution like this:

>> "Proxy-Require: outbound" would mean that the proxy must support STUN

>> (i.e. expect it and send replies), Path and the generation/mapping of

>> flow identifiers.
>> "Require: outbound" would mean that the registrar must support STUN
and 
>> the mapping of flow identifiers
>>
>> I personally don't see any ambiguity here. So in my mind the UAC
would 
>> send
>>
>> REGISTER
>> Require: outbound
>> Proxy-Require: outbound
>> Supported: path
>> ....
>>
>> and if there is an edge proxy, it would remove only the Proxy-Require

>> header. The registrar would even be able to detect whether it should 
>> expect STUN requests (if there is still a Proxy-Require, it would be
a 
>> direct connection). However, I don't see why it would need to know
this.

Regards,

Erkki

_______________________________________________
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 29 Jun 2006 12:29:16 +0200

Hi Erikki, 

>>The problem with Proxy-Require (Proxy-Require: keepalive) is that it 
>>would require ALL proxies in the path to support STUN, and I don't 
>>think we want that.

>Not quite if it is done like Jeroen suggested:

>>> and if there is an edge proxy, it would remove only the 
>>> Proxy-Require header.

>I.e. just like Sec-Agree works.

[CHH] Ok, if you require the proxy closest to client to understand outbound I guess it would work, because it could then remove the option-tag from the Proxy-Require header. I guess it would also work for STUN keep-alive, IF the client requires the proxy closest to it to support STUN keep-alive.

However, if the client simply wants to know whether the proxy supports STUN or not, and continue no matter what, I guess we would need another solution. We can not use the Supported header, because it could be inserted by any proxy in the path, and if the proxy closest to the client does not support STUN it won't remove the option-tag from the Supported header.

>>I think we are talking about separate things. You talk about being able 
>>to make sure proxies support outbound, while I am talking about a way 
>>for a proxy to indicate that it supports STUN NAT keep-alive :)
>
>Right. Indicating support for outbound also covers support for STUN but if you have to indicate ONLY the STUN support you 
>would need something else than Proxy-Require: outbound.

[CHH] As I said, we COULD use Proxy-Require: stun-keepalive... or something like that.

But, I also proposed that one way for a proxy to indicate that it supports STUN keepalive would be that the proxy itself inserts the URI parameter in the Path URI - assuming it supports Path, of course.

Regards,

Christer

>The following email in my opinion describes very well the reasons why 
>outbound would need a way within SIP signalling to indicate if the 
>contacted proxy actually supports STUN keepalives or not:
>Another reason for the indication is that the UA might derive the 
>outbound-proxy-set from a URI got from DHCP or AOR of the user. In 
>those cases is is not possible to get any keepalive=stun token along 
>with the URI.
>
>The thread from end of March with name RE: [Sip] How to indicate during 
>proxy discovery that a proxysupports"outbound"
>contains an extensive discussion of the subject. In the end Jeroen van 
>Bemmel outlined the possible solution like this:
>