Subject: [Sip] comments on sipping-dialog-package-06 draft

From: "Nasir Khan" <[email-masked]>
Date: Wed, 20 Apr 2005 22:32:13 -0700

Following are some comments on
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-06
.txt

1>  Section 4.1 

  "state: This attribute indicates whether the document contains the
      full dialog information, or whether it contains only information
      on those dialogs which have changed since the previous document
      (partial). "
 
>From this it looks that the "state" attribute is partial or full
depending upon if "some" or "all" dialogs are reported in the NOTIFY.
The semantics of partial or full do not convey any information on the
completeness of information within a <dialog> element (in context of any
filter that subscriber may have set). 
This needs to be clarified in the spec: Should the implementer flush and
rewrite the "row" with that dialog ID even when the dialog-info element
indicates "partial" (which would imply that information within the
<dialog> element is always complete for subsequent NOTIFY's) or should
it do equivalent of SQL update with whatever information is available
within the dialog element. (In this latter case is there a need for
equivalent of "full" in context of an individual dialog update). 
 
2>  Section 4.1.4
 "4.1.4  Replaces
 
   The replaces element is used to correlate a new dialog with one it
   replaced as a result of an invitation with a Replaces header.  This
   element is present in the replacement dialog only (the newer dialog)
   and contains attributes with the call-id, local-tag, and remote-tag
   of the replaced dialog.
 
   <replaces call-id="hg287s98s89"
             local-tag="6762h7" remote-tag="09278hsb"/>"
 
IMHO instead of call-id, local-tag and remote-tag the dialogID is
necessary and sufficient information in the replaces element. The
Subscriber may not be authorized to get this "replaced" dialog
information like call-id etc.based upon some authorization policy. By
giving away the dialog information of the replaced dialog the subscriber
can gain information it was not privy of originally. However, if the
subscriber was getting notifications for the replaced dialog also then
it can use the dialogID to correlate. (Besides the subscriber table will
most likely be keyed on dialogID. and user.)

3>  Section 4.1.5 
"Referred-By [11] header and contains the (optional) display name
   attribute and the Referred-By URI as its value.
 
   <referred-by display="Bob">sip:[email-masked]</referred-by>"
 
There could be identity concerns in sending out the referred-by
information. Though not directly concerned with this draft, it could be
mentioned about the mechanism to expunge the referer information based
on privacy headers. The same applies to other identity elements also. 

4> Section 4.3 
Perhaps it could be added that the dialog information table as suggested
is referenced by the SUBSCRIBE/NOTIFY dialog (that which subscriber
maintains with the notifier) AND the user whose dialog information is
retrieved, this will help to associate the incremental status updates
that each NOTIFY entails. In the absence of any such association there
could be a problem: Let us say that there were two dialogs that were
being reported about, one dialog gets terminated and UA sends a NOTIFY
with a higher "version" (+1) attribute. If this NOTIFY is lost and
subsequently another NOTIFY with yet higher (+2) version attribute is
sent then this SHOULD result in refresh request from Subscriber (sec
4.3). The Notifier will then generate a "full" notification but it will
potentially NOT have any information on the "terminated" dialog. The
Subscriber now needs a higher level reference to the DialogID that it
can use to now flush the now terminated dialog. 
This probably is implied in the text but IMO may help implementers if
specified clearly. 

5> Should target refreshes be reported, i.e. have a new "event" type in
schema for state element <xs:enumeration value="refreshed"/> for target
refreshes? 

6> Section 6.1 Minor typo - 
"If it receives a second 180 with a different tag:
 
------- SIP/2.0 180 Ringing
 
   This results in the creation of a second dialog:

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="2"
                state="full"
                entity="sip:[email-masked]">
     <dialog id="as7d900as8" call-id="a84b4c76e66710"
             local-tag="1928301774" remote-tag="456887766"
             direction="initiator">
       <state>early</state>
     </dialog>
     <dialog id="as7d900as8" call-id="a84b4c76e66710"
             local-tag="1928301774" remote-tag="hh76a"
             direction="initiator">
       <state>early</state>
     </dialog>
   </dialog-info> "
 
The dialog id in the second dialog created should have a different
dialogID as specified in section 4.1

7> The draft talks about the dialog events at the UAs because this is
where the dialog state machine exists, but will it be useful to have the
capability to monitor such dialogs at a record routing proxy?  So will
it be useful to enable a Subscriber SUBSCRIBE to a dialog which is
"known" at  a proxy? 

8> This draft more than other event drafts points towards a need for a
mechanism in which a subscription would be required through a non
SUBSCRIBE mechanism. This is because the Subscriber in this case may be
a party outside of the dialog that needs to monitor and may not know
when the dialog came into existence. Of course the subscriber can
subscribe before hand, but will still lack the capability to subscribe
in real-time to a dialog to which the subscriber may be interested in. 
Will it be worthwhile to add a mechanism by which the subscriptions
could also carry over another method like INVITE? 
A new "Subscription" header could carry the subscription and the value
of the header may be the target for the subsequent NOTIFY. This could be
a non- SUBSCRIBE way of installing subscription. The Event header would
then have the required event package.  
If the subscriber is within the trust domain then the NOTIFY's could
start as soon as the first qualifying event occurs rather than waiting
for SUBSCRIBE or relying on before-hand subscriptions.  
This feature could be useful for future event users like say an event
package for notifying the Voice XML media server interaction state after
dialog establishment [e.g. notifications about the digit collection etc.
rather than using HTTP route]. 
 
In a nutshell this would be useful to a subscriber who cannot know
before hand where/whom to subscribe for the events that it is interested
in as the dynamic network situations create these event conditions. So
the "application" (say a proxy) that knows about the Subscriber and this
special condition occurring in the network, inserts this Subscription
header and Event header with the subscribers target address.  
If Notifier wants to authenticate the subscriber it could generate a
NOTIFY with Subscription-State as "terminated" and reason=auth-required.

Regards 
Nasir Khan
BEA 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