Subject: RE: [Simple] MSRP: Some thoughts on session updates

From: [email-masked]
Date: Tue, 16 Dec 2003 17:45:00 +0200

Ben Campbell wrote:
 > > Because, it makes little sense to repeat a "offer both-> 
 > try active and fail -> answer passive" sequence for each new 
 > MSRP component added to a session. This is an additional 
 > benefit we would get by the below restrictions, which is a 
 > good thing. Of course, this would not allow negotiating 
 > 'direction' per MSRP session inside a SIP dialog, but I 
 > don't see much use for that anyway.
 > 
 > I think I agree, as long as we are only talking about MSRP 
 > sessions. I 
 > don't think the direction of some other kind connection 
 > oriented media 
 > session would necessarily imply the direction for MSRP, but 
 > I think one 
 > MSRP session can definitely imply a direction for a second 
 > MSRP session.

Definitely agree that this would only apply to MSRP. Other connection oriented medias (or indeed the COMEDIA stuff in general) may define their own ways for handling this. 

Cheers,
Aki

 > 
 > 
 > > 
 > > Cheers,
 > > Aki
 > > 
 > > 
 > >  > -----Original Message-----
 > >  > From: [email-masked] [mailto:[email-masked]]On 
 > >  > Behalf Of
 > >  > ext Ben Campbell
 > >  > Sent: 15 December, 2003 23:20
 > >  > To: Simple WG
 > >  > Subject: [Simple] MSRP: Some thoughts on session updates
 > >  > 
 > >  > 
 > >  > We have had a lot of discussion on how we deal with 
 > >  > connection failures, 
 > >  > session continuance across a failure, duplicate supression, 
 > >  > etc. Much of 
 > >  > that depends on how we handle session updates. Here are some 
 > >  > thoughts 
 > >  > for discussion.
 > >  > 
 > >  > Although the sense of the room at IETF58 indicated we needed 
 > >  > a way to 
 > >  > re-establish TCP connections without resignaling, 
 > subsequent list 
 > >  > discussion has indicated consensus that this will not work, 
 > >  > and we will 
 > >  > indeed have to re-signal. I am slightly concerned that many 
 > >  > of those who 
 > >  > favored reconnection without resignaling at the meeting 
 > have not 
 > >  > participated in the email thread. I must assume that means 
 > >  > they agree ;-)
 > >  > 
 > >  > Obviously resignaling means a new SDP exchange. For SIP, 
 > >  > that would mean 
 > >  > a re-INVITE or an UPDATE. Since the MSRP spec only 
 > tangentally talks 
 > >  > about sip, I think the re-INVITE vs UPDATE question is out 
 > >  > of scope, and 
 > >  > is treated sufficiently well in the UPDATE rfc.
 > >  > 
 > >  > So, here are some assumptions and observations about 
 > how an updated 
 > >  > offer/answer would work.
 > >  > 
 > >  > 0) We don't have to worry about early media. (I expect 
 > this to be 
 > >  > controversial, but I can always hope. The following are 
 > >  > based on that 
 > >  > assumption.)
 > >  > 
 > >  > 1) The active party must remain the active party. If the 
 > >  > active party 
 > >  > initiates an updated offer, it MUST NOT contain a session URL.
 > >  > 
 > >  > 2) The passive party must remain the passive party. If the 
 > >  > passive party 
 > >  > initates an updated offer, it MUST contain a session URL. 
 > >  > This updated 
 > >  > URL may be the same as before, or may be completely 
 > different, even 
 > >  > pointing to a completely different location.
 > >  > 
 > >  > 3)If the passive party sends an updated offer with a 
 > semantically 
 > >  > identical URL as the original, this indicates no change. (I 
 > >  > don't know 
 > >  > why you would do this, but Paul asked for an example of an 
 > >  > update that 
 > >  > changes nothing.) Interestingly, the active party 
 > _cannot_ send an 
 > >  > updated without giving the active party a chance to 
 > provide a new 
 > >  > session URL.
 > >  > 
 > >  > 4) A corrolary of 1) and 2) is that direction=both would not be 
 > >  > permitted for an update.
 > >  > 
 > >  > 5) Updated offers can occur for both healthy sessions and as 
 > >  > a result of 
 > >  > connection failures, etc.
 > >  > 
 > >  > Thoughts?
 > >  > 
 > >  > 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

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 7 Jan 2004 09:37:32 -0000

