Subject: RE: [Sip] INFO use-cases

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 Dec 2007 20:48:19 -0500

Hi JK,
I actually saw that draft but did not include it because I thought it was essentially another DTMF-style event type, and would be subsumed into it, but you're right I should have included that use-case.  Sorry!

-hadriel

________________________________________
From: 황진경[연구전문그룹] [mailto:[email-masked]]
Sent: Thursday, December 06, 2007 8:33 PM
To: Hadriel Kaplan; [email-masked]
Subject: RE: [Sip] INFO use-cases
Dear folks,
 How about the Midcall INFO ?
 When 'Hook-Flash' from the SIP or POTS phone during a dialogue, we (KT) use INFO method from the CSCF/MGCF to AS.
 I submitted a draft I-D two years ago but it was not accepted,
But we still use the case.
 Can it be another Use-Case ?
 JK Hwang
KT

-----원본 메시지-----
보낸 사람: "Hadriel Kaplan" <[email-masked]>
보낸 날짜: 2007-12-07 오전 8:38:36
받는 사람: "[email-masked]" <[email-masked]>
참조:
제목: [Sip] INFO use-cases

Howdy,
Jonathan asked for use-cases for what types of things would need an in-dialog SIP message for user-user communication, vs. should be done either out of dialog or in the media plane.  If the only use-case is DTMF, then we could just document the DTMF negotiation/use only and not have to create a general info-events framework.  That seems a very reasonable argument to me.  I also don't want to do work for no use.

There is a counter-argument that there are proprietary uses of INFO in the wild, and that a framework for negotiation at least removes the manual configuration of vendor-specific profiles, which is a problem of interop today - even if the IETF should not bless/document the specific use cases themselves.  But that would make the draft a very different one than it currently is as well, and I will ask that in a separate email thread.

The chairs have asked for 3 use cases, and I assume they mean 3 NEW use cases (we already have 3 RFCs which use INFO, as well as DTMF).  I am not sure if they mean potential future use-cases, or current use-cases (i.e., already implemented).  Can I get a clarification on that?

So anyway, taking the shot-gun approach, here's a first go at some use-cases, and my personal take on whether they should be in INFO vs. SUB/NOT vs. media-plane, FWIW.
[apologize for formatting ugliness]

/***************
*  Already standardized use-cases:
***************/
1) SIP-T/ISUP/QSIG/PSTN
        -Documented in RFC 3372 and RFC 4497.

2) ECMA TR/87 uaCSTA
        -Uses INFO to send ECMA-323 XML for monitoring and controlling phones from a PC.

3) Sending media server control commands.
        -Documented in RFC4722 MSCML.

/****************
*  Use-cases that I think are potentially/possibly valid for INFO:
****************/
1) Sending a vcard asynchronously.  Alice calls Bob, Alice says "can you send me John's vcard?", Bob clicks something and voila it's sent.
        -Alternatives: send a re-Invite or Update with a Call-Info, with either a URL reference, data URI, or MIME and CID URL.
        -Counter-argument: IMO this type of data really belongs in MIME for a number of reasons, including length is less restricted for mime attachments; one AD has said the Data URL may be deprecated.  And sending a re-Invite for this purpose seems odd.

        -Also, the Call-Info header is really about the caller or callee, and thus Bob shouldn't be sending me John's vcard info in it technically.  That may sound like a nit, but UA's may well store the call-info vcards into their address-books automatically and so tie it to the wrong user/call.
        -Pros of using INFO: it's explicit what you're doing when you send the vcard, and you can send it knowing the other end can accept it, and you can send it based on user input.

2) Sending a user-icon jpeg/bitmap/gif.  Alice calls Bob, Bob has an icon that represents himself, sends it when he picks up the phone.
        -Alternatives: send a 200ok, re-Invite, or Update with call-info, which explicitly has a type for icon.
        -Counter-argument: same as for vcard, plus with call-info there is no way to know which picture format the far-end supports a priori.  With a supported-package negotiation one could know.

3) Sending a vcalendar-type invitation.  Alice calls Bob, Bob says "hey let's have a con call at time X", clicks and voila his phone sends a vcalendar..
        -Whether the vcalendar is related to the session or not and thus whether it should be sent in an in-dialog request or not is certainly debatable.  Message method can already be used for this anyway.

4) Sending an HTTP URL.  Alice calls Bob, a sales guy; Alice asks for more info or a datasheet and Bob sends a URL for Alice to open with her web-browser.
        -One could also argue this is just making SIP the new SMTP, or this should be sent using MESSAGE (which really is the new SMTP).

5) Sending a session traceroute.  Alice calls Bob, Bob answers, Alice does a sip-traceroute to figure out the path to Bob, by sending Info with an incrementing max-forwards type header starting at 0 (but not really max-forwards), with a sip-frag type response body or some such.
        -It's debatable if certain types of B2BUA's (ie, SBCs) would ever allow this type of thing to happen, due to security concerns, but I think they may do it at domain boundary hops.  I think this is a reasonable use for INFO though, maybe.

6) Sending geo-location information after call establishment.  Alice calls Bob, a hotel receptionist.  Alice asks for directions to hotel, clicks button and sends him location info of her phone (or Bob clicks button and sends her his location).
        -The location conveyance draft specifically calls out INFO as acceptable for geo-loc info.  Whether this is a real use-case is debatable, and obviously it could be done with a sub/not.

7) Sending softkey-labels (not digit-match maps, but rather softkey button labels).  Alice calls her vmail server.  Vmail server sends softkey-labels for the menu items available in the response, Alice presses softkeys and sends them in INFO.
        -This could (and maybe should) be done with sub/not, a la KPML, where the vmail server sends the softkey labels in the Subscribe, UA sends buttons pressed in Notifies.  But this is similar to the DTMF use case so may well have the same benefit of lower overhead since buttons are rarely pressed.

8) Sending a screen-pop-up message, e.g., "Do you want to continue with this session?"
        -There is a patent for doing screen pop-ups using INFO.  I guess Alert-Info could be used for this, but it's not clear it should?

/*****************
*  Use-cases which have been proposed by others or even implemented,
*  which are dubious for INFO (IMHO):
*****************/
1) Sending RTP/RTCP statistics during call.
        -There is an implementation of this, and the rationale is the signaling plane box that wants this info is not actually the media plane box that gets RTCP.  Again this could (and IMO should) be done with sub/not, so it can get stats after the call is over, and since it will probably want periodic reports the overhead of the Subscribe should be dwarfed by the number of Notifies.

2) Sending access-location information after call establishment.
        -There is a P-Access-Network-Info header, and some have proposed to send an update for it as a phone roams access points or cells.  But I think this is an odd thing to do inside an Invite session, vs. in a sub/not or Register (and besides half the time the network inserts this header, not the UA).

3) Sending media-control indications (ie, remote-control "play/pause/etc.")
        -This is done today by at least one vendor, but is debatable if it's the right model.  The argument is it's like SDP re-Invite for hold, except at a media content layer above RTP, so not done in RTCP nor SDP.

4) Sending video fast update command
        -This is an informational draft, which documents what has been implemented, but states it should really be done in the media plane.

5) Sending peripheral control commands (ie, USB commands)
        -There is actually a patent on this, amazingly.  Someone thinks it makes sense to create a SIP session to your laptop, or vice-versa, and then send USB commands inside MIME in INFO messages.  Methinks this should be media-plane, if anything.

6) Sending charging information for a call (i.e., minutes remaining or cost so far).
        -There was a proposal to use this for Advice of Charge information in TISPAN.  IMO it should be a sub/not though, as they want this to survive the Invite session.

-hadriel

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: 황진경[연구전문그룹] <[email-masked]>
Date: Fri, 7 Dec 2007 11:12:27 +0900

Dear Hadriel Kaplan and folks

(in our case) 
Midcall INFO is used in 

1) Three-way calling: to add another party to existing call 
2) Call waiting: to change dialogue between two ongoing calls
3) Centrex services: call transfer, etc.

THX

JK Hwang
KT
-----원본 메시지-----
보낸 사람: "Hadriel Kaplan" <[email-masked]>
보낸 날짜: 2007-12-07 오전 10:48:19
받는 사람: "황진경[연구전문그룹]" <[email-masked]>
참조: "[email-masked]" <[email-masked]>
제목: RE: [Sip] INFO use-cases

Hi JK,

-hadriel

-----원본 메시지-----
보낸 사람: "Hadriel Kaplan" <[email-masked]>
보낸 날짜: 2007-12-07 오전 8:38:36
받는 사람: "[email-masked]" <[email-masked]>
참조:
제목: [Sip] INFO use-cases

Howdy,

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

2) ECMA TR/87 uaCSTA

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

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

-hadriel

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 6 Dec 2007 23:54:17 -0500

These 3 use cases below seem misuse of INFO as there are established mechanism of doing these using non-INFO way.

________________________________

	From: 황진경[연구전문그룹] [mailto:[email-masked]] 
	Sent: Thursday, December 06, 2007 9:12 PM
	To: Hadriel Kaplan
	Cc: [email-masked]
	Subject: RE: [Sip] INFO use-cases

	(in our case) 

	Midcall INFO is used in 

	THX

	JK Hwang

	KT
	-----원본 메시지-----
	보낸 사람: "Hadriel Kaplan" <[email-masked]>
	보낸 날짜: 2007-12-07 오전 10:48:19
	받는 사람: "황진경[연구전문그룹]" <[email-masked]>
	참조: "[email-masked]" <[email-masked]>
	제목: RE: [Sip] INFO use-cases

	Hi JK,
	
	-hadriel

	-----원본 메시지-----
	보낸 사람: "Hadriel Kaplan" <[email-masked]>
	보낸 날짜: 2007-12-07 오전 8:38:36
	받는 사람: "[email-masked]" <[email-masked]>
	참조:
	제목: [Sip] INFO use-cases

	Howdy,

	
	
	/***************
	
	2) ECMA TR/87 uaCSTA

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

	

	

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

	

	
	-hadriel

---

From: 황진경[연구전문그룹] <[email-masked]>
Date: Fri, 7 Dec 2007 14:10:04 +0900

Dear sanjsinh

I don't know the other way to collect "Hook-Flash" event along on-going dialogue.
What is the suggested 'non-INFO way' ? 

THX 

JK
-----원본 메시지-----
보낸 사람: "Sanjay Sinha (sanjsinh)" <[email-masked]>
보낸 날짜: 2007-12-07 오후 1:54:17
받는 사람: "황진경[연구전문그룹]" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>
참조: "[email-masked]" <[email-masked]>
제목: RE: [Sip] INFO use-cases

(in our case) 
Midcall INFO is used in 

THX

JK Hwang
KT
-----원본 메시지-----
보낸 사람: "Hadriel Kaplan" <[email-masked]>
보낸 날짜: 2007-12-07 오전 10:48:19
받는 사람: "황진경[연구전문그룹]" <[email-masked]>
참조: "[email-masked]" <[email-masked]>
제목: RE: [Sip] INFO use-cases

Hi JK,

-hadriel

-----원본 메시지-----
보낸 사람: "Hadriel Kaplan" <[email-masked]>
보낸 날짜: 2007-12-07 오전 8:38:36
받는 사람: "[email-masked]" <[email-masked]>
참조:
제목: [Sip] INFO use-cases

Howdy,

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

2) ECMA TR/87 uaCSTA

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

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

-hadriel

---

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

I think the confusion just came from your describing what purpose you wanted the hook-flash indication for, which was for application features (3-way calling, call waiting, transfer).  SIP obviously expects such things to be done/initiated by the UA’s themselves natively, by handling multiple sessions, REFERs, etc. – vs. using a centralized app-server to contain the entire service logic and treating the phone as a POTS line.  In your draft you had MGCP-controlled phone serviced by an MGC, which was acting as a SIP UA but expecting a separate SIP App Server to do its dirty work.  That MGC really is a stand-alone SIP UA and thus could/should handle the service logic.  Otherwise it’s just using SIP as a tunneling transport for MGCP in a way (at least architecturally).  For example if your SIP UA receives a call directly from another proxy/UA, the “features” no longer work because the App Server is not in the loop.

So I think it‘s just safer/cleaner if you describe your use-case as simply wanting to get hook-flash indication, as just another form of asynchronous user input similar in concept to a soft-button or DTMF.  (it’s actually not clear to me hook-flash actually is such a thing, because it’s really synonymous with a hold/transfer/conference button, but it’s arguable at least)

-hadriel

________________________________
From: 황진경[연구전문그룹] [mailto:[email-masked]]
Sent: Friday, December 07, 2007 12:10 AM
To: Sanjay Sinha (sanjsinh); Hadriel Kaplan
Cc: [email-masked]
Subject: RE: [Sip] INFO use-cases

Dear sanjsinh

THX

JK
-----원본 메시지-----
보낸 사람: "Sanjay Sinha (sanjsinh)" <[email-masked]>
보낸 날짜: 2007-12-07 오후 1:54:17
받는 사람: "황진경[연구전문그룹]" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>
참조: "[email-masked]" <[email-masked]>
제목: RE: [Sip] INFO use-cases

(in our case)

Midcall INFO is used in

THX

JK Hwang

KT
-----원본 메시지-----
보낸 사람: "Hadriel Kaplan" <[email-masked]>
보낸 날짜: 2007-12-07 오전 10:48:19
받는 사람: "황진경[연구전문그룹]" <[email-masked]>
참조: "[email-masked]" <[email-masked]>
제목: RE: [Sip] INFO use-cases

Hi JK,

-hadriel

-----원본 메시지-----
보낸 사람: "Hadriel Kaplan" <[email-masked]>
보낸 날짜: 2007-12-07 오전 8:38:36
받는 사람: "[email-masked]" <[email-masked]>
참조:
제목: [Sip] INFO use-cases

Howdy,

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

2) ECMA TR/87 uaCSTA

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

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

-hadriel