Subject: RE: [Sip] Ready for WGLC on Outbound?

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

Hi Rohan,

Thanks for your reply! Comments inline. 

> Unfortunately, I don't think all issues have been addressed yet. There

> are a number of issues we've been discussing on e-mail, and on some I 
> think we have even reached agreements.
>
>
> FIRST, the issue I raised in the "Outbound: keep-alive, outbound and 
> 3489bis" thread has not been issued. STUN NAT keep-alive is nowadays a

> "core" STUN usage - not something specific to the outbound mechanism.
> We need to separate them, because it should be possible to use STUN 
> for keep-alive without using the rest of outbound (instance-id, flow 
> etc etc).
>
> Chapter 4.2 says:
>
> "The UAC MAY examine successful registrations for the presence of an 
> 'outbound' option-tag in a Supported header field value.  Presence of 
> this option-tag indicates that the registrar is compliant with this 
> specification.
>
> Again, that is not true if I only support STUN for NAT keep-alive, but

> not the rest of outbound.

>No, if you indicate support for the option tag, you support all the
MUSTs in outbound.  If you just want to support STUN 
>muxed on the same port as SIP, you can indicate that you do that by
adding the 
>keepalive=stun URI parameter.   Outbound defines the semantics of this.

[CHH] Perhaps, but I don't think it's clearly indicated that the STUN
NAT keep-alive can be used as a "stand alone" feature. I don't think
much text is needed for that. I also think that the scope of the
document clearly shall say that the document defines how to use the STUN
keep-alive (and also, as I mention futher down, the connectivity check)
usage, as defined in 3489bis, for SIP. [/CHH]

