Subject: AW: [Sipping] Question on INVITE Initiated Dialog Event Package a nd Automatic C allback

From: Stupka Jean-Marie <[email-masked]>
Date: Tue, 15 Jul 2003 11:53:48 +0200

Jonathan, 

I doubt that sending the SUBSCRIBE request for the dialog package outside of any dialog is possible in case of automatic callback, since the required data are no more available.

The problem is that when a 486 is received, the dialog initiated by the INVITE terminates and, the data related to that dialog (including the called user number) disappear. Therefore it is no more possible to send the SUBSCRIBE to request automatic callback for this destination.

A possible solution would be to keep for a short period of time the data of the previous call attempt (i.e. the called user number, the bearer description, ...) at the user agent after a 486 is received. This would allow the user agent to re-use the called user number and other data from the preceding call attempt for the SUBSCRIBE request and for the subsequent call after the remote user is free. However, the procedure of retaining data is not foreseen in RFC 3261.

A better (more economical and user friendly) solution would be to keep at the user agent only when an automatic callback is possible (e.g. not precluded by other services at the remote user side, lacking network resources, etc.). This would require to extend the 486 with a "Automatic Callback Possible" indication, or to introduce a new message with this meaning.

Jean-Marie

-----Ursprungliche Nachricht-----
Von: Jonathan Rosenberg [mailto:[email-masked]]
Gesendet: Montag, 14. Juli 2003 10:18
An: Stupka Jean-Marie
Cc: [email-masked]'
Betreff: Re: [Sipping] Question on INVITE Initiated Dialog Event Package
and Automatic C allback

The dialog package can be used by subscriptions made both within, and 
outside, of a dialog. So, in the case of automatic callback, the 
caller would, after receiving a 486, send a SUBSCRIBE request for the 
dialog package, and do so outside of any dialog.

-Jonathan R.

Stupka Jean-Marie wrote:

> Hello All,
> 
> As said in RFC 3265 it is possible to create an event subscription
> within a pre-existing dialog, e.g. a dialog created by an INVITE.
> In my understanding, this is the intention of
> draft-ietf-sipping-dialog-package-02.txt.
> 
> According to the (PSTN) Automatic Callback given as example
> application in the introduction of this draft, user A can request a
> callback when user B hangs-up. User A off course needs to get the
> information that user B is busy before requesting the automatic
> callback, i.e. receive a "486 Busy Here" message. However, all
> early dialogs are considered terminated upon reception of a non-2xx
> final response (13.2.2.3 of RFC 3261). As consequence, the dialog
> and thus the data of the preceding call attempt are no more
> available and the callback cannot be requested.
> 
> Can somebody provide clarification of the applicability of RFC 3265
> and the draft-ietf-sipping-dialog-package-02.txt to Automatic
> Callback?
> 
> Regards,
> 
> Jean-Marie
> 
> 
> _______________________________________________ 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
> 

-- 
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: Rohan Mahy <[email-masked]>
Date: Tue, 15 Jul 2003 05:21:17 -0700

Jean-Marie,

It seems perfectly reasonable to send a SUBSCRIBE to the dialog package 
outside of a dialog.  The default behavior would be to send a list of 
dialogs but with no dialog information or peer information.  I believe 
this is sufficient to build a callback service.

thanks,
-rohan

On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote:

> Jonathan,
>
> I doubt that sending the SUBSCRIBE request for the dialog package 
> outside of any dialog is possible in case of automatic callback, since 
> the required data are no more available.
>
> The problem is that when a 486 is received, the dialog initiated by 
> the INVITE terminates and, the data related to that dialog (including 
> the called user number) disappear. Therefore it is no more possible to 
> send the SUBSCRIBE to request automatic callback for this destination.
>
> A possible solution would be to keep for a short period of time the 
> data of the previous call attempt (i.e. the called user number, the 
> bearer description, ...) at the user agent after a 486 is received. 
> This would allow the user agent to re-use the called user number and 
> other data from the preceding call attempt for the SUBSCRIBE request 
> and for the subsequent call after the remote user is free. However, 
> the procedure of retaining data is not foreseen in RFC 3261.
>
> A better (more economical and user friendly) solution would be to keep 
> at the user agent only when an automatic callback is possible (e.g. 
> not precluded by other services at the remote user side, lacking 
> network resources, etc.). This would require to extend the 486 with a 
> "Automatic Callback Possible" indication, or to introduce a new 
> message with this meaning.
>
> Jean-Marie
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 16 Jul 2003 13:39:29 -0500

Hi Jean-Marie,

The SIP Service Examples section 2.17 shows exactly this flow with a 
SUBSCRIBE outside of the dialog (which ended with the 486).

Thanks,
Alan Johnston
MCI

At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote:
>>I doubt that sending the SUBSCRIBE request for the dialog package outside 
>>of any dialog is possible in case of automatic callback, since the 
>>required data are no more available.
>>
>>The problem is that when a 486 is received, the dialog initiated by the 
>>INVITE terminates and, the data related to that dialog (including the 
>>called user number) disappear. Therefore it is no more possible to send 
>>the SUBSCRIBE to request automatic callback for this destination.
>>
>>A possible solution would be to keep for a short period of time the data 
>>of the previous call attempt (i.e. the called user number, the bearer 
>>description, ...) at the user agent after a 486 is received. This would 
>>allow the user agent to re-use the called user number and other data from 
>>the preceding call attempt for the SUBSCRIBE request and for the 
>>subsequent call after the remote user is free. However, the procedure of 
>>retaining data is not foreseen in RFC 3261.
>>
>>A better (more economical and user friendly) solution would be to keep at 
>>the user agent only when an automatic callback is possible (e.g. not 
>>precluded by other services at the remote user side, lacking network 
>>resources, etc.). This would require to extend the 486 with a "Automatic 
>>Callback Possible" indication, or to introduce a new message with this meaning.
>>
>>Jean-Marie
>>