Subject: [Sipping] RFC 2976 INFO and CANCEL question

From: Kim Liu <[email-masked]>
Date: Wed, 13 Jun 2001 10:52:04 -0400

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.
    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.  That is still not much of a window for
CANCEL
messages to be sent.  (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?  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?)

    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.  That would imply that the CANCEL sent for the
INFO must only apply to the transport and not the service requested,
which makes little sense after the message has been received by an
endpoint. ...?

    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.  (Section 4 of the RFC implies INFOs
may
fork, which seems odd if INFO must take the path a BYE would.)

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

Thank you,
Kim Liu
[email-masked]

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 18:34:34 -0400

> -----Original Message-----
> From: Kim Liu [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 8:07 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Sipping] RFC 2976 INFO and CANCEL question
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Kim Liu [mailto:[email-masked]]
> > > Sent: Monday, June 25, 2001 6:24 PM
> > > To: Adam Roach (EUS)
> > > Cc: [email-masked]
> > > Subject: Re: [Sipping] RFC 2976 INFO and CANCEL question
> > >
> > >
> > > > "Adam Roach (EUS)" wrote:
> > >
> > > >
> > > > This means that no matter how well the CANCEL seems to go, the
> > > > sending node **MUST** continue to retransmit the INFO until
> > > > a final response is received. You can rest comfortably knowing
> > > > that, if your 487 is lost, the other side will re-send
> > > > the INFO.
> > > >
> > >
> > > Are you implying that after sending the CANCEL, an
> > > infinite number of INFOs should be sent until some sort of
> > > response is received?
> > 
> > Infinite? Hardly. Its the same number that would be sent 
> without CANCEL,
> > which is 11.
> > 
> > > How long should the recipient of
> > > the INFO store state on the INFO request given that his
> > > only indication that the response he sent was actually
> > > received by the sender is a cessation of INFO requests?
> > 
> > 32s
> > 
> > > Without the equivalent of an ACK it would appear impossible
> > > to guarantee that both sides are assured of a mutual
> > > understanding of what happened.
> > 
> > With non-INVITE, the UAS has no way to know if the UAC 
> definitely got the
> > response. WIth INVITE, the UAC has no way to know if the 
> UAS got the ACK.
> > Byzantine armies problem. Unsolvable.
> 
> Lovely.  

I detect some sarcasm here. I'm afraid SIP cannot solve provably unsolvable
computer science problems. However, the retransmisions that are built in are
meant to help assure (but cannot GUARANTEE, and thats the operative word),
that the ACK arrives. With seven retransmits over 16 seconds, the odds are
pretty good except under really nasty network conditions. You'll have other
problems in those scenarios.

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