Subject: Re: AW: [Sip] Diversion interrogation

From: [email-masked]
Date: Tue, 24 May 2005 12:26:13 -0400

Your are absolutely correct in describing the problem of knowing the state
of calls that have been diverted as intractable.

However, this may not be the problem the initiator of this thread was
trying to solve, and it is not a problem I would seriously think of
solving. What may be a tractable problem is for a device to know the
current state of some service (diversion in this case) provided by, say, a
proxy. The state of the service can be well-defined, but the current state
of any dialogs that may have been affected by that service is not generally
knowable.

Communicating the state of a service is in general a problem that no single
standard can solve. Even limiting consideration to a diversion service,
diversion can be arbitrarily complex when considering the criteria by which
the service would decide whether and to what destination to redirect an
INVITE. What would be the appropriate state for the service to communicate
to an agent that subscribes to the state? RFC 3265 provides a framework
within which an event package can be defined for a particular, relatively
constrained notion of a diversion service. I suspect that to define a
sufficiently constrained event package would result in something that is
too constrained to be considered worthy of attention at the SIP or SIPPING
WG level.

                      "Dean Willis"                                                                                             
                      <dean.willis@soft        To:       "Thomas Ackermann" <[email-masked]>, Dave C.               
                      armor.com>                Robbins/EMPL/MA/Verizon@VZNotes                                                 
                                               cc:       [email-masked]                                                           
                      05/24/2005 11:34         Subject:  Re: AW: [Sip] Diversion interrogation                                  
                      AM                                                                                                        

On May 24, 2005, at 7:14 AM, [email-masked] (following up on
Thomas' question) wrote:

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

_______________________________________________
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: Anders Kristensen <[email-masked]>
Date: Tue, 24 May 2005 14:12:03 -0400

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.

Anders

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2005 15:34:54 -0400

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

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.

If you are willing to constrain the features to some well known set, 
then it becomes easier to do this. But I certainly hope we don't go that 
way.

	Paul

>>                       "Dean 
>> Willis"                                                                                             
>>                       <dean.willis@soft        To:       "Thomas 
>> Ackermann" <[email-masked]>, Dave C.               
>>                       armor.com>                
>>                                                cc:       
>> [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 May 2005 12:32:52 -0400

inline.

> thing as a service configuration for an AoR that is available via XCAP 

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.

> could get the service agreement, its not obvious how it could draw this 

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