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

From: "Chris Boulton" <[email-masked]>
Date: Tue, 6 Jan 2004 08:43:40 -0000

<snip>
>
>> (I note with great embarrassment that the examples in the MSRP draft
are
>> missing o lines...)
>>
>> This does not seem to solve Paul's issue of replacing one stream, but
>> not another. It is not clear to me that this is an MSRP issue,
>> though--how would you handle it for RTP?
>
>I think we must recognize that this isn't just an msrp issue, and find
a
>solution that at least works for msrp, but hopefully one that is
>applicable to other media as well.
>
>Perhaps this is something akin to the o-line on a per-media-session
>basis. (The obvious thing would be a session-specific o-line, but that
>would require SDP changes. Adding an a-line for the same purpose would
>be easier.)
>
>	Paul

[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?

Thanks,

Chris.

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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Jan 2004 16:02:50 -0500

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Jan 2004 16:02:50 -0500

c=IN IP4 fillername

         Bob->Alice (SIP): 200 OK

         c=IN IP4 ignorefield

         c=IN IP4 fillername

         Bob->Alice (SIP): 200 OK

         c=IN IP4 ignorefield

         c=IN IP4 ignorefield

         Alice->Bob (SIP): 200 OK

         c=IN IP4 fillername

	Paul