Subject: [Sip] Questions about early dialog

From: Norihiko Tashi <[email-masked]>
Date: Wed, 15 Dec 2004 18:22:01 +0900

Hi,

I have questions about an INVITE "early" dialog.

Question 1.
In an INVITE early dialog, can UA send or process other dialog-
creating methods(e.g. SUBSCRIBE)?

If so, SUBSCRIBE messages in the mid-dialog can establish subscriptions.

In this case, if the first INVITE (dialog-creating) transaction
terminated later (e.g. non-2xx final response, transport error 
or timeout) , should the dialog terminate despite existence of 
subscriptions?

Question 2.

A UAS can inform methods that that can be used in the dialog while this is
in the early state as below (RFC3261 13.2.2.1).

How does a UAC inform methods that can be used 
in "only" the early dialog?

Is only solution UAS's reception of a response 
with "405 Method Not Allowed"?

> 13.2.2.1 1xx Responses
>    The early dialog will only be needed if the UAC needs to send a
>    request to its peer within the dialog before the initial INVITE
>    transaction completes.  Header fields present in a provisional
>    response are applicable as long as the dialog is in the early state
>    (for example, an Allow header field in a provisional response
>    contains the methods that can be used in the dialog while this is in
>    the early state).

Thanks in advance.

---------------------
Norihiko Tashi
Alpha Systems, Inc.
---------------------

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Nataraju A B" <[email-masked]>
Date: Wed, 15 Dec 2004 17:32:11 +0530

Best Regards,
Nataraju A.B.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Norihiko Tashi
Sent: Wednesday, December 15, 2004 2:52 PM
To: [email-masked]
Subject: [Sip] Questions about early dialog

Hi,

Question 1.

[ABN] there can be multiple dialogs in a session.... when you send the
subscribe within session then that creates one more dialog as part of
the same session....
when dialog created by INVITE is terminated then dialog created by
SUBSCRIBE still goes on... in this case only session exists with the
subscription dialog... 

Basically there can be multiple dialogs as part of the same session..
some thing similar to multiple transactions in a dialog...

Question 2.

A UAS can inform methods that that can be used in the dialog while this
is
in the early state as below (RFC3261 13.2.2.1).

[ABN] this may not be required... basic constraint is that, at any point
in time there can be overlap between INVITE and non-INVITE transactions
within a dialog. But there CAN'T be multiple INVITE transactions as part
of the same dialog...

>    contains the methods that can be used in the dialog while this is
in

[ABN] this does mean that before INVITE transaction completes you can
send any request other than new INVITE request....

if you go through RFC3263 about Offer/Answer model you can understand
this topic pretty well...

Thanks in advance.

---------------------
Norihiko Tashi
Alpha Systems, Inc.
---------------------

---

From: Norihiko Tashi <[email-masked]>
Date: Fri, 17 Dec 2004 14:12:33 +0900

Thanks you for reply.

> some thing similar to multiple transactions in a dialog...

What does "a session" means?
I think a session in sip specifications is a negotiated state about 
mmedia streams (e.g. by using SDP, SDPng etc..)
between two UAs. 

And, a dialog is a peer-to-peer SIP relationship between two
UAs that persists for some time.
A dialog has dialog identifier and some other informations.
Dialog matching for mid-dialog request will be done by using 
dialog identifier that does not include dialog creating method
information.

In this case, a session and a subscription are higher-layer concept
over a dialog.

So, I think a dialog can be shared by zero or more sessions
(if any, early session/session) and/or zero or more subscriptions.

If there are no sessions and no subscriptions, 
the dialog will terminate because both an INVITE dialog "FSM" 
(doumented in draft-ietf-sipping-dialog-package) and 
an SUBSCRIBE/REFER dialog "FMS"(not subscription state and 
not documented anywhere now) are in terminated state.

The problem in my question is whether the dialog should or not
terminate when "first" dialog creating transaction failed 
after sending or receiving subsequent 
mid-dialog messages (e.g. SUBSCRIBE).

Because if first dialog creating transaction
(that is outside of a dialog) did not succeeded,
subsequent mid-dialog messages could have been existed.

When mid-dialog transaction failed, the dialog will not terminate.

> this topic pretty well...

The problem is scope of Allow Header.

Allow Header in provisional response with tag is effective
as far as the dialog is in early state (if it was created by INVITE).

And, Allow Header in 2xx response is effective in subsequent
mid-dialog request.

But, Allow Header in INVITE request is effective in both early and
confirm state.

So, A UAS can't get information about methods that can be used 
only in the early dialog.

---

From: "Nataraju A B" <[email-masked]>
Date: Fri, 17 Dec 2004 15:32:49 +0530

Best Regards,
Nataraju A.B.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Norihiko Tashi
Sent: Friday, December 17, 2004 10:43 AM
To: [email-masked]
Subject: Re: [Sip] Questions about early dialog

Thanks you for reply.

[ABN] when u send an invite request it will create a dialog as well as a
session which contains only one dialog created by this INVITE request.
Later when u send the subscribe request with same from & To tags as was
used in INVITE transaction then that lead to one more dialog as part of
the same session which was created when INVITE transaction happened.

[ABN] a dialg will always be part of a session not otherway round...

[ABN] its other way round session will be terminated only when all the
dialogs as part of that session are deleted. 
[ABN] for instance in your case (INVITE and SUBSCRIPTION) session will
not be deleted once the INVITE's dialog is deleted, that session will be
alive till the subscription dialog is deleted....

---

From: Norihiko Tashi <[email-masked]>
Date: Tue, 21 Dec 2004 16:33:38 +0900

Best regards,
Norihiko Tashi

> > subscribe within session then that creates one more dialog as part of

A dialog is "associated with" a session, so is not part of a session and
is not associated with only a session.

RFC3261 refers to this matter.

15 Terminating a Session

  This section describes the procedures for terminating a session
  established by SIP.  The state of the session and the state of the
  dialog are very closely related.  When a session is initiated with an
  INVITE, each 1xx or 2xx response from a distinct UAS creates a
  dialog, and if that response completes the offer/answer exchange, it
  also creates a session.  As a result, each session is "associated"
  with a single dialog - the one which resulted in its creation.  If an
  initial INVITE generates a non-2xx final response, that terminates
  all sessions (if any) and all dialogs (if any) that were created
  through responses to the request.  

Presumably, my question 1 is solved..
When first INVITE transaction fails, all sessions and all of dialogs
(because when forked, multiple dialog are created) 
and probably all of subscriptions will terminate.

Furthermore, in special cases, a session can exist without a dialog.
An example is as below.

 13.3.1 Processing of the INVITE
 The INVITE may contain a session description, in which case the UAS
 is being presented with an offer for that session.  It is possible
 that the user is already a participant in that session, even though
 the INVITE is outside of a dialog.  This can happen when a user is
 invited to the same multicast conference by multiple other
 participants.  If desired, the UAS MAY use identifiers within the
 session description to detect this duplication.

Probably, the definitions of "dialog" and "session" 
between you and me are different terminologically.

A dialog by SUBSCRIBE/REFER in your eyes is equivalent to a subscription
in my eyes.

A session in your eyes is equivalent to a dialog and a session 
by INVITE and all of subscriptions in my eyes.

RFC3261 and RFC3265 define theses terminology as below.

Dialog: A dialog is a peer-to-peer SIP relationship between two
  UAs that persists for some time.  A dialog is established by
  SIP messages, such as a 2xx response to an INVITE request.  A
  dialog is identified by a call identifier, local tag, and a
  remote tag.  A dialog was formerly known as a call leg in RFC
  2543.

Session: From the SDP specification: "A multimedia session is a
  set of multimedia senders and receivers and the data streams
  flowing from senders to receivers.  A multimedia conference is
  an example of a multimedia session." (RFC 2327 [1]) (A session
  as defined for SDP can comprise one or more RTP sessions.)  As
  defined, a callee can be invited several times, by different
  calls, to the same session.  If SDP is used, a session is
  defined by the concatenation of the SDP user name, session id,
  network type, address type, and address elements in the origin
  field.

Subscription: A subscription is a set of application state associated
  with a dialog.  This application state includes a pointer to the
  associated dialog, the event package name, and possibly an
  identification token.  Event packages will define additional
  subscription state information.  By definition, subscriptions
  exist in both a subscriber and a notifier.

> > some thing similar to multiple transactions in a dialog...

Sorry, I can't understand why multiple dialogs with same dialog id
(call-id, from-tag and to-tag) can be created.

Since a dialog is identified by dialog id, only one dialog that have 
same dialog id can exist.

And, I think that a dialog is like a SIP-level virtual connection
(peer relationsip) between UAs that is target-refresh-capable.

INVITE, SUBSCRIBE and REFER methods can establish a virtual 
connection by only sending or receiving them outside a dialog.

So, if you want to establish new virtual connection, 
you have to send a INVITE, SUBSCRIBE or REFER message with 
different from-tag and call-id (outside the dialog).

If there are multiple dialogs, target refresh affect one dialog.

But, If target refreshed, this change affect all of continuing
mid-dialog messages.

So, I represent that a dialog can be shared by sessions and
subscriptions.

I agree that there can be multiple transactions in a dialog.