Subject: RE: [SIP] RE: [Sip-implementors] Interpretation of break in TCP connection

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Mar 2001 00:36:10 -0500

> -----Original Message-----
> From: Benny Prijono [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 10:38 AM
> To: Jonathan Rosenberg
> Cc: 'Jo Hornsby'; [email-masked]; [email-masked]'
> Subject: Re: [SIP] RE: [Sip-implementors] Interpretation of 
> break in TCP
> connection
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > I suspect there is no implementation which uses TCP, and 
> actively closes
> > connections prematurely instead of cancelling. Similarly, I 
> suspect there
> > are no servers which close TCP connections instead of 
> explicitly sending a
> > 500. If my suspicions are correct, we can safely remove 
> this capability from
> > SIP. I think it adds little value. If a client crashes 
> before a transaction
> > completes, the server will know it when it tries to re-open 
> the connection
> > to send the response. Simiarlly, if a client sends a 
> request, and the server
> > crashes during the transaction, and there is no backup, the client
> > transaction will timeout.
> > 
> > Comments?
> > 
> 
> This is a very good thing to do.
> 
> But this might not be backward compatible. A server which conforms to
> the new behaviour might close TCP connection (for a very odd reason),
> and assumes that it would not change transaction state. But it does
> change the transaction state, if the client conforms to the old (i.e.
> current) behaviour. So there will be state inconsistency between
> client and server.

Backwards compatibility is best defined as this: the behavior of the system
when there is a mix of bis and rfc2543 devices is the same as, or better
than, the case where every device was rfc2543 compliant.

Consider this case. If both the client and server were rfc2543 only, the
result of the server closing the connection early is call failure.

In this case above, the result of closing the connection will also be call
failure. The transaction in progress may generate a final response, which
the proxy tries to send to the client, but it will be ignored. The end
result, though, is the same. Call failure.

If both are bis compliant, the call can still complete. 

The wording should probably say not to gratuitously close connections,
because it will cause call failure with rfc2543 clients. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.