Subject: RE: [Simple] Message Sessions: Offer/Answer

From: Adam Roach <[email-masked]>
Date: Sat, 19 Apr 2003 12:40:52 -0500

It's not exactly the same case. With MSRP, both sides
can be passive (the two-relay case).

/a

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Saturday, April 19, 2003 0:12
> To: Adam Roach
> Cc: [email-masked]'
> Subject: Re: [Simple] Message Sessions: Offer/Answer
> 
> 
> Although we have decided not to use comedia directly, I would 
> prefer to 
> follow the basic mechanism it provides for this, which is to 
> negotiate 
> active/passive roles through parameter negotiation in SDP. After all, 
> thats what we're talking about here. Is there any reason this 
> can't be 
> directly applied?
> 
> -Jonathan R.
> 
> Adam Roach wrote:
> > The current draft does some things that aren't really
> > consistent with the Offer/Answer model -- despite
> > contentions that it wants to use it.
> > 
> > First, I'd like to strongly support the use of Offer/Answer.
> > If we are to be able to treat this generically, like any
> > other media stream, we can't have deviations from
> > offer/answer. For example, to us "UPDATE" for the currently
> > defined mechanism, we would need the ability to ACK an
> > UPDATE response (!).
> > 
> > The only case the current draft really deviates from offer/answer
> > is the situation in which the invitee wants to either host
> > the MSRP session or needs to use a relay.
> > 
> > Here's what I propose:
> > 
> >   - The inviter includes both "i-am" and "you-are" in the
> >     SDP (unless he can't)
> >   - If the invitee doesn't need a relay, it echos back the
> >     same URIs.
> >   - If the invitee does need a relay, it echos back different
> >     URIs.
> > 
> > Of course, this doesn't give the invitee a way to say,
> > "oh, you're too kind, but I'd prefer to host it myself
> > instead". It does cover all four combinations of relay
> > use cases (i.e. direct connection, A must use a relay,
> > B must use a relay, both A and B must use a relay).
> > 
> > If we really must support the ability for the
> > invitee to host, I propose we instead make the
> > invitee use reliable responses to provide the
> > counterproposal. e.g.:
> >   
> >   1. Inviter offers to host; invitee counter-proposes that
> >      invitee will host. Inviter accepts counter-proposal by
> >      not making another offer.
> > 
> >      |--INVITE-->| i-am:1@a; you-be:2@a [offer]
> >      |<---183----| i-am:3@b; you-be:4@b [answer]
> >      |---PRACK-->|
> >      |<---200----|
> >      |<---200----| i-am:3@b; you-be:4@b
> >      |----ACK--->|
> > 
> >   2. Inviter offers to host; invitee doesn't care, but must
> >      go through a relay. Inviter accepts counter-proposal by
> >      not making another offer.
> > 
> >      |--INVITE-->| i-am:1@a; you-be:2@a [offer]
> >      |<---183----| i-am:3@b; you-be:1@a [answer]
> >      |---PRACK-->|
> >      |<---200----|
> >      |<---200----| i-am:3@b; you-be:1@a
> >      |----ACK--->|
> >    
> >   3. Inviter offers to host; invitee counter-proposes that
> >      invitee will host. Inviter insists on hosting his
> >      own half (i.e. two relays will be used)
> > 
> >      |--INVITE-->| i-am:1@a; you-be:2@a [offer]
> >      |<---183----| i-am:3@b; you-be:4@b [answer]
> >      |---PRACK-->| i-am:1@a; you-be:3@b [offer]
> >      |<---200----| i-am:3@b; you-be:1@a [answer]
> >      |<---200----| i-am:3@b; you-be:1@a
> >      |----ACK--->|
> > 
> > Note that this approach requires the addition of a host portion
> > to the i-am and you-be attributes. While I think this sort of
> > explicit indication is helpful and good, we can actually
> > get around it by omitting the "you-be" attribute
> > whenever it refers to an identifier in the other domain.
> > 
> > /a
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple