Subject: RE: [Simple] Comments on message-sessions-02 - message retry

From: [email-masked]
Date: Fri, 12 Dec 2003 09:17:16 +0200

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 11.December.2003 19:05
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] Comments on message-sessions-02 - message retry
> 
> 
> [email-masked] wrote:
> 
> > What was the outcome of this discussion? Are we supporting 
> message retransmission?
> 
> I think we are agreed to not attempt retransmission on the same 
> connection. We are also agreed that, when a connection fails, we must 
> re-signal to create a new one.

Can we define what connection failure means? If a connection is dropped by the visitor, how does the host know if that was a connection failure or simply that the visitor is ending the session?

> 
> I think we still need discussion on how to associate a new connection 
> with the old, when both are associated with the same dialog, 
> and how to 
> deal with retrying any messages that may have failed on the old 
> connection on an associated new connection.

Oh yes, this was for the automata case, right? I still think humans are intelligent enough to know that a message that they sent did not get through and to resend. In this case, we don't need to associate connections. This assumption helps greatly in enabling the protocol to handle long messages.

/Hisham

> 
> 
> > 
> > Regards,
> > Hisham
> > 
> > 
> >>-----Original Message-----
> >>From: ext Chris Boulton [mailto:[email-masked]]
> >>Sent: 28.November.2003 18:56
> >>To: Ben Campbell; Paul Kyzivat
> >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]
> >>Subject: RE: [Simple] Comments on message-sessions-02 - 
> message retry
> >>
> >>
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Ben Campbell [mailto:[email-masked]]
> >>>Sent: 10 November 2003 17:09
> >>>To: Paul Kyzivat
> >>>Cc: [email-masked]; [email-masked]
> >>>Subject: Re: [Simple] Comments on message-sessions-02 - 
> message retry
> >>>
> >>>Paul Kyzivat wrote:
> >>>
> >>>[...]
> >>>
> >>>
> >>>>I'm not certain a time period is really necessary. I 
> think this can
> >>
> >>be
> >>
> >>>>local option.
> >>>>
> >>>>Even uniqueness across streams isn't *required*, though 
> it would be
> >>>>helpful. Instead, we can simply introduce an error response to be
> >>
> >>used
> >>
> >>>>when a duplicate is detected and supressed. If it was supressed in
> >>
> >>error
> >>
> >>>>because the sender duplicated a TR-ID from another stream, 
> >>
> >>the sender
> >>
> >>>>would then know to recover.
> >>>>
> >>>>But I agree that some further clarification on TR-ID 
> >>
> >>uniqueness could
> >>be
> >>
> >>>>helpful.
> >>>>
> >>>
> >>>If TR-ID is not required to be unique across sessions, and 
> you allow
> >>>clients to attempt to find duplicate messages using TR-ID across
> >>>sessions, then you introduce the possibility of false 
> >>
> >>detection caused
> >>
> >>>by TR-ID collisions. This seems bad to me.
> >>>
> >>
> >>[Chris Boulton] I totally agree.
> >>
> >>
> >>>
> >>>_______________________________________________
> >>>Simple mailing list
> >>>[email-masked]
> >>>https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>>_____________________________________________________________
> >>
> >>__________
> >>_
> >>
> >>>This email has been scanned for all viruses by the 
> MessageLabs Email
> >>>Security System. For more information on a proactive email security
> >>>service working around the clock, around the globe, visit
> >>>http://www.messagelabs.com
> >>>_____________________________________________________________
> >>
> >>__________
> >>_
> >>
> >>______________________________________________________________
> >>__________
> >>This email has been scanned for all viruses by the MessageLabs Email
> >>Security System. For more information on a proactive email security
> >>service working around the clock, around the globe, visit
> >>http://www.messagelabs.com
> >>______________________________________________________________
> >>__________
> >>
> 
> 
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 12 Dec 2003 08:25:31 -0600

> Can we define what connection failure means? If a connection is dropped by the visitor, how does the host know if that was a connection failure or simply that the visitor is ending the session?

If the visitor really means it, it should first be sending a BYE, or 
equivelant if it is not using SIP.

This is, by the way, not so much an MSRP issue as a general SIP issue 
using any connection-oriented media. I wonder if the current COMEDIA 
draft has anything to say about this? (I will check, unless someone 
knows off the top of his or her head.)

> Oh yes, this was for the automata case, right? I still think humans are intelligent enough to know that a message that they sent did not get through and to resend. In this case, we don't need to as…

Others have wanted it for the intelligent being case as well. I am 
personally neutral on this point.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 12 Dec 2003 08:25:31 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Dec 2003 10:40:19 -0500

Ben Campbell wrote:
>>> with the old, when both are associated with the same dialog, and how 
>>> to deal with retrying any messages that may have failed on the old 
>> Oh yes, this was for the automata case, right? I still think humans 
>> are intelligent enough to know that a message that they sent did not 
>> get through and to resend. In this case, we don't need to associate 
>> connections. This assumption helps greatly in enabling the protocol to 
>> handle long messages.
> 

Yes, it is needed for all those reasons.

But nobody will be forced to use it. If your UA chooses not to 
retransmit messages, that is fine. When the message is large, the UA 
might want to think hard before retrying it. But that is an application 
design issue.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Dec 2003 10:40:19 -0500

Paul