Seems like a fine idea to me.
Cheers, Charles
Michael Hammer (mhammer) wrote:
Charles,
OK, I give up. I found the requirement in 13.2.2.4 that requires an ACK for every 200 OK INVITE sent. So, effectively the sole purpose of the ACK is simply 200 OK suppression.
However, I would note that the behavior of a UAC sending a CANCEL, then receiving a 200 OK triggering immediately sending a BYE should be documented. I can't find it in RFC-3261. The closest it comes is in Section 13.2.2.4 last paragraph. But, based on other parts of 3261, the UAC could have concluded that it already did release the dialog and already be gone.
So the above will be documented in the exception examples draft?
Mike
-----Original Message-----
From: Charles Eckel (eckelcu) Sent: Tuesday, April 05, 2005 12:07 PM
To: Michael Hammer (mhammer)
Cc: Malleswara Rao Ankem; [email protected]; [email protected]; Miki HASEBE
Subject: Re: [Sipping] RE: Semi Regular Examples draft
I agree with the statement about having to send the BYE, except that you need the send the ACK first. More inline.
Michael Hammer (mhammer) wrote:
But, this leaves us in a state where:
UAC:
Sent CANCEL, receives 200 OK INVITE, sent ACK, receives 200
OK CANCEL,
goes away.
It can't. It needs to send a BYE after sending the ACK, and needs retrans the ACK if it gets another 200 OK for the INVITE, and needs to retrans the BYE until it gets a 200 for the BYE (or times out trying). It all goes back to the underlying principle of every transaction completing independently.
UAS:
Sent 200 OK INVITE, receives CANCEL ***but doesn't act on
it***, sends
200 OK CANCEL, receives ACK, remains in active dialog.
Right, that is why the UAC needs to send the BYE.
Cheers, Charles
That can't be right. If it were, it would mean that the ACK
has no real
meaning and could be omitted.
The only part above that is not required by RFC-3261 is the
sending of
ACK. It is not so clear, but should be that getting a 200 OK INVITE after sending a CANCEL should immediately require a BYE to be sent. Also, in 14.2, it says a UAS that does not get an ACK (e.g. timesout) SHOULD send a BYE to terminate dialog.
Mike
>-----Original Message-----
>From: Malleswara Rao Ankem [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, April 05, 2005 12:51 AM
>To: Michael Hammer (mhammer)
>Cc: Miki HASEBE; [email protected]; [email protected]
>Subject: Re: [Sipping] RE: Semi Regular Examples draft
>
>Hi Michael,
>Some thoughts in line
>
>On Apr 4, 2005 9:08 PM, Michael Hammer (mhammer)
><[EMAIL PROTECTED]> wrote:
>> Miki,
>>
>> If we did cover this specific aspect before, it is probably
>in the SIP
>> email archive. But, to save time looking for that, let's
>look at this
>> closely now. Email below trimmed to specific issue. I
re-read the
>> note text in beginning of Section 15 of RFC-3261. It
addresses the
>> cleaning up state of the UAS, but does not discuss all possible
>> message sequences from the UAC. What the UAC sends and when
>is the main issue below.
>>
>> >-----Original Message-----
>> >From: Miki HASEBE [mailto:[EMAIL PROTECTED]
>> >Sent: Monday, April 04, 2005 7:59 AM
>> >To: Michael Hammer (mhammer)
>> >Cc: Kenneth Ho; Cullen Jennings (fluffy);
>> >[email protected]; Dean Willis; [email protected];
>> >Gonzalo Camarillo
>> >Subject: Semi Regular Examples draft
>>
>> [snip]
>>
>> >> 2) how you can send a CANCEL then ACK a 200 OK, (seems like a
>> >> retrans of CANCEL or a BYE would do the trick here)
>> >
>> >Considering notes about "hanging up" on chapter 15 of
RFC3261, this
>> >is considered to be the recommendation specification that the
>> >software in phones need to maintain state for a short while
>in order
>> >to clean up properly.
>> >
>> >Therefore, I think UAC should send ACK to the 200 OK.
>> >I think we would like to add the sequence to the draft, that is
>> >sending BYE soon after sending ACK.
>>
>> I still don't like sending the ACK after a CANCEL was sent. This
>> leads to the possibility that the CANCEL is lost (or 200 OK's
>> suppressing further CANCELs but not acted upon) and the ACK is
>> received, leading the UAS to think the dialog is really
>complete. The
>> only advantage you seem to get is that the UAS can now send
>a BYE, if
>> the called party hears nothing and decides to hang up. The
>down side
>> is that the UAC won't send another message since it will get
>a 200 OK
>> to CANCEL, and the UAS won't timeout, since it got the
ACK. So, the
>> called party listens to a mute call until he gets angry and
>hangs up. >> Not getting the ACK would give the UAS a clue that something
>is wrong. >> Also, once it times out waiting for the ACK, it could then
>send a BYE.
>
>a) Instead of sending a ACK the UAC can send a BYE (presuming
>that this would stop any retransmissions from the UAS side
>which is waiting for a ACK).
>b) Moreover, UAS MUST NOT send a BYE before it receives an ACK
>for its 200OK. So this is one of the reasons sending an ACK is
>not harmful as you say.
>
>regards
>Mallesh
>>
>> But, if the UAC sends a CANCEL, then receives a 200 OK
to INVITE, it
>> knows that the CANCEL was not received in time and will have
>no effect
>> on the UAS (see Section 9, p. 53, and 9.2, p. 55). Therefore, it
>> needs to immediately send a BYE. (Note: This is not covered in
>> Section 9.1, nor in Section 9.2 that only covers the
case of CANCEL
>> received before final response sent). By transitioning from
>> retransmissions of CANCELs to sending and retransmission
of BYEs the
>> UAC can be more assured of ending the call.
>>
>> Last, note that Section 9.2 says that a CANCEL is reponded
>with a 200
>> OK if it matches an existing transaction, which is the
case here.
>> This seems to be true whether it arrives before a final
response is
>> sent or after, even though no action will be taken on it.
>>
>> [snip]
>>
>> >> 4) If you receive a CANCEL, accept that and the fact that an
>> >ACK won't be forthcoming to the 200 OK. There is no sense
>trying to
>> >complete that dialog once both sides know it is going to fail.
>> >
>> >As you have pointed out, I also think that receiving
the CANCEL may
>> >be considered as failure of the dialog establishment.
>> >According to RFC3261, UAC MAY send a BYE in this situation.
>> >But surely UAS knows that the dialog establishment has
failed, so I
>> >would like to consider the recommendation of UAS behavior.
>>
>> [snip]
>>
>> My whole goal above is to not send the UAS mixed (contradictory)
>> signals. Let me know what you think.
>>
>> Mike
>>
>> _______________________________________________
>> Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use >> [email protected] for questions on current sip Use >> [email protected] for new developments of core SIP >> >
_______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use [email protected] for questions on current sip Use [email protected] for new developments of core SIP
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
