Subject: [Sip] A coment to draft-ietf-sip-outbound-04

From: Miguel Garcia <[email-masked]>
Date: Wed, 05 Jul 2006 13:44:48 +0300

Reading Section 4.2 of Outbound-04, there is a sentence that came to my 
attention.

    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.

I think it is not appropriate to use a MUST strength in this case. I 
suspect that the spirit of the draft is to offer high availability by 
making the UA to establish one flow per URI, which is a good spirit. 
However, one has to evaluate the cost of establishing one flow per URI, 
which might be quite high in terms of battery consumption, for example 
(due to STUN refreshes).

I also believe the MUST is misused here because it is not an absolute 
requirement for the specification. In other words, the SIP outbound 
procedures work OK even if the UA establishes just one flow (even when 
it is provisioned with several outbound URIs). Nothing is broken.

So, we should be looking at adding a paragraph that describes the 
benefit of establishing one flow per outbound URI, but letting up to the 
UA's policy to decide on the absolute number of established flows.

I would suggest to replace the above mentioned sentence with something 
around these lines:

    For each outbound proxy URI in the set, the UA MAY send a
    REGISTER in the normal way using this URI as the default outbound
    proxy. Sending one REGISTER per outbound proxy URI decreases the
    likelihood of interrupted service due to dropped connections at the
    cost of maintaining a living flow which each outbound proxy server.

Comments?

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Wed, 5 Jul 2006 14:19:22 +0300

> it is provisioned with several outbound URIs). Nothing is broken.

reliability may get broken.  wasn't this issue discussed already
earlier?  i remember that a conclusion was reached something along the
lines that the default is to establish at least two flows unless
instructed otherwise by the domain?

-- juha

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 05 Jul 2006 14:29:50 +0300

> instructed otherwise by the domain?

That is what I remember as well, but I don't recall any conclusion of 
"unless instructed otherwise by the domain". In otherwise, there is 
still some "magic" for the domain instructions.

But coming back to my point... I don't understand why there is a MUST 
here, because the protocol is not broken if the MUST is not followed.

/Miguel

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 5 Jul 2006 14:12:42 +0200

I agree with Miguel here

Outbound can be used for (at least) two things:
1) firewall/NAT traversal (especially for inbound requests)
2) high(er) reliability for registrations, by using multiple

