> -----Original Message-----
> From: Christer Holmberg [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 20, 2001 2:23 AM
> To: Vijay Gurbani
> Cc: Christian Jansson; Harpreet Ahluwalia;
> [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] multiple 2xxs
>
>
> >An INVITE will be "unbounded in time" if a 1xx ends up
> creating an "early"
> >call leg. If no further final responses arrive on that call
> leg (due to the
> >downstream proxies successfully CANCEL'ing those branches),
> then the UAC
> >can destroy these "early" call legs after a suitable delay.
>
> I had a look at the draft, and I didn't find anywhere written what the
> time should be.
>
> However, I do remember that issue was discussed on the list a
> while ago,
> so you may want to check the archieves. If I remember correctly it was
> discussed that this is pretty much an implementation issue.
> For example,
> some people always ACK every final response to an INVITE (and
> then also
> sends BYE if it was a 200 final response), even if the client
> never sent
> an INVITE in the first place.
THere are two cases here. The first is, how long should the UAC wait between
receiving a 1xx for an initial INVITE until it gives up. The answer to that
is that its an implementation choice - how long do you let the phone ring?
The second case is the one where once you receive a 2xx, how long do you
wait before terminating the transaction? Well, the first 2xx SHOULD trigger
a CANCEL in proxies (now that I changed the text to that - the UAC can
always do that on its own, but its a waste since it doesn't know if a
downstream proxy forked). So, the only case to worry about is when that
CANCEL passes another 2xx on the wire. In the event of no errors, this 2xx
will pretty much arrive immediately. But, network problems could cause it to
be lost. If it doesn't arrive in 16 seconds (the amount of time between
sending the first 2xx and the last at the UAS), it will never arrive. So,
the answer is, 16s is the maximum time to wait at the UAS.
But, you need to wait that long anyway to handle reliability for that first
2xx. So, there is no time or state penalty for this.
>
> I do think this should be mentioned in the draft, though.
I will add text.
Harpreet writes:
> 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!
This definition is definitely confusing, mostly because this multiple-200 OK
thing is confusing and screwy. Sigh....
The definition as written is not consistent. If you consider a transaction
to be significant in that its associated with an FSM, you really have to
include the ACK in that because it has an impact on transaction processing
(although one can build it differently). In that case, a transaction
consists of a request, any provisional responses to that request, and a
single final response to it, plus the ACK for that final response. This
would further imply that multiple 2xx effectively cause a transaction to
"fork", since each 2xx has its own ACK, and therefore, constitute a separate
transaction. Now, one need not implement it this way, but at the moment its
probably a more correct definition than what is written.
Now, if you consider a transaction is a request, any responses to it, and
any ACKs for those responses, thats OK too; you would need to strike the bit
about call legs (you need to do that also for the above definition). This
definition of transaction is less useful, though, but probably closer to
what more people have implemented.
-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
