Hi,
Refering to bis03:
The definition of a transaction is
"... all messages from the first request
sent from the client to the server up to a final (non-1xx)
response sent from the server to the client. A transaction
is identified by the CSeq sequence number (Section 10.20)
within a single call leg ..."
Consider the scenario that I am a UAC, I send an INVITE to my outbound
proxy. The proxy forks it to n other servers.
Now, I could end up getting n 18Xs ( or even n 200 ) responses. All
these will have the same Cseq no. So, do all these 18Xs & 200s form a
part of the same transaction? Going by definition the transaction
should end the moment it gets the first 200. Which means the other 200s
belong to a NULL ( already deleted) transaction!
Also, I as the UAC don't know how many people the proxy had forked the
request to. So, for how long should I maintain the state of the
transaction, I could get n 180s for that transaction. I don't know
whether the 200s belong to the same transaction or not.
The draft 03 on pg. 121 says "Responses are processed as follows. The
process completes (and state
can be freed) when all requests have been answered by final status
responses (for unicast) or 60 seconds have elapsed (for multicast). "
But this is for the proxy, he knows to how many people he has forked the
request to. What about the UAC, I as a UAC also have to process the
multiple 18X/200 responses the proxy might send to me. For how long
should I keep the state of the transaction & even the call, just to
respond to these multiple responses.
I can not wait infinitely, or should I destroy the transaction state
immediately upon getting the first 200. But then what about the next
200s that can follow. It is even possible that I could have destroyed
the call context and even after that I keep receiving 200s for an INVITE
that the proxy forked. I can't even keep expecting processing 200s for a
call in active/deleted phase forever.
--
Regards,
Harpreet Ahluwalia,
Consultant,
Lucent Technologies
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
