Subject: Re: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic Callback

From: Alan Johnston <[email-masked]>
Date: Thu, 17 Jul 2003 04:04:28 -0500

Hi Jean-Marie,

Comments below.

Thanks,
Alan Johnston
MCI

At 10:21 AM 7/17/2003 +0200, 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".

In this flow, the dialog between Alice and Bob does terminate with the 
INVITE/486/ACK exchange.  However, Bob has a dialog with another user, say 
Carol (perhaps the flow should show this for clarity?).  If Bob was not 
currently involved in a dialog, the 486 would not have been sent, right?

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

Bob is in a dialog with Carol and keeps this dialog state for as long as 
the session exists (as long as Bob is busy).

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

I don't know what you mean here.  Bob still exists - he is still 
sip:[email-masked], right?  As a result, Bob can receive a 
SUBSCRIBE request from Alice.  Alice does not specify any call-id, to-tag, 
or from-tag Event parameters, so that means that Alice is requesting 
information about ANY dialogs that Bob is currently active in.  (Alice is 
not requesting information about only dialogs with Alice - this information 
would be redundant since if Alice is in the dialog, Alice would already 
know the state and dialog identifiers.)  All the NOTIFYs that Alice 
receives provides information about the dialog between Bob and Carol.

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

Dialog state does need to be kept for 32 seconds after sending a 
non-success final response in case of the loss of the 486 which would be 
detected by the failure to receive an ACK.  However, this has no bearing on 
this scenario.

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

Are you saying that you would like Alice to be able to send a SUBSCRIBE to 
Bob within the dialog between Bob and Carol?  This is not possible - a 
dialog is between two peers - a third party can not inject messages.

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

Are you perhaps concerned about authorizing the subscription?  That is, Bob 
only accepts a SUBSCRIBE from Alice if Alice has previously just made a 
call attempt (sent an INVITE and received a 486 busy)?  If this is what you 
want, I'm not sure the exact benefit of this.

>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: "Eric Burger" <[email-masked]>
Date: Fri, 18 Jul 2003 05:43:51 -0400

[sorry for the formatting -- Web Outlook at VIE]
 
I don't understand why there is a need to have the callback in the same dialog. It is a different call. It is up to the UAC to know it tried a location, got a 486, and should try again later.  As Alan wrote, you don't need to be in a dialog to subscribe to the dialog state.
 
I am trying to understand the request.  If it is to simply save on the ACK, it is not worth it.  Is it to have something special going on at the UAS? For example, only accept an INVITE from a camped-on caller?  There are better ways of doing that, driven by the UA's, as well.

