Subject: [Sip] Outbound and multiple connections

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 08 Jul 2006 18:09:38 -0400

I have been watching this ongoing discussion with some bemusement.
It appears that there are two very different views of the purpose for 
the multiple connections specified in 
draft-ietf-sip-outbound-04.txt.  There also seems to be some 
discrepancies about where the multiple connections go.

With regard to purpose, the question I see is whether the reliability 
is for the clients benefit, or the networks.  If it is for the 
client's benefit, then as has been suggested the client should be 
able to choose whether to take advantage of it or not.  The multiple 
connections ought not be MUST strength.  On the other hand, if it is 
a mechanism to enable the network to offer better service 
(particularly, better service to incoming requests) then the network 
would reasonably expect the multiple connections, and so the usage 
should be a MUST.
--Personally, I think that network techniques for providing 
reliability are the network's job / business, and so the multiple 
connections are about the clients desire for reliability, and ought 
to be SHOULD, or even MAY strength.

I believe that the above alternatives lead to confusion about the 
draft.  Further, I think that there is related confusion about the 
usage of the multiple connections.

I note that the wording of the draft is very fuzzy as to whether the 
multiple connections are to the same server, multiple "closely 
coupled" servers, or distinct servers.  I had assumed that the 
connections would be to distinct servers.  However, re-reading the 
draft I see wording like (3.1) "it [proxy] can use any one of the 
flows on which a successful registration has been completed."  For a 
proxy to have several flows would imply that the client connected to 
the same server multiple times.  is in order.  Wording in section 3.2 
also talks about the proxy, which is the registrar, having multiple 
connections to the target.
I suspect that all the wording about a single registrar is to be 
interpreted in conjunction with the example case (3.3) of a single 
registrar that is actually two "closely coupled" hosts.  This is a 
perfectly reasonable deployment.
However, I think we would be much better off describing this as if it 
were two registrars, and indicating that coordination among the 
registrars is outside of the scope of this draft.  And we ought not 
require that they be closely coupled.
Whatever the actual intent of the authors of 3.1, 3.2, and 3.3, we 
need to decide what we want it to mean, and clarify the wording so 
that it says that, clearly.

Yours,
Joel M. Halpern

PS: I believe the reference in section 4.4 to "Section 4.2 to form a 
new flow" is actually a reference to 4.4.2?

_______________________________________________
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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 10 Jul 2006 10:43:18 -0400

I wonder if the author is using an IMS orientation where the client
attaches to different edge proxies, but the same registrar proxy, but
that all gets conflated to talking about a "proxy".  

In any case, good writing technique would suggest scanning a draft and
replacing all instances of "it" with whatever "it" is.  Saving a couple
characters is a bad trade-off for the confusion that often ensues.

Mike

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Saturday, July 08, 2006 6:10 PM
> To: [email-masked]
> Subject: [Sip] Outbound and multiple connections
> 
> It appears that there are two very different views of the 
> purpose for the multiple connections specified in 
> With regard to purpose, the question I see is whether the 
> reliability is for the clients benefit, or the networks.  If 
> it is for the client's benefit, then as has been suggested 
> the client should be able to choose whether to take advantage 
> of it or not.  The multiple connections ought not be MUST 
> strength.  On the other hand, if it is a mechanism to enable 
> the network to offer better service (particularly, better 
> service to incoming requests) then the network would 
> reasonably expect the multiple connections, and so the usage 
> should be a MUST.
> reliability are the network's job / business, and so the 
> multiple connections are about the clients desire for 
> reliability, and ought to be SHOULD, or even MAY strength.
> 
> I believe that the above alternatives lead to confusion about 
> the draft.  Further, I think that there is related confusion 
> about the usage of the multiple connections.
> 
> I note that the wording of the draft is very fuzzy as to 
> whether the multiple connections are to the same server, 
> multiple "closely coupled" servers, or distinct servers.  I 
> had assumed that the connections would be to distinct 
> servers.  However, re-reading the draft I see wording like 
> (3.1) "it [proxy] can use any one of the flows on which a 
> successful registration has been completed."  For a proxy to 
> have several flows would imply that the client connected to 
> the same server multiple times.  is in order.  Wording in 
> section 3.2 also talks about the proxy, which is the 
> registrar, having multiple connections to the target.
> I suspect that all the wording about a single registrar is to 
> be interpreted in conjunction with the example case (3.3) of 
> a single registrar that is actually two "closely coupled" 
> hosts.  This is a perfectly reasonable deployment.
> However, I think we would be much better off describing this 
> as if it were two registrars, and indicating that 
> coordination among the registrars is outside of the scope of 
> this draft.  And we ought not require that they be closely coupled.
> Whatever the actual intent of the authors of 3.1, 3.2, and 
> 3.3, we need to decide what we want it to mean, and clarify 
> the wording so that it says that, clearly.
> 
> Yours,
> Joel M. Halpern
> 
> PS: I believe the reference in section 4.4 to "Section 4.2 to 
> form a new flow" is actually a reference to 4.4.2?
> 
> 
>