That looks good to me ;-)

Chris.

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: 06 January 2004 21:03
>To: Chris Boulton
>Cc: Ben Campbell; [email-masked]; [email-masked]
>Subject: Re: [Simple] MSRP: Some thoughts on session updates
>
>
>
>Chris Boulton wrote:
>>
>> [Chris Boulton] I think we can all recognize that this is a global
>> problem rather than msrp specific.  I like Paul's idea of having an
>> attribute e.g. 'a=reconnect' to indicate the continuation of a
session.
>> Just one question, the version number in the offer will have changed,
>> due to payload change, so how would the msrp client associate a
>> reconnect with an existing session, if multiple exist?
>>
>> e.g. Client A and B currently have 2 connection, one for messaging,
one
>> for file transfer - client B is hosting.  Client A detects failure in
>> one of the connections (Client B has not detected failure) and issues
a
>> new offer via an 'update'.  Client B receives the offer and realizes
>> it's a reconnect.  How does client B know which of the two
connections
>> we are attempting to reconnect?
>
>The attribute is associated with a particular media session. It can be
>inserted into the one for the session that is to be reconnected. It is
>inserted twice if both are to be reconnected.
>
>         Alice->Bob (SIP): INVITE sip:[email-masked]
>
>         c=IN IP4 fillername
>         m=message 9999 msrp/tcp *
>         a=accept-types:text/plain
>         a=direction:both
>         a=session:msrp://alicepc.atlanta.com:7777/iau39
>         a=version:1
>
>         Bob->Alice (SIP): 200 OK
>
>         c=IN IP4 ignorefield
>         m=message 9999 msrp/tcp *
>         a=accept-types:text/plain
>         a=direction:active
>         a=version:1
>
>Alice then adds another session for file transfer:
>
>         Alice->Bob (SIP): INVITE sip:[email-masked]
>
>         c=IN IP4 fillername
>         m=message 9999 msrp/tcp *
>         a=accept-types:text/plain
>         a=direction:both
>         a=version:1
>         m=message 9998 msrp/tcp *
>         a=accept-types:application/pdf
>         a=direction:passive
>         a=sendonly
>         a=session:msrp://alicepc.atlanta.com:7777/iau40
>         a=version:1
>
>         Bob->Alice (SIP): 200 OK
>
>         c=IN IP4 ignorefield
>         m=message 9999 msrp/tcp *
>         a=accept-types:text/plain
>         a=direction:active
>         a=version:1
>         m=message 9998 msrp/tcp *
>         a=accept-types:application/pdf
>         a=direction:active
>         a=recvonly
>         a=version:1
>
>Bob later discovers something wrong with the file transfer:
>
>         Bob->Alice (SIP): (re)INVITE sip:[email-masked]
>
>         c=IN IP4 ignorefield
>         m=message 9999 msrp/tcp *
>         a=accept-types:text/plain
>         a=direction:active
>         a=version:1
>         m=message 9999 msrp/tcp *
>         a=accept-types:application/pdf
>         a=direction:active
>         a=recvonly
>         a=version:2
>
>Alice sees that the version for the first session is unchanged and so
>does nothing with it. But the version for the 2nd session is changed,
so
>she starts listening again for a new connection, and responds:
>
>         Alice->Bob (SIP): 200 OK
>
>         c=IN IP4 fillername
>         m=message 9999 msrp/tcp *
>         a=accept-types:text/plain
>         a=direction:passive
>         a=version:1
>         m=message 9999 msrp/tcp *
>         a=accept-types:application/pdf
>         a=direction:passive
>         a=sendonly
>         a=session:msrp://alicepc.atlanta.com:7777/iau41
>         a=version:2
>
>A subsequent offer/answer that didn't want to change anything could use
>these same sdp bodies.
>
>	Paul
>
>

This message has been scanned for viruses by MailControl - www.mailcontrol.com