Subject: [Sip] draft-ietf-sip-connect-reuse: proposal source-alias parameter

From: "Brett Tate" <[email-masked]>
Date: Fri, 23 Sep 2005 17:00:50 -0400

Hello Rohan and the rest of the SIP community,

Draft-ietf-sip-connect-reuse is definitely useful 
to help reduce the number of open connections. 
As specified within version 4, using "alias" and 
sent-by definitely satisfies requirement 2 of 
the draft.  And when desired, it appears to allow 
a device to open multiple connections and allows 
the reuse of each connection to be based upon 
the provided sent-by.

However as currently specified (or my current 
understanding), I do not think the alias parameter 
totally satisfies requirement 1.  It requires the 
following to avoid a connection being opened in 
both directions.

1) It requires the opening device to pass requests 
for every possible alias to avoid the receiver 
from opening another connection.

2) It requires both devices to pass the alias 
parameter instead of just requiring one to pass 
it and both to support it.  I mention this mainly 
because the current solution does not provide a 
complete solution for clusters desiring a single 
connection between device and each cluster member while 
desiring the device to adhere to the SRV priority levels.

Additionally, alias adheres to the RFC 3261 requirement 
to send CANCEL and ACK for non-2xx response to the 
same ip-address and port.  Thus if the TCP connection 
is reclaimed, the CANCEL and ACK cannot be delivered 
while satisfying requirements 3 and 4.

I propose that Via parameter "source-alias" be added 
to indicate that all SIP messages directed towards the 
source ip-address and transport can be sent over this 
connection.  The port calculations should be performed 
per the "alias", RFC 3261, and RFC 3263.  However if 
the connection is not currently opened to the port, 
another connection to the ip-address for the same 
transport can be used.  This nullifies the port 
requirement of RFC 3261 for CANCEL, retries, and ACK for 
non-2xx responses.  The sender should take precautions 
to help ensure correct delivery order when multiple 
connections exist.

I have not followed the progression of the draft.  
Thus please forgive me if something similar has already 
been discussed or if there is something obviously 
wrong with the proposal.

Thanks in advance for a response,
Brett Tate

_______________________________________________
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