These are separate use cases, it should be possible to do (1), (2) or both 
together (for example: I might be in a situation where there is no NAT, but 
I'd still like to use 2 registrations with different reg-ids). A MUST which 
forces an implementation to always do (2) makes it impossible to do only 
(1).

The abstract only talks about (1). The introduction talks mainly about (1), 
but mentions (2) in relation to flow failure (basically (2) is needed to 
overcome the window of max. 29 (UDP) or 120 (TCP) seconds it may take to 
detect a failed flow)

The benefit of (2) is highly dependent on the deployment environment and on 
the type of failures that occur. A UAC may set up 2 flows, but if both go 
through the same NAT device and this NAT device reboots, there may only be a 
benefit (in terms of period for which the UAC is not reachable) if the 
keep-alives for both flows are not too synchronized. It does help to 
maintain reachability in case one of the registrars (or edge proxies) 
reboots and looses its state

What I miss in the draft is discussion on the above aspects (i.e. 
synchronization of flow keep-alive timers, types of failures). A minimum of 
2 flows should IMO be RECOMMENDED (with explanation that this protects 
against single registrar / edge proxy failure, and reduces non-reachability 
to at most 15 (UDP) resp. 60 (TCP) seconds in case of NAT reboots, using the 
recommended timer values and provided the keep-alive timers are synchronized 
on half periods )

Note that for deployments where registrar failure is rare, one might decide 
to use only a single flow with half the keep-alive period. So if we go with 
the 'domain suggests number of flows", we should also include "domain 
suggests keep-alive timer periods"

Regards,

Jeroen

----- Original Message ----- 
From: "Miguel Garcia" <[email-masked]>
To: "Juha Heinanen" <[email-masked]>
Cc: <[email-masked]>; "Cullen Jennings" <[email-masked]>; "Rohan Mahy" 
<[email-masked]>
Sent: Wednesday, July 05, 2006 1:29 PM
Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04

>>  > requirement for the specification. In other words, the SIP outbound > 
>> procedures work OK even if the UA establishes just one flow (even when > 
> "unless instructed otherwise by the domain". In otherwise, there is still 
> some "magic" for the domain instructions.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 5 Jul 2006 07:48:59 -0700

My impression of what the WG wanted was that the service provider  
could provide between 1 and the max number the UA supported of URIs.  
The UA must implement support for at least 2 and should support 4.

So let's say that the domain use two and this domains has to have two  
do to reliability. If the UA has "local policy" and only decided to  
use one - things don't work. I think this is more or less the same as  
if you are doing a single registration and the registry tells you  
your registration expires after 1 hour but the UA decided to refresh  
after two hours to reduce network load, well things are broken.

Now you say that the UA might decide by local policy if it wanted to  
do say 1 or 2 flows - but where will this local policy come from? The  
end user is not going too provide it. I suspect the domain will  
provide it. I'm fine with some times the domain tells the UA to use 1  
uri and other times two. I can imagine the domain changing this  
configuration as the UA moves from different types of access networks.

I expect you are right in that this MUST is too strong here but I  
think there is an argument for SHOULD. The problem is that if the  
domain assume the UA is doing two flows and the UA does one, things  
are broken.

On Jul 5, 2006, at 3:44 AM, Miguel Garcia wrote:

> Reading Section 4.2 of Outbound-04, there is a sentence that came  
> to my attention.
>
> I think it is not appropriate to use a MUST strength in this case.  
> I suspect that the spirit of the draft is to offer high  
> availability by making the UA to establish one flow per URI, which  
> is a good spirit. However, one has to evaluate the cost of  
> establishing one flow per URI, which might be quite high in terms  
> of battery consumption, for example (due to STUN refreshes).
>
> I also believe the MUST is misused here because it is not an  
> absolute requirement for the specification. In other words, the SIP  
> outbound procedures work OK even if the UA establishes just one  
> flow (even when it is provisioned with several outbound URIs).  
> Nothing is broken.
>
> benefit of establishing one flow per outbound URI, but letting up  
> to the UA's policy to decide on the absolute number of established  
> flows.
>
> I would suggest to replace the above mentioned sentence with  
> something around these lines:
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 5 Jul 2006 17:23:39 +0200

Cullen,

see inline,

Regards,

jeroen

>
> My impression of what the WG wanted was that the service provider  could 
> provide between 1 and the max number the UA supported of URIs.  The UA 
> must implement support for at least 2 and should support 4.
>

yes, agree. And "the service provider SHOULD provide at least 2" I suppose

> So let's say that the domain use two and this domains has to have two  do 
> to reliability. If the UA has "local policy" and only decided to  use 
> one - things don't work.

This depends on the definition of "work". The resillience against certain 
types of failures is less, but things will work provided no such failures 
occur.

> I think this is more or less the same as  if you are doing a single 
> registration and the registry tells you  your registration expires after 1 
> hour but the UA decided to refresh  after two hours to reduce network 
> load, well things are broken.
>

This is a clear case because *it is the UAs responsibility to stay 
registered*. In this scenario, we would say that specifically the UA is 
broken (RFC3261 section 10.2.4 : "Each UA is responsible for refreshing the 
bindings that it has previously established.")

Things are not so clear cut for outbound. The question is: who is 
responsible for achieving a certain level of reliability? who decides what 
is sufficient?

> Now you say that the UA might decide by local policy if it wanted to  do 
> say 1 or 2 flows - but where will this local policy come from? The  end 
> user is not going too provide it. I suspect the domain will  provide it. 
> I'm fine with some times the domain tells the UA to use 1  uri and other 
> times two. I can imagine the domain changing this  configuration as the UA 
> moves from different types of access networks.
>

This type of policy could very well be implemented in the UA, in fact it may 
be in a better position to estimate the reliability of the access network(s) 
it is connected to (eg by monitoring channel conditions). Therefore, a model 
in which the UA decides how many flows it uses is defendable too.

The decision on the number of flows depends on the desired level of 
reliability, which in turn depends on the failure characteristics of a 
number of things including the access network, any NAT devices, any edge 
proxies, and the home proxy.

What if we adopt a modus operandi in which the UA decides what level of 
reliability it desires and (thus) how many flows it needs, and the domain 
provides information to support this decision (eg MTBF figures for the 
registrar, or derived information such as a *suggestion* for the number of 
flows)

> I expect you are right in that this MUST is too strong here but I  think 
> there is an argument for SHOULD. The problem is that if the  domain assume 
> the UA is doing two flows and the UA does one, things  are broken.
>

Not from the point of view of the UA, it is getting exactly the level of 
reliability that it would expect from one flow. What reason would the domain 
have to assume anything about the number of flows the UA is using?

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 05 Jul 2006 21:43:45 +0300

Cullen Jennings wrote:
> there is an argument for SHOULD. The problem is that if the domain 
> assume the UA is doing two flows and the UA does one, things are broken.
> 

I would like to understand which part of the outbound mechanism is 
broken if the domain assumes the UE will do two flows, but the UA does 
one flow. Yes, it isn't reliable, but the mechanism works nicely... or not?

Then... why can't a domain indicate just one outbound URI? At the moment 
the draft has an artificial lower limit for all the domains to provide 
two URIs and impose a reliability that might not be required/needed.

I still think that it makes sense to enable the possibility of the 
network to provide a minimum of URI, although it is not the recommended 
behavior.

With respect the MUST strength... I can accept a SHOULD as well.

BR,

       Miguel

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 5 Jul 2006 21:58:33 +0300

> still some "magic" for the domain instructions.

if i remember correctly, someone proposed that register reply somehow
tells how many flow the domain needs.  anyway, it was alway decision of
the network, not the UA.

 > here, because the protocol is not broken if the MUST is not followed.

i have told at least eight times now on this mailing list that the only
real added value that outbound brings is reliability due to more than
one flow.  outbound is NOT needed for nat traversal.  if you say MAY in
the spec, UA vendors don't even support setting up more than one flow
and can claim compatibility.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 5 Jul 2006 22:05:17 +0300

> forces an implementation to always do (2) makes it impossible to do only 

see old postings.  every implementation must be able to establish at
least two flows (default), but this default may be overridden by
configuration.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 5 Jul 2006 21:45:18 +0200

Juha,

> it was alway decision of the network, not the UA

OK, current section 4.2 says "For each outbound proxy URI in the set, the UA 
MUST send a REGISTER". So that implies that the network could control the 
number of flows, by controlling the number of URIs provided through 
configuration (though this would possibly not work well for manual 
configuration)

I think this warrants some more discussion. The network may have reasons to 
limit the *maximum* number of flows (ie resource allocation), but it could 
enforce such a constraint in other ways too. For example, it could refuse 
registrations beyond the first N

But is it really necessary for the network to impose a minimum?

For flows beyond the maximum the network "suffers" (just like the registrar 
determines the expiration time). But by imposing a minimum number of flows, 
the UA potentially "suffers" (spending scarce resources such as battery 
power). And anyway, when the UA sets up less flows the consequences are for 
its user.

4.2 "UA MUST support sets with at least two outbound proxy URIs" should be 
sufficient to ensure vendor compliance. But to me, the UA should have some 
freedom to choose less than all URIs in the outbound proxy set (and you seem 
to agree: "default may be overridden by configuration", unless you consider 
that this configuration again comes from the network)

> tells how many flow the domain needs

I'm having trouble with "needs" here. Perhaps "allows" ?

Regards,

Jeroen

----- Original Message ----- 
From: "Juha Heinanen" <[email-masked]>
To: "Miguel Garcia" <[email-masked]>
Cc: <[email-masked]>; "Cullen Jennings" <[email-masked]>; "Rohan Mahy" 
<[email-masked]>
Sent: Wednesday, July 05, 2006 8:58 PM
Subject: Re: [Sip] A coment to draft-ietf-sip-outbound-04

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 5 Jul 2006 23:18:10 +0300

> But is it really necessary for the network to impose a minimum?

in case network's reliability solution is based on more than one
simultaneous flow, then network must impose a minimum.

 > power). And anyway, when the UA sets up less flows the consequences are for 

in the above situation, assuming that network has two proxies, if UA
decides to establish only one flow instead of two, then the likely hood
is 50% that incoming call to the UA cannot be establishes.  it thus
makes no sense for the UA to violate network policy on number of flows.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 6 Jul 2006 06:58:01 +0200

Juha,

> makes no sense for the UA to violate network policy on number of flows.

This hints at a very different setup than I had in my mind. I always assumed 
that any flows beyond the first would be redundant, to be used when the 
first ("primary") flow would fail. Your text here suggests something more 
resembling a load balancing situation, with very different call completion 
probabilities

Indeed, in the case above the UA would need to know that it MUST use two 
flows (or miss 50% of its calls). An alternative setup would have the 
proxies (say P1 and P2) exchange requests when there is no direct connection 
to the UA. If P1 and P2 are setup as a DNS proxyfarm, the routing logic that 
each would follow could be something like "if (UA flow) then forward to UA; 
else if (not from other proxy) forward to other proxy; else send 480"

This looks like an issue to be discussed in the draft (ie what assumptions 
are made regarding how those N flows are used)

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 6 Jul 2006 09:24:24 +0300

Jeroen van Bemmel writes:

 > An alternative setup would have the 
 > proxies (say P1 and P2) exchange requests when there is no direct
 > connection to the UA. 

no thank you.  i don't want to consume resources of both proxies for the
request and, more importantly, i don't want to loose reliability.

conclusion: in some proxy configurations UA MUST set up more than one
flow or miss service.

-- juha

---

From: <[email-masked]>
Date: Thu, 6 Jul 2006 09:39:27 +0300

Hi Jeroen,

>This hints at a very different setup than I had in my mind. I 
>always assumed that any flows beyond the first would be 
>redundant, to be used when the first ("primary") flow would fail.

The concept you had in your mind seems to be a possible implementation
but by no means mandated by -04 version. In that version the network 
treats all the flows towards an UA in an equal way. It appears already
in the definitions:

  outbound-proxy-set A set of SIP URIs (Uniform Resource Identifiers)
      that represents each of the outbound proxies (often Edge Proxies)
      with which the UA will attempt to maintain a direct flow.  The
      first URI in the set is often refereed to as the primary outbound
      proxy and the second as the secondary outbound proxy.  There is no
      difference between any of the URIs in this set, nor does the
      primary/secondary terminology imply that one is preferred over the
      other.

The normative text leaves it open how the location service will select
a specific contact and related flow for an incoming request. In my
understanding the implementation may either always select one specific
flow as long as it works but it may also balance the load and select
a different contact for different requests. In case the location service
is distributed and colocated with different outbound proxies, it might
prefer using always the local flow towards the UA, as long as it works.

This is why I had to send this proposal for sip-outbound-discovery
draft: http://www1.ietf.org/mail-archive/web/sip/current/msg14985.html
However I have not received any comments to that and will highlight it
as an open issue in the WG meeting.

Regards,

Erkki

>-----Original Message-----
>From: ext Jeroen van Bemmel [mailto:[email-masked]] 
>Sent: 06.July.2006 07:58
>To: Juha Heinanen
>Cc: Garcia Miguel.An (Nokia-NRC/Helsinki); [email-masked]; 
>Cullen Jennings; Rohan Mahy
>> > determines the expiration time). But by imposing a minimum 
>number of 
>> > flows,
>> > power). And anyway, when the UA sets up less flows the 
>consequences are 
>> > for
>> > its user.
>>

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 06 Jul 2006 09:59:55 +0300

