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

From: "Adam Roach (EUS)" <[email-masked]>
Date: Mon, 25 Jun 2001 17:00:49 -0500

> -----Original Message-----
> From: Kim Liu [mailto:[email-masked]]
>
> 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.

You'll re-send the 487 iff you receive a retransmission of the
INFO. I'll say it on behalf of Jonathan:

All transactions complete independently.
All transactions complete independently.
All transactions complete independently.

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.

/a

---

From: Kim Liu <[email-masked]>
Date: Mon, 25 Jun 2001 18:23:52 -0400

> "Adam Roach (EUS)" wrote:

> that, if your 487 is lost, the other side will re-send

Are you implying that after sending the CANCEL, an 
infinite number of INFOs should be sent until some sort of
response is received?  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?
Without the equivalent of an ACK it would appear impossible
to guarantee that both sides are assured of a mutual 
understanding of what happened.

Just curious.

Kim

_______________________________________________
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