Subject: RE: [Simple] MSRP: updates and re-invites

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 3 Jul 2004 13:28:34 +0200

Hi,

I think it is important to look at this from a generic TCP point of view, and not only from a MSRP perspective. Because, if we in a session have multiple "streams" (used for different applications and/or multiple instances of the same application) using TCP, and they all define separate SIP behaviour we may end up in situations when re-INVITEs are sent in different directions etc. Because, unlike in H.323, we do need to include ALL m= lines in a new offer, even if we only modify/(re-)establish/delete a specific stream.

So, the question is: what does a SIP node (offerer and answerer) do if a bearer level TCP connection goes down? WHO does re-establish the TCP connection? WHEN is the TCP connection re-establish? Do we send a re-INVITE, or don't we send anything?

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Ben Campbell
> Sent: 29. kesäkuuta 2004 21:41
> To: Paul Kyzivat
> Cc: Simple WG
> Subject: Re: [Simple] MSRP: updates and re-invites
> 
> 
> Paul Kyzivat wrote:
> 
> > 
> > 
> > Ben Campbell wrote:
> > 
> >> In the shared connection model, connections are as-needed. By 
> >> implication, we do not signal connections, we signal 
> sessions. If we 
> >> signal a session, and the endpoints already have a connection that 
> >> will serve, they use it.
> >>
> >> So, if we don't signal the connections in the first place, 
> why would 
> >> we signal a new connection?
> > 
> > 
> > Unless I missed a change somewhere, connections *at the 
> endpoints* are 
> > not entirely as-needed. In particular, if a connection has 
> gone away but 
> > is still needed it cannot just be made again.
> 
> Oops, yes, you are correct.
> 
> > 
> > But I agree that the need to do that can be defined away, 
> by saying that 
> > loss of the connection implies loss of the session, so that a new 
> > session must be requested.
> > 
> > I think this is what you mean, and if so that is fine. I 
> just want to be 
> > sure.
> 
> Yes, that is what I mean.
> 
> > 
> >     Paul
> > 
> >> Paul Kyzivat wrote:
> >>
> >>> Ben,
> >>>
> >>> I think what you describe here is what we discussed at 
> some point, 
> >>> that should work. But the general wording below leaves me a bit 
> >>> uncertain of that. Am I right that point below is that if 
> the path is 
> >>> unchanged then the old connections are reused, while when 
> the path is 
> >>> changed (by either end) then the offerer establishes a 
> new connection?
> >>>
> >>>     Paul
> >>>
> >>> Ben Campbell wrote:
> >>>
> >>>> We have had a lot of discussion on how to handle updated 
> offers in 
> >>>> SIP updates and re-invites. We had made some proposals 
> back when we 
> >>>> negotiated connection direction that are not really 
> relevant any more.
> >>>>
> >>>> The design team spent some time discussing this, and 
> came up with a 
> >>>> proposal:
> >>>>
> >>>> Reconnection no longer an issue with connection sharing. TCP 
> >>>> connection establishment is done on-demand. Therefore we 
> do not need 
> >>>> a way to signal a desire to establish a new TCP session.
> >>>>
> >>>> The offerer of a new sdp exchange assumes the role of 
> offerer for 
> >>>> all purposes, regardless of whether it was the 
> origininal offerer.
> >>>>
> >>>> An offerer or answer is effectively unchanged if the 
> path does not 
> >>>> change from the previous version. If either side changes 
> the path, 
> >>>> then we effectively have a new session.
> >>>>
> >>>> If offerer does not change anything, answerers can still make 
> >>>> changes. Answerer must always answer with a currently 
> valid path. 
> >>>> These could be the same as before the update, or different.
> >>>>
> >>>> Local policy may choose to re-invite to fix session 
> problems without 
> >>>> user interaction, or give user a choice. (examples: you 
> get an error 
> >>>> report to the initial send, a mobile device looses connectivity 
> >>>> through tunnel, etc.)
> >>>>
> >>>> I invite everyone who cares to think this through, and 
> make sure we 
> >>>> are not breaking something important.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Ben.
> >>>>
> >>>> _______________________________________________
> >>>> Simple mailing list
> >>>> [email-masked]
> >>>> https://www1.ietf.org/mailman/listinfo/simple
> >>>>
> >>
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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