Juha:

While I understand that you want to impose reliability to your users, by 
requesting them to establish 2 or more flows, you also need to 
understand that this might not be always the case, because the cost of 
such reliability might be that my battery is drained in half of the 
time, due to the STUN refreshes.

So, what I am advocating is for a way to decoupling reliability from NAT 
traversal. There must be a way for the network to indicate more than one 
outbound URI, used for backup purposes, but still instruct or let the UA 
to establish a single flow. The current text in the draft seems to 
prevent this use case.

/Miguel

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 6 Jul 2006 10:09:06 +0300

>through the Path header fields to ensure that all of them contain URIs=20
>with ";outbound" parameters. If they don't, it can take evasive action=20
>(perhaps not returning the "Supported: outbound" header field in the=20
>response?) that prevents things from going wrong.
=20
Erkki Koivusalo:
>The specific concerns that I have (and would like the WG to=20
>consider in the meeting) are closely related to what you told:
>
>>We got very strong feed back on one point - don't send=20
>>STUN messages to a proxy unless you know it supports them.=20
>
>Does the WG consider checking the configured URI as a safe enough
>check for the UA to ensure that the SIP proxy support STUN ?
>
>In my opinion it is not. As an example a vendor X could implement
>a compliant but bad UA which provides an option for the user to=20
>configure the settings via an User Interface e.g. like this:
>"Is the phone behind a NAT: Yes/No". When the user selects
>"Yes" the UA would add the keepalive=3Dstun flag to the proxy URI
>even if the user does not have a clue if the proxy actually
>supports outbound or not. There is nothing in outbound draft
>to prevent such unsafe implementations to appear.

Jeroen van Bemmel:
>The point is that these are really 2 separate issues:
>1. Discovering the set of outbound proxy URIs (with keepalive=3Dstun=20
>parameters in them)
>2. Confirming that a given proxy in the set actually supports=20
>outbound (ie validating the keepalive=3Dstun information)
>
>Of these 2 options, (1) is indeed a separable problem.=20
>(2) - to me - is not, for me outbound is not acceptable=20
>without something to address (2).

Regards,

Erkki

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 6 Jul 2006 10:09:06 +0300

> to establish a single flow. The current text in the draft seems to 

then suggest some specific mechanism to achieve that you want.  for
example, like someone proposed, introduce some parameter to register 200
OK that tells than one flow is enough.  you cannot simply say that "a UA
may establish only one flow if it doesn't feel like setting up more".

-- juha

ngs <[email-masked]>,
	Rohan Mahy <[email-masked]>
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

 > to establish a single flow. The current text in the draft seems to 

