[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] INFO use-cases
In regard to your use case 1, then if we follow the Alan Johnston draft, this would be a header being transported rather than a body, whereas all the cases we have been discussing so far have been message body transport issues. If you mean something different, then it would be probably be better to use a different term that "user to user".
Regards
Keith
> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> Sent: Friday, December 07, 2007 1:22 AM
> 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
>
_______________________________________________
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