Subject: [Sipping] Re: draft-hasebe-sipping-exceptional-procedure-example-03

From: miki hasebe <[email-masked]>
Date: Sun, 19 Mar 2006 10:40:18 +0900

Paul,

Thank you for review and comments.

> Miki,
> 
> I reviewed this document. It is a very valuable piece of work, and it is 
> much improved from the last version. This is a difficult subject to 
> present in a way that people can understand.
> 
> Here are some notes I took as I was going through the draft.
> 
> 	Paul
> 
> Regarding Figure 1:
> 
> - I know this is intended to be similar to, but more complete than, the 
> corresponding diagram used by the dialog event package. That diagram 
> covers both the UAC and UAS, and is neutral about whether a transition 
> means the sending or receipt of a message. In some cases it doesn't 
> matter. But for some of the details you are trying to cover it does 
> matter. It might be helpful to add to the label of each transition an 
> indication of whether it is the sending or receipt of the message, or 
> both. (Both could be the default.) Or perhaps for your purposes it would 
> be clearer to have different elaborations of the diagram for the UAC and 
> UAS.

The figure of dialog state transition has been created referring to RFC4235,
and has been simplified by undistinguish sending and receiving.
I will try to consider and draw the diagram for UAC and UAS for each.

> - your diagram deviates from the one on dialog event package in some 
> ways that I don't think you intend. These confused me. First, you don't 
> mention CANCEL at all. And second, the 1xx transition from Early and the 
> 2xx transition from Moratorium don't mention that they create a new 
> state machine. I had to go back to RFC4235 to figure out what those 
> transitions were about.

CANCEL is to require the cancellation to the user of ini-INVITE,
which means CANCEL doesn't change the dialog state.
Dialog enters the Mortal state after UAS sends a 487.
487 response is the trigger for the transition, not the CANCEL.
I think CANCEL doesn't appear on the figure of dialog state.

> - I think a transition is missing on 2xx from Established - creating a 
> new state machine and another dialog.

I will add creating a new state machine by 1xx and 2xx like RFC4235 to
avoid modeling of dialog state is complicated by forking.

> - I believe some messages can be received while in the Morgue state, but 
> all would leave the state unchanged. For instance a UAS could get into 
> the Morgue state by sending a 4xx and still receive an UPDATE.

I think UAS may receive UPDATE after it sends 4xx and enters Morgue state.
However, UAS doesn't have dialog state and session anymore in the Morgue state,
so UAS will return a 481 response to the UPDATE.

> - I was expecting to see CANCEL as a transition in the diagram, but I 
> don't. Is there a reason?

Yes. it's because of the following reasons.
I think CANCEL is not the message which directly changes the dialog state
but the one which influence the transaction.
I think 487 (Request Terminated) is the trigger to change the dialog state.
And the 487 is pulled out by CANCEL,but the CANCEL itself dose not change
the dialog state

It is thought that processing of SIP protocol is divided into three layers,
transaction level, dialog level and session level.
CANCEL itself act on the transaction level.
However, CANCEL in the Ealry state act as a cancel request on the session
level as well as on the transaction level.
In the result of that, a dialog still remains even though session is
terminated, if CANCEL results in failure and dialog becomes established.
I think this is why a BYE has to be sent on the dialog level in such a
situation.

> - the Mortal state is entered on BYE, but has an internal BYE transision 
> as well. I think this can only happen if one is sent and the other is 
> received. Is that the intent? Its not clear.

I mean dialog enters the Mortal state on sending a BYE, and internal
BYE transition occurs when UA receives a BYE from other UA.
In the next version, I'll add "sending/receiving of the message" and the like,
and make it easy to understand.

> - I don't see UPDATE anywhere. Seems like it should be mentioned.

I'll mention UPDATE in the body text of next version.
I think UPDATE doesn't influence dialog state and it acts on the session level.
Perhaps, UPDATE is related to the race condition of the session level.

> - how does this diagram apply to reINVITE? For instance, once 
> established, it is possible to send or receive a reINVITE, and then send 
> or receive a BYE before the reINVITE has completed. That is another kind 
> of "race" condition that might be useful to clarify.

Re-INVITE as well as UPDATE doesn't influence the dialog state,
and it is related to the race condition of the session level.

> Regarding notes on the dialog states:
> 
> - Proceeding: the text says a CANCEL may be sent. But the diagram shows 
> no CANCEL transitions.

About the dealing of CANCEL, see above. 

