These questions were raised earlier in the list and I am attaching the responses from the draft's author - The receipt of final response does not negate the need to ensure that reliable provisional responses previously sent be acknowledged since the UAS may want to know that the information in those responses are received by the UAC. Also, retransmission of the reliable provisional responses and PRACK requests complete independent of the Canceled request. Seems pointless, but those are protocol rules. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Doug Hurtig Sent: Thursday, February 15, 2001 4:41 PM To: Christer Holmberg Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [SIP] Cancel of Invite and affect (if any) on prack and reliableprovisionalresponses Christer, Thanks for the response. Christer Holmberg wrote: > Hi, > > >Hi, > > > >I have a question related to what should the UAC and UAS do with > >outstanding PRACK requests and reliable provisional responses when the > >associated INVITE is canceled? > > > > UAC UAS > > > > INVITE --------------------------> > > > > <-------------------------- 100 provisional response > > <-------------------------- 18x reliable provisional > > response > > > > PRACK ------------> lost > > > > CANCEL --------------------------> > > > > > >At this point the UAC is waiting the 200 OK for CANCEL and will > >resend PRACK on time-out. UAS is awaiting PRACK for 18x and will resend > 18x > >on time-out. > > > >Should UAC abort the PRACK or let it continue? > > I see no reason why you would keep the PRACK alive, since you have > canceled your setup request. The problem is that if you simply kill your > transaction the UAS is going to re-transmit the 18x response until > timeout. One answer would be to also CANCEL to PRACK, but that is > related to the issue about if CANCEL is allowed for other requests than > INVITE... I agree with you. However, the 100Rel draft states that CANCEL of PRACK is not valid. > > > Also, you have a similar case if you receive the final respones to your > INVITE while you still have ongoing PRACK transactions. Why would you > then want to keep the PRACK transactions alive, since you (the UAC) > KNOWS you have received the provisional responses (otherwise you would > never have started the PRACK transaction), and you already have received > the final response? I think that CANCEL should be used here. > You are correct in that it does not seem to be the best use of resources to keep the PRACK's going. However, since CANCEL is not allowed can I assume that server will stop 18x retransmission at this point? May need to allow PRACKs to complete. > > Also (I have a number of issues on PRACK :), what should the UAS do, if > it get triggered to send a final response to the INVITE it received, but > it is still sending 18x provisional responses it hasn't received a PRACK > for? Maybe this is more an implementation issue, but I wanted to point > it out. Given the way the 100rel draft is currently written I suspect that you need to allow the PRACKs to continue. The 100rel draft does recommend that the UAS not send the next provisional response until it the previous one is acknowledged. If this is the case, then you could drop unsent provisional responses at the UAS if it was determined that a final response was to be sent. This works if media is sent in first provisional response or in the final response. If however, media could be in one of the dropped provisional responses you could have a problem. > > > >UAS must send the 200 OK for the CANCEL and should send a 487 > >response for the INVITE. Should the UAS abort the timer associated with > any > >active 18x response? That is, stop waiting for the PRACK. > > This is also an issue. It is related to what I just wrote, but the > difference is that now the UAS hasn't received a CANCEL, but it has > still sent the final response to the INVITE. > > My personal opinion about PRACK is that it is a little weird to spend > more resources to ack provisional responses, (PRACK request + response) > than to ack the final response (only an ACK request), but I guess that > is not related to your question, so... :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > -- > > Regards, > > Doug Hurtig > > > > Tekelec > > 2425 N. Central Expressway > > Richardson, Texas 75080 > > > > [EMAIL PROTECTED] > > 972.301.1203 > > _______________________________________________ This list is for > > continuing development of the SIP protocol. The sip-implementer's list > > is the place to discuss implementation, and to receive advice on > > understanding existing sip. To subscribe to it, send mail to > > [EMAIL PROTECTED] with "subscribe sip-implementors" in the > > body. > (See attached file: christer.holmberg.vcf) > (See attached file: InterScan_Disclaimer.txt) > > ------------------------------------------------------------------------ -------- > Name: InterScan_Disclaimer.txt > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: base64 -- Regards, Doug Hurtig Tekelec 2425 N. Central Expressway Richardson, Texas 75080 [EMAIL PROTECTED] 972.301.1203 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to [EMAIL PROTECTED] with "subscribe sip-implementors" in the body.
> -----Original Message----- > From: Aymeric Moizard [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 11, 2001 11:10 AM > To: [EMAIL PROTECTED] > Subject: [SIP] Question on draft-ietf-sip-100rel-02.txt > > > > Hi, > > The draft-ietf-sip-100rel-02.txt appears to > expire in December 2000. Is there a new > version of this one and is it on the way > to be accepted? This document was submitted to IESG for consideration as proposed standard. According to: http://www.ietf.org/IESG/status.html it has been under AD review since September 8. > > How do we cancel the INVITE if the UAC has > already received the 183 response. Must we > complete the PRACK "transaction" and send > "request canceled" for invite right after? Cancellation of the INVITE would proceed normally. You'd send a CANCEL, and the UAS would respond with a 487 to the INVITE, and then a 200 OK to the CANCEL. Any reliable provisionals in progress would complete normally; that is, the UAS would continue to retransmit them until it received a PRACK. This is part of the important SIP characteristic that all transactions complete normally and independently of any other transactions. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list [EMAIL PROTECTED] http://lists.bell-labs.com/mailman/listinfo/sip
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 04, 2001 12:21 AM > To: [EMAIL PROTECTED] > Subject: [SIP] Clarification of para in 100-rel-02.txt > > > > > Hi, > please refer to sec 5.2 of the rel-02 draft (june 30, 2000) > > "Note that the UAS MAY send a final response to the initial request > before having received PRACKs for all outstanding reliable > provisional responses. However, it MUST be prepared to process PRACK > requests for those outstanding responses. A UAS MUST NOT send > reliable provisional responses after sending a final response to a > request." > > The clarificartion is wrt to the last line. Does it mean that the > > 1) UAS MUST not send any new rel prov. responses after > sending the final > response > or > does it mean that > 2) the UAS must stop retransmission of its old non PRACKed rel prov. > responses + 1) > > > I feel its the former - I may have sent some early media > information in my > 1xx response which > I want to make sure he has got. Correct. It is new provisional responses you are not supposed to send. Existing ones in flight should complete normally. I'll clarify that. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list [EMAIL PROTECTED] http://lists.bell-labs.com/mailman/listinfo/sip
