Subject: [SIP] Clarification to Figure 13 Bis Draft

From: Phil Hoffer <[email-masked]>
Date: Fri, 05 May 2000 11:05:26 +0100

Hi All,

I think we all agree that the Bis draft is infinitely more readable than the
plain text forerunner. A big improvement.

As a result of the improved readability, I require a clarification to Figure 13
in section 11, which documents a State Transition Diagram of server for
INVITE Method.

My confusion mainly centres around the Failure state and subsequent
transitions.

1) If the Failure state receives an ACK, a transition to Confirmed occurs.
This doesn't make sense to me as there is now no way to revert to Initial
state. I can see how this works for the Success state, as the BYE event,
as a result of a hangup, causes the transition to Initial state.

Perhaps the ACK event in the Failure state should cause a transition to
Initial state?

2) A transition from Failure state to Initial state is shown on the diagram, as
a dashed line. Unfortunately, this transition is unlabelled. I'm referring
to the left hand dashed line, not the BYE event which joins the Success
dashed line.

3) Does the diagram need to be modified in light of changes in section
4.2.5 CANCEL, which talks about the issuing of a 487 (Request Cancelled)?
Presumably the 487 response is the response to the original INVITE, and a
separate 200 is issued as a response to the CANCEL?

4) This leads me into more questions about Cancel in section 4.2.5.
The draft states ....

"A redirect or user agent server receiving a CANCEL request responds with a
status of 200 (OK) if the transaction exists and a status of 481 (Transaction Does
Not Exist) if not, but takes no further action. In particular, any existing calls is
unaffected"

What defines "transaction does not exist" from a user agent server perspective?
Is a transaction deemed to be non-existent if the user agent server has issued
a final response?

If so then the Failure and Success states in Figure 13, presumably should issue
481 (Transaction Does Exist) as a result of CANCEL request?

The user agent client is then left with two scenarios:

a) Call failed at user agent server after Cancel was sent, so ACK >= 300 response
b) Call succeeded at user agent server after Cancel was sent, so ACK the 200
response, and issue BYE to terminate call.

So many questions, I hope that you will be able to follow my thread. :-)

Thanks In Advance
Phil

--
Ubiquity Software Corporation           http://www.ubiquity.net

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 08 May 2000 01:19:38 -0400

> plain text forerunner. A big improvement.

Well, we had a postscript version for rfc2543 also, but decided not to
make it available. Unfortunately, it is very difficult to guarantee
consistency between the ASCII and PS versions. As the ASCII version is
the absolutely correct one, we stuck with that. The next SIP revision
will be the same; the final version (as will all RFCs) will be ascii
text.

> in section 11, which documents a State Transition Diagram of server for

Actually, I believe this diagram is confusing partly because it is
combining two things - call state and transaction state. The INVITE
transaction and BYE transactions are totally separate as far as
retransmissions and the like are concerned. Each has its own state
machinery. There is also a state machine for the call. This machine
tracks the INVITE transaction state, but eventually is different once
the transaction completes.

> Perhaps the ACK event in the Failure state should cause a transition to

Again, confusing because two things are being combined. The INVITE
transaction, upon moving to confirmed, should stay there for some amount
of time, around 32s. This isn't really critical. Its main point is to
make sure that any additional ACKs are treated as retransmissions. If
the server machine moved immediately from failure to confirmed and then
initial when an ACK came, the next ACK would appear as a "stray" ACK
since the transaction state no longer exists. Stray ACKs are anyway not
a big deal, but it helps to keep the state around to make sure they all
get absorbed.

> to the left hand dashed line, not the BYE event which joins the Success

Hmm. not sure, actually. The labeling would make this appear to be
CANCEL, but thats not correct. Henning?

> separate 200 is issued as a response to the CANCEL?

Definitely. I believe it also needs to be reworked considering the
separation of transaction state from call state. The 487 response to the
original INVITE is an example of this separation.

> Is a transaction deemed to be non-existent if the user agent server has issued

Transaction doesn't exist means that the UA has no current state at all
for the transaction identified by the CANCEL. If the server has sent a
final response, but knows about the transaction, its not a 481, but a
200 OK.

> 481 (Transaction Does Exist) as a result of CANCEL request?

No.

> response, and issue BYE to terminate call.

Yes. Same behavior as if there was no CANCEL, pretty much. Thats the
whole idea - CANCEL "speeds things up" in getting a response from the
UAS.

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

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

---

From: Phil Hoffer <[email-masked]>
Date: Mon, 08 May 2000 09:42:02 +0100

> Phil Hoffer wrote:

<snip>

> > in section 11, which documents a State Transition Diagram of server for

<snip>

> CANCEL, but thats not correct. Henning?

Presumably this unlabelled event could be a CANCEL as they UAC
might have issued the CANCEL when the UAS was in Call Proceeding
state. So the >= 300 response could cross the incoming CANCEL on
the wire. Therefore a CANCEL could arrive in the Failure state. ??!!

What do you think?

Thanks In Advance

--
Phil Hoffer                         Ubiquity Software Corporation
Software Developer                  Ubiquity House
Tel: +44 (0) 1633-765600            Langstone Park
Fax: +44 (0) 1633-765601            Newport   NP18 2LH
URL: http://www.ubiquity.net

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 May 2000 18:10:36 -0400

> the wire. Therefore a CANCEL could arrive in the Failure state. ??!!

Yes, but in this case the next state is not Initial. You've already sent
the response, and need to retransmit until the ACK comes.

-Jonathan R.