>This is just like RFC 3265 which happens to define the 202 Accepted
response code.  It doesn't mean I need to implement 
>all of RFC 3265 to implement 202 (It even referenced this way in
MESSAGE).
>
>Now, one COULD of course claim that the generic SIP usage of STUN for 
>NAT keep-alive shall be described in a SEPARATE document, and that the 
>outbound spec ONLY describes the STUN keep-alive when used TOGETHER 
>with outbound. BUT, if that is the case the "keepalive" URI parameter 
>should not be defined in the outbound draft - it should be defined in 
>that generic SIP STUN keep-alive usage draft (I ASSUME that we would 
>use the "keepalive" parameter also when we use STUN keep-alive without 
>outbound". Also, the text on STUN processing etc should also be 
>described in the generic draft in that case, because it's not outbound 
>specific.
>
>there is no milestone for a spec for STUN keepalives, and no
groundswell of support for a separate draft.  We have 
>consensus to go forward with STUN keepalives described in outbound
because outbound needs it.  If you happen to want a 
>little piece of outbound, you can still implement it.  You just don't
have a separate shiny RFC number to tell people 
>you've implemented.  You can still reference the description of the
parameter in the IANA registry (which will have a 
>description of the semantics once outbound is published).

[CHH] I have no problem with keeping the STUN keep-alive stuff in the
outbound draft. Again, what I am asking for is to more clearly separate
it, as a stand alone feature, from the rest of the outbound stuff. Of
course we can say that the support of outbound requires the support of
STUN keep-alive. [/CHH]

>Also, since STUN keep-alive is now a core STUN usage, I wonder if we 
>can remove the note in chapter 3.5. Because, again, this draft shall 
>not define the keep-alive mechanism - it is already defined in 
>3489bis.
>
>outbound defines what a STUN client is supposed to do when the
keepalives fail, how fast to backoff, and what to do if 
>the binding response XOR-MAPPED-ADDRESS is different from the address
the client had previously.  There is a lot of 
>behavior here that is not and should not be in 3489bis.

[CHH] I totally agree with you. 3489bis defiens the STUN keep-alive
usage, and the outbound draft describes how to "adopt" it with SIP. And,
that is what I think should be more clear in the spec. The outbound
draft does not define the usage of STUN for keep-alive as such, only how
to use it for SIP. The outbound draft DOES refer to 3489bis, but it does
not mention the USAGE defined ni 3489bis.

Related to that, chapter 7.1 says: "This document defines a new STUN
usage for connectivity checks." Again, this usage is already defined in
3489bis (chapter 12.3), so we only need to adopt it to SIP. [/CHH]

>>SECOND, the draft talks about the outbound proxy URIs configured in 
>>the client. I think we agreed that configured URIs are ok as 
>>"default", but I think we should say that the client may also retreive

>>the proxy address using other mechanisms (e.g. something similar to 
>>the P-CSCF discovery mechanism in IMS). I don't think we need to talk 
>>about "additional mechanisms" that may be defined in the future 
>>(chapter 4.2): we simply say that other mechanisms are outside of the 
>>scope of this document.
>>
>>From Section 4.2:
>>UAs obtain at configuration time one or more SIP URIs representing the

>>default outbound-proxy-set. This specification assumes the set is 
>>determined via any of a number of configuration mechanisms and future 
>>specifications may define additional mechanisms such as using DNS to 
>>discover this set. How the UA is configured is outside the scope of 
>>this specification.
>
>Everything you mentioned is covered by the previous two sentences.  A
P-CSCF discovery mechanism is already allowed.

[CHH] I still don't understand why normative text should talk about the
future... 

Also, the issue is that what may be configured (no matter how you
configure it) may not be a URI. It may simply be an IP address/FQDN,
which is then used to build a SIP-URI. I think we shall allow that, and
make it more clear in the spec. [/CHH]

>>THIRD, I think we agreed that there may be other ways of providing a 
>>reliable system
>>
>>Chapter 3.3 says:
>>
>>"There are various ways to deploy SIP to build a reliable and scalable

>>system.  This section discusses one such design that is possible with 
>>the mechanisms in this specification.  Other designs are also 
>>possible."
>
>>To make it more clear I think it should say:
>
>>"Other designs, where multiple registrations/flows are not required, 
>>are also possible."
>
>The existing text is *an* example and fully acknowledges you can build
other reliable systems.
>I also think the existing text is much clearer that your proposed text.

[CHH] So, what text do you think clearly says that there may be
scenarios where only a single flow can be used? Just saying that one
chapter describes *an* example doesn't make that clear.

Also, "Other designs" sounds to me like using mechanisms that are not
defined "in this specification", which is not correct. Even if you only
register a single flow you would use the mechanism "in this
specification". [/CHH]

>>FOURTH, related to the second and third issue, chapter 4.2 says:
>>
>>"For each outbound proxy URI in the set, the UA MUST send a REGISTER 
>>in the normal way using this URI as the default outbound proxy."
>>
>>Again, there may be other ways to provide reliability.
>>
>>And, shall it really be mandatory to register to ALL URIs? In issue 
>>seven I talk about the "max-flow" indicator we've been discussing on 
>>the list.
>
>If you don't want to register ALL the URIs you can think of, only
configure (by the definition above) the UAC with the 
>URIs you want registered.

[CHH] Again, you may not always configure the edge proxies "manually".
You may use a separate discovery mechanism. And, that discovery
mechanism may, for different reasons, provide a list of edge proxies,
but that doesn't mean that you always want to register to all of them at
the same time. [/CHH]

>>FIFTH, related to the second, third and fourth issues, we discussed 
>>that that the network should be able to provide a "max-flow" number to

>>the client.
>>
>the maximum number of flows is the number of outbound-proxy-set URIs.  
>If you want to come up with another piece of configuration data (by the
very broad definition of configuration we are 
>using) that is a set of candidate URIs for the outbound-proxy-set which
are chosen at random up to some maximum to form 
>the outbound-proxy-set, you are free to do so.

[CHH] I am not talking about new configuration data, but a value that
could be returned (in the registration response) by the network to the
client, indicating how many flows to configure. The client then does not
need to try to register more flows, if the network isn't going to accept
them anyway. [/CHH] 

>>SIXTH, one issue we've recently been discussing is what an edge proxy 
>>does if it receives "keepalive=stun", but it doesn't support STUN. I 
>>think we need to say something. I don't think we should just call it 
>>an error case, and therefor it is "an implementation issue" how to 
>>handle it.
>
>We can't define rules in an extension for proxies that don't support
that extension.  The proxy will do whatever it does 
>during this misconfigured case, consistent with RFC3261.
>
>>SEVENTH, related to the first issue, chapter 4.2 says:
>>
>>"Forming the route set for the request is outside the scope of this 
>>document, but typically results in sending the REGISTER such that the 
>>topmost Route header field contains a loose route to the outbound 
>>proxy URI. Other issues related to outbound route construction are 
>>discussed..."
>>
>>Maybe I just missunderstand that text, but IF we use an URI parameter 
>>to indicate STUN NAT keep-alive I think there MUST be a Route header 
>>to the outbound proxy URI.
>>
>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.

[CHH] If that is true, what is wrong with the client using the Supported
header (Supported: keepalive) to indicate that? 

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]

Regards,

Christer

_______________________________________________
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: <[email-masked]>
Date: Thu, 29 Jun 2006 10:36:13 +0300

Hi,

>>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. 

>STUN or not, BEFORE the client starts sending STUN requests and figures

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

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 29 Jun 2006 09:44:14 -0700

Hi,

> course we can say that the support of outbound requires the support of

I don't see why you need a separate section in the draft when you can 
point at the IANA registry.  Besides, defining a standalone description 
of STUN keepalives was never a requirement motivating this work.

