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

That looks good to me ;-)

Chris.

>-----Original Message-----
>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:
>>
>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
>
>