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

From: Adam Roach <[email-masked]>
Date: Wed, 3 Mar 2004 04:38:42 -0600

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Mar 2004 13:22:30 -0500

Adam,

Are you just suggesting that an offerless invite not be used in a 
particular situation? Or are you suggesting that offerless invites not 
be used at all?

The fact is that offerless invites are useful in quite a number of 
circumstances. Then, as soon as you have devices that have some 
capability for a variety of media you start to have this problem. There 
are reasons why a device might not want to spontaneously offer media 
that it would be willing to accept if requested. For instance, offering 
of audio might require reconfiguring the device - preempting use of 
audio resources from some other use (like playing music). This might be 
appropriate for an incoming call that requires voice, but not for one 
that uses only IM. If it is unknown what the caller may need (the 
offerless invite) the device might choose to only offer what is convenient.

I think the only good solution to this is a more extended negotiation, 
and that is what preconditions would offer.

A way for an offerless invite to indicate what media it would prefer 
would be another solution.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Mar 2004 13:22:30 -0500

Adam,

	Paul