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

From: [email-masked]
Date: Wed, 10 Dec 2003 14:36:05 +0200

What was the outcome of this discussion? Are we supporting message retransmission?

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: [email-masked]
Date: Fri, 12 Dec 2003 09:17:16 +0200

> 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]
> [email-masked] wrote:
> 
> 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

---

From: "Andrew Allen" <[email-masked]>
Date: Fri, 12 Dec 2003 03:15:26 -0500

Surely the use of a BYE is mandatory for the normal ending of a session.
This is what I understood from the draft anyway.

According to message-sessions-02 in clause 4

"When either party wishes to end the session, it informs the peer
   party with a SIP BYE request. A terminates the session by
   invalidating associated state, and dropping the connection." 

If no BYE is received and the connection is dropped then it is a failure
condition in my opinion.

Andrew

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 12, 2003 2:17 AM
> To: [email-masked]
> 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?
> 
> >
> 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
> > >
> > >

---

From: [email-masked]
Date: Fri, 12 Dec 2003 18:33:08 +0200

Ok, for the sake of moving forward, I agree provided the text is clear that this is not mandated and its an application design issue to retransmit, especially long messages.

Regards,
Hisham

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 12.December.2003 17:40
> To: Ben Campbell
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> [email-masked]
> 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 
> >> 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 
> > Others have wanted it for the intelligent being case as well. I am 
> > personally neutral on this point.
> 
> 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: [email-masked]
Date: Fri, 12 Dec 2003 18:33:08 +0200

Regards,
Hisham