-----Ursprüngliche Nachricht----- 
Von: Stupka Jean-Marie [mailto:[email-masked]] 
Gesendet: Fr 18.07.2003 05:25 
An: 'Alan Johnston' 
Cc: 'Jonathan Rosenberg'; Rohan Mahy; [email-masked]' 
Betreff: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic Callback

	Hi Alan, all,
	
	Thanks for your answer. Having seen your comments, I think that my previous mail was somewhat unclear. Let me clarify my concerns with the flows below.

	          A             GW / B
	          |                |
	          |    INVITE F1   |
	          |--------------->|
	          |486 Busy Here F2|
	          |<---------------|    User B is busy
	          |     ACK F3     |
	          |--------------->|
	          |                |
	          |                |
	
	User A calls user B which is either a SIP client (B) or a PSTN subscriber behind a Gateway (GW). User B is initially busy when User A calls.
	
	The dialog initiated by the INVITE terminates upon reception of the 486. After having received the 486, a standard SIP client -- i.e. a client compliant to RFC3261 -- considers the INVITE transaction completed and generates the ACK for the response (this behavior is described in 13.2.2.3 of RFC3261).
	
	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.
	
	For the reason above, a procedure is needed to keep the dialog/transaction open after a 486. Of course it would only make sense to keep the dialog if an automatic callback is possible, e.g. not precluded by other services at the remote user side, lacking network resources, etc. This should be indicated to the A's SIP UA. If automatic callback is possible, then the dialog (the transaction having the call data) shall not be terminated upon reception of a 486, leaving user A the possibility to request automatic callback.
	If user A does not request automatic callback within a reasonable time interval (about 10-15s) the dialog terminates.
	If user A does request automatic callback then a SUBSCRIBE (F4) is sent on the already existing dialog that was initiated by the preceding INVITE (F1). Sending the SUBSCRIBE 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). The call data can then be re-used for the SUBSCRIBE request and for the subsequent call when user B gets free.
	
	The flow then looks like this:

	          A             GW / B
	          |                |
	          |    INVITE F1   |
	          |--------------->|
	          |486 Busy Here F2|
	          |<---------------|      User B is busy
	     T    |(Autom.Callback |   T  Timer for automatic callback
	     |    |   possible)    |   |
	     |    |     ACK F3     |   |
	     |    |--------------->|   |
	     |    |                |   |
	==>  |    |                |   |  User A requests automatic callback
	     |    |                |   |
	     |    |  SUBSCRIBE F4  |   |
	     v    |--------------->|   v
	          |   200 OK F5    |
	          |<---------------|
	          |    NOTIFY F6   |
	          |<---------------|
	          |   200 OK F7    |
	          |--------------->|
	          |                |
	          |    NOTIFY F8   |  <== User B is now available
	          |<---------------|
	          |   200 OK F9    |
	          |--------------->|
	          |                |
	          |   INVITE F10   |
	          |--------------->|      Session setup successfully
	          | 180 Ringing F11|
	          |<---------------|
	          |   200 OK F12   |
	          |<---------------|
	          |     ACK F13    |
	          |--------------->|
	          |  Media Session |
	          |<==============>|
	          |                |
	
	User A calls user B which is either a SIP client (B) or a PSTN subscriber behind a Gateway (GW). User B is initially busy when user A calls.
	
	- F1 INVITE creates a new dialog between A and GW/B (let's say D1)
	
	- F2 486 Busy Here: automatic callback is possible.
	GW/B indicates to A that automatic callback is possible and starts a timer in order to retain the dialog and call data for a possible request for automatic callback.
	When receiving a 486 with the indication automatic callback possible, A starts a timer in order to retain the dialog and call data giving user A the possibility to request automatic callback.
	If the timer expires (no callback request has arrived) then the dialog/transaction is terminated at A and GW/B.
	
	- User A requests automatic callback: A stops the timer and sends a SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the preceding INVITE. There is one hand no necessity to open a new dialog, and one the other hand, sending the SUBSCRIBE 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)
	
	- F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states.
	F5, F6, F7, F8, F9 as in 2.17 of draft-ietf-sipping-service-examples-04.txt
	
	- F10 INVITE: A sends the INVITE within the still open dialog (D1) initiated by F1 (reason given above)
	
	- F11, etc. as in 2.17
	
	Summary:
	- There is a need to retain dialogs initiated by an INVITE after a 486 message when automatic callback is possible
	- It is desirable that the SUBSCRIBE request and a subsequent call set-up triggered by the NOTIFY uses the pre-existing dialog initiated by the preceding INVITE.
	
	I hope I have clarified my concerns.
	
	Regards,
	Jean-Marie

	> Gesendet: Donnerstag, 17. Juli 2003 11:04
	> An: Stupka Jean-Marie; Rohan Mahy
	> Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated
	> Dialog Event
	> Package and Automatic Callback
	>
	>
	> Hi Jean-Marie,
	>
	> Comments below.
	>
	> Thanks,
	> Alan Johnston
	> MCI
	>
	
	Right.
	
	> the session exists (as long as Bob is busy).
	
	Right.
	
	> receives provides information about the dialog between Bob and Carol.
	
	See explanation and flows above.
	
	> detected by the failure to receive an ACK.  However, this has
	
	See explanation and flows above.
	
	> >given as an example in
	> draft-ietf-sipping-dialog-package-02.txt. Sending a
	
	Of course not, see explanation and flows above.
	
	> want, I'm not sure the exact benefit of this.
	
	Not at all my concern.
	
	> > >>Sipping mailing list 
	> https://www1.ietf.org/mailman/listinfo/sipping
	> > >Sipping mailing list 
	> https://www1.ietf.org/mailman/listinfo/sipping

J*i�x&j)b�	b��m��?�0�'�~���f��f��X��)ߣ�"����8b�X��+��DYׯzZ)�����ay�i�'�*'��=K�*b��^�������%�f�i�n~���-���w.����ȩRǬ�����+��+��z�������(}�+y"

---