then suggest some specific mechanism to achieve that you want.  for
example, like someone proposed, introduce some parameter to register 200
OK that tells than one flow is enough.  you cannot simply say that "a UA
may establish only one flow if it doesn't feel like setting up more".

-- juha

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 06 Jul 2006 10:21:39 +0300

> may establish only one flow if it doesn't feel like setting up more".

That solution would work for me, but I think it was discussed in the 
past and, I dont' know really why, it was somehow rejected.

The other alternative solution it comes to my mind is to play with the 
Priority of the SRV record. So we could say that the UA establishes a 
flow to each server defined with the lower Priority. Servers defined 
with higher priority will be used in cases of failure.

Within the same priority, the UA establishes one flow per server listed 
there. So, if the network requests several flows, it configures several 
SRV records with the lower priority (say, 0). If the network requests 
one flow, it configures one SRV record with the lower priority. This 
will cover all the use cases we have been discussing.

/Miguel

---

From: <[email-masked]>
Date: Thu, 6 Jul 2006 10:40:41 +0300

Hi,

Rohan rejected the proposal like this:

>As a scope issue, the chairs (previous and current) and the ADs (at
>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.

So nothing specific against the proposed mechanism, just a
general concern of loading outbound draft with too many
different mechanisms.

Rohan also suggested using DNS for the purpose, however
without mentioning yet any specific way how to use it:

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

What comes to your suggestion on using DNS...

>with higher priority will be used in cases of failure.

... it seems that there is a drawback. If SRV records would
be used like that, then a service provider could not any more
use the SRV RRs with same level of priority for balancing the
load for the UA population, wishing each UA to maintain lower
number of flows than the number of servers in that priority level.
E.g. balancing the load to 4 servers would require every UA to
maintain 4 flows, which would be impractical and cause extra
load (for keepalives and registration refreshes) for all those
proxies.

Regards,

Erkki

>From: ext Miguel Garcia [mailto:[email-masked]] 
>Sent: 06.July.2006 10:22
>To: Juha Heinanen
>Cc: [email-masked]; Cullen Jennings; Rohan Mahy

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 06 Jul 2006 10:45:35 +0300

> load (for keepalives and registration refreshes) for all those

So why would you publish 4 servers with the same Priority in SRV, but 
don't want 4 flows, but still want load balancing among what? Strange...

/Miguel

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 6 Jul 2006 10:40:20 +0200

Hi Miguel,
 
I agree with your text proposal. It is pretty much the same which was proposed weeks ago, when the issue was brought up (eventhough the wording may have been a little different).
 
Regards,
 
Christer

________________________________

From: Miguel Garcia [mailto:[email-masked]]
Sent: Wed 05/07/2006 12:44
To: [email-masked]; Cullen Jennings; Rohan Mahy
Subject: [Sip] A coment to draft-ietf-sip-outbound-04

Comments?

/Miguel

---

From: <[email-masked]>
Date: Thu, 6 Jul 2006 12:21:17 +0300

Hi Miguel,

>don't want 4 flows, but still want load balancing among what?  

What I meant is that a service provider might provide e.g.
4 proxies for load balancing (over the whole UA population) 
while deciding that 2 flows per UA would be sufficient for 
reliability. Note that DNS SRV allows the UAs to select 
different servers for their flows, like this:

UA1 would connect to P1 and P2
UA2 would connect to P1 and P3
UA3 would connect to P3 and P4

If the service provider aims to have different SRV weights
for each of those proxies to get bigger amount of load to
servers with more capacity and less amount of load for the
rest of the servers, it would no more be possible with the
solution you outlined. Each of the UAs would create a flow
to each server and assuming that each of the flows will be
treated equally, each of the proxies would get equal amount 
of the total load.

---
An example with 3 proxies to clarify what I mean:

With legacy TCP SIP the DNS SRV is used so that each 
UA would create a connection to single proxy only.
So assume we have 100 UAs so that each of those will
generate and recieve equal amount of traffic over 3
proxies.

P1 has SRV weight 5 and 50 UAs will connect to it
P2 has SRV weight 3 and 30 UAs will connect to it
P3 has SRV weight 2 and 20 UAs will connect to it

In this TCP SIP example P1 will get 50%, P2 30%
and P2 20% of the load within the domain.

With your suggestion with outbound the situation 
would be changed so that each of the 100 UA would
create connections to each of the three proxies.
If those connections are handled in an equal way
the traffic will be distributed equally to each
of the proxies, so each will get 33% of the load.

However if the service provider would decide that
for reliability one connection is sufficient the
result would be the same as without outbound i.e.

P1: 50%   P2: 30%   P3:20%

If the service provider decides that two flows per
UA is needed for reliability and flows are treated
equally the calculation is no that trivial but should
result pretty similar load balancing figures:

50 UAs would select P1 for the primary flow
	30 of them would select P2 for the secondary flow
	20 of them would select P3 for the secondary flow

30 UAs would select P2 for the primary flow
	21 of them would select P1 for the secondary flow
	 9 of them would select P3 for the secondary flow

20 UAs would select P3 for the primary flow
	12 of them would select P1 for the secondary flow
	 8 of them would select P2 for the secondary flow

So the result would be altogether this:

P1 would have 83 flows i.e. 41 % of the load
P2 would have 68 flows i.e. 34 % of the load
P3 would have 49 flows i.e. 25 % of the load

This is why I suggest that your proposal would make
a considerable difference for the load balancing that
service provider can make. It would mean equal load
for each of the servers while SRV RRs usually enable
the provider to share the load unequally to different
proxies based on their capacities.

Regards,

Erkki

>Sent: 06.July.2006 10:46
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: Juha Heinanen; [email-masked]; Cullen Jennings; Rohan Mahy

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 6 Jul 2006 13:58:34 -0400

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Wednesday, July 05, 2006 4:18 PM
> To: Jeroen van Bemmel
> Cc: Miguel Garcia; [email-masked]; Cullen Jennings; Rohan Mahy

That doesn't make any sense to me.  If a UA only establishes 1 flow, then
the registrar only has one registered contact/flow, which points through 1
edge proxy if there is one, and 100% of the incoming calls to the UA will go
over that 1 flow path.  Obviously if the flow fails, there will be some
amount of service-outage to the UA until it detects the loss and connects
through an alternate path, but hopefully that's not happening 50% of the
time. :)  

