Subject: RE: [Sip] outbound i-d update?

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 15 Jun 2006 09:54:54 -0400

So, keeping score:

Client must be capable of establishing a minimum of 2 flows.

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.

Did I miss anything?

Mike

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Thursday, June 15, 2006 4:25 AM
> To: [email-masked]; Paul Kyzivat (pkyzivat)
> Cc: Cullen Jennings (fluffy); [email-masked]; [email-masked]
> Subject: RE: [Sip] outbound i-d update?
> 
> 
> Hi, 
> 
> >>and how would that knowledge be auto-configured to the client?
> >In the next version of draft-koivusalo-sip-outbound-discovery
> >it might be possible to introduce a configuration option to 
> tell the UA 
> >whether it should keep one or two flows open. The spec might 
> tell that 
> >the default value for this option SHOULD be two and that the 
> operator/user could override this default behaviour e.g. in 
> order to save battery or some other policy related reasons.
> >
> >Comments ?
> 
> That sounds ok. But, as I've said, I think it would be useful 
> if the network could indicate (e.g. In the first REGISTER 
> response) how many flows it wants the client to establish. 
> Because, the numbers of flows wanted may not always be 
> static, so having a UA configuration parameter as the only 
> option may not always be very feasible.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> >-----Original Message-----
> >From: ext Paul Kyzivat [mailto:[email-masked]]
> >Sent: 15.June.2006 01:42
> >To: Christer Holmberg (JO/LMF)
> >Cc: [email-masked]; [email-masked]; Juha Heinanen
> >Subject: Re: [Sip] outbound i-d update?
> >
> >The decision about how many to keep open is *policy*. It may be that 
> >there is a UA that doesn't care about reliability very much, so its 
> >policy is to keep only one connection up. (Outbound is still 
> useful for 
> >nat traversal.)
> >
> >Both ends of the connection may have a policy about this. If 
> so, those 
> >need to be reconciled somehow. But I don't see why that 
> should be wired 
> >into this specification.
> >
> >IMO it would be sufficient to specify a default that SHOULD apply 
> >unless there is explicit policy to the contrary.
> >
> >	Paul
> >
> >Christer Holmberg (JO/LMF) wrote:
> >> Hi,
> >> 
> >> For example, the knowledge could come to the client from the
> >network in a REGISTER response, i.e. the network tells the 
> client how 
> >many flows it wants to client to establish.
> >> 
> >> Or something like that... I haven't thought much about it,
> >but maybe it's one possible alternative.
> >> 
> >> Regards,
> >> 
> >> Christer
> >>  
> >> 
> >> -----Original Message-----
> >> From: Juha Heinanen [mailto:[email-masked]]
> >> Sent: 14. kesäkuuta 2006 11:24
> >> To: Christer Holmberg (JO/LMF)
> >> Cc: [email-masked]; [email-masked]; [email-masked]
> >> Subject: RE: [Sip] outbound i-d update?
> >> 
> >> Christer Holmberg (JO/LMF) writes:
> >> 
> >>  > But, I still think that the client should still be
> >allowed to open a  > flow with only a single IP address, because the 
> >fact that it receives  > multiple URIs/addresses may have 
> nothing to do 
> >with fault  > tolerance. But, in this case the client must of course 
> >have knowledge  > about that.
> >> 
> >> and how would that knowledge be auto-configured to the client?
> >> 
> >> -- juha
> >> 
> >> _______________________________________________
> >> 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
> >
> 
> _______________________________________________
> 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: Juha Heinanen <[email-masked]>
Date: Thu, 15 Jun 2006 16:58:25 +0300

> Client should attempt to equal max-flows if terminal capabilities allows.

ok with me,

-- juha

---

From: <[email-masked]>
Date: Fri, 16 Jun 2006 13:28:47 +0300

Hi,

I have sent the draft-koivusalo-sip-outbound-discovery-02
to be published. Summary of changes since 01 version is as
follows:

- Adopted the terminology primary and secodary flow in those
  cases where the secondary flow is not specifically having backup
  status. Primary flow just means the one that the UA creates
  first and secondary the other one.

- Added text to define how the UA determines the number of 
  flows to create.

- Clarified how the UA uses the created flows: when the two
  flows should be used in an equal way and when the primary
  and backup status really matter for the UA.

02 is the version to be discussed in IETF#66 meeting,
according to the draft SIP WG agenda.

Regards,

Erkki

---

From: "Jan Rögde" <[email-masked]>
Date: Fri, 16 Jun 2006 11:20:21 +0200

A couple of questions that I think are related to this discussion.

* Assume the client wants reliability so it is prepared to set up multiple connections.
* Study the scenario in chapter 8 "Example Message Flow".
* Since the terms Backup and Primary are obsolete now (right?) assume that there are multiple proxy/registrars hosting the domain.
* As in the example, the proxy that was in involved in the call setup goes down.
* The BYE arrives at another proxy server, because the Record-Route just stated the domain name, which in the example "happens" to have a connection to the callee.

