Subject: [Simple] message-sessions-10 WGLC: unique message ID and failed connections?

From: Ignacio Más "Ivars (KI/EAB)" <[email-masked]>
Date: Tue, 12 Apr 2005 16:24:33 +0200

Hi all:
I still have some doubts about the unique message ID when a connection
fails. Right now, the draft specifies that an endpoint MAY attempt to
recreate a failed session, and then it MUST use a new SDP exchange. If
the session is recreated the endpoints can resend non-confirmed content,
using the same message ID. But what happens if the sender does not want
to resend the non-confirmed content and still chooses to start a new
session? In principle the receiver will be holding on to the partial or
non-confirmed messages, waiting for the sender to recreate the session,
and then it will open a new session which, according to the draft, can
contain messages with the same message ID as the ones in the failed
session. Since B does not know whether A wants to still recreate the
failed session, it can't discard those messages, which will be
overwritten by the ones with the same message ID in the new session... 
I  principle, there is a way to differentiate those messages since the
ones being resent come from a REINVITE or UPDATE... but what happens if
a possible new session fail? Then there would be two 'partial' sessions
and there would be no way to identify the partial messages from each
session. I might be overlooking something, but that looks to me as a
problem.

Wouldn't it be more reliable to have the same requirements for the
message ID as the ones in SMTP? SMTP and other previous protocols
require a uniqueness of the message-ID over time and space that refers
to a particular version of a particular message and is guaranteed by the
host that generates it. Why does MSRP deviate from this definition by
just asking uniqueness over the current and previous session?

======================rfc2822
 The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.  The
   uniqueness of the message identifier is guaranteed by the host that
   generates it.  This message identifier is intended to be
   machine readable and not necessarily meaningful to humans.  A message
   identifier pertains to exactly one instantiation of a particular
   message; subsequent revisions to the message each receive new message
   identifiers.
======================rfc2822

Perhaps there is an obvious answer to that problem, but I have not found
it so far, so comments are greatly appreciated!

/Ignacio

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Apr 2005 11:29:45 -0400

It would be bad to reinvite and establish a replacement session, and 
then send new messages with message ids that match incomplete messages 
from the prior session.

The "simple" answer is that in such a case the new messages should have 
unique ids to those of the replaced session. This isn't an unreasonable 
requirement if its the same two endpoints.

But, as with everything else, this could get complex in a 3pcc 
situation. A 3pcc controller might do a transfer using reinvites. As 
result, one endpoint thinks it has a replacement session, while the 
other thinks it has a new session. The guy who thinks its a new session 
can't very well know what message ids had been used before. Its only 
soluiton is to use message ids that are guaranteed to be globally unique.

But I think this isn't going to be a major problem in practice. I hope 
we can defer the details of this kind of stuff, including perhaps some 
added guidelines, as future work.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 13 Apr 2005 21:41:25 +0300

Paul,

> can't very well know what message ids had been used before.

I agree with you on this one. We have already been there (e.g., the 
comedia and the preconditions stuff), and relaying on the concept of a 
SIP session to set the scope of any media-related identifier is not a 
good idea.

Paul and I tried exactly the same in comedia (using identifiers scoped 
by the SIP session) and cocluded that they did not work.

 > Its only

Yes, I agree this is the way to resolve the problem. In fact, I believe 
this is how RFC 2822 defines uniqueness of message identifiers. With 
your proposal we kill two birds with the same stone. We align with RFC 
2822 and we resolve the session mobility problem.

Thanks,

Gonzalo