please read the inline comments.
[EMAIL PROTECTED] wrote:
> >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!
>
> As you mentioned,"a transaction is identified by the Cseq number within a
> Call Leg."
> Whenever a proxy forks a request, the response for each request forms a
> different Call Leg.
> This is identified by the tag in the To Header of the response. So,CSeq
> within the Call Leg will
> uniquely identify a transaction.
Yeah, but the draft also says that the call leg starts when we get a 200, so
shouldn't the 180 (what Jonanthan described as an early call leg) that comes
before the 200 be associated with the original transaction, I mean every
response has to be associated with a Request and I as the UAC had given out
just one request (the proxy forked it). I sent one request and got two 180s,
now I have to associate the next 180 with the same request, so why is it not a
part of the same transaction??
Now when the 2nd 200 comes in, I still have to associate it with the only
request I had sent, so I still have to look at the same transaction context,
even though I may have to consider this now as a different call leg.
Also, what about the time factor, for how long can I the UAC, expect such
multiple 200s to come in. I have to keep the context of the original request
till then.
Harpreet
>
>
> >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.
>
> Now that you can match the response to the request with the To header
> tag which identifies a call leg, and cseq header which identifies a
> transaction within a call leg,the proxy can maintain state untill
> it recieves a final response for the request sent or if the retransmissions
> timeout.
>
> >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
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Regards,
Harpreet Ahluwalia
Lucent Technologies
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