-hadriel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2006 14:30:15 -0400

inline.

> two URIs and impose a reliability that might not be required/needed.

Thats not my read.

The draft says that a client has to support at least 2 outbound URI, and 
that it MUST send a REGISTER for each. However, that doesn't mean a 
domain *has* to provide two; it can also provide one. A domain would 
only provide one if it knows that it doesn't need two for purposes of 
reliability, or if it doesn't require reliability of service.

As such, I support the current text which says that a client MUST send a 
REGISTER to each outbound URI.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 07 Jul 2006 08:58:35 +0300

Inline

Jonathan Rosenberg wrote:
>> Then... why can't a domain indicate just one outbound URI? At the 
>> moment the draft has an artificial lower limit for all the domains to 
>> provide two URIs and impose a reliability that might not be 
>> required/needed.
> 
> Thats not my read.
> 

True, but then the UA does not have an alternative outbound server, in 
case the supplied one fails. What I don't like is the one to one 
relation between the number of supplied outbound URIs and the number of 
flows (and REGISTER).

Additionally I suspect that users may still impose local policies in the 
UAs as for the number of established flows, independently of the number 
of learned URIs. So, the MUST in the spec is always subject to local policy.

And a third thing is that, according to RFC 2119:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.

I don't see the need for a MUST in that paragraph, because the spec is 
not broken even if the UA does not obey the MUST.

/Miguel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Jul 2006 11:12:30 +0300

Hi,

> relation between the number of supplied outbound URIs and the number of 

using a SHOULD instead of a MUST would break this coupling, which would 
give more freedom to the UA in order to decide how many flows it wants 
to establish (maybe the terminal does not want high reliability).

If things do not break, a SHOULD is more appropriate than a MUST.

Cheers,

Gonzalo

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 7 Jul 2006 08:02:47 -0700

Miguel,

On Jul 6, 2006, at 22:58, Miguel Garcia wrote:
>>> moment the draft has an artificial lower limit for all the domains 
>>> to provide two URIs and impose a reliability that might not be 
>>> required/needed.
>> Thats not my read.
>> The draft says that a client has to support at least 2 outbound URI, 
>> and that it MUST send a REGISTER for each. However, that doesn't mean 
>> a domain *has* to provide two; it can also provide one. A domain 
>> would only provide one if it knows that it doesn't need two for 
>> purposes of reliability, or if it doesn't require reliability of 
>> service.
>
> relation between the number of supplied outbound URIs and the number 
> of flows (and REGISTER).

There is a difference from a flow failing to a particular server and an 
outbound URI failing.  If you only provide a single URI, its trivial to 
make the single URI have several SRV entries pointing to separate 
actual servers.

> Additionally I suspect that users may still impose local policies in 
> the UAs as for the number of established flows, independently of the 
> number of learned URIs. So, the MUST in the spec is always subject to 
> local policy.

The spec currently says that UAs MUST support a minimum of 2 flows.  If 
they don't open the two flows, the mechanism is broken since the UA can 
lose inbound messages for several minutes.

thanks,
-rohan

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 7 Jul 2006 19:47:35 +0200

Rohan,

> lose inbound messages for several minutes.

OK, let me try to see if I understand where this "several minutes" comes 
from, and if we could quantify "broken" here.

Assuming that the client uses the default keepalive timer values (UDP: 
24..29 seconds, TCP: 95..120 seconds), I deduce that worst case a client 
using only one flow could loose its registration status for a period of 120 
seconds (on average, this would be only 60 seconds). So your "several" 
equals 2 ?

One could probably calculate the chance that in this window a request would 
come in (given message rate assumptions, etc). Multiply that with the chance 
at flow failure (given component MTBF figures etc), and you would have the 
kind of reliability one would have for one flow only. Call that reliability 
R

My question now is: what are reasonable assumptions for these figures, and 
could it be that for some clients, R could be sufficient?
Intuitively I say: yes, that's possible. There exist clients and users that 
would be happy with a scheme that is broken for (1-R) part (I know at least 
one - me).

There is currently nothing in the requirements regarding reliability. 
Section 4.4 mentions the relationship between timer values and server load, 
and has some text on "the expected time that a user may not receive inbound 
communications"; but not in relation to the number of flows (nor does it 
mention to de-synchronize keepalive timers across multiple flows). Do we 
need that, perhaps with some sample quantitative analysis?

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jul 2006 20:11:26 +0300

Hadriel Kaplan writes:

 > That doesn't make any sense to me.  

obviously you didn't notice that in the example there was two proxies,
one flow to each.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 8 Jul 2006 20:01:33 +0200

Juha,

Hadriel is not the only one who was puzzled by this, so was I. I've been 
trying to follow your reasoning, and I think I now know where this confusion 
comes from

The reason outbound introduces multiple flows is stated in the introduction: 
"[...] Since such detection takes time and leaves a window of opportunity 
for missed incoming requests, this mechanism allows the UA to use multiple 
flows to the proxy or registrar."

I read this as "multiple flows to the *same, single* proxy or registrar". 
When reading this, I think "ah, that makes sense, because NAT devices can be 
unstable and drop flows all the time, and keepalive messages could get 
lost". So I interpret this as protection against failing NAT devices, and 
*not* against failing proxies.

This is why I initially did not understand why things would break if a UA 
sets up only 1 flow, instead of 2. This makes sense only in case of flows to 
*distinct* proxies, ie your 50% scheme below.

What you are doing, is saying: "ah, outbound gives me multiple flows, and 
that is its main benefit (and not NAT traversal)". So you take something 
that is only a side effect of the main intention of the draft, and turn it 
around by assuming that flows go to different proxies. Probably inspired by 
section 3.3 which does this too.

My conclusion is that all this reliability stuff (mainly section 3.3 and 
part of section 3.4) is a *separate issue*, and has nothing to do with the 
core of outbound. It should not be in this draft, because it is confusing 
and - as the text already points out - only one of many ways to provide 
reliability.

