Subject: Re: [SIP] Retransmissions

From: [email-masked]
Date: Wed, 31 May 2000 09:10:53 +0530

On the contrary, the fact that I let all transactions complete their normal
way has imho, made our client development
much easier. This has meant that our transaction request-response code
remains usually intact, and hence,  we do not
really have to maintain cross-related state - only one transaction state
and still be able to support BYE and more importantly CANCEL.

Further, there is a bigger issue for not having the transaction complete as
you mention.
Lets suppose client A sends an INVITE to client B through proxy P.
Now again, lets assume that B returned A a contact address for further
requests - which happens to be the direct address of B.
Then that would mean that A would send its future request directly to B
without P (Assuming a simple proxy that does not do
record-route).

What would then happen is that when A sent a BYE directly to B , the proxy
would have no idea that the pending transaction
of INVITE is no longer valid - and would not have any option but to wait
for a regular timeout to happen before it could flush
the old INVITE out. This is certainly not a good situation.

The beauty, imho, of letting *all* transactions complete is that no
inbetween node is left hanging in between a transaction
state unnecessarily.

The merits of transaction completeness, I feel, over-weigh message
optimisation.

Regs
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems

Billy Biggs wrote:

 I do hate to beat on this more, but...

  In the case where you get an INVITE and then a BYE with a higher CSeq,
it seems really silly to have to keep around state for both of these
transactions on the call leg.  Why bother with the INVITE transaction at
all?  The far end has cancelled it anyways?  That just seems like more
unnecessary state to keep in my code.

  It seems more important to me to worry about keeping the endpoints
simple rather than the proxies, otherwise it's going to take everyone
alot longer to implement good clients.  Proxies can afford more bloat
than endpoints: let them time out or be smarter with the CSeqs.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip