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

From: Juha Heinanen <[email-masked]>
Date: Wed, 14 Jun 2006 10:19:47 +0300

i made a mistake yesterday when i wrote:

  i don't like a single URI alternative at all, since a single URI may
  result into a single host.  there must be at least two URIs in outbound
  proxy set.

it is OK for me to have only one URI in outbound proxy set, but if that
is the case, then outbound-id must say that this single URI MUST resolve
to at least two proxy hosts and that each UA MUST keep a flow open to at
least two proxy hosts.

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 14 Jun 2006 10:20:57 +0200

To at least TWO of those, that is... 

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]] 
Sent: 14. kesäkuuta 2006 11:20
To: Juha Heinanen
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] outbound i-d update?

Hi,

If the client receives multiple URIs, and/or IP addresses, the "default behavior" could be to open flows to at least of those.

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.

Regards,

Christer

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]]
Sent: 14. kesäkuuta 2006 11:15
To: Christer Holmberg (JO/LMF)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] outbound i-d update?

Christer Holmberg (JO/LMF) writes:

 > I think that can be mentioned in the document, but I still think the  > operator should be able to choose. Because, there may be other ways to  > provide fault tolerance than using multiple IP addresses.

i know, since at the moment we are using those "other ways" and i can tell you that they are not fun.  but you are right in that if a domain only advertises one outbound URI, which resolves to only one proxy host, then let it be that way.  it is domain's call.

however, the important thing is that IF domain advertises more than one outbound URI or a single URI that resolve(s) to more than one proxy host, then UA MUST keep flows open to at least two of those proxy hosts.

without this above requirement, outbound-id doesn't add any real value over what we have today.

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Jun 2006 10:22:46 +0200

Hi, 

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

Yes, but the policy could also be in the network, because the UA may simply not know whether one or multiple flows are required in order to achieve reliability. Like I said earlier, there may be systems where you can achieve reliability with a single IP address.

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

I have nothing against that. But, I still think it would be useful if the network could tell the client how many flows it wants to client to establish (then it is an implementation issue what happens if the client does not establish the numbers of flows it's asked to).

Regards,

Christer

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
>  
> 
> Sent: 14. kesäkuuta 2006 11:24
>  > 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
> 
> 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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Jun 2006 10:25:22 +0200

Hi, 

>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

>From: ext Paul Kyzivat [mailto:[email-masked]]
>Sent: 15.June.2006 01:42
>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
>
>> 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.
>> 
>>  > 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.
>>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Jun 2006 10:31:19 +0200

Hi, 

> need to be reconciled somehow. But I don't see 
>>why that should be wired  into this specification.
>if you don't wire it in the spec that UA must keep more than flow open
when there is more than one outbound proxy 
>defined, then it will VERY likely happen that UA vendors make outbound
implementations that are NOT capable of keeping 
>more than one flow open and still they can claim outbound compliance.

There are a number of 100rel compliant products out there - do they all
support offer/answer with PRACK? :)

Seriously, I think the make-sure-a-product-is-compliant issue should be
solved in another way. The only thing we can say in the spec is that a
client must be ABLE to establish more than one flow.

>>IMO it would be sufficient to specify a default that SHOULD apply
unless  > there is explicit policy to the contrary.
>that would be acceptable if EVERY implementation that claims outbound
compatibility IS CAPABLE of keeping more than flow 
>open and will do so unless manually overridden.  wording of this must
be made very clear in the spec.

Yes.

>>Outbound is still useful for nat traversal.)
>is not true, because as i have told on this list at least four times
already, NAT traversal can and is successfully 
>handled from proxy's end.  so the only REAL added value of outbound is
reliability.

Outbound, using STUN for keep-alives, also allows you to detect if a NAT
has rebooted, which is also one type of reliability. But, you don't need
multiple flows for that.

Regards,

Christer

---

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

Hi Mike,

We can discuss whether the network MUST provide max-flows, or if MAY/SHOULD/RECOMMENDED is enough (in which case the terminal decideds how many flows it creates, based on configuration or a default value), but otherwise what you say sounds like my proposal.

Regards,

Christer 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: 15. kesäkuuta 2006 16: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:

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

> Sent: Thursday, June 15, 2006 4:25 AM
> To: [email-masked]; Paul Kyzivat (pkyzivat)
> Cc: Cullen Jennings (fluffy); [email-masked]; [email-masked]
> >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
> 
> 
> 
>