Subject: Re: AW: [Sip] Diversion interrogation

From: [email-masked]
Date: Tue, 24 May 2005 08:14:09 -0400

The idea here seems to be that you have an agent somewhere (e.g., a PBX or
a proxy) that is managing call forwarding (diversion) on behalf of an AOR,
and you would like one or more of your SIP phones to be able to know the
current status of diversions. An event package would seem to be one of the
best ways to fit this into the SIP framework. A phone that wants to know
the status would subscribe to that event package at the AOR, and would be
notified whenever the diversion state changes. When the phone first comes
online and subscribes to the event package, it gets an immediate
notification of the state.

Such a call forwarding/diversion event package has not, AFAIK, been defined
or even proposed to date. It is probably debatable whether such an event
package would be of sufficient general interest and applicability to be the
subject of an IETF standard; if it is, SIPPING is probably the place to
propose it. I can say that such a package would be of interest in at least
some contexts.

Dave Robbins
Verizon Laboratories, Waltham, MA

                      "Thomas                                                                                                   
                      Ackermann"               To:       [email-masked]                                                           
                      <TAckermann@innov        cc:                                                                              
                      aphone.com>              Subject:  AW: [Sip] Diversion interrogation                                      
                      Sent by:                                                                                                  
                      sip-bounces@ietf.                                                                                         
                      org                                                                                                       

                      05/24/2005 02:56                                                                                          
                      AM                                                                                                        

Ok,

but I am looking for a centralized way to handle diversions.
If I want to divert all incoming calls to my homeoffice phone
while my office phone is offline, I have to activate a unconditional
diversion at my local PBX|proxy|server, because my office phone
cannot send a 302 response or a REFER in case of an incoming call.

Once a diversion is active at my local PBX|proxy|server, the office phone
goes online again I would like to see something on the office phone's
display
telling me: "Unconditional diversion active". So I would deactivate that
diversion. Otherwise I'd miss all calls to my office phone.

So there should be some kind of subscription that notifies me of
current diversions on my contact|aor and any changes made on that
diversion status (adds or dels).

Is there such an event package already defined, or do I have to devise my
own?

Best regards,
Thomas

_______________________________________________
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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2005 09:33:20 -0400

Thomas,

I'm inclined to agree with Dave, and with Wayne on another post in this 
thread. The problem is that you want to monitor the policy settings of 
the proxy responsible for your AOR. There are currently no standards for 
what kinds of policy, if any, might reside there, so there is no clear 
way to monitor the setting of that policy. (The closest thing that I am 
aware of is RFC 3880 for CPL. But it would be difficult to interrogate a 
CPL script to determine if it is set to do call diversion.)

You can of course achieve this through proprietary means. But if you 
think a standard is needed in this space, then I think the first step 
would be to start gathering requirements for standard policy to be 
applied to routing of requests addressed to an AOR. SIPPING is probably 
the right place to start. But I'm not at all confident that there would 
be widespread interest in this.

A proxy responsible for an AoR can have arbitrary logic to decide how to 
direct an incoming call addressed to that AoR. I don't think people want 
to restrict that. Characterizing arbitrary behavior as being "diversion" 
or "not diversion" is an impossible job.

A perhaps more likely possibility would be to find a way for a device, 
such as your office phone, to obtain a description of the policy in 
effect. It could perhaps then learn to simply identify one or a few 
policies that it considers "normal" and others that are not.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 May 2005 10:34:41 -0500

On May 24, 2005, at 7:14 AM, [email-masked] (following up on 

> notification of the state.
In the general case, this is actually an intractable problem.

Imagine a case where a call originates from PSTN and comes through an 
SS7 gateway to SIP. The gateway generates an INVITE, which goes to a 
proxy. The proxy sends a 302 REDIRECT with tel: URI as the Contact. The 
gateway uses something like the ISUP release-link-trunk extension to 
drop the call back to the preceding switch, which then IAMs the new 
phone number.

How would the proxy, which was involved only in the stateless issuance 
of a 302, know the future state of the new call that is proceeding 
entirely in the PSTN?

So to completely satisfy the requirement for knowing the state of 
ongoing diversions, we probably need to base this sort of service from 
a back-to-back user agent instead of a proxy. This greatly reduces the 
flexibility and efficiency, as we're essentially going to "trombone" 
calls.

That being said, the dialog event package lets a watcher know what 
dialogs the B2BUA is engaged in, and I think a simple set-difference 
operation gives us the "current diversions" set (the set of dialogs the 
B2BUA is involved in MINUS the set of dialogs that the watching UA is 
involved in).

So -- good news. I don't think you need any SIP extensions to build a 
service that works this way. But most SIP systems aren't going to have 
the information you need.

--
Dean