Subject: RE: [Simple] MSRP & Comedia

From: [email-masked]
Date: Mon, 1 Mar 2004 09:00:03 +0200

In some cases, different INVITEs cause different applications to start at the UAS. The way to differentiate between those INVITEs is sometimes by using the sdp as a clue. For those devices, receiving INVITE with no sdp might cause problems. The UAS needs to guess what application to start.

/Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Cullen Jennings
> Sent: 27.February.2004 08:50
> To: Ben Campbell; Robert Sparks; Rohan Mahy; Adam Roach
> Cc: [email-masked]
> Subject: [Simple] 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: Adam Roach <[email-masked]>
Date: Tue, 2 Mar 2004 19:13:45 -0600

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

> 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
> > 
> >> From: Cullen Jennings [mailto:[email-masked]]
> >> Sent: Friday, February 27, 2004 0:50
> >> Subject: MSRP & Comedia

---

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

Paul Kyzivat [mailto:[email-masked]]

> In this particular case, it is the device that will have the bad user 
> experience that takes the initiative to send the offer with 
> preconditions. And in this case, since the offer is in a response, it 
> would typically only be tried if the request indicated 
> support for the 
> preconditions. When it can't do that, we have a less that 
> desirable user 
> experience, but things still work.

And that's precisely the difference between the cases. At least
the ones you're talking about here *work*, even if suboptimally.
With the ones that I'm warning against, things don't even work.

/a

---

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

/a

---

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

> 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]
> 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
> >
> >> 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]
> >> 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:
> >>>>>> 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
> >>>>>>

---

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

> 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
> 
>