From: Alan Johnston <[email-masked]>
Date: Tue, 22 Jul 2003 14:28:24 -0500

I agree 100% with Eric.

No dialog information storage is needed or required for this service.

Thanks,
Alan Johnston
MCI

At 05:43 AM 7/18/2003 -0400, Eric Burger wrote:
>I don't understand why there is a need to have the callback in the same 
>dialog. It is a different call. It is up to the UAC to know it tried a 
>location, got a 486, and should try again later.  As Alan wrote, you don't 
>need to be in a dialog to subscribe to the dialog state.
>
>I am trying to understand the request.  If it is to simply save on the 
>ACK, it is not worth it.  Is it to have something special going on at the 
>UAS? For example, only accept an INVITE from a camped-on caller?  There 
>are better ways of doing that, driven by the UA's, as well.
>
>
>-----UrsprÃ¼ngliche Nachricht-----
>         Thanks for your answer. Having seen your comments, I think that 
> my previous mail was somewhat unclear. Let me clarify my concerns with 
> the flows below.
>
>
>                   A             GW / B
>                   |                |
>                   |    INVITE F1   |
>                   |--------------->|
>                   |486 Busy Here F2|
>         User A calls user B which is either a SIP client (B) or a PSTN 
> subscriber behind a Gateway (GW). User B is initially busy when User A calls.
>
>         The dialog initiated by the INVITE terminates upon reception of 
> the 486. After having received the 486, a standard SIP client -- i.e. a 
> client compliant to RFC3261 -- considers the INVITE transaction completed 
> and generates the ACK for the response (this behavior is described in 
> 13.2.2.3 of RFC3261).
>
>         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.
>
>         For the reason above, a procedure is needed to keep the 
> dialog/transaction open after a 486. Of course it would only make sense 
> to keep the dialog if an automatic callback is possible, e.g. not 
> resources, etc. This should be indicated to the A's SIP UA. If automatic 
> callback is possible, then the dialog (the transaction having the call 
> data) shall not be terminated upon reception of a 486, leaving user A the 
> possibility to request automatic callback.
>         If user A does not request automatic callback within a reasonable 
> time interval (about 10-15s) the dialog terminates.
>         If user A does request automatic callback then a SUBSCRIBE (F4) 
> is sent on the already existing dialog that was initiated by the 
> preceding INVITE (F1). Sending the SUBSCRIBE 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). The call data can 
> then be re-used for the SUBSCRIBE request and for the subsequent call 
> when user B gets free.
>
>         User A calls user B which is either a SIP client (B) or a PSTN 
> subscriber behind a Gateway (GW). User B is initially busy when user A calls.
>
>         GW/B indicates to A that automatic callback is possible and 
> starts a timer in order to retain the dialog and call data for a possible 
> request for automatic callback.
>         When receiving a 486 with the indication automatic callback 
> possible, A starts a timer in order to retain the dialog and call data 
> giving user A the possibility to request automatic callback.
>         If the timer expires (no callback request has arrived) then the 
> dialog/transaction is terminated at A and GW/B.
>
>         - User A requests automatic callback: A stops the timer and sends 
> a SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the 
> preceding INVITE. There is one hand no necessity to open a new dialog, 
> and one the other hand, sending the SUBSCRIBE 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)
>
>         F5, F6, F7, F8, F9 as in 2.17 of 
> draft-ietf-sipping-service-examples-04.txt
>
>         - F10 INVITE: A sends the INVITE within the still open dialog 
> (D1) initiated by F1 (reason given above)
>
>         - F11, etc. as in 2.17
>
>         Summary:
>         - There is a need to retain dialogs initiated by an INVITE after 
> a 486 message when automatic callback is possible
>         - It is desirable that the SUBSCRIBE request and a subsequent 
> call set-up triggered by the NOTIFY uses the pre-existing dialog 
> initiated by the preceding INVITE.
>
>J*iŠx&j)bž 
>b²Øm¶›?ÿ0Ö'~Šàþf¢f§þX¬¶)ß£û"¦˜§8b²X¬¶+¢³DY×¯zZ)™éí¡ûayªi'¶*'¡ôˆ=K²*bš™^™éí¢»±Ê%ºfâiçn~Šê¹ë-Š‰ì¢w.®·§¶È©RÇ¬Š˜žµú+ú+ìz÷¥¢™žžÛ(}Ê+y"