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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 30 Jun 2006 12:25:42 +0200

Hi Rohan, 

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

[CHH] Again, RFC3489bis defines a STUN keepalive usage, and we shall
describe how it's implemented in SIP. I see no reason why outbound
should define a mechanism for using STUN for keepalive with outbound,
and then we may later define how to use STUN for keepalive with some
other extension. We should have one generic mechanism, and I should be
able to use STUN for keepalive without having to use the rest of the
outbound stuff.

As part of the "[Sip]Outbound:keep-alive,outbound and 3489bis" thread
Jonathan also said:

"I think we should allow the STUN keepalives without the rest of the
stuff. Its a handy tool for inter-server keepalives in cases where there
are no NAT or firewalls.

-Jonathan R." [/CHH]

>>[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]
>OK, I will change this to something like: "This document uses the STUN
connectivity check usage [ref] for connectivity checks over the SIP
flow."

[CHH] "...and defines how to use/implement the STUN NAT keepalive usage
[ref] with SIP". [/CHH]

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

[CHH] The issue is that you talk about "configured URIs". No matter HOW
the configuration is done, to me this sounds like the URI is provided to
the client somehow (manually or automatically). BUT, what may be
configured is only an IP address. The client can then use that
information to GENERATE a SIP-URI, but that generated SIP-URI is not
necessairly what was "configured", or given as "input" to the client.

So, I do think we are talking about the same thing. I am just saying
that the "configured URI" wording is a little unclear. [/CHH]

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

[CHH] The SIP stack in the client acts on each SIP-URI, which it has
generated based on configured information (which very well be that
SIP-URI, but also maybe just a domain name, or IP address...) 

We don't necessarily need to replace the current wording - I am just
asking for clarification text. [/CHH]

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

[CHH] Well, that's your opinion - I am sure there are people having
other opinions :) In any case, that is an implementation issue, so we
don't need to argue about that.

AND, earlier I HAVE proposed that manual configuration of a SIP-URI
would be the "default" mechanism, which one must implement, unless there
is another mechanism. [/CHH]

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

[CHH] I am not really sure I understand... All I am asking is for a
clarification saying that the SIP-URI may not be what is "provided"
(manually or automatically) to the client as part of the
"configuration". The SIP-URI is what the client generates from whatever
configuration input it gets (e.g. using the P-CSCF discovery mechanism
in 3GPP), and uses it for generating Route headers etc. I don't see
anything strange or controversial in that... 

Chapter 4.2 says:

"UAs obtain at configuration time one or more SIP URIs representing the
default outbound-proxy-set."

Maybe it's my english, but to me this sounds like the SIP-URI is
actually what is given, from whatever external source, as input to the
client. [/CHH]

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

[CHH] All I want is an indication saying that the OUTBOUND MECHANISM can
be used with systems where a single flow is enough to provide
reliability. I do NOT want to define a new "outbound" mechanism for
those systems, and I see no reason why I should have to write a draft to
describe such systems... [/CHH]

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

[CHH] It has been discussed... 

I have also said that, unless the client KNOWS (that is one of the
reasons why the "max-flow" indicator would be useful) it is
communicating with such system, it SHALL register at least 2 (or
whatever the number is at the moment) flows. So, again, I am NOT trying
to change the basic ideas behind outbound, of which one is to provide
reliability. I am simply saying that there may be systems where a single
flow is enough to provide that reliability. 

You say the draft does not forbid the usage in such systems - I am
saying that the draft doesn't indicate that clear enough :) [/CHH]

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

[CHH] Like I said earlier, it seems like we agree on the technical
issue, i.e. you are allowed to have a system where e.g. only the IP
address of the ege proxy is provided (using whatever mechanism) to the
client - do we agree on that? [/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]
>You are talking about something new.  If you want to define this new
thing, please write a draft.

[CHH] What is "new" and what is "old"??? Since we are working on the
draft, aren't we allowed to add stuff to it???  Also, when this was
discussed (see Erikki's mail) I think it was considered that this would
be a useful addition - at least there were no objections. [/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: Cullen Jennings <[email-masked]>
Date: Fri, 30 Jun 2006 09:59:14 -0700

> stuff. Its a handy tool for inter-server keepalives in cases where  

I agree with this too. The question is how to get to easily get to  
this. If the answer is a separate document, by all means nothing in  
outbound stops a separate document from doing this.