Subject: [Sipping] Semi Regular Examples draft

From: Miki HASEBE <[email-masked]>
Date: Mon, 04 Apr 2005 20:58:44 +0900

Mike,

Thank you for the comment.

> I'll confess I haven't read the draft yet, but the examples below seem to add to the confusion rather than suppress the confusion.  I am also assuming that this is UDP-based, not TCP-based SIP.  I don't understand:

Yes, they are the examples on UDP-based SIP. Applications like an IP
phone are assumed as a target, but it is not limited only to them.

> 1) how you can send a 200 OK to an INVITE and then later send a 4xx response to that INVITE,

I agree that any 4xx must not be transmitted after sending
200 OK as the response to the INVITE. The final response must not be
changed, once UAS has transmitted the final response.

I would like to clarify for avoiding misunderstandings.
What I would like to point out in the crossover sequence of CANCEL
and 200 OK (Chapter 2.1) is that the CANCEL is answered by 481(4xx)
when the CANCEL arrives after sending 200 OK as a last response 
to the INVITE.

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

> 3) Treat a retransmission of an INVITE as a new dialog until you have an ACK to the 200 OK with To: tag,
> (retransmissions must be recognizable and handled as such, i.e. retransmit the 200 OK)

Yes, I agree to your idea that re-transmitted INVITEs must be recognizable
as such.
There is a comment pointing out that UAS seems not to distinguish
between the re-transmitted INVITE after sending 200 OK and the new INVITE. 

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

I think that there were many discussions of the same kind in various places.
If you know the discussions relative to this draft, please let me know the pointer.
Your cooperation is appreciated.

thank you.

Miki

---------------------------------------------------------
Miki HASEBE
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 4768
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