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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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]

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

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

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

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

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

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.

> /*****************
> *  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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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-----
> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
> Sent: Thursday, December 06, 2007 9:13 PM
> To: Hadriel Kaplan
> Cc: sipietf.org
> Subject: Re: [Sip] INFO use-cases
>
> 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]
>
> > /****************
> > *  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.
>
> 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.)
>
> > 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.
>
> UPDATE with geo-loc is reasonable here, or even
reINVITE.
>
> > 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?
>
> 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.
>
> > /*****************
> > *  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://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol
> > Use sip-implementorscs.columbia.edu for
questions on current sip
> > Use sippingietf.org for new developments on the
application of sip
> >


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Hadriel Kaplan wrote:
> 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.

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

> -hadriel
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
>> Sent: Thursday, December 06, 2007 9:13 PM
>> To: Hadriel Kaplan
>> Cc: sipietf.org
>> Subject: Re: [Sip] INFO use-cases
>>
>> 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]
>>
>>> /****************
>>> *  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.
>>
>> 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.)
>>
>>> 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.
>>
>> UPDATE with geo-loc is reasonable here, or even
reINVITE.
>>
>>> 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?
>>
>> 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.
>>
>>> /*****************
>>> *  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://ww
w1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core
SIP Protocol
>>> Use sip-implementorscs.columbia.edu for
questions on current sip
>>> Use sippingietf.org for new
developments on the application of sip
>>>
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:pkyzivatcisco.com]
Lähetetty: pe 7.12.2007 3:48
Vastaanottaja: Hadriel Kaplan
Kopio: sipietf.org
Aihe: Re: [Sip] INFO use-cases





Hadriel Kaplan wrote:
> 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.

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

> -hadriel
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
>> Sent: Thursday, December 06, 2007 9:13 PM
>> To: Hadriel Kaplan
>> Cc: sipietf.org
>> Subject: Re: [Sip] INFO use-cases
>>
>> 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]
>>
>>> /****************
>>> *  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.
>>
>> 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.)
>>
>>> 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.
>>
>> UPDATE with geo-loc is reasonable here, or even
reINVITE.
>>
>>> 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?
>>
>> 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.
>>
>>> /*****************
>>> *  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://ww
w1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core
SIP Protocol
>>> Use sip-implementorscs.columbia.edu for
questions on current sip
>>> Use sippingietf.org for new
developments on the application of sip
>>>
>


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbergericsson.com]
> Sent: Friday, December 07, 2007 12:12 AM
> To: Paul Kyzivat; Hadriel Kaplan
> Cc: sipietf.org
> 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
>
> ________________________________
>
> Lähettäjä: Paul Kyzivat [mailto:pkyzivatcisco.com]
> Lähetetty: pe 7.12.2007 3:48
> Vastaanottaja: Hadriel Kaplan
> Kopio: sipietf.org
> Aihe: Re: [Sip] INFO use-cases
>
>
>
>
>
> Hadriel Kaplan wrote:
> > 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.
>
> 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
>
> > -hadriel
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
> >> Sent: Thursday, December 06, 2007 9:13 PM
> >> To: Hadriel Kaplan
> >> Cc: sipietf.org
> >> Subject: Re: [Sip] INFO use-cases
> >>
> >> 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]
> >>
> >>> /****************
> >>> *  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.
> >>
> >> 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.)
> >>
> >>> 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.
> >>
> >> UPDATE with geo-loc is reasonable here, or
even reINVITE.
> >>
> >>> 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?
> >>
> >> 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.
> >>
> >>> /*****************
> >>> *  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://ww
w1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the
core SIP Protocol
> >>> Use sip-implementorscs.columbia.edu for
questions on current sip
> >>> Use sippingietf.org for new
developments on the application of sip
> >>>
> >
>
>
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
>



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

Christer Holmberg wrote:
> 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:pkyzivatcisco.com]
> Lähetetty: pe 7.12.2007 3:48
> Vastaanottaja: Hadriel Kaplan
> Kopio: sipietf.org
> Aihe: Re: [Sip] INFO use-cases
> 
> 
> 
> 
> 
> Hadriel Kaplan wrote:
>> 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.
> 
> 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
> 
>> -hadriel
>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
>>> Sent: Thursday, December 06, 2007 9:13 PM
>>> To: Hadriel Kaplan
>>> Cc: sipietf.org
>>> Subject: Re: [Sip] INFO use-cases
>>>
>>> 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]
>>>
>>>> /****************
>>>> *  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.
>>>
>>> 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.)
>>>
>>>> 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.
>>>
>>> UPDATE with geo-loc is reasonable here, or even
reINVITE.
>>>
>>>> 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?
>>>
>>> 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.
>>>
>>>> /*****************
>>>> *  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://ww
w1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the
core SIP Protocol
>>>> Use sip-implementorscs.columbia.edu for
questions on current sip
>>>> Use sippingietf.org for new
developments on the application of sip
>>>>
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

________________________________

Lähettäjä: Paul Kyzivat [mailto:pkyzivatcisco.com]
Lähetetty: pe 7.12.2007 3:48
Vastaanottaja: Hadriel Kaplan
Kopio: sipietf.org
Aihe: Re: [Sip] INFO use-cases





Hadriel Kaplan wrote:
> 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.

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

> -hadriel
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
>> Sent: Thursday, December 06, 2007 9:13 PM
>> To: Hadriel Kaplan
>> Cc: sipietf.org
>> Subject: Re: [Sip] INFO use-cases
>>
>> 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]
>>
>>> /****************
>>> *  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.
>>
>> 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.)
>>
>>> 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.
>>
>> UPDATE with geo-loc is reasonable here, or even
reINVITE.
>>
>>> 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?
>>
>> 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.
>>
>>> /*****************
>>> *  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://ww
w1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core
SIP Protocol
>>> Use sip-implementorscs.columbia.edu for
questions on current sip
>>> Use sippingietf.org for new
developments on the application of sip
>>>
>


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip