Subject: AW: AW: [Sip] Diversion interrogation

From: "Thomas Ackermann" <[email-masked]>
Date: Thu, 26 May 2005 08:25:35 +0200

Thanks for your input,
the reason why I've asked for that is with my H.323 background I simply thought
there must be an equivalent in SIP for the H.450.3 "Call diversion supplementary service".
In H.450.3 there just 3 different types of diversions: unconditional, busy, no-reply.
With the means of H.450.3 you're able to query current state of every single div type.
In the interrogation response the server tells you where you are diverted to (name and number).
Actually that's all I want to implement with SIP. Not more.

Thomas Ackermann

-----Ursprüngliche Nachricht-----
Von: Jonathan Rosenberg [mailto:[email-masked]]
Gesendet: Mittwoch, 25. Mai 2005 18:33
An: Paul Kyzivat
Cc: Anders Kristensen; [email-masked]; Dean Willis; Thomas Ackermann;
[email-masked]
Betreff: Re: AW: [Sip] Diversion interrogation

inline.

Paul Kyzivat wrote:

> 
> 
> Anders Kristensen wrote:
> 
>> You could have the service configuration be accessible to clients 
>> through XCAP. Clients would retrieve the configuration on startup and 
>> can subscribe to the sip-profile event package to get notifications 
>> about changes to the service configuration.
> 
> 
> Yes, you could - if there was general agreement that there *is* such a 
> thing as a service configuration for an AoR that is available via XCAP 
> in some well known way.

Sure there is. Its called the sipping configuration framework. One of 
the things it allows you to do is to subscribe to the applications for 
    a particular AOR. Each application would have its own xcap 
application usage that defines the data for that application.

> 
> The feature that started this thread could be abstracted to: the phone 
> wants to indicate something like "this phone isn't ever going to ring 
> because of the way the service configuration is set." Even if the phone 
> could get the service agreement, its not obvious how it could draw this 
> conclusion.

Drawing the conclusion is going to be very hard without standardizing 
the set of services that can cause forwarding to take place. Screening 
applications could also cause the phone to never ring. I agree with 
others that it is not a good thing to fix the set of services.

However, there is a means for the phone to learn the applications 
enabled for a particular AOR, and for those applications understood by 
the phone, and for those that have xcap data associated with them, it 
could figure out what is going to happen. I don't think we can or should 
do better than that.

-Jonathan R.

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

_______________________________________________
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: Mariano Stokle <[email-masked]>
Date: Thu, 26 May 2005 12:19:05 -0300

well, in my sip client I have a diversion rule established that
says:"if the call comes from my wife cellphone, ring my wired office
phone and my sip client by 5 times, if I did not answer then ring my
cell phone". I have other several rules established for other numbers
and presence conditions (Busy Anywhere or Out to Lunch). I cannot
imagine an easy way to represent those diversion conditions by any
rather than accesing the web page where I establish the rules...

-- 
Mariano Stokle
One Protocol to rule them all,
One Protocol to find them,
One Protocol to bring them all
       And in the darkness bind them

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 May 2005 14:06:56 -0400

Exactly - thats the point.

In a world where the set of call features and services is fixed, 
immutable, and written into stone, then it is possible for a client to 
know whether its call will be diverted.

In a world where we allow new services that the clients don't know about 
(the SIP model), then there is no way to know. THe best we can do is 
that the client can know the configuration of the services it does know 
about, and for which configuration information is exposed through the 
sipping configuration framework.

-Jonathan R.