Subject: RE: [BLISS] Welcome! Main question - what services?

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Feb 2007 07:22:10 +0000

Jonathan,

I agree with your point about defining a basic but extensible mechanism.
What is not clear is whether mechanisms for "invocation" of features like
DND should be within scope or not. On the one hand, these can be generally
done by web pages and other non-SIP means. The question is whether we need
to define a SIP means too or simply leave it out of scope.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 16 February 2007 21:40
> To: Elwell, John
> Cc: Miguel Garcia; Drage, Keith (Keith); [email-masked]
> Subject: Re: [BLISS] Welcome! Main question - what services?
> 
> There is an issue here, and it has to do with 'invocation' - how does 
> the user signal that they'd like this desired behavior?
> 
> If DND is being done in the network, and we want a user on a 
> phone to be 
> able to hit the 'DND for Video' button, then we do need a 
> standardized 
> way of communicating from the phone to the network element 
> providing the 
> feature (say, its proxy or IP PBX or CSCF or whatever) that 
> this is the 
> desired intent.
> 
> We have this kind of problem even if the phone implements the DND 
> processing. In every real system I've seen, there are always multiple 
> ways of setting this DND status - from a user profile web page, from 
> phone keys, from an admin web page, and so on. So even if the 
> processing 
> is implemented in the phone, we'd need a way to communicate 
> the desired 
> criteria from the web server/provisioning system or whatever, to the 
> phone. Indeed, its exactly the same information we'd need to 
> communicate 
> from the phone to the 'network' when the actual call processing is 
> implemented in the network.
> 
> This (fancy conditions for defining when to block a call) may 
> be an area 
> that we decide to leave alone; that is, BLISS is about *basic* 
> interoperability. We need to define the basic framework 
> needed for this 
> to interoperate, and make sure we leave the hooks in place 
> for vendors 
> to do special stuff when its their phones ontop of their 
> servers, such 
> as a fancier DND service.
> 
> In the particular case of DND for example, let us say we specify that 
> DND call processing is done in the network, and that the service is 
> invoked by including a body in a REGISTER message that indicates the 
> criteria and desired action (just for arguments sake). We 
> could define a 
> basic format for this object which defines no conditions 
> (i.e., DND is 
> either on or off) and defines three actions (reject, 
> send-to-voicemail, 
> ring-indefinitely). We do a nice job in the XML and leave it 
> extensible 
> for other conditions and actions. We define XML namespace 
> techniques for 
> adding new conditions and actions. We support negotiation of 
> supported 
> namespaces during registration time, so the phone knows whether the 
> server supports the extensions it knows about. Then, it can gray out 
> those buttons on its UI, or not show the menu options for them, etc, 
> when the phone finds its connected to a server that only supports the 
> baseline format.
> 
> -Jonathan R.
> 

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: Shida Schubert <[email-masked]>
Date: Mon, 19 Feb 2007 15:17:41 -0800

John;

 I personally think it would depend on the feature/service we look into.

 After exploring the current deployments/implementations, we may realize
that certain features are best served with defining a SIP means for 
"invocation".

 If that's the case defining a mechanism for "invocation" is likely to 
be in scope
for that specific feature we explore.

 In contrary, if it is realized that defining SIP means to invocate the 
feature/service
is not appropriate/unnecessary/overkill then text mentioning this 
approach may
be noted that it does exist, but it would not be the recommended approach.

 Regards
  Shida