> 3489bis (chapter 12.3), so we only need to adopt it to SIP. [/CHH]

OK, I will change this to something like: "This document uses the STUN 
connectivity check usage [ref] for connectivity checks over the SIP 
flow."

> make it more clear in the spec. [/CHH]

the outbound spec defines a piece of configurable data (the 
'outbound-proxy-set'), which is a list of URIs.  This list of URIs may 
never have a one-to-one correspondence to a user or administrator 
manually configurable field.  That piece of configurable data may be 
derived from several fields, manually configurable, discovered via 
DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP 
download, or via a random character generator seeded by the phase of 
the moon.

The outbound-proxy-set was defined as a list of URIs because the UA 
acts on each item in the list, because each URI is expected to be 
places in a Route header, and because each URI is expected to typically 
have a keepalive URI parameter in it.

What you want is already allowed, but the most straightforward, logical 
thing for a UA designer to do is to make the outbound-proxy-set 
manually and automatically configurable. It would be a disservice to 
the community to clog up the draft with text describing things you are 
already allowed to do, unless we have strong motivations, use-cases, 
and requirements.  We have none of these, but if you feel strongly 
enough to write an informative draft that reminds implementors of all 
the things they are allowed to do in this context and provides 
motivations and requirements, go for it.  But that would be a future 
draft.

> register a single flow you would use the mechanism "in this

Christer, the IETF model of specifications is that you can do anything 
you like as long as you implement the normative parts of the 
specification.  If you want to implement a reliable system that just 
use one flow, just go and implement it.  If you want to describe a 
reliable system that uses one flow, write a draft to describe it.

Micro-editing non-normative language to more explicitly allow for 
reliability (or other) schemes that have not been discussed and have no 
requirements is contrary to the charter of this WG.

> but that doesn't mean that you always want to register to all of them 

Christer, you seem to be missing the definition of configure.  As a lay 
definition, lets use the following: Configure means to cause a piece of 
non-per-call, non-per-dialog state to be set.  Manual configuration is 
only one mechanism of configuration.  This is consistent with the SIP 
configuration framework (draft-ietf-sipping-config-framework) which 
explicitly includes DHCP, DNS, downloaded files, and manual 
configuration.

In other words, the discovery mechanism you mention is already a 
configuration mechanism and always has been.

The text does not need to change, because the text is consistent with 
the definitions used in a SIPPING WG document.  We came to a consensus 
on this definition both there and in the SIP WG.

> need to try to register more flows, if the network isn't going to 

You are talking about something new.  If you want to define this new 
thing, please write a draft.

> header (Supported: keepalive) to indicate that?

The Supported header is really irrelevant since the proxy or UAS could 
receive either a STUN request or a SIP message in any order.  Since the 
proxy or UAS needs to receive a STUN request before it ever receives a 
SIP request, the SIP Supported header would just bloat the SIP message. 
  The SIP message will also often be carried to several other SIP nodes 
before arriving at the UAS.  Only the first hop cared.

> STUN or not, BEFORE the client starts sending STUN requests and figures

This isn't necessary to implement the draft now.  The mechanism you 
describe is sufficiently complicated in the details that I would 
recommend writing a draft about it.  I actually like this idea, but it 
could be complex and there is a slight chance that it won't work.  
Nothing in outbound will prevent what you've described.

thanks,
-rohan

---

From: <[email-masked]>
Date: Fri, 30 Jun 2006 09:10:51 +0300

Hi Rohan,

>> which is then used to build a SIP-URI. I think we shall 
>> allow that, and make it more clear in the spec. [/CHH]
>
>places in a Route header, and because each URI is expected to 
>typically have a keepalive URI parameter in it.

Like mentioned in other recent emails the problem is that if the UA
derives the proxy URI(s) from DHCP SIP server option or e.g. the AOR
of the user, in those cases the derived URI will NOT contain the
keepalive URI parameter in it. DHCP just returns IP addresses or
domain names instead of URIs with parameters.

Thus in those cases it would be critical for the UA to be able
to ensure in REGISTER - 200 OK sequence that the contacted proxy
supports Outbound and can handle STUN requests sent to its SIP
port (not to cause any damage to an uncompliant proxy). I fully
agree with this proposal from Jeroen:

--
The text should then say "the UAC MUST wait for a 200 OK to REGISTER
before 
it starts sending STUN packets. If the last Path header of the 200 OK
does 
not contain keepalive=stun, the UAC MUST NOT use STUN towards this URI.
If 
there are no Path headers and no "Supported: outbound", the UAC also
MUST 
NOT use STUN towards the registrar.". It could still use TCP keepalive
if it 
supports that
--

Please excuse me if I am just repeating myself and what e.g. Jeroen
has said but I believe the importance of this issue justifies some
redundancy :-)

Regards,

Erkki