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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Mar 2006 00:04:56 -0500

Miki,

Sorry to be slow in responding. I've been distracted by my day job 
lately. Comments inline.

	Paul

miki hasebe wrote:
> 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.

So you are saying that the Cancel doesn't appear because its actions 
only indirectly affect the dialog by causing a 487 response to the 
INVITE, and that *is* handled by the state machine???

I guess that makes sense on the UAC side. But on the UAS side shouldn't 
the CANCEL potentially (optionally) trigger state transitions to cause 
the invite transaction to be cancelled?

>>- 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.

I want to think about this more, and maybe discuss with you. I think at 
least it would be helpful to explain this thinking in the document.

>>- 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.

I got lost in the above. But I don't feel very knowledgable about this 
ACK transmission stuff.

>>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.

Oh. I probably just stupidly misinterpretted it. I need to go check 
again. Unfortunately I am sitting on an airplane now, and I find I don't 
have the current version of the draft on my computer. (I always save 
these but this time I apparently didn't.) So will have to do later.

>>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.

Ah, yes - now I understand. :-)

>>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.

I think that should be fine.

>>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.

Again, this is an area I don't know much about. I would like to hear 
from somebody else who is.

>>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?

Yes. There might not be a conference (yet). But when the 2nd 200 
arrives, Alice may choose to establish a conference. Or to send a BYE. 
Either way, it is up to Alice to do this. Alice needs to retain enough 
state to recognize this case.

>>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