Subject: [Sip] INFO use-cases

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 Dec 2007 18:38:36 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Thu, 6 Dec 2007 19:46:00 -0500

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:[email-masked]]
Sent: Thu 12/6/2007 6:38 PM
To: [email-masked]
Subject: [Sip] INFO use-cases

Howdy,

/***************

2) ECMA TR/87 uaCSTA

/****************

/*****************

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2007 21:13:24 -0500

Hadriel,

I buy some of your use cases, but not others. Comments below.

A competitor for INFO in several of these is MESSAGE. I think a good 
case can be made for that if the information is to be rendered to the 
recipient.

	Paul

Hadriel Kaplan wrote:
[snip]

For this case MESSAGE seems entirely appropriate.

(Not so much so for vcard, which probably isn't intended to be directly 
rendered to the recipient.)

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

Yes to MESSAGE.

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

UPDATE with geo-loc is reasonable here, or even reINVITE.

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

This is very definitely a use case for MESSAGE.

Also, all of the above could probably be justifiably sent via MSRP - 
either directly or via the file transfer extensions.

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Thu, 6 Dec 2007 21:27:21 -0500

Paul:
 
In fact if INFO is outlawed for anything but DTMF....   ATIS  and tispan 3 will probably use Message  in doing the npt book mark stuff...  And there are quite a few proprietary use cases that will never show up on the list.  Yes I do know the argument that "they are proprietary and we dont care about... Let the devil take them ..."  I am not sure about that one
 
Sam

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thu 12/6/2007 9:13 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [Sip] INFO use-cases

Hadriel,

        Paul

Hadriel Kaplan wrote:
[snip]

Yes to MESSAGE.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 Dec 2007 21:43:27 -0500

Hey Paul,
Yeah I agree MESSAGE makes a lot of sense for things to be rendered natively/directly to the user.

Regarding using MSRP: while that is obviously possible and for some cases undoubtedly the right thing to do, for some uses it is a crazy amount of overhead.  For example if I want to send you a vcard mid-call, it seems silly to send a re-Invite to add an MSRP session, potentially go get msrp-relay info to do so, and/or possibly go through ICE procedures, all just to send you a 100 byte little vcard I could have sent in an INFO.  But clearly if I need to send you a 10MB file it will be appropriate.  My 2 cents anyway.

-hadriel

> -----Original Message-----
> Sent: Thursday, December 06, 2007 9:13 PM
> To: Hadriel Kaplan
> Cc: [email-masked]
> > 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).
>
> Yes to MESSAGE.
>
> > 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.
> >
> >         -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?
>
> >         -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.
> >
> >         -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).
> >
> >         -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.
> >
> >         -This is an informational draft, which documents what has been
> implemented, but states it should really be done in the media plane.
> >
> >         -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.
> >
> >         -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
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2007 21:48:52 -0500

> Regarding using MSRP: while that is obviously possible and for some cases undoubtedly the right thing to do, for some uses it is a crazy amount of overhead.  For example if I want to send you a vca…

Yes, I agree. In some cases even though it is a rediculous amount of 
overhead it just won't matter and will be the right thing to do anyway 
if the infrastructure is there to do it. In other cases that isn't so. 
I'm certainly open to some uses for INFO or for more marginal uses of 
MESSAGE.

Especially if we go ahead with this INFO enhancement I think we need to 
draw the line carefully between INFO and MESSAGE.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Dec 2007 06:11:33 +0100

Hi,
 
Just to clarify, when we talk about MESSAGE I assume we do allow it to be used within the invite dialog if appropriate (RFC3428 does allow it)?
 
Regards,
 
Christer

Lähettäjä: Paul Kyzivat [mailto:[email-masked]]
Lähetetty: pe 7.12.2007 3:48
Vastaanottaja: Hadriel Kaplan
Kopio: [email-masked]
Aihe: Re: [Sip] INFO use-cases

        Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Dec 2007 01:04:32 -0500

Yup, it's allowed.  Section 4: "A UAC MAY associate a MESSAGE request with an existing dialog."
-hadriel

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, December 07, 2007 12:12 AM
> To: Paul Kyzivat; Hadriel Kaplan
> Cc: [email-masked]
> Subject: VS: [Sip] INFO use-cases
>
> Hi,
>
> Just to clarify, when we talk about MESSAGE I assume we do allow it to be
> used within the invite dialog if appropriate (RFC3428 does allow it)?
>
> Regards,
>
> Christer
>
> > Regarding using MSRP: while that is obviously possible and for some
> cases undoubtedly the right thing to do, for some uses it is a crazy
> amount of overhead.  For example if I want to send you a vcard mid-call,
> it seems silly to send a re-Invite to add an MSRP session, potentially go
> get msrp-relay info to do so, and/or possibly go through ICE procedures,
> all just to send you a 100 byte little vcard I could have sent in an INFO.
> But clearly if I need to send you a 10MB file it will be appropriate.  My
> 2 cents anyway.
>
> >>> 8) Sending a screen-pop-up message, e.g., "Do you want to continue
> with
> >> this session?"

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Dec 2007 01:41:07 -0500

Yes, AFAIK it is permitted within a dialog. It just is improper to 
establish a dialog for the purpose of using MESSAGE for an IM session. 
Using it in support of an existing dialog should be fine.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Dec 2007 05:54:28 +0100

Hi,
 
I guess the MSRP overhead issue applies also to other cases where there may be some small amount of data sent at some point during the session. User-to-user information is one example.
 
But, I fully agree that INFO shall not be used for sending 10MB of data.
 
Regards,
 
Christer

        Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Dec 2007 02:22:29 +0100

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:[email-masked]]
Lähetetty: pe 7.12.2007 1:46
Vastaanottaja: Hadriel Kaplan; [email-masked]
Aihe: RE: [Sip] INFO use-cases

Sam

Howdy,

/***************

2) ECMA TR/87 uaCSTA

/****************

/*****************

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Dec 2007 13:40:43 -0500

Yeah, but I think we do have to recognize there really are use cases that are simply wrong to do using INFO.  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.

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

> Sent: Thursday, December 06, 2007 8:22 PM
> To: Ganesan Sam-W00184; Hadriel Kaplan; [email-masked]
> 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
>
> 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
>
> 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.
>         -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.
>         -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.
>
> 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.
> 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).
> 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.
>         -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
>         -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
>
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 7 Dec 2007 20:12:35 +0100

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

> Sent: Friday, December 07, 2007 1:22 AM
> 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
> 
> 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
> 
> 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.
> 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.
> 
>         -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?
> 
> 
> /*****************
>         -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 
>         -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).
> 
>         -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.
> 
>         -This is an informational draft, which documents what 
> has been implemented, but states it should really be done in 
> the media plane.
> 
>         -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.
> 
>         -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
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Dec 2007 19:55:35 +0100

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
> 
> 
> > 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):
> >
> > 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 
> use 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
> >
> > 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 
> 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.
> >         -Uses INFO to send ECMA-323 XML for monitoring and 
> controlling 
> > phones from a PC.
> >
> 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.
> >
> > 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.
> > send the vcard, and you can send it knowing the other end 
> can accept 
> > it, and you can send it based on user input.
> >
> >         -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.
> >
> > more info or a datasheet and Bob sends a URL for Alice to open with 
> > her web- browser.
> 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.
> 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 
> > 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.
> >
> > 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?
> >
> >
> > /*****************
> 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.
> >
> >         -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).
> >
> 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.
> >
> >         -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).
> > information in TISPAN.  IMO it should be a sub/not though, as they 
> > want this to survive the Invite session.
> >
> > -hadriel
> >
> >
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> >
> 
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 7 Dec 2007 13:36:08 -0600

On Dec 7, 2007, at 12:40 PM, Hadriel Kaplan wrote:
> 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.
>

I agree completely. There are arguably some good uses for INFO, and  
very likely there will be people who choose to do very silly things  
with it. I really don't want to waste SIP working group time deciding  
which are which. I just want to set up a framework that keeps all  
these uses, good or bad, silly or ingenious, from stepping on each  
other.

The only question in my mind is whether the registry for INFO package  
names should be "specification required" or "First come, first served".

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Dec 2007 21:38:53 -0500

Sorry I should have clarified - meant that just as a general comment, but partly because I thought you were saying anything fitting into your use-case-1 would qualify as legitimate use.
I didn't mean to imply you weren't in agreement. :)

-hadriel

> Sent: Friday, December 07, 2007 1:56 PM
> To: Hadriel Kaplan; Ganesan Sam-W00184; [email-masked]
> Subject: RE: [Sip] INFO use-cases
>
>
> Hi,
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Dec 2007 00:03:40 -0500

Hadriel,

Thanks much for putting down some use cases. These are helpful for a 
good discussion.

Some comments below, but I will say that I'm now convinced that we 
should go ahead and define an info-framework. The real compelling 
argument, I think, is one you make below. Even if we tell everyone they 
shouldn't, its clear that folks are going to be doing this. So, instead 
of saying no, and leaving us with an non-interoperable mess, lets define 
how it works, and give some guidance on what the issues are and when you 
might want to step back and think about whether something else (SUB/NOT, 
media plane, MESSAGE) would be a better choice.

It is very reminiscent of the NAT discussion. Sure, we all agree NAT is 
bad and it makes things harder for lots of apps, and there are better 
ways (v6). But, the architecturally right thing was not as easily 
deployable as the quick-fix NAT solution, and so the latter won out. In 
hindsight, we would have been much better off had we immediately 
standardized clear behaviors for NAT, and not ignored them and just 
declared them bad.

INFO is the same. Sure, there'll often be better ways. But folks have 
spoken with their implementations, that it is more easily deployable 
than any of the other solutions. So lets not re-do the NAT mistake, lets 
define how it works, and not just say 'they're bad', and then end up 
regretting it in a few years when there are hundreds of INFO usages out 
there.

More below:

Hadriel Kaplan wrote:
> 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.
> 
> 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?
> 
> 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 argument is bogus since RFC 3261 clearly says call-info is about 
the caller or callee:

    The Call-Info header field provides additional information about the
    caller or callee, depending on whether it is found in a request or
    response.

There is also a purpose parameter (a close cousin to the info-event, 
I'll note), which is specifically about vcard.

That said, I agree data URI is bad so the real use case for call-info is 
when the vcard is to be sent by indirection. But its clear that 
indirection is much more of a pain than just sending the darn thing; you 
need to store it somewhere, get a URL, and then make sure that URL is 
derefenceable from the target, figure out when its retrieved, and then 
delete the content once retrieved at some point. Thats clearly a lot 
harder than just including it.

Another alternative would be MESSAGE, but I think thats wrong. The 
reason is that MESSAGE should only be used when the one and only purpose 
of the content is to *render*. A vcard isn't just rendered; one can 
imagine a UA saying to a user, "bob has sent his vcard, would you like 
to add to your contacts?" and that is NOT rendering. So MESSAGE is wrong.

ANother choice is the media channel. I agree here the overhead is high 
for that relative to the size of the content.

So I think this is a reasonable use case in fact.

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

Well, here I think the arguments are a bit more compelling for a 
media-path channel. This could be big, very possibly bigger than 1500 
bytes, and this puts us into issues with SIP.

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

Well, I'll disagree with MESSAGE again under the argument that the 
intention here is not to render, but to have some kind of automated 
handling which depends on the purpose of the content (and not just the 
type). But I think this also passes the litmus test for cases where the 
other choices besides INFO are going to add complexity, overhead, or 
latency for no benefit; SUB/NOT is a lot of work when you have no idea 
if you would ever even receive it. Media-path setup would be overly 
complex and a lot of messages for something which is very likely to 
never be sent. The size of these is small, so in the signaling path is 
reasonable.

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

Well, here we already have something defined - REFER with an http URL. 
See draft-ietf-sipping-app-interaction-framework.

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

Max-FOrwards 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.

I'm much less convinced here. This would require handling at proxies and 
we haven't been discussing usage of INFO at proxies like this. Only e2e.

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

SUB/NOT seems a bit better here, I think, since the recipient knows that 
they want it.

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

Rarely pressed yes, but this is an application specifically looking for 
them. This is squarely in the territory of 
draft-ietf-sipping-app-interaction-framework and is better handled by 
those mechanisms.

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

See discussion on indirection above. I think this is reasonable for INFO 
also.

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

Agree SUB/NOT is better. Its already been defined that way.

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

I think this is much better done via a media-plane session. There is a 
requirement for low latency here and there will be a lot of these that 
get sent.

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

Agree.

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

Agree.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Dec 2007 00:47:25 -0500

I'm including some comments to Jonathan's comments, inline.

	Paul

[snip]
> harder than just including it.

Apparently the data url has been declared politically incorrect.

But an Alert-Info or Call-Info with a CID URI should be quite reasonable 
in cases where you want to include the content in the message. (We just 
have to get settled what the Content-Disposition should be.)

> bytes, and this puts us into issues with SIP.

3261 defines both a Call-Info purpose of "icon" and a 
Content-Disposition of "icon" as ways to send a picture of the caller.

> never be sent. The size of these is small, so in the signaling path is 

Frankly the whole Content-Disposition meaning is still a bit up in the 
air IMO. It may be worth a discussion of what it means to have a content 
disposition other than "render" in a MESSAGE.

> See discussion on indirection above. I think this is reasonable for INFO 

Why isn't this a place that where MESSAGE *is* appropriate? Sure seems 
like it is to me.