Subject: Re: AW: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Eve nt P ackage and Automatic Callback

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Aug 2003 12:50:46 -0400

Jean-Marie,

Myself, and many others on this list, appear to be confused as to why
you believe what is currently specified will not work. You had
previously made this comment:

> The transaction being terminated, the data of the call attempt are
> deleted and thus the data (including user B's number) are no more
> available for a subsequent automatic callback request, right? If I
> am wrong, could you please show me where it is said in RFC3261 that
> a SIP user agent has to keep data of a transaction that is
> terminated.

Your assumption is that this data needs to exist for the service to 
work, but I dont see why. The caller has the original URI it used to 
call B. So, it subscribes to B. This gets routed to B's device once 
more. B accepts the subscription. Now, B reports information on 
whether or not it has any active dialogs. If its still in a call, it 
will, and the caller knows this. When B no longer has any active 
calls, the caller gets a notification and can now initiate a new INVITE.

What doesn't work, in your mind?

Perhaps you are concerned about authorization? i.e., how does B know 
whether to authorize the subscription? THe dialog package talks about 
this, and it says to provide summary information, identical to what a 
random caller would know if they simply sent INVITEs.

Perhaps you are concerned about routing? i.e., that the SUBSCRIBE 
would somehow get routed to a different device? Thats possible. The 
GRUU work would resolve that. However, I would argue that an even 
better way to implement this service is to use PRESENCE.

Instead of having the calling device subscribe to the dialog package 
on one device, it would subscribe to presence for the user. One 
problem with the dialog package (which Christian Stredicke has pointed 
out to me) is that if the phone is merely off-hook, and not in an 
actual call, the dialog package would report it as available. However, 
a presence indicator, being an application layer view on state, would 
indicate that the user is not available.

Another benefit of presence is that it works well for multi-device 
situations. It can also cover cases where I'm not actually in a call, 
but busy for some other reason (i.e., in a meeting).

-Jonathan R.

Stupka Jean-Marie wrote:

> The protocols imply procedures, the procedures imply data. If you
> want to offer a network wide service you need the network elements
> and the user equipments to work in a predictable manner with the
> protocols, the procedures and the data.
> 
> What is basically said in the previous mails is that standard
> compliant equipment is nice, but to really work, it needs more. I
> can easily understand that an operator can't accept this view.
> 
> Regards, Jean-Marie
> 

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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Michael Hammer <[email-masked]>
Date: Wed, 13 Aug 2003 13:20:29 -0400

Jonathan and Jean-Marie,

There are 3 dialogs here:
INVITE resulting in busy
SUBSCRIPTION resulting in notify when free
INVITE resulting in completion of call.

Each of these can be independently interworked to the corresponding SS7 
messages on the PSTN side.

One question is which if any of these dialogs needs to be bound together in 
any way.  I would contend that it is not necessary to relate the first two 
in any way.  The common information element is the called party number 
which is known when the INVITE was sent.  One could conceivably launch the 
subscription without the first INVITE ever having occurred and the 
interworking should be identical.  A Subscription probe should translate to 
a CCBS probe, which is either accepted or rejected.  I don't believe this 
causes any problems for the PSTN EO.  (Someone please correct me if not true!)

A second question is whether the indication of "party free" from CCBS 
interworked to a Notify should somehow provide some information (e.g. a 
token in a Contact address) that could be used in an INVITE interworked 
back to an IAM to distinguish the CCBS IAM from any other IAM.

Question:  Does that busy subscriber's EO upon notification of "subscriber 
free" to a camped-on subscriber block IAMs not containing the appropriate 
CCBS indicator?  Otherwise, I am assuming that IAMs are treated 
first-come-first-served.

Either way, there is no issue with this at the interworking point because 
such a Contact header with a CCBS indicator token is possible in the 200 OK 
SUBSCRIBE and Notify messages.  As I understand it, the nature of the 
user-part of the user@domain address is completely up to the GW to fashion 
if the domain is that GW, and thus does not need standardization.  That 
address could be used in the INVITE in the 3rd dialog and interworked to an 
IAM.  If the SIP UAC doesn't use the contact, but instead just reuses the 
Called Party number, then a normal IAM will result and be treated accordingly.

Mike

At 12:50 PM 8/13/2003 -0400, Jonathan Rosenberg wrote:
>Your assumption is that this data needs to exist for the service to work, 
>but I dont see why. The caller has the original URI it used to call B. So, 
>it subscribes to B. This gets routed to B's device once more. B accepts 
>the subscription. Now, B reports information on whether or not it has any 
>active dialogs. If its still in a call, it will, and the caller knows 
>this. When B no longer has any active calls, the caller gets a 
>notification and can now initiate a new INVITE.
>
>Perhaps you are concerned about routing? i.e., that the SUBSCRIBE would 
>somehow get routed to a different device? Thats possible. The GRUU work 
>would resolve that. However, I would argue that an even better way to 
>implement this service is to use PRESENCE.
>
>Instead of having the calling device subscribe to the dialog package on 
>one device, it would subscribe to presence for the user. One problem with 
>the dialog package (which Christian Stredicke has pointed out to me) is 
>that if the phone is merely off-hook, and not in an actual call, the 
>dialog package would report it as available. However, a presence 
>indicator, being an application layer view on state, would indicate that 
>the user is not available.
>
>situations. It can also cover cases where I'm not actually in a call, but 
>busy for some other reason (i.e., in a meeting).
>
>-Jonathan R.
>
>
>Stupka Jean-Marie wrote:
>