Subject: [Simple] MSRP & Comedia

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 Feb 2004 15:49:58 +0900

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 3 Mar 2004 01:49:18 -0600

That's all great. Now tell me how it works using
the Cisco 7960 sitting on my desk right now. Assume
that upgrading the software is not an option.

/a

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, March 02, 2004 20:09
> To: Adam Roach
> Cc: 'Cullen Jennings'; Ben Campbell; Robert Sparks; Rohan Mahy;
> [email-masked]
> Subject: Re: [Simple] RE: MSRP & Comedia
> 
> 
> There are a couple of solutions to the bad user experience 
> you outline:
> 
> - the UAC can use callerprefs to indicate what media it desires.
>    For this to work the UAS would have to evaluate the callerprefs,
>    which isn't currently required or expected.
> 
> - preconditions could be used to ensure that there is a satisfactory
>    agreement on media before alerting. In this particular 
> case it would
>    be the UAS that inserts the preconditions as a way of improving the
>    user experience at its end. Most any precondition would do, though
>    the newly proposed connectivity precondition would be quite
>    appropriate. A hypothetical new precondition relating to 
> negotiation
>    of some acceptable (set of) media stream(s) might also be 
> interesting.
> 
> Paul
> 
> Adam Roach wrote:
> > Okay, so, the user experience you're promoting
> > here would lead to a situation in which you open
> > up your IM client, type in a message for me,
> > and my desktop hard phone starts ringing. Several
> > seconds later, I pick up the receiver, my hardphone
> > sends a "200 OK" response, and... well, nothing
> > good can come of any result at this point.
> > 
> > If your client supports audio, my voice is suddenly
> > coming out of your PC speakers. If not, the call
> > is torn down, your client renders an error to you,
> > sends me a bye, and I'm sitting there holding a dead
> > handset.
> > 
> > This is the problem that I've pointed out occasionally
> > for several years: this "send an INVITE with no body"
> > approach for setting up sessions causes all kinds
> > of problems. It was originally added for interwork
> > with the prehistoric H.323v1 procedures, and not killed
> > because we observed that it can be used in this clever
> > 3pcc hack -- but it invariably leads to a message that
> > semantically means the same thing as the dialog
> > box that I sent earlier.
> > 
> > /a
> > 
> > 
> >>-----Original Message-----
> >>From: Cullen Jennings [mailto:[email-masked]]
> >>Sent: Monday, March 01, 2004 8:38
> >>To: Adam Roach; Ben Campbell; Robert Sparks; Rohan Mahy
> >>Cc: [email-masked]
> >>Subject: Re: [Simple] RE: MSRP & Comedia
> >>
> >>
> >>
> >>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
> >>>>
> >>>>
> >>>>
> >>>>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
> >>>>