Subject: [Simple] Message Sessions: Offer/Answer

From: Adam Roach <[email-masked]>
Date: Mon, 7 Apr 2003 18:47:44 -0500

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

---

From: Ben Campbell <[email-masked]>
Date: 07 Apr 2003 20:27:09 -0500

>      |<---183----| i-am:3@b; you-be:4@b [answer]

I think this is the correct direction to take overall. As far as a host
part for the URI encoding, I have already become convinced we need it
for other reasons. (For example, the split dns example you made off
list.)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Apr 2003 01:12:02 -0400

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.

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