Section 3.4 should be rewritten to consider the case of a UA, a *single* 
edge proxy, and a registrar. By including two edge proxies here, two 
different issues are introduced: 1) how does one do outbound in case of an 
edge proxy and 2) how does one deal with multiple edge proxies. Again, 
separate that please!

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jul 2006 21:28:30 +0300

jeroen,

multiple flows to the same proxy is not interesting.  the only added
value of outbound is multiple flows to more than one proxy.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 8 Jul 2006 20:43:04 +0200

Dear outbound authors,

Could you share your thoughts on the view Juha is expressing below?

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jul 2006 22:15:11 +0300

jeroen,

are you saying that if outbound-proxy-set consists of two sip uris, it
would be ok if the UA sets up two flows to one of them and no flow to
the other one?

if this is allowed by outbound i-d, then i have wasted my (and other
people's) time on it.

-- juha

---

From: Miguel Garcia <[email-masked]>
Date: Sun, 09 Jul 2006 14:25:39 +0300

> lose inbound messages for several minutes.

I think I have a different opinion on whether the mechanism is broken or 
not. The mechanism is not broken, but obviously the server can loose 
inbound connections. This scenario, although not perfect, may be much 
desirable than draining battery of portable devices at a fast speed.

/Miguel

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 9 Jul 2006 14:37:00 +0200

I think the system is "broken" in the sense that it does not behave as the 
authors of the draft had intended
There are 2 questions here:
1) Is that intention expressed sufficiently clear and consistent in the 
draft?
2) Is the intended behavior (and associated system architecture) 
appropriate/desirable (in all/most cases)?

The draft seems to be written under the assumption that "reliability" (not 
well defined yet what that means) can only be provided through multiple 
flows. However, "outbound" (ie enabling UAs behind NAT to register and 
receive incoming requests) can be done using only a single flow, albeit with 
a somewhat higher chance at missing incoming requests.

If the system is architected as Juha was describing (2 independent proxies, 
UA missing 50% of its calls when only setting up 1 flow), the chance at 
missed requests for such a UA is much higher than double that of a single 
flow system. I feel that outbound should certainly not mandate such an 
architecture.

Currently in SIP the assumption is that a single registration suffices to 
receive all incoming requests for a given AoR. If we break that, it means 
that current UAs won't be able to register with "outbound-enhanced" 
registrars and edge proxies. That to me is not acceptable.

In other words, a requirement is missing: "Support UAs that do not implement 
this extension"

Regards,

jeroen

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 8 Jul 2006 17:16:26 -0700

On Jul 7, 2006, at 10:47, Jeroen van Bemmel wrote:
>>> number of learned URIs. So, the MUST in the spec is always subject 
>>> to local policy.
>>
>> The spec currently says that UAs MUST support a minimum of 2 flows.  
>> If they don't open the two flows, the mechanism is broken since the 
>> UA can lose inbound messages for several minutes.
>
> OK, let me try to see if I understand where this "several minutes" 
> comes from, and if we could quantify "broken" here.
>
> 24..29 seconds, TCP: 95..120 seconds), I deduce that worst case a 
> client using only one flow could loose its registration status for a 
> period of 120 seconds (on average, this would be only 60 seconds). So 
> your "several" equals 2 ?

Yes, you are right. The UA could lose inbound messages for 2 minutes  I 
went back and rechecked all the timers.  I was still (wrongly) thinking 
about the problem based on timer values that resulted in a ~10 minute 
window of potential downtime.  While 10 minutes was not acceptable to 
me, I agree that 2 minutes is in a gray area that will be fine for some 
and not fine for others.

So we are back to a pure semantic question.  Does the service get to 
decide how many flows the UA opens (up to an implementation supported 
maximum), does the UA decide how many flows to open, or is there some 
negotiation?   I still think the current semantics are fine, because 
they allow a single flow to a URI that can still load-share and 
failover to a large number of actual servers.  Of course there are 
others who don't like that because it relies on DNS for failover.

thanks,
-rohan

> One could probably calculate the chance that in this window a request 
> would come in (given message rate assumptions, etc). Multiply that 
> with the chance at flow failure (given component MTBF figures etc), 
> and you would have the kind of reliability one would have for one flow 
> only. Call that reliability R
>
> My question now is: what are reasonable assumptions for these figures, 
> and could it be that for some clients, R could be sufficient?
> Intuitively I say: yes, that's possible. There exist clients and users 
> that would be happy with a scheme that is broken for (1-R) part (I 
> know at least one - me).
>
> Section 4.4 mentions the relationship between timer values and server 
> load, and has some text on "the expected time that a user may not 
> receive inbound communications"; but not in relation to the number of 
> flows (nor does it mention to de-synchronize keepalive timers across 
> multiple flows). Do we need that, perhaps with some sample 
> quantitative analysis?
>
> Regards,
>
> Jeroen

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 8 Jul 2006 17:25:32 -0700

Hi,

I do not understand the motivation for wanting multiple flows to the 
same actual server.

At some point we need to ask ourselves as a group whether we are a 
building a mechanism that solves a problem in every conceivable 
topology we can come up with , or whether it is sufficient for us to 
build a mechanism that solves a variety of important problems using one 
or two plausible topologies.

thanks,
-rohan

On Jul 8, 2006, at 11:43, Jeroen van Bemmel wrote:
> ----- Original Message ----- From: "Juha Heinanen" <[email-masked]>

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 8 Jul 2006 17:16:26 -0700

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 8 Jul 2006 17:25:32 -0700

Hi,

thanks,
-rohan

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 9 Jul 2006 23:41:41 +0200

> Hi,
>
> I do not understand the motivation for wanting multiple flows to the same 
> actual server.
>

Not multiple *connections*, but multiple flows via different edge proxies: 
yes (see section 3.4). Of course, the single server itself will need to be 
built properly to provide adequate reliability (eg storage that survives 
reboots for registration state, etc).

Perhaps we should let edge proxies refuse a REGISTER that comes in when 
another flow already exists through it though.

> building a mechanism that solves a problem in every conceivable topology 
> we can come up with , or whether it is sufficient for us to build a 
> mechanism that solves a variety of important problems using one or two 
> plausible topologies.
>

