Subject: RE: [Sipping] RFC 2976 INFO and CANCEL question

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 03:32:44 -0400

> -----Original Message-----
> From: Kim Liu [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2001 10:52 AM
> To: [email-masked]
> Subject: [Sipping] RFC 2976 INFO and CANCEL question
> 
> 
> Good morning --
> 
>     I was just studying RFC 2976 on the INFO method and ran into a
> question about section 2.4 of the RFC that states that an INFO request
> can be cancelled.
> 
>     By the reading of the RFC that I have, this does not make a lot of
> sense.
> If the receiving party receives an INFO, it is either going to
> understand the
> message (and send a 200 OK) or not (and send an apropriate 4xx class
> response.)  There is no time window to receive a CANCEL in.

Indeed. For this reason there has been discussion about deprecating CANCEL
for anything but INVITE.

>     Now, if the response to the INFO was delayed until an
> application/service
> processed the INFO body, but there is no 1xx class response sent to
> indicate
> the processing is in progress, the sender will be resending INFO
> messages
> and may eventually time out.

The constant retransmits of non-INVITEs is why you almost always want to
answer them right away.

> (Also, suppose an INFO was sent, then a CANCEL
> was sent.  A 200 OK is sent in response to the CANCEL, but 
> then a 487 is
> 
> sent in response to the INFO, but due to network/UDP issues, 
> the 487 is
> lost.  Should the 487 always be retransmitted?  

Yes, of course. Each transaction must complete independently.

> There is no ACK to the
> INFO
> to indicate that the response has been received.  Would 
> another INFO be
> sent (after the CANCEL) to trigger the retransmission of the 
> response?)

Yes. Sending a CANCEL would not cause INFO retransmissions to cease.

> 
>     The implications in section 2.2 that the 200 OK response MUST be
> sent
> with no message body seem to be that if the INFO request was used to
> trigger a service, then any resulting information/response from that
> service
> must be sent back in a separate INFO originated by the service in the
> message body of that.  

INFO is not meant to trigger services. Its meant to deliver information that
has no impact on call or session state.

>     Is the CANCEL mechanism meant for cancelling INFO requests that
> are getting munged by a forking proxy or such, though, to tell it to
> stop
> (re)sending/trying various hosts with the INFO?  If so, shouldn't
> section
> 2.5 of the INFO RFC be updated to reflect this?  As stated, 
> section 2.5
> says that the intermediary servers should treat INFOs the 
> same as BYEs,
> which doesn't seem to take this into account, as as far as I am aware,
> BYEs
> neither fork nor are cancellable.  

That is not correct. BYE can fork, as can any other non-INVITE method. BYE
can also be cancelled, but it has the same issues with INFO that you have
raised.

>     Is there any document/discussion thread which clarifies 
> the matter?

There have been some threads, which have not yet come to a conclusion. I
have sort of been on the fence on this. I think I have probably argued in
favor of allowing CANCEL for non-INVITEs, since there can be cases where it
is useful (for example, when the server is taking a long time to respond),
but I don't feel terribly strongly. It seems to remain an open issue.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sipping

---

From: Kim Liu <[email-masked]>
Date: Thu, 21 Jun 2001 16:12:19 -0400

> Indeed. For this reason there has been discussion about deprecating CANCEL

Well it would be nice to see this concluded so I know whether or not I 
need to support it. :-)

> Yes, of course. Each transaction must complete independently.

What I am getting at is that without the ACK there is no way
to know whether or not the response to the INFO got through
successfully or not.  The question is more clearly that if
a SIP device received an INFO, then received a CANCEL, and
sent a 200 OK for the CANCEL, then a 487 for the INFO, should
the SIP device always send multiple copies of the 487?  There
is no ACK to indicate when the 487 was successfully received.

> has no impact on call or session state.

Okay.  So no DTMF tones then.

> but I don't feel terribly strongly. It seems to remain an open issue.

Well, so much for implementing it, then.

Thanks.

Kim Liu

Senior Software Engineer
Lucent Technologies
Clearwater, FL, 33761

_______________________________________________
Sipping mailing list  http://www.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