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

From: "Elwell, John" <[email-masked]>
Date: Fri, 02 Feb 2007 08:33:39 +0000

Miguel,

An entity providing a DND service should be able filter based on any number
of criteria. One criterion might be the set of media requested (e.g., DND to
any offer involving audio). This filtering doesn't need to be standardised,
unless some sort of reason (e.g., can't accept audio) needs to be returned
to the caller.

John 

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: 01 February 2007 15:13
> To: Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [BLISS] Welcome! Main question - what services?
> 
> Right... the capability of indicating a DND for SIP offers 
> that contain 
> certain media streams. Similarly with SIP methods.
> 
> /Miguel
> 
> Drage, Keith (Keith) wrote:
> > I assume that you mean you wish to be DND to a request with 
> a SIP offer
> > of a particular media stream, rather than just DND to a 
> particular media
> > stream.
> > 
> > Regards
> > 
> > Keith 
> > 
> >> -----Original Message-----
> >> From: Miguel Garcia [mailto:[email-masked]] 
> >> Sent: 01 February 2007 15:02
> >> To: Paul Kyzivat
> >> Cc: Drage, Keith (Keith); [email-masked]
> >> Subject: Re: [BLISS] Welcome! Main question - what services?
> >>
> >> DND can also apply to a particular media stream. In 
> >> particular, if I am in a meeting, I may want to activate the 
> >> DND for audio and video, but not for messaging.
> >>
> >> I guess in general, you need to consider all the different 
> >> media streams that can apply to service. It would be a big 
> >> mistake just to restrict to audio or to "things that are 
> >> initiated with an INVITE" because this is what the PSTN did.
> >>
> >> /Miguel
> >>
> >> Paul Kyzivat wrote:
> >>> I have been inovlved in an exercise of trying to map 
> >> traditional PSTN 
> >>> services to SIP, and make them apply more generally to the 
> >> broader set 
> >>> of things that can happen in SIP.
> >>>
> >>> Some services seem to apply to an AOR, others to a UA, and some 
> >>> potentially to a particular media stream. And in some cases 
> >> there are 
> >>> multiple meaningful ways to apply the service. For instance:
> >>>
> >>> - DND can meaningfully apply at either the AOR level or the 
> >> UA level.
> >>>   You could consider these to be different services.
> >>>
> >>> - HOLD can apply to a whole dialog, or to a particular 
> media stream
> >>>   within a dialog.
> >>>
> >>> Its important to consider these things.
> >>>
> >>>     Paul
> >>>
> >>
> >> -- 
> >> Miguel A. Garcia           tel:+358-50-4804586
> >> sip:[email-masked]
> >> Nokia Research Center      Helsinki, Finland
> >>
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bliss
> 

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

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 02 Feb 2007 15:02:44 +0200

John:

We agree that one possible criterion to DND is the media type(s) 
requested in the offer. While this does not need to be standardized 
itself, perhaps we need to standardize the interface from the endpoint 
to the application server that executes the DND server. This depends 
basically on how the service is implemented, and in particular, on 
whether the service is network provided or not. But I think it is worth 
having a discussion on how the service can work in such circumstances.

/Miguel

---

From: [email-masked]
Date: Fri, 2 Feb 2007 10:56:00 -0500

From: "Elwell, John" <[email-masked]>

   An entity providing a DND service should be able filter based on
   any number of criteria. One criterion might be the set of media
   requested (e.g., DND to any offer involving audio).

I don't quite see what the dispute is here -- Certainly, it's possible
to put a UA into a state where it doesn't accept a media type that it
normally would.  Whether we want to call this a form of "Do Not
Disturb" seems to be entirely a matter of definition.  And since all
the machinery needed to implement it already exists, I see no need for
further standardization.

   This filtering doesn't need to be standardised, unless some sort of
   reason (e.g., can't accept audio) needs to be returned to the
   caller.

I'm not up on the offer/answer machinery, but isn't there a way to
indicate this, by declining every offered m-line in the INVITE's SDP
in a 200 response?  I know that there is a standard indication for
"all of the codecs/media you have offered are unacceptable to me".

My belief is that 488 is restricted to meaning "I can't process
application/sdp [or whatever content-type was in the request]", but I
might very well be wrong about that.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Feb 2007 16:39:53 -0500

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.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: [email-masked]
Date: Mon, 19 Feb 2007 12:00:59 -0500

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

Um, if I might be so bold to ask, *why* would be want to have DND call
processing done in the network?  It's true that if we want to have DND
done in the network, we need to define some moderately complex
mechanism for having the UA report to the network its DND status.  But
that's really an argument that DND should be done in the phone, and
activated by a button (like it is on every SIP phone).

If we're really going to try to define such a mechanism, we first need
to review that there really is such a requirement, that such an
architecture is really the best solution to the DND "problem" in a
reasonable fraction of real-world cases.  That this is a significant
deviation from the end-to-end principle is a warning sign...

Dale

---

From: Jaimin Pancholi <[email-masked]>
Date: Tue, 20 Feb 2007 09:12:36 +0530

Hi ,
	I may be a junior in this area but as per my understanding
the problem that the circuit switched network has is the centralized logic
for
almost everything. The end terminal does not have any intelligence at all,
making 
deployment of the service / application a big issue !

In general, SIP network (VoIP) network provides a advantage i.e. it has
decentralized the
logic and had proposed some intelligence in the end terminal.

I think, I would agree with Dale that intelligence in end terminal is good
for basic
services like DND, Call forward

Cheers
Jaimin

Email Privacy Declaration
****************************************************************************
***********
	This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

>From: [email-masked] [mailto:[email-masked]] 
>Sent: Monday, February 19, 2007 10:31 PM
>To: [email-masked]
>Um, if I might be so bold to ask, *why* would be want to have 
>DND call processing done in the network?  It's true that if we 
>want to have DND done in the network, we need to define some 
>moderately complex mechanism for having the UA report to the 
>network its DND status.  But that's really an argument that 
>DND should be done in the phone, and activated by a button 
>(like it is on every SIP phone).
>
>If we're really going to try to define such a mechanism, we 
>first need to review that there really is such a requirement, 
>that such an architecture is really the best solution to the 
>DND "problem" in a reasonable fraction of real-world cases.  
>That this is a significant deviation from the end-to-end 
>principle is a warning sign...
>
>Dale
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Feb 2007 13:48:54 -0500

> deviation from the end-to-end principle is a warning sign...

If I have multiple phones all registered to the same AOR, then I may 
want the DND to prevent them all from ringing. A DND implemented in the 
phone on my desk won't prevent the phones in the living room and bedroom 
and kitchen from ringing. A network based DND will.

Of course there are other ways to skin this cat. For instance, I could 
send a DND feature activation notice to all the other phones. That would 
only work for phones that were on at the time, so I would have to 
monitor for other phones registering, and send notifications to them 
when they do. And if a phone reboots I might have to send it again. (Not 
sure how I would detect that.)

When there are common policies that should be applied to any and all 
registered devices then there is some potential value in implementing 
that policy at the common point.

Of course it may be that I don't want my DND applied to the other 
registered phones. Specifically, if I am in my hotel room in Prague and 
have registered a phone to my home phone number, then I probably don't 
want DND selected by someone at home to affect me.

IMO this says that DND isn't just one feature. Instead, there is 
DND-device, and DND-AOR. They both have value in different cases. And 
both can be implemented in different ways.

	Paul

---

From: [email-masked]
Date: Tue, 20 Feb 2007 15:06:34 -0500

From: Paul Kyzivat <[email-masked]>

So there are various "scopes" to which the DND might apply, which
superficially seem to be the same AOR.  I've seen this phenomenon in
other places, particularly SUBSCRIBEs to obtain status information.
Often, the scope of forking that I want is not quite the same as all
the contacts for an AOR.

Dale