[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] INFO use-cases
Hi,
>Yeah, but I think we do have to recognize there really are
>use cases that are simply wrong to do using INFO.
I agree. I've never said anything else :)
>There's nothing the IETF or anyone can do to stop people from doing
>them (there's no RFC interpol), but that doesn't mean we
>should give them explicit blessing either, and a draft such
>as Eric's really is the best we can do if we can't find
>legitimate use cases. That's why I like Jonathan's proposal
>for finding good use-cases, which is what I wanted to say at
>the mic at the end of that debate.
Yes, and that is what we are trying to do now.
The two use-cases I gave I believe are valid use-cases for INFO.
Or, was your mail a reply to Sam's mail?
Regards,
Christer
>
> There is, though, another aspect to this. As we all know,
> interoperability is a major SIP issue, and even if we
> discourage INFO use we know it will be used. So an
> unresolved question in my mind is whether we should define at
> least how such proprietary use can be signaled, to avoid
> vendor-specific static configuration profile proliferation
> making interop harder. In other words: not accept draft
> proposals for INFO use, not be bothered with repeating these
> discussions anymore in the IETF, etc.; but at least give them
> a standardized way to negotiate it so their UAs can
> interoperate with legitimate IETF-following UAs without
> needing configuration.
>
> -hadriel
>
>
> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> > Sent: Thursday, December 06, 2007 8:22 PM
> > To: Ganesan Sam-W00184; Hadriel Kaplan; sip at ietf.org
> > Subject: VS: [Sip] INFO use-cases
> >
> > Hi,
> >
> > Use-case 1:
> > -----------------
> >
> > One use-case is the transport of user-to-user information, and the
> > reasons people don't think it's feasible to establish a media plane
> > connection for this are (at least):
> >
> > 1. The information will not be sent for every call, and
> when sent the
> > amount of information is relatively small 2. In
> interworking cases the
> > information may be received out-of-band from the "other
> side", so it
> > is seen as unfeasible to send it down to the MG - in some cases the
> > interworking may even be performed without a MG.
> >
> >
> > Use-case 2:
> > -----------------
> >
> > Pretty much the same arguments are also used for sending
> DTMF out-of-band.
> > In addition there may be intermediate entities, without
> media access,
> > which are interested in the DTMF information.
> >
> >
> > (I hope we have understood the arguments why people want to
> use INFO
> > instead of SUB/NOT, so I will not go into that again.)
> >
> > Regards,
> >
> > Christer
> >
> > ________________________________
> >
> > Lähettäjä: Ganesan Sam-W00184 [mailto:sam.ganesan at motorola.com]
> > Lähetetty: pe 7.12.2007 1:46
> > Vastaanottaja: Hadriel Kaplan; sip at ietf.org
> > Aihe: RE: [Sip] INFO use-cases
> >
> >
> > I also know of a use case where video npt bookmarks are
> sent over INFO
> > across the SIP path while using SIP for video stream set
> up. Tispan 3
> > is actually writing specs on this and so is ATIS...
> >
> >
> > Sam
> >
> > ________________________________
> >
> > From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com]
> > Sent: Thu 12/6/2007 6:38 PM
> > To: sip at ietf.org
> > Subject: [Sip] INFO use-cases
> >
> >
> >
> > Howdy,
> > Jonathan asked for use-cases for what types of things would need an
> > in- dialog SIP message for user-user communication, vs.
> should be done
> > either out of dialog or in the media plane. If the only
> use-case is
> > DTMF, then we could just document the DTMF negotiation/use only and
> > not have to create a general info-events framework. That
> seems a very
> > reasonable argument to me. I also don't want to do work for no use.
> >
> > There is a counter-argument that there are proprietary uses
> of INFO in
> > the wild, and that a framework for negotiation at least removes the
> > manual configuration of vendor-specific profiles, which is
> a problem
> > of interop today - even if the IETF should not bless/document the
> > specific use cases themselves. But that would make the
> draft a very
> > different one than it currently is as well, and I will ask
> that in a separate email thread.
> >
> > The chairs have asked for 3 use cases, and I assume they mean 3 NEW
> > use cases (we already have 3 RFCs which use INFO, as well
> as DTMF). I
> > am not sure if they mean potential future use-cases, or current
> > use-cases (i.e., already implemented). Can I get a
> clarification on that?
> >
> > So anyway, taking the shot-gun approach, here's a first go at some
> > use- cases, and my personal take on whether they should be
> in INFO vs.
> > SUB/NOT vs. media-plane, FWIW.
> > [apologize for formatting ugliness]
> >
> > /***************
> > * Already standardized use-cases:
> > ***************/
> > 1) SIP-T/ISUP/QSIG/PSTN
> > -Documented in RFC 3372 and RFC 4497.
> >
> > 2) ECMA TR/87 uaCSTA
> > -Uses INFO to send ECMA-323 XML for monitoring and
> controlling
> > phones from a PC.
> >
> > 3) Sending media server control commands.
> > -Documented in RFC4722 MSCML.
> >
> >
> > /****************
> > * Use-cases that I think are potentially/possibly valid for INFO:
> > ****************/
> > 1) Sending a vcard asynchronously. Alice calls Bob, Alice
> says "can
> > you send me John's vcard?", Bob clicks something and voila
> it's sent.
> > -Alternatives: send a re-Invite or Update with a Call-Info,
> > with either a URL reference, data URI, or MIME and CID URL.
> > -Counter-argument: IMO this type of data really belongs in
> > MIME for a number of reasons, including length is less
> restricted for
> > mime attachments; one AD has said the Data URL may be
> deprecated. And
> > sending a re-Invite for this purpose seems odd.
> >
> > -Also, the Call-Info header is really about the caller or
> > callee, and thus Bob shouldn't be sending me John's vcard
> info in it technically.
> > That may sound like a nit, but UA's may well store the call-info
> > vcards into their address-books automatically and so tie it to the
> > wrong user/call.
> > -Pros of using INFO: it's explicit what you're
> doing when you
> > send the vcard, and you can send it knowing the other end
> can accept
> > it, and you can send it based on user input.
> >
> > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob,
> Bob has an
> > icon that represents himself, sends it when he picks up the phone.
> > -Alternatives: send a 200ok, re-Invite, or Update with
> > call-info, which explicitly has a type for icon.
> > -Counter-argument: same as for vcard, plus with call-info
> > there is no way to know which picture format the far-end supports a
> > priori. With a supported-package negotiation one could know.
> >
> > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says
> > "hey let's have a con call at time X", clicks and voila his phone
> > sends a vcalendar.
> > -Whether the vcalendar is related to the session or not and
> > thus whether it should be sent in an in-dialog request or not is
> > certainly debatable. Message method can already be used
> for this anyway.
> >
> > 4) Sending an HTTP URL. Alice calls Bob, a sales guy;
> Alice asks for
> > more info or a datasheet and Bob sends a URL for Alice to open with
> > her web- browser.
> > -One could also argue this is just making SIP the
> new SMTP, or
> > this should be sent using MESSAGE (which really is the new SMTP).
> >
> > 5) Sending a session traceroute. Alice calls Bob, Bob
> answers, Alice
> > does a sip-traceroute to figure out the path to Bob, by
> sending Info
> > with an incrementing max-forwards type header starting at 0
> (but not
> > really max- forwards), with a sip-frag type response body
> or some such.
> > -It's debatable if certain types of B2BUA's (ie,
> SBCs) would
> > ever allow this type of thing to happen, due to security
> concerns, but
> > I think they may do it at domain boundary hops. I think this is a
> > reasonable use for INFO though, maybe.
> >
> > 6) Sending geo-location information after call
> establishment. Alice
> > calls Bob, a hotel receptionist. Alice asks for directions
> to hotel,
> > clicks button and sends him location info of her phone (or
> Bob clicks
> > button and sends her his location).
> > -The location conveyance draft specifically calls
> out INFO as
> > acceptable for geo-loc info. Whether this is a real use-case is
> > debatable, and obviously it could be done with a sub/not.
> >
> > 7) Sending softkey-labels (not digit-match maps, but rather softkey
> > button labels). Alice calls her vmail server. Vmail server sends
> > softkey-labels for the menu items available in the response, Alice
> > presses softkeys and sends them in INFO.
> > -This could (and maybe should) be done with sub/not, a la
> > KPML, where the vmail server sends the softkey labels in the
> > Subscribe, UA sends buttons pressed in Notifies. But this
> is similar
> > to the DTMF use case so may well have the same benefit of lower
> > overhead since buttons are rarely pressed.
> >
> > 8) Sending a screen-pop-up message, e.g., "Do you want to continue
> > with this session?"
> > -There is a patent for doing screen pop-ups using INFO. I
> > guess Alert-Info could be used for this, but it's not clear
> it should?
> >
> >
> > /*****************
> > * Use-cases which have been proposed by others or even implemented,
> > * which are dubious for INFO (IMHO):
> > *****************/
> > 1) Sending RTP/RTCP statistics during call.
> > -There is an implementation of this, and the
> rationale is the
> > signaling plane box that wants this info is not actually the media
> > plane box that gets RTCP. Again this could (and IMO
> should) be done
> > with sub/not, so it can get stats after the call is over,
> and since it
> > will probably want periodic reports the overhead of the Subscribe
> > should be dwarfed by the number of Notifies.
> >
> > 2) Sending access-location information after call establishment.
> > -There is a P-Access-Network-Info header, and some have
> > proposed to send an update for it as a phone roams access points or
> > cells. But I think this is an odd thing to do inside an Invite
> > session, vs. in a sub/not or Register (and besides half the
> time the
> > network inserts this header, not the UA).
> >
> > 3) Sending media-control indications (ie, remote-control
> > "play/pause/etc.")
> > -This is done today by at least one vendor, but is
> debatable
> > if it's the right model. The argument is it's like SDP
> re-Invite for
> > hold, except at a media content layer above RTP, so not
> done in RTCP nor SDP.
> >
> > 4) Sending video fast update command
> > -This is an informational draft, which documents
> what has been
> > implemented, but states it should really be done in the media plane.
> >
> > 5) Sending peripheral control commands (ie, USB commands)
> > -There is actually a patent on this, amazingly. Someone
> > thinks it makes sense to create a SIP session to your laptop, or
> > vice-versa, and then send USB commands inside MIME in INFO
> messages.
> > Methinks this should be media-plane, if anything.
> >
> > 6) Sending charging information for a call (i.e., minutes
> remaining or
> > cost so far).
> > -There was a proposal to use this for Advice of Charge
> > information in TISPAN. IMO it should be a sub/not though, as they
> > want this to survive the Invite session.
> >
> > -hadriel
> >
> >
> > _______________________________________________
> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sipping at ietf.org for new developments on the application of sip
> >
>
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip