Subject: [Sipping] Comments on PoC drafts

From: Schmidt Christian <[email-masked]>
Date: Wed, 2 Mar 2005 15:34:01 +0100

Hallo,

after a first review of both drafts, here first comments / questions / proposals.

draft-garcia-sipping-poc-isb-am-01.txt
"This document defines a SIP event package to support publication, subscription and notification of additional capabilities required by the PoC service.  This SIP event package is applicable to the PoC service and may not be applicable to the general Internet."

draft-allen-sipping-poc-p-headers-01.txt
"This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the Open Mobile Alliance OMA),For Push to talk over Cellular (PoC) along with their applicability, which is limited to the OMA PoC application.  The P-headers are used for requesting and indicating the alerting mode of the handset which is particular to the PoC application."

General issues:
*	What is the correlation of the two drafts? Are they independent? Are they describing independent requirements / solutions for PoC?
*	What is the exact meaning behind the applicability restriction within the Internet? Perhaps it would be better to include the preconditions for applicability in this case.

draft-allen-sipping-poc-p-headers-01.txt:
*	The usage / handling of the new SIP private headers in the different entities become not clear. An example (PoC Group Call) could help for understanding the use case and the need for the new headers and should be added.
*	Calling PoC terminal -> PoC Server: INVITE with P-Altering-Mode header: Auto-Answer.
*	PoC Server -> Called PoC terminals 1-n): INVITE with P-Altering-Mode header: Auto-Answer.
*	Called PoC terminal x: 200 Reply: P-Answer-State header "unconfirmed response"
*	PoC Server -> Calling PoC terimal: 200 Reply: P-Answer-State header "unconfirmed response"
*	The 200 responses from other called PoC terminals are not forwarded by the PoC Server to the Calling PoC terminal.
*	After receipt of the 200 Reply with "unconfirmed response", the calling PoC terminal can signal to the subscriber, that in theory somebody could listen to his talk.
*	Are the assumptions correct?
*	Is it possible for a PoC terminal to signal to the PoC server a change in the answering mode, independent from call activities.
*	Would it be possible for the calling PoC terminal, to derive the kind of response from the period between INVITE and 200 reply?

Some editorial comments:
draft-garcia-sipping-poc-isb-am-01.txt
*	1. Introduction / 3. paragraph: This is mode of operation > This mode of operation.
*	1. Introduction / Last paragraph: Difficult to read, please rephrase.

draft-allen-sipping-poc-p-headers-01.txt:
*	4.1.1 Requirements / AM2: a manual answer mode which allows requires the invited.. > a manual answer mode which requires the invited..
*	4.1.4 Usage of the P-Alerting-Mode header:  At the location of the first usage of MAO, the abbreviation should be explained.

Regards
Christian Schmidt, Siemens COM

	Phone: 	+49 89 636-75192
	Mobile: 	+49 178 7700363
	Fax: 	+49 89 636-75577
	E-Mail: 	[email-masked]

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

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 04 Mar 2005 11:40:08 +0200

Hi Christian:

Thanks for your comments. See some thoughts inline.

Schmidt Christian wrote:

> "This document defines a SIP event package to support publication, 
> subscription and notification of additional capabilities required by the 
> PoC service.  This SIP event package is applicable to the PoC service 
> and may not be applicable to the general Internet."
> 
> "This document describes a set of private Session Initiation 
> Protocol(SIP) headers (P-headers) used by the Open Mobile Alliance 
> OMA),For Push to talk over Cellular (PoC) along with their 
> applicability, which is limited to the OMA PoC application.  The 
> P-headers are used for requesting and indicating the alerting mode of 
> the handset which is particular to the PoC application."
> 
> General issues:
> 
>     * What is the correlation of the two drafts? Are they independent?
>       Are they describing independent requirements / solutions for PoC?

 From the point of view of the IETF process, these drafts are 
independent, since one is defining a SIP event package and the other is 
defining a number of P- headers. Conceptually they are different. 
However, both are done in support of the Push-to-Talk over Cellular 
(PoC) service, defined by OMA. Both contribute to the PoC solution.

>     * What is the exact meaning behind the applicability restriction
>       within the Internet? Perhaps it would be better to include the
>       preconditions for applicability in this case.

The meaning is that these documents contain a bunch of assumptions, 
specified in the PoC documents, that we believe make these documents not 
generally applicable to the Internet.

>     * The usage / handling of the new SIP private headers in the
>       different entities become not clear. An example (PoC Group Call)
>       could help for understanding the use case and the need for the new
>       headers and should be added.
>           o Calling PoC terminal -> PoC Server: INVITE with
>             P-Altering-Mode header: Auto-Answer.
>           o PoC Server -> Called PoC terminals 1-n): INVITE with
>             P-Altering-Mode header: Auto-Answer.
>           o Called PoC terminal x: 200 Reply: P-Answer-State header
>             "unconfirmed response"
>           o PoC Server -> Calling PoC terimal: 200 Reply: P-Answer-State
>             header "unconfirmed response"
>           o The 200 responses from other called PoC terminals are not
>             forwarded by the PoC Server to the Calling PoC terminal.
>           o After receipt of the 200 Reply with "unconfirmed response",
>             the calling PoC terminal can signal to the subscriber, that
>             in theory somebody could listen to his talk.
>           o Are the assumptions correct?
>     * Is it possible for a PoC terminal to signal to the PoC server a
>       change in the answering mode, independent from call activities.
>     * Would it be possible for the calling PoC terminal, to derive the
>       kind of response from the period between INVITE and 200 reply?
> 
> Some editorial comments:

Ok, thanks for your comments. I will take them into account in the next 
revision.

>     * 4.1.1 Requirements / AM2: a manual answer mode which allows
>       requires the invited.. > a manual answer mode which requires the
>       invited..
>     * 4.1.4 Usage of the P-Alerting-Mode header:  At the location of the
>       first usage of MAO, the abbreviation should be explained.
> 
> Regards

Regards,

        Miguel.
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Mar 2005 11:54:31 -0600

On Mar 4, 2005, at 3:40 AM, Miguel Garcia wrote:
> specified in the PoC documents, that we believe make these documents 
> not generally applicable to the Internet.
>

I think the problem here is that that applicability restriction is 
insufficiently clear in its discussions of exactly WHY these things are 
inappropriate for the Internet, including discussion of the liability 
should they be used inappropriately. This was something I noted in my 
review of the Allen draft.

Simply saying "Don't use these headers unless you're using them in an 
OMA context" is insufficient. We need to know what it is about the OMA 
context that makes it OK to use these headers there, and how this 
differs from the Internet at large.

If there isn't really any justification, and we're just doing 
"P-headers" because the barrier to entry is lower and we don't EXPECT 
anybody to use them outside of OMA. we might get by with something like 
"These extensions are inappropriate for use in the general Internet 
because they did not receive security review for use on the Internet. 
Instead, the security analysis was conducted in the context of an OMA 
network as documented  in (insert ref)." Although I'll probably get 
slapped by a security AD for suggesting it, and I would much rather see 
a useful discussion of the specific properties and assumptions that 
make the extension OK when used with OMA.

And of course, we  don't have "P-event-packages", so a full discourse 
there would be appropriate.

--
Dean

---

From: David R Oran <[email-masked]>
Date: Sun, 6 Mar 2005 11:07:26 -0500

I suspect that auto-answer will be widely used (and abused) for lots of 
purposes and nobody will worry that it happens to be defined in a 
P-header targeted at push-to-talk-over-cellular.

I don't necessarily want to stop this work, but simply point out the 
likely practical consequences. I certainly would prefer a general SIP 
solution for auto-answer if there was any hope of getting it past the 
Mullahs.

Dave.

(P.S. people I know and work with will likely be among the first to 
jump on this, for better or worse)

On Mar 4, 2005, at 12:54 PM, Dean Willis wrote:

> insufficiently clear in its discussions of exactly WHY these things 
> are inappropriate for the Internet, including discussion of the 
> liability should they be used inappropriately. This was something I 
> noted in my review of the Allen draft.
>
> anybody to use them outside of OMA. we might get by with something 
> like "These extensions are inappropriate for use in the general 
> Internet because they did not receive security review for use on the 
> Internet. Instead, the security analysis was conducted in the context 
> of an OMA network as documented  in (insert ref)." Although I'll 
> probably get slapped by a security AD for suggesting it, and I would 
> much rather see a useful discussion of the specific properties and 
> assumptions that make the extension OK when used with OMA.
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]