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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jun 2006 18:42:25 -0400

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

---

From: <[email-masked]>
Date: Thu, 15 Jun 2006 11:01:50 +0300

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 ?

Regards,

Erkki

>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?
>
>> 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: Juha Heinanen <[email-masked]>
Date: Thu, 15 Jun 2006 11:57:31 +0300

> e.g. in order to save battery or some other policy related reasons.

that is fine with me as long as it is NOT POSSIBLE to build a outbound
compliant UA that is able to keep only one flow open.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 15 Jun 2006 10:00:08 +0300

> need to be reconciled somehow. But I don't see why that should be wired 

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

your note that

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

-- juha