Subject: [Sip] P-Alerting-Mode to standards track?

From: Dean Willis <[email-masked]>
Date: Tue, 15 Mar 2005 14:08:29 -0600

One of the consensus points that seemed to emerge during the recent 
meeting was around the proposed P-Alerting-Mode header. We appear to 
have decided that we really do need a standard (NOT a P-header) way to 
ask a UAS to "auto answer", whether for a diagnostic loopback or 
push-to-talk application. There also seems to be a consensus that this 
should be done with a header, rather than a request parameter or other 
mechanism.

So, it has been proposed that this header be withdrawn from the 
P-header "informational" draft, and re-documented on standards track.

If we pursue this path, it should be noted that we would need to do it 
very quickly, as OMA has real needs for this functionality ASAP. I'll 
volunteer to help Andrew get it whipped into shape, unless somebody 
else wants to throw themselves on it. It seems like a relative 
no-brainer, just an exercise in documentation.

So, poll for consensus: Does anybody strongly object to the development 
of a standard header for requesting auto-answer of a request?

Second poll: Do we see any reasons why this couldn't be done fairly 
quickly, such as obvious dependencies on ongoing work that I've just 
missed?

Thanks,

--
Dean Willis
SIP WG chair

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Mon, 21 Mar 2005 20:46:12 -0800

On the requirement, I would like to have this functionality.

On the mechanism, I would expect this to lead to a few discussions.

---

From: Arjun Roychowdhury <[email-masked]>
Date: Tue, 22 Mar 2005 13:35:36 -0500

Just a quick question - if P-Alerting-Mode were to be used to indicate
"Auto" for a diagnostic call (loopback or otherwise), is it expected
that we use a "Reason" header to provide more infomation on why I want
this mode ? This is no doubt something that will be reused for other
apps beyond PoC, diag being one - and I wanted a clear way to define a
reason. Ideally, a token would be nice - not sure if a free form 
reason header can really be as effective as a well defined token....

regds
arjun

-- 
Arjun Roychowdhury

---

From: David R Oran <[email-masked]>
Date: Thu, 24 Mar 2005 09:58:44 -0500

On Mar 22, 2005, at 1:35 PM, Arjun Roychowdhury wrote:

> this mode ?
No. We need tighter semantics than that in order to be able to do 
authorization feasibly. The direction I'd prefer is to define a 
diagnostic header that actually specifies the diagnostic mode (e.g. 
rtp-loopback, decode/encode loopback, analog loopback, synthetic 
stream, etc.) so you know if, for example, the transducers are going to 
be enabled or not and can authorize appropriately.

> This is no doubt something that will be reused for other
Open ended reasons make authorization harder. I much prefer specifying 
exactly what you want to do rather than why. It works better with 
automatons and is also more in keeping with the general SIP philosophy 
of specifying mechanisms rather than services/applications.

Cheers,. Dave.

>>> quickly, such as obvious dependencies on ongoing work that I've just
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Mar 2005 10:08:38 -0500

> reason header can really be as effective as a well defined token....

I'm not convinced a single item like a token is useful in this regard.

If I am requesting an invite session with auto answer, there may be many 
things in the request that identify what I want to accomplish:
- an offer
- callerprefs
- other special headers
- special body parts
- ...

Any or all of those could be used by the recipient to decide whether to 
accept the call without alerting. With or without such indications, the 
recipient could establish restrictions on what is it is willing to do in 
the absence of some kind of user confirmation that normally follows 
alerting.

For instance, a device that supports PTT and regular voice calls might 
only permit PTT with auto answer because it is "safe" in the sense that 
it still won't transmit without explicit user input. (Auto answering a 
regular voice call with auto answer is a good way to assist people in 
listening in to your room unannounced.)

	Paul

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 24 Mar 2005 10:46:01 -0500

Okay, good. I agree with this reasoning.

In that case, a question on how P-headers evolve - since this was a
call for standards track, my assupmtion was that P-headers evolve to
standards if they are applicable to a variety of networks - not just
one (in this case PoC). If that is true (not sure, please clarify if
this is wrong), then should this draft not also include a mechanism to
identify why P-Alerting is requested - since it really is a big deal
asking my phone not to ring and accept a call, even if you are known
to me.

regds
arjun

-- 
Arjun Roychowdhury

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 24 Mar 2005 11:10:45 -0500

Dave, missed this part in your mail. So are you saying its not a good
idea to specify somewhere in the SIP message that is is for a "poc"
application (or say this is for a "diag" application) and this should
really be inferred by analyzing the other parts of the message ?

So to answer my own question of indicating why P-Alerting mode is
needed, I guess you are saying that if another application needs to
use P-Alerting then its the responsibility of that draft specfying the
usage to also specify a mechanism to identify the application through
the headers/SDP attributes it may choose to introduce. Is this correct
?

regds
arjun

-- 
Arjun Roychowdhury

---

From: David R Oran <[email-masked]>
Date: Thu, 24 Mar 2005 11:28:48 -0500

> really be inferred by analyzing the other parts of the message ?
Correct. I'm saying headers should say what to do, not what application 
it is for. In the case of diagnostics, the header would say you want 
various diagnostic features on the call. (The detail of exactly what to 
loop or synthesize, and how, would be in the SDP rather than the SIP 
signaling, of course). There's no reason to define something rigid like 
a "diagnostic" application.

Ditto for Push-to-talk. If there's some actual mechanism to invoke, 
that goes in the SIP signaling, otherwise it gets inferrred from other 
things. For example, I might honor auto-answer simply based on whether 
the caller is on a particular buddy list.

> the headers/SDP attributes it may choose to introduce. Is this correct
Something has to tell the callee if the caller wants auto-answer rather 
than normal alerting and waiting for user action.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]