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

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 12, 2003 2:17 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Simple] Comments on message-sessions-02 - message retry
> 
> 
> 
> > -----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

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

---

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

BYE certainly isn't required to end the MSRP media session, but some 
form of signaling is. It could be BYE, but it could be another offer 
that sets the port to zero in the m-line.

But I agree with the basic point - a connection drop is ok after 
signaling indicating it should go away, otherwise it is an error.

	Paul

---

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

Paul