> - Early: says "UAC may send CANCEL in Proceeding state". Perhaps this is 
> a type and should say "... Early state"??? I think there should be a 
> transition from this state on CANCEL.

I'll fix it.
About the dealing of CANCEL, see above. 

> Section 3:
> 
> - I don't understand why the paragraph beginning "In case that CANCEL" 
> is here. It seems out of place. Perhaps it was intended to be part of 
> one of the state descriptions above.

Yes, you're true. I'll fix it in the next revision.

> Section 3.1.1:
> 
> It might be helpful to note that for messages F3 and F4 Alice and Bob 
> are in inconsistent states.

I'll add more explanation of inconsistent states in the next revision.

> Section 3.1.3:
> 
> I was trying to follow the changing dialog statea of alice and bob 
> through this flow and relate it to the messages. But it wasn't entirely 
> clear to me. Mostly it is the impact of CANCEL that isn't clear. I think 
> it is natural to want to use the state diagram as a guide to 
> understanding the flows, so it might be good to help the reader out by 
> mentioning the states during the discussion of the flow. (In all the 
> examples.)

I'll enhance the explanation of all examples in the next revision.
(I couldn't handle the modification of explanation of each example.)

> Section 3.1.4:
> 
> Is it really true that an ACK is not to be sent in this case? (I was 
> thinking it should be, but I don't understand the details of this and am 
> willing to trust you on it.)

I agree with you.
In the Mortal State, I think the TU can't send any request.
So, I don't think that UA needs to send ACK to 2xx in this case, because
the ACK should be a new request message transaction in the Mortal State.
When UAC receives a 3xx-6xx response message, transaction layer of UAC
has to send ACK message in the same INVITE transaction.
Only when UAC receives a 2xx response message, TU of UAC can (will) send
ACK message with establishing a new ACK transaction.

> Section 3.1.5:
> 
> Is F6 really a reINVITE? Isn't it a retransmission of F1? or is it 
> technically a reINVITE because F3 ended the transaction for F1? Isn't it 
> supposed to trigger a retransmission of F4 rather than sending a fresh 
> ACK? (Again this is something I don't know well, so I am asking to be 
> educated.)

F6 is sure to be re-INVITE.
(The situation occurs when the user push the HOLD button of the phone soon
after the call is established. In this case, re-INVITE will be sent soon
after the ACK is sent.)

If ACK message, which transports an answer, is lost and re-INVITE reaches
UAS earlier than the ACK, TU should return 491 to the re-INVITE because
the offer/answer has not been completed yet.

I think that the re-INVITE could be taken for an acknowledgement of reaching 200 OK in place of ACK message, and I wrote the idea on the Editor's Note.
I'm sorry if this note confuse you.

> Section 3.2.1:
> 
> I can't quite understand what the following sentence is trying to tell 
> me: "As shown in section 2, UA remains in Mortal state after sending a 
> BYE until sending a BYE to actually terminating the dialog."

Well, I mean the following. I'll modify the sentence in the next revision.

As shown in section 2, UA remains in Mortal state for a while after sending
a BYE, until the BYE transaction times out and UA transits to the Mortal state.

> Later in the same paragraph is "UAs in Mortal state return error 
> responses to the requests that operate dialog or session, such as 
> re-INVITE, or REFER. Exception is a BYE message. UA shall return 200 OK 
> to the BYE because it can give the dialog in Mortal State a finishing 
> stroke and send it to the Morgue." This seems to cover valid cases as 
> well as invalid ones. If Mortal state was entered by *receiving* a BYE, 
> the receiving another BYE is an error. (Though there may be nothing 
> better to do in that case than ignore it.) Seems like the basic rule is 
> that its always ok to receive *one* BYE, but receiving more is 
> erroneous. (Its hard to show that in a state machine - need to introduce 
> another state. Maybe its sufficient to mention in the text.

In the next version, I'll add the new example of UA's behavior in the case
which UA receives multiple BYEs in the Mortal State.

> Section 3.2.3:
> 
> I am afraid this example brings up the ugly issue of dialog usages. I 
> know you wanted to stay away from that subject, so we should discuss the 
> extent to which we can.
> 
> Your state machine is really for an invite dialog usage, not a dialog. 
> In the current example, you say (in comment to F6): "Bob sends a REFER 
> on the INVITE dialog. The state of dialog transits to Mortal state at 
> the moment Alice sends a BYE..."
> 
> This is at least a little misleading. There are multiple things going on 
> here:
> - the REFER is sent sharing the dialog with the invite dialog usage
> - the REFER implicitly *references* the invite dialog usage. The
>    implication is that the resulting INVITE should replace that usage.
> - the 481 response has been designed in a way that is overloaded.
>    It could actually arise in two ways from this request:
>    - the dialog itself could be gone, and so the refer that is
>      trying to use it is rejected
>    - the invite dialog usage that is implicitly referenced is gone,
>      and the REFER is then rejected because of that.
> 
> A dialog can't go away until all its usages have gotten to a state where 
> they no longer depend on the dialog. The invite dialog usage will have 
> to be in the Morgue before the dialog can go away. (If it went away in 
> the Mortal state the BYE couldn't be received.) So I think in this case 
> the dialog will still be present when the REFER is received, so that 
> can't be the reason for the 481. Instead, the 481 occurs for the second 
> reason I listed above - for the same reason that messages that belong in 
> the invite dialog usage (like UPDATE) are rejected while in the Mortal 
> state.

I don't mean to deal with dialog usage on the race condition draft,
 but I agree that I need to fix the description about the dialog usage,
because this example deals with REFER. I'll modify it as "REFER will
fail because something implicitly referenced is gone in the Mortal State."
Your comment makes me think that REFER's example is in the race condition
of the session level, not the dialog level. 
This sequence may be classified into section 3.3.

> Note that the same failure would occur if the REFER were send 
> out-of-dialog and contained the new Target-Dialog header to reference 
> the call to be replaced. (But this does point up a problem with 
> Target-Dialog that I hadn't considered before. The REFER needs to 
> identify a target dialog usage, but Target-Dialog only identifies the 
> dialog. The processing of REFER must figure out that an INVITE is to be 
> generated and so it is the invite dialog usage that is of interest.)

> 
> I am not certain how best to change this so it is not confusing or 
> misleading and yet avoid deep involvement in the dialog usage discussion.

About this example, I agree that I need to correct the description
considering the dialog usage. I want to add the note of "Further
discussions about the Dialog Usage are described on the dialog usage
draft.", and avoid dealing with the topic.

> Section 3.2.4: I think there is something subtley wrong here. Suppose 
> that the BYE (F6) was lost. In that case, Alice would keep 
> retransmitting F7, expecting an ACK. As a result, I think it must be the 
> receipt of F8 rather than the sending of F6 that causes bob to supress 
> the sending of ACKs. If so, then since F7 is received before F8, I would 
> expect to see an ACK sent.

I think that the Mortal State is the one in which
the TU can't send any request.
When UAC of INVITE receives a 3xx-6xx response message,
transaction layer of UAC shall send ACK message.
Only when UAC of INVITE receives a 2xx response message,
TU of UAC can send ACK message.
So, I think that UA doesn't need to send ACK to 2xx in the Mortal State.

Again, I think retransmittings F7 are generated by TU of Alice,
and I believe TU can understand dialog state machine.
If so, Alice will stop retransmittings caused by getting BYE from Bob.
Even if Alice does not stop retransmitting, just timeout shall occur
without race conditions.

> Section 3.3.1:
> 
> I think you imply that after receiving F18 Alice should terminate the 
> early dialog with Bob. In this case that is indeed the correct thing to 
> do. But suppose the cancel had failed. It is possible that sometime 
> after F18 Bob will return a 200 response. Alice must be prepared for 
> that. It is likely that Alice would then just send a BYE to Bob. But 
> that is not required - e.g. when there are multiple 2xx responses Alice 
> could conference them all together. So Alice may not want to terminate 
> early dialogs until enough time has passed that the invite transaction 
> would have timed out.

As you mentioned, UA receives and handles multiple 200 OKs when it has
a conference.
Do you mean a forking proxy sends multiple 200 OKs with different to-tags
to UAC?

> Section 3.3.3: This seems fine. But it might be worth a note that Bob 
> must not blindly retransmit F6 as F14. The changes resulting from 
> F11-F13 most likely will impact what should be included in F14, and may 
> well entirely eliminate the need for F14.

I agree. I haven't noticed that. I'll add it in the next revision.
It may be thought that the race condition in F5-F9 is resolved by answer in F11.
To clarify the behavior of UAS, I will leave the sequence and add a note.

----
There is no more to it.

Best Regards,
Miki Hasebe
---------------------------------------------------------
Miki HASEBE
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 1236
E-mail: [email-masked]
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
---------------------------------------------------------

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP