Subject: Re: [Simple] RE: MSRP & Comedia

From: Cullen Jennings <[email-masked]>
Date: Mon, 01 Mar 2004 23:37:56 +0900

It just sends an offer with all three and then the other ends selects. This
is how SIP is today - you can send an invite with no offer then get the
offer in the response and put the answer in the ack.

On 3/1/04 10:41 AM, "Adam Roach" <[email-masked]> wrote:

> From a protocol perspective, this sounds reasonable.
> 
> I think the key problem is that the first example shifts the
> decision of what type of communication is requested
> from the caller to the callee. Without getting into a discussion
> of whether that is the "right" thing to do, it certainly is
> going to differ from user expectations.
> 
> +----------------------------------------------+
> | Cullen Jennings <sip:[email-masked]> wants |
> | to start a conversation, but I have no idea  |
> | what kind. Take your best guess:             |
> |                                              |
> |    +-------+  +-----------------+  +----+    |
> |    | Voice |  | Voice and video |  | IM |    |
> |    +-------+  +-----------------+  +----+    |
> +----------------------------------------------+
> 
> /a
> 
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]]
>> Sent: Friday, February 27, 2004 0:50
>> To: Ben Campbell; Robert Sparks; Rohan Mahy; Adam Roach
>> Cc: [email-masked]
>> Subject: MSRP & Comedia
>> 
>> 
>> 
>> This is a half baked idea that I am just tossing out as food
>> for thought
>> 
>> Consider a systems where something like the UA that sends the
>> answer sends
>> the VISIT. 
>> 
>> Consider the cases where A want to set up a MSRP session with B.
>> 
>> A is behind a NAT and does not want to use a relay. A sends
>> an INVITE with
>> no offer. B sends an offer, gets back an answer and A sends the VISIT.
>> A -> inv    -> B
>> A <- offer  <- B
>> A -> answer -> B
>> A -> visit  -> B
>> 
>> B is behind a NAT. A sends an offer and B sends an answer and
>> A sends VISIT.
>> A -> offer  -> B
>> A <- answer <- B
>> A <- visit  <- B
>> 
>> A and B are behind NATS. A sends INVITE no offer, B knows
>> relay is needed
>> and gets one and sends offer.
>> 
>> The underlying principal is basically if you don't know what
>> port you are
>> going to receive media at (which is the case with a NAT) you
>> should not be
>> making any offers and if you make an offer the assumption is
>> that the other
>> side and send media (a VISIT) to that and have it work.
>> 
>> The fundamental thing I am trying to avoid is two vendors
>> both saying they
>> have MSRP compliant systems yet still having them fail to be
>> able to talk to
>> each other because they both expect the other one to host.
>> 
> 
> _______________________________________________
> 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: Cullen Jennings <[email-masked]>
Date: Mon, 01 Mar 2004 23:37:56 +0900

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Mar 2004 09:28:52 +0900

> offer in the response and put the answer in the ack.

Who is "it" in your scenario? Are you suggesting that if my IM client 
sends an empty INVITE, I have a right to expect the receiver will offer 
every media type it can possibly understand? That is, the receiver is 
not allowed to have media types it can accept, but will never offer?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Mar 2004 09:28:52 +0900