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

From: [email-masked]
Date: Wed, 3 Mar 2004 15:51:19 +0200

Just for the recond, I fully support adam's views on this issue.

/Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Adam Roach
> Sent: 03.March.2004 12:39
> To: 'Rohan Mahy'; Adam Roach
> Cc: 'Paul Kyzivat'; Ben Campbell; 'Cullen Jennings'; Robert Sparks;
> [email-masked]
> Subject: RE: [Simple] RE: MSRP & Comedia
> 
> 
> I really don't like the prospect of requiring caller
> prefs to avoid these kind of bizarre and unfortunate
> user experiences.
> 
> My main point is that using empty INVITEs seems to
> cause more problems than it solves. Are these problems
> completely intractable? Probably not. Are they
> unpleasant? Well, I certainly think so.
> 
> So, given the chance, I'd far prefer to see solutions
> that don't require callee offers explored before we
> resort to a tool that brings unpleasant consequences
> (or, at the very least, specific additional mechanisms
> added throughout the system).
> 
> /a
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[email-masked]]
> > Sent: Wednesday, March 03, 2004 2:17
> > To: Adam Roach
> > Cc: 'Paul Kyzivat'; Ben Campbell; Rohan Mahy; 'Cullen 
> > Jennings'; Robert
> > Sparks; [email-masked]
> > Subject: Re: [Simple] RE: MSRP & Comedia
> > 
> > 
> > Adam,
> > 
> > You could use caller prefs even with your 
> rusty/dusty/trusty "legacy" 
> > SIP phone  ;-).
> > 
> > You would need something to add media feature parameters to the 
> > registration of the 7960 on its behalf.  This is not that 
> big a deal.
> > 
> > thanks,
> > -rohan
> > 
> > 
> > On Mar 3, 2004, at 4:49 PM, Adam Roach wrote:
> > 
> > > 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
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> 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
> > >>>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Simple mailing list
> > >>> [email-masked]
> > >>> https://www1.ietf.org/mailman/listinfo/simple
> > >>>
> > >>
> > 
> 
> _______________________________________________
> 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: Ben Campbell <[email-masked]>
Date: Thu, 04 Mar 2004 08:48:43 +0900

Just for the record, this conversation was about using delayed offers to 
control which MSRP endpoint initiates a connection. I thought that we 
had concensus in the wg meeting to atandardize that one end (either the 
inviter or the invitee) always initiated the connection, if one did not 
already exist. Did people understand otherwise?

If true, then this seems a rather academic excercise.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 04 Mar 2004 08:48:43 +0900

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 04 Mar 2004 15:02:46 +0900

I've lost what the key part of this discussion is. Should we use it here? I
agree - much rather not. Hope to find a better way.

However, UA Servers have to deal with Invites with no offer. If we want to
deprecate this out of 3261 - that is going to be a big deal.  If we are
defining something that does not work with 3261 - that is going to cause
some grief. Definitely agree we should try not to use it.

On the stuff here, I wonder about the problems with a SDP offer that
provides no way for the other end to send media to the device making the
offer. 

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 04 Mar 2004 15:02:46 +0900

Cullen

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Mar 2004 01:47:53 -0500

I am probably guilty of taking this thread off the subject.

I agree with what Ben said elsewhere that this issue probably isn't 
germane to the general issue of who connects for msrp.

But Cullen's point is why I was poking at this. Maybe it needs to be 
taken to another context. As things stand I believe it is highly likely 
that devices supporting different combinations of media will not 
interoperate as well as one might expect they should. It will take at 
least some common agreement re best practices, and possibly some 
additional mechanisms (like use of preconditions to negotiate compatible 
media) to achieve a wholely satisfactory user experience.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Mar 2004 01:47:53 -0500

Paul