So, for this to work in the general case I guess that the client really needs to have a connection to ALL proxy servers hosting the domain, it is not enough to just have "multiple flows"? 

Or maybe outbound alone should not solve this case? If combined with GRUU it would be enough to have a few connections open to "make sure" that the request will reach the recipient.

And finally moving slightly off topic, wouldn't it be easier for everyone involved if outbound and gruu was combined? That combination solves a problem...

/Jappe

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: den 15 juni 2006 15:55
To: Christer Holmberg (JO/LMF); [email-masked]; Paul Kyzivat (pkyzivat)
Cc: Cullen Jennings (fluffy); [email-masked]; [email-masked]
Subject: RE: [Sip] outbound i-d update?

So, keeping score:

Did I miss anything?

Mike

> operator/user could override this default behaviour e.g. in order to 
> save battery or some other policy related reasons.
> >
> >Comments ?
> 
> That sounds ok. But, as I've said, I think it would be useful if the 
> network could indicate (e.g. In the first REGISTER
> Because, the numbers of flows wanted may not always be static, so 
> having a UA configuration parameter as the only option may not always 
> be very feasible.
> 
> 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: Tue, 20 Jun 2006 11:45:13 -0700

On Jun 16, 2006, at 2:20 AM, Jan Rögde wrote:

> wouldn't it be easier for everyone involved if outbound and gruu  
> was combined?

I feel very strongly this would complicate things. They can be  
seperated and I think we should keep them this way. These have all  
take too long and combining them would only slow things donw.

---

From: "Jan Rögde" <[email-masked]>
Date: Wed, 21 Jun 2006 14:01:08 +0200

Ok, that was the answer I expected although I don't agree... :-)

Anyway, I would appreciate a comment from someone regarding the failover scenario which was the main purpose of my previous mail. Basically, the list seems to agree on this (your last comment to Juha):
"
* UA need to implement support for multliple flows - at least two and should do four can do more
* Operator of a domain can choose how many to use
"

My point is just that I do not see how this solves the failover scenario in chapter 8. However, combined with GRUU it would. Am I right or am I wrong?

I include my previous mail below for easy access,
  Jappe

Previous mail:
"A couple of questions that I think are related to this discussion.

And finally moving slightly off topic, wouldn't it be easier for everyone involved if outbound and gruu was combined? That combination solves a problem..."

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: den 20 juni 2006 20:45
To: [email-masked]
Cc: IETF SIP List
Subject: Re: [Sip] outbound i-d update?

On Jun 16, 2006, at 2:20 AM, Jan Rögde wrote:

> wouldn't it be easier for everyone involved if outbound and gruu was 
> combined?

I feel very strongly this would complicate things. They can be seperated and I think we should keep them this way. These have all take too long and combining them would only slow things donw.

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 21 Jun 2006 15:27:31 +0300

"Jan Rögde" writes:

 > * The BYE arrives at another proxy server, because the Record-Route
 > * just stated the domain name, which in the example "happens" to have
 > * a connection to the callee.

my proxys don't use domain names in rr headers that they insert.

-- juha

---

From: "Jan Rögde" <[email-masked]>
Date: Wed, 21 Jun 2006 15:19:34 +0200

> my proxys don't use domain names in rr headers that they insert.

I'm just trying to follow the example in chapter 8 (with Primary and Backup changed to multiple proxies for the domain as I believe that was the suggestion for the next version).

>From the example:
"   The messages in the call flow are very normal.  The only interesting
   thing to note is that the INVITE in message 6 contains the following
   Record-Route header field:

   Record-Route: <sip:example.com;lr>"

/Jappe

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: den 21 juni 2006 14:28
To: [email-masked]
Cc: Cullen Jennings; IETF SIP List
Subject: RE: [Sip] outbound i-d update?

"Jan Rögde" writes:

 > * The BYE arrives at another proxy server, because the Record-Route  > * just stated the domain name, which in the example "happens" to have  > * a connection to the callee.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 21 Jun 2006 16:28:03 +0300

"Jan Rögde" writes:

 > I'm just trying to follow the example in chapter 8 (with Primary and
 > Backup changed to multiple proxies for the domain as I believe that
 > was the suggestion for the next version).

perhaps the example has a problem in it.  it is not a good idea to use
domain names in rr headers if you want that in-dialog requests hit the
same proxy as initial one.

-- juha

---

From: "Jan Rögde" <[email-masked]>
Date: Wed, 21 Jun 2006 16:27:05 +0200

Yes, but the idea is to handle a fail-over scenario.

If it record-route with its own IP-address, in-dialog requests will fail if that proxy goes down. If it record-route with a domain-name as in the example, in-dialog requests could end up at any working proxy and then UA would need a connection to ALL the proxies for the domain-name. But on the list you all seem to agree that a fixed number (min 2 connections) is enough.