The problem is: in the current outbound draft there are *several* mechanisms 
( multiple flows, keepalive, outbound request handling, reliability schemes) 
defined that solve a variety of *separate* problems, while making 
assumptions that rule out certain other, equally plausible, topologies.

For example, topologies involving mobile devices are important too. Such 
networks are quite capable of providing certain degrees of reliability 
themselves, but that won't do any good once the battery is drained. For 
these devices, "MUST setup 2 flows" can be too much. So we cannot (only) 
have a scheme that requires that

Regards,

Jeroen

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 9 Jul 2006 18:12:57 -0400

I'm really confused now.  If there are 2 proxies, with "one flow to each",
then clearly the UAC created a flow to each, and registered through each.
Jeroen's case is one where the operator configures 2 outbound proxies, but
the UAC only USES one - i.e, it only registers and stuns through/to one.
Not that it somehow registers to it but rejects requests from it. (right
Jeroen?)

Whether you as an operator configure all UACs with 2 proxies, or more, does
not make a difference for his case - if the UAC only establishes 1 flow,
then it only registers through one proxy, and only one proxy adds a path
header, and the registrar only has one flow and registration contact info to
use to reach the UAC, and 100% of the requests go that 1 proxy path.  The
other proxy(s) know nothing about the UAC, short of being able to find out
from the location server that it's through the 1 proxy that the UAC actually
registered through.

To suggest otherwise, that somehow the secondary proxy gets 50% of the
requests (and they fail) even if the UAC did not register through it, means
that in a failure mode where the UAC can only reach one proxy, then it only
gets 50% service.  That would be a significant step BACKWARDS from today's
fairly common reliability mechanisms and availability models, IMO. 

-hadriel

> Sent: Saturday, July 08, 2006 1:11 PM
> To: Hadriel Kaplan
> Cc: [email-masked]

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 10 Jul 2006 00:34:23 +0200

Hi Hadriel,

> Not that it somehow registers to it but rejects requests from it. (right

Right, it establishes only 1 registration (like most UACs do today) and 
keeps this flow alive

> fairly common reliability mechanisms and availability models, IMO.

In my mind, how you would end up with this "50% model" is to have 2 
registrar instances configured in DNS as load-balancing alternatives for the 
domain. With or without edge proxies, this model would indeed require the UA 
to setup 2 registrations/flows, or miss 50% of the requests (on average).

I am no great fan of this model, but if people want to do this, the UA needs 
to know how many registrations it is expected to create. This is *not* equal 
to the number of URIs in the magically discovered outbound proxy set, 
because the UA cannot tell how many distinct registrar instances are 
reachable through this set. The number of registrations cannot be larger 
than the number of URIs in the set, but it could be less (i.e. value is in 
range 1..#URIs)

Regards,

Jeroen

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 9 Jul 2006 19:50:44 -0400

Hi Jeroen, inline...

> From: Jeroen van Bemmel [mailto:[email-masked]]
> 
> Hi Hadriel,
> 

I would think any model using 2 registrars in this way has to use a shared
registrar database, a database exchange/sync mechanism, or a "if not on this
registrar then try the other" mechanism.  There is simply no way to
guarantee every UAC has reach-ability to both registrars all the time.
There are just too many failure modes, some of which are long-lived.  They
would just be asking for trouble, imho.  :)

-hadriel

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 10 Jul 2006 00:42:02 -0400

On Jul 9, 2006, at 8:37, Jeroen van Bemmel wrote:

> I think the system is "broken" in the sense that it does not behave as 
> the authors of the draft had intended
> 1) Is that intention expressed sufficiently clear and consistent in 
> the draft?
> The draft seems to be written under the assumption that "reliability" 
> (not well defined yet what that means) can only be provided through 
> multiple flows. However, "outbound" (ie enabling UAs behind NAT to 
> register and receive incoming requests) can be done using only a 
> single flow, albeit with a somewhat higher chance at missing incoming 
> requests.

the draft assumes that *if* the outbound-proxy-set contained <n> URIs, 
then whoever provided the outbound-proxy-set believes that <n> flows 
are needed to provide reliability.  If only a single URI is provided in 
the outbound-proxy-set, then a single flow is sufficient.

> If the system is architected as Juha was describing (2 independent 
> proxies, UA missing 50% of its calls when only setting up 1 flow), the 
> chance at missed requests for such a UA is much higher than double 
> that of a single flow system. I feel that outbound should certainly 
> not mandate such an architecture.

The UA doesn't miss 50% of its calls in this case.  If only one flow is 
registered, the registrar/home proxy will forward incoming requests 
only over that flow.  Its just that the UA is not playing nicely with 
the proxies, as they would like to load balance over two flows, but 
they have to forward all the traffic for the UA over one flow instead.

> Currently in SIP the assumption is that a single registration suffices 
> to receive all incoming requests for a given AoR. If we break that, it 
> means that current UAs won't be able to register with 
> "outbound-enhanced" registrars and edge proxies. That to me is not 
> acceptable.

there is no requirement in outbound that pre-outbound registrations 
will not work.

> In other words, a requirement is missing: "Support UAs that do not 
> implement this extension"

What amount of "support" do you envision?

thanks,
-rohan

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Jul 2006 10:24:59 +0300

> have a scheme that requires that

