[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] RE: MSRP & Comedia
Just for the recond, I fully support adam's views on this issue.
/Hisham
> -----Original Message-----
> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]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;
> simple@ietf.org
> 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:rohan@cisco.com]
> > Sent: Wednesday, March 03, 2004 2:17
> > To: Adam Roach
> > Cc: 'Paul Kyzivat'; Ben Campbell; Rohan Mahy; 'Cullen
> > Jennings'; Robert
> > Sparks; simple@ietf.org
> > 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:pkyzivat@cisco.com]
> > >> Sent: Tuesday, March 02, 2004 20:09
> > >> To: Adam Roach
> > >> Cc: 'Cullen Jennings'; Ben Campbell; Robert Sparks; Rohan Mahy;
> > >> simple@ietf.org
> > >> 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:fluffy@cisco.com]
> > >>>> Sent: Monday, March 01, 2004 8:38
> > >>>> To: Adam Roach; Ben Campbell; Robert Sparks; Rohan Mahy
> > >>>> Cc: simple@ietf.org
> > >>>> 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" <adam@dynamicsoft.com> 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:fluffy@cisco.com> 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:fluffy@cisco.com]
> > >>>>>> Sent: Friday, February 27, 2004 0:50
> > >>>>>> To: Ben Campbell; Robert Sparks; Rohan Mahy; Adam Roach
> > >>>>>> Cc: simple@ietf.org
> > >>>>>> 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
> > >>>>> Simple@ietf.org
> > >>>>> https://www1.ietf.org/mailman/listinfo/simple
> > >>>>>
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> Simple mailing list
> > >>>> Simple@ietf.org
> > >>>> https://www1.ietf.org/mailman/listinfo/simple
> > >>>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Simple mailing list
> > >>> Simple@ietf.org
> > >>> https://www1.ietf.org/mailman/listinfo/simple
> > >>>
> > >>
> >
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple