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

From: Michael Hammer <[email-masked]>
Date: Fri, 18 Jul 2003 16:02:03 -0400

Jean-Marie,

The fact that A may want to reserve some media resources may be an 
implementation detail.  Requiring the GW to maintain state for a failed 
call is probably not the best use of media resources for the GW.  Better to 
release those media reserved, and only let A separately request 
SUBSCRIPTION dialog be established to report on availability of user 
B.  When B's media resources free up, then A can re-submit the 
INVITE.  It's probably less brittle that way.

Mike

At 11:25 AM 7/18/2003 +0200, Stupka Jean-Marie wrote:
>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
>
>
>
> > -----Ursprungliche Nachricht-----
> > Von: Alan Johnston [mailto:[email-masked]]
> > Gesendet: Donnerstag, 17. Juli 2003 11:04
> > An: Stupka Jean-Marie; Rohan Mahy
> > Cc: 'Jonathan Rosenberg'; [email-masked]'
> > Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated
> > Dialog Event
> > Package and Automatic Callback
> >
> >
> > 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?
>
>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).
>
>Right.
>
> >
> > >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.
> >
>
>See explanation and flows above.
>
> > >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.
>
>See explanation and flows above.
>
> >
> > >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.
> >
>
>Of course not, see explanation and flows above.
>
> >
> > >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.
>
>Not at all my concern.
>
> >
> > >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