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

From: Stupka Jean-Marie <[email-masked]>
Date: Thu, 17 Jul 2003 10:21:02 +0200

Hi Alan,

The flow 2.17 of draft-ietf-sipping-service-examples-04.txt is a good example to show what is wrong. After the 486 message and the ACK the transaction is terminated: 13.2.2.3 of RFC3261 says "All early dialogs are considered terminated upon reception of the non-2xx final response". As a consequence, all data related to the previous call attempt are lost (why and how long should a SIP client keep this data?). This is at least conforming RFC3261.
Therefore, the SUBSCRIBE message shown in the flow is just not possible, as the destination address (Bob's address or user number) is no more existing at the SIP user side. Keeping the data for a short period of time after a 486 would help, but I wouldn't say that this is an implementation matter, the behavior of a SIP client needs to be predictable, i.e. standardized.

Coming back to my initial concern, the PSTN call completion application given as an example in draft-ietf-sipping-dialog-package-02.txt. Sending a SUBSCRIBE to the Dialog Package within the dialog initiated by the INVITE of the preceding call attempt would ease the implementation because the call data are available within this dialog at the SIP user side and at its peer (e.g. the gateway in the PSTN). This is in my understanding the benefit of draft-ietf-sipping-dialog-package-02.txt.

A possible solution would be to keep for a short period of time the dialog with 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 if an automatic callback is possible (e.g. not precluded by other services at the remote user side, lacking network resources, etc.). Then the called user number and other data from the preceding call attempt could be re-used for the SUBSCRIBE request and for the subsequent call when the remote user gets free. This would require to extend the 486 with a "Automatic Callback Possible" indication, or to introduce a new message with this meaning and the procedure of retaining data - a change to RFC3261.

Any view on that?

Thanks,
Jean-Marie

-----Ursprungliche Nachricht-----
Von: Alan Johnston [mailto:[email-masked]]
Gesendet: Mittwoch, 16. Juli 2003 20:39
An: Rohan Mahy; Stupka Jean-Marie
Cc: 'Jonathan Rosenberg'; [email-masked]'
Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event
Package a nd Automatic C allback

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:
>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
>>
>>-----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
>
>
>_______________________________________________
>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

_______________________________________________
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: Sun, 20 Jul 2003 04:53:19 +0200

On Thursday, July 17, 2003, at 10:21 AM, Stupka Jean-Marie wrote:

> Hi Alan,
>
> The flow 2.17 of draft-ietf-sipping-service-examples-04.txt is a good 
> example to show what is wrong. After the 486 message and the ACK the 
> transaction is terminated: 13.2.2.3 of RFC3261 says "All early dialogs 
> are considered terminated upon reception of the non-2xx final 
> response". As a consequence, all data related to the previous call 
> attempt are lost (why and how long should a SIP client keep this 
> data?). This is at least conforming RFC3261.
> Therefore, the SUBSCRIBE message shown in the flow is just not 
> possible, as the destination address (Bob's address or user number) is 
> no more existing at the SIP user side.

There is something incredibly basic and fundamental here which you are 
not grasping. If you want to implement a service on your User Agent 
(whether it is a PSTN gateway, a media server, a phone, or an instant 
messaging client), you are responsible for storing the information you 
need in order to accomplish that service. There is no expectation that 
all the state you need in order to accomplish some arbitrary service is 
encapsulated in some data structure that is defined in the SIP 
specification.

The flow shown is not only possible, it has been implemented and it 
works.

> Keeping the data for a short period of time after a 486 would help, 
> but I wouldn't say that this is an implementation matter, the behavior 
> of a SIP client needs to be predictable, i.e. standardized.

The behavior of SIP User Agents is predictable insofar as what is 
exchanged on the wire.  The IETF does not mandate services or 
implementations operate in a particular way.

> Coming back to my initial concern, the PSTN call completion 
> application given as an example in 
> draft-ietf-sipping-dialog-package-02.txt. Sending a SUBSCRIBE to the 
> Dialog Package within the dialog initiated by the INVITE of the 
> preceding call attempt would ease the implementation because the call 
> data are available within this dialog at the SIP user side and at its 
> peer (e.g. the gateway in the PSTN). This is in my understanding the 
> benefit of draft-ietf-sipping-dialog-package-02.txt.

the problem is that a full dialog does not even exist.

> A possible solution would be to keep for a short period of time the 
> dialog with 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 if an automatic callback is possible (e.g. not 
> resources, etc.).
> Then the called user number and other data from the preceding call 
> attempt could be re-used for the SUBSCRIBE request and for the 
> subsequent call when the remote user gets free. This would require to 
> extend the 486 with a "Automatic Callback Possible" indication, or to 
> introduce a new message with this meaning and the procedure of 
> retaining data - a change to RFC3261.

Just keep the data yourself in your User Agent. There is no need to 
modify any specifications, in fact doing so would be harmful.  I'll 
also point out that "486 Automatic Callback Possible" is a bit silly. 
You can already tell if automatic callback is possible if the 486 
contains an Allow-Events header with the dialog package token.

thanks,
-rohan