So again, is outbound intended to solve the reliability problem? If so, the draft is not clear about this. 

/Jappe

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: den 21 juni 2006 15:28
To: [email-masked]
Cc: IETF SIP List
Subject: RE: [Sip] outbound i-d update?

"Jan Rögde" writes:

 > I'm just trying to follow the example in chapter 8 (with Primary and  > Backup changed to multiple proxies for the domain as I believe that  > was the suggestion for the next version).

perhaps the example has a problem in it.  it is not a good idea to use domain names in rr headers if you want that in-dialog requests hit the same proxy as initial one.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 21 Jun 2006 18:03:19 +0300

"Jan Rögde" writes:

 > If it record-route with its own IP-address, in-dialog requests will
 > fail if that proxy goes down. If it record-route with a domain-name
 > as in the example, in-dialog requests could end up at any working
 > proxy and then UA would need a connection to ALL the proxies for the
 > domain-name. But on the list you all seem to agree that a fixed
 > number (min 2 connections) is enough.

UA can try the two to which it has established a flow, but if both of
them fail to respond to BYE, nothing prevents it from trying other
proxies in outbound set even if UA does not currently have flow open
with them.

-- juha

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Jun 2006 09:20:28 -0700

The proxy farm needs a way of providing high reliability - that would  
mean getting the BYE that arrived at one server to a server that  
actually had a connection to the UA. There have been many proposals  
on how to do this - one of them was have the UA connect to every host  
in the farm. Others have involved moving TCP connections from one  
server to another. Others have limited the machines that might act as  
a backup for the failed machine and making sure it has a connection.  
Others have involved internal routing the BYE around the proxy farm.  
The point is, there are many ways and the outbound draft (and the  
GRUU draft) do not pretend to tell someone how to build a high  
reliably proxy farm. However, it does seem to work with all the  
various proposal people have come up with.

On Jun 21, 2006, at 5:01 AM, Jan Rögde wrote:

> Anyway, I would appreciate a comment from someone regarding the  
> failover scenario which was the main purpose of my previous mail.  
> Basically, the list seems to agree on this (your last comment to  
> Juha):
> "
> My point is just that I do not see how this solves the failover  
> scenario in chapter 8. However, combined with GRUU it would. Am I  
> right or am I wrong?
>
> * Since the terms Backup and Primary are obsolete now (right?)  
> assume that there are multiple proxy/registrars hosting the domain.
> just stated the domain name, which in the example "happens" to have  
> a connection to the callee.
>
> So, for this to work in the general case I guess that the client  
> really needs to have a connection to ALL proxy servers hosting the  
> domain, it is not enough to just have "multiple flows"?
>
> Or maybe outbound alone should not solve this case? If combined  
> with GRUU it would be enough to have a few connections open to  
> "make sure" that the request will reach the recipient.
>
> And finally moving slightly off topic, wouldn't it be easier for  
> everyone involved if outbound and gruu was combined? That  
> combination solves a problem..."
>
> This list is for NEW development of the core SIP Protocol Use sip- 
> [email-masked] for questions on current sip Use

---

From: [email-masked]
Date: Sun, 25 Jun 2006 12:02:12 -0400

From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= <[email-masked]>

   If it record-route with its own IP-address, in-dialog requests will
   fail if that proxy goes down. If it record-route with a domain-name
   as in the example, in-dialog requests could end up at any working
   proxy and then UA would need a connection to ALL the proxies for
   the domain-name. But on the list you all seem to agree that a fixed
   number (min 2 connections) is enough.

Without sip-outbound, the best practice seems to be for the proxy to
use for the record-route a domain name that routes preferentially to
the proxy, and secondarily to its clones.  So as long as that proxy is
available, requests will go through it, but if it fails, requests can
go through any clone proxy.  It seems that for the best effect, we
want a rule that if RFC 3263 turns up a set of destinations with equal
desirability, the agent should prefer any with which it already has
established flows.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 25 Jun 2006 18:38:15 +0200

What I miss in these discussions is a distinction in fail-over scenarios:
1) reboot of some proxy
2) reboot of the registrar

In particular the latter case (2) is where outbound with 2 flows would help, 
especially when edge proxies are used. Currently, for a direct connection 
with the registrar a UAC could detect a reboot by keeping a TCP connection 
up. When using an edge proxy, the UAC would not detect that its registration 
was lost. A second backup registration would keep the UAC reachable; when 
receiving a request over the second flow, the UAC should probably verify if 
the first flow is still up (end-to-end, not only the connection to the edge 
proxy)

For this to work, it must be guaranteed that the two REGISTERs end up at 2 
distinct registrar machines - I still miss how that is to be achieved, in 
particular when edge proxies are in between

For case (1), in-dialog requests for dialogs which the proxy record-routed 
using its IP address need not fail, as long as any state the proxy needs is 
stored in a way that survives reboots

Regards,

Jeroen