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

From: "Eric Burger" <[email-masked]>
Date: Mon, 21 Jul 2003 14:25:29 -0400

The standard is VERY well defined.  Behaviors are VERY well defined.

BY DESIGN, application behaviors are... up to the application.

Note that the service you describe can be done 100% at the calling user agent.  However you want to define it, you can.  It does not rely on ANYTHING being implemented at the called user agent.

As a service provider, you can implement the service at an outbound proxy for your subscribers.

What this means is that you can give a better (or worse) offering than your competitors.  Contrast this to developing a small set of services (small, because it takes a long time to standardize something, so nothing much will get done).  This means that everyone offers identical services.  That means that service providers compete predominantly on price.  That is not a good situation, either technically or commercially.

> -----Original Message-----
> From: Poetzl, Joachim [mailto:[email-masked]]
> Sent: Mon, July 21, 2003 11:18 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog
> Event P ackage and Automatic Callback
> 
> 
> Hi Rohan Mahy, all,
> 
> response to your answer (see below):
> 
> What is the use of standards, RFCs and all the discussions on 
> the list, if an implementation and any implementer can choose 
> what ever data it/he want?s to store or not? The behaviour of 
> an implementation should somehow be predictable and fixed in 
> a document which should state a clear particular behaviour.
> 
> It is clearly said in 13.2.2.3 of RFC3261, that after having 
> received the 486 a standard SIP client considers the INVITE 
> transaction completed and all early dialogs are considered 
> terminated upon reception of the non-2xx final response.
> 
> So there is no freedom to store anything arbitrarily.
> 
> Some views on that?
> 
> Thanks in advance
> 
> --snip
> 
> no.  the data about the *dialog* is deleted. You are free to keep 
> whatever data around you would like.
> 
> > 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.
> 
> it doesn't *have* to keep any data.  it *wants* to keep the data, 
> because it wants to invoke another SIP primitive.
> 
> --snap
> 
> 
> 
> 
> Best Regards
>  
> Joachim Potzl
> Deutsche Telekom AG
> T-Com Zentrale
> T38-13; Signalling, Gateways and Switching Systems
> 64307 DARMSTADT, GERMANY 
> Phone:  +49 6151 83-2134
> Fax:      +49 6151 83-4577
> PCFax:  +49 521 52244 983
> mailto:[email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Ursprungliche Nachricht-----
> Von: Rohan Mahy [mailto:[email-masked]]
> Gesendet: Sonntag, 20. Juli 2003 05:18
> An: Stupka Jean-Marie
> Cc: 'Alan Johnston'; 'Jonathan Rosenberg'; [email-masked]'
> Betreff: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog
> Event P ackage and Automatic Callback
> 
> 
> 
> On Friday, July 18, 2003, at 11:25 AM, 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?
> 
> no.  the data about the *dialog* is deleted. You are free to keep 
> whatever data around you would like.
> 
> > 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.
> 
> it doesn't *have* to keep any data.  it *wants* to keep the data, 
> because it wants to invoke another SIP primitive.
> 
> thanks,
> -rohan
> 
> > 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
> 
> _______________________________________________
> 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: "Shu-Lin CHen" <[email-masked]>
Date: Mon, 21 Jul 2003 14:32:24 -0400

Hi:
It is mentioned in RFC3261 that a Stateful Proxy cannot switch to
Stateless mode if 100 Trying was sent initially. Why should 
100 Trying prevent the proxy from switching mode?

Thanks.

shu-lin chen