i don't remember anybody suggesting "MUST setup 2 flows", but "MUST be
capable of setting at least 2 flows".  the domain will then decide how
many flows need to be set up (by that particular device if we adopts
jonathan's discovery proposal).

-- juha

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 10 Jul 2006 16:58:05 +0300

Rohan Mahy wrote:
> they allow a single flow to a URI that can still load-share and failover 
> to a large number of actual servers.  Of course there are others who 
> don't like that because it relies on DNS for failover.
> 
> thanks,
> -rohan
> 

I thought a bit more about this. I believe the service provider has no 
more say than providing the list of outbound URIs. The UA has to decide 
on how many flows to open, and what is the cost of this decision. I can 
imagine a policy in my laptop that makes the number of flows dependent 
on whether I am plug to the main or running on battery, so that if I am 
running on batteries I keep only one flow. My provider will never know 
what is my battery status: He can only set the maximum number of flows, 
but not the minimum.

/Miguel

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Jul 2006 17:53:05 +0300

Miguel Garcia writes:

 > The UA has to decide 
 > on how many flows to open, and what is the cost of this decision. 

what if the cost is missing half of incoming calls?  if that is not
acceptable, then you exclude configuration where outbound proxies
operate standalone.  and once you do that, outbound does not provide ANY
benefit over what we have today (reliability nor nat traversal).

in fact, outbound would provides LESS than what we have today.  in
current implementations where proxies do nat keepalives, an intelligent
nat can be build that does not actually send ANY keepalives to your
battery operated UA, but still keep nat binding open.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Jul 2006 11:05:00 -0400

inline.

Miguel Garcia wrote:

> more say than providing the list of outbound URIs.

No. I think the semantic is clear. If the provider offers N URI, then 
the semantic is, "I, the provider, want you to open N flows".

> what is my battery status: He can only set the maximum number of flows, 

I'm not entirely convinced that, once you're doing one flow with 
sip-outbound, that the incremental cost of an additional flow has a 
major impact on battery life.

That said, I think this is starting to split hairs. The main point, I 
think, is that, under almost all conditions, if a client is offered N 
URI it opens N flows. Only for *exceptional* conditions would it open 
less. I would be OK with a strongly-qualified SHOULD. I.e., the spec 
would say SHOULD and then explain that its only under such extreme 
conditions that it would open fewer.

Thanks,
Jonathan R.

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 10 Jul 2006 19:13:17 +0300

> benefit over what we have today (reliability nor nat traversal).

If the user does not want to miss any calls, he can install a policy 
that uses several flows. The draft allows you to do it. What the draft 
does not allow me to do is to install a policy where I use only one flow.

> battery operated UA, but still keep nat binding open.

True, in that case you probably don't need STUN or SIP outbound, so no 
need to discuss it either. The same applies if you can get a non-private 
IP address to your UA. We don't discuss the lack of need of the outbound 
draft in those cases.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 10 Jul 2006 19:17:51 +0300

> major impact on battery life.

It does, not because of the flow itself, but because of the keepalives 
every 30 seconds.

> conditions that it would open fewer.

I am fine with this proposal. And I wouldn't mine to add some paragraph 
describing the conditions under which the UA would establish the N flows.

/Miguel

---

From: Aki Niemi <[email-masked]>
Date: Mon, 10 Jul 2006 14:51:24 -0400

On ma, 2006-07-10 at 17:53 +0300, ext Juha Heinanen wrote:
> in fact, outbound would provides LESS than what we have today. 

>From my point of view, the most important thing missing today is getting
SIP over TCP to work in presence of NATs. This is what outbound
provides, which IMO is more than what's available today.

-- 
Aki Niemi
Nokia Research Center

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 10 Jul 2006 21:15:52 +0200

Rohan,

>> chance at missed requests for such a UA is much higher than double that 
>> of a single flow system. I feel that outbound should certainly not 
>> mandate such an architecture.
>
> registered, the registrar/home proxy will forward incoming requests only 
> over that flow.  Its just that the UA is not playing nicely with the 
> proxies, as they would like to load balance over two flows, but they have 
> to forward all the traffic for the UA over one flow instead.
>

As long as things work as you describe here, it's fine with me. The 50% was 
based on Juha's description of the system he envisioned earlier in this 
thread

> there is no requirement in outbound that pre-outbound registrations will 
> not work.
>

True, but this is not the same as a requirement that says that pre-outbound 
registrations MUST still work (and receive 100% of service, not 50%). I 
thought this was implicitly obvious, but recent discussions suggest 
otherwise

> What amount of "support" do you envision?

Just no less - statistically speaking - than a UA would get from a REGISTER 
today.

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Jul 2006 22:29:36 +0300

Jeroen van Bemmel writes:

 > otherwise.

i haven't said that pre-outbound registrations would not work.  what
would not work is that if UA claims outbound support, but establishes
only one flow when two would be the minimum for a particular domain.

-- juha

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Jul 2006 15:39:47 -0400

I do not think it is the UAs job to provide support for the operators 
architecture.
Nor is it "outbound"s job to mandate specific redundancy mechanisms 
(it currently seems to do so, although I think all of that is 
intended as examples.)

Yours,
Joel

---

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

My problem is that this couples the network requirements for 
resiliency with the UA's preferences and with the UA's need to get 
through a firewall (often not even under the networks control.)
Outbound is not the place for the network to get the UA to help with 
redundancy.

Yours,
Joel

At 03:47 PM 7/10/2006, Juha Heinanen wrote:
>Joel M. Halpern writes:
>outbound can support any number of redundancy mechanisms.  if a domain
>chooses to require two flows from a particular UA, then it is up to
>outbound UA to do so.  another domain may have different policy.  as
>long as outbound UA is able to setup at least two flows everything is
>ok.
>
>-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Jul 2006 23:05:34 +0300

> Outbound is not the place for the network to get the UA to help with 

ok, in case i was misled to believe so.  it would have been years of
migration to outbound anyhow and without normative reference to
discovery, its deployment would have been a nightmare in open
environment.  so i'll rest my case and go back to write code.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Jul 2006 22:47:50 +0300 (EEST)

-- juha

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Jul 2006 19:25:21 -0400

By this interpretation, a network could not offer redundant / backup 
connectivity (via outbound) to UAs which want to take advantage of 
that without also mandating that all UAs make connect  to all the entities.
Yours,
Joel

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 17 Jul 2006 18:51:52 +0200

Hi,
 
If the UA chooses to only establish a single flow there is really nothing the network can do about it, even if the network allows the UA to establish multiple flows.
 
But, as we have discussed before, it would be useful if the network could indicate the max number of flows it allows the UA to establish. And, if thet network indicates max-flow=1 the UA can assume that the network can provide reliability even with a single flow.
 
Regards,
 
Christer

From: Joel M. Halpern [mailto:[email-masked]]
Sent: Tue 11/07/2006 01:25
To: Juha Heinanen
Cc: Miguel Garcia; Rohan Mahy; [email-masked]; Cullen Jennings
Subject: Re: [Sip] Re: A coment to draft-ietf-sip-outbound-04