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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Jun 2006 09:01:01 +0200

Hi,

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.

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.

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.

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.

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

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.

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.

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.

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.

Regards,

Christer 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: 28. kesäkuuta 2006 2:03
To: IETF SIP List; Rohan Mahy; Cullen Jennings
Subject: [Sip] Ready for WGLC on Outbound?

Rohan said:

> I'll be on the hook for any outbound-related issues, but AFAIK there 
> are no open issues.  The draft has incorporated all the comments we 
> received.

So if there are no open issues, are we ready for working group last call?

--
Dean

_______________________________________________
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

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Wed, 28 Jun 2006 22:03:30 -0700

Hi Christer,

On Jun 28, 2006, at 0:01, Christer Holmberg ((JO/LMF)) wrote:
> Hi,
>
> 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.
>

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.

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

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

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

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

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.

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

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

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

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

thanks,
-rohan

> 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:04:10 +0300

Hi,

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

I would like to point out two emails in the thread where this
"max-flow" issue was discussed:

http://www1.ietf.org/mail-archive/web/sip/current/msg14745.html
http://www1.ietf.org/mail-archive/web/sip/current/msg14753.html

In that thread a solution was outlined as follows:

"Network must provide max-flows in Register response.
 Client must not exceed max-flows when establishing flows.
 Client should attempt to equal max-flows if terminal capabilities
allows."

To me this sounds a good idea due to the following facts:

- Instead of explicit configuration the UA might find the
  proxies supporting outbound e.g. from DNS

- The number of proxies configured in DNS does not necessarily
  equal to the number of flows the UA should set up. For instance
  the service provider might have there many proxies to do load
  balancing but targets to have reliability on other means than
  the UAs maintaining multiple flows.

Thus I was also expecting the proposed a solution to appear in
outbound-04 (or later version). In sip-outbound-discovery-02
there is text like this:

   Whether the UA actually sets up one single flow or two redundant
   flows, is determined in the following ways:

   o  When the network responds to the primary REGISTER with 200 OK, the
      response may contain an indication telling the maximum number of
      flows the network expects the UA to use.  The UA SHOULD create two
      flows if the indicated value is at least two or if the network
      does not give the indication at all.  [[OPEN: the details of this
      indication are still to be defined but are not in scope of this
      spec]]

I have not seen any serious comments given why this could
not be specified like proposed and would thus vote for 
adding it to outbound -05.

Regards,

Erkki
____________________________________

  Erkki Koivusalo
  Nokia Mobile Software
  tel:+358 40 7571197
  mailto:[email-masked]
____________________________________

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 29 Jun 2006 10:04:46 -0700

Erkki,

I can think of a number of ways to make this work where the intended 
semantics are entirely embedded in DNS.  Alternatively you can discover 
*candidate* outbound-proxy-URIs via DNS and use a max-flows value 
configured/discovered elsewhere to decide how to derive/self-configure 
the actually outbound-proxy-set.

As a scope issue, the chairs (previous and current) and the ADs (at the 
time still Allison and Jon) directed the editors to make outbound 
separate from gruu, initial proxy discovery/configuration, and 
specification of record-routing behavior for high reliability and 
per-call state cookies.  We then had WG consensus on this approach. I 
think that was a wise choice, and I fear that adding new parameters now 
will only unwind that consensus.

thanks,
-rohan

---

From: <[email-masked]>
Date: Fri, 30 Jun 2006 08:55:01 +0300

Hi Rohan,

>Alternatively you can discover 
>configured elsewhere to decide how to derive/self-configure 

Max-flows manually configured to the UA is what I already 
have in sip-outbound-discovery. There were just some
suggestions that it would be useful to be able to
autoconfigure this parameter, too.

>I can think of a number of ways to make this work where 
>the intended semantics are entirely embedded in DNS. 

If you have any ideas like that, could you please pass them
to me since I am working on a related I-D where no such ideas
have been introduced. I would be happy to receive those to be
able to check if they work with the rest of the DNS scheme
currently proposed. If yes, I could take them into my draft.

Thanks,

Erkki 

>From: ext Rohan Mahy [mailto:[email-masked]] 
>Sent: 29.June.2006 20:05
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; Rohan Mahy; [email-masked]
>Subject: Re: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER
>
>Erkki,
>