Subject: [siprec] Comments on draft-ietf-siprec-protocol-06

From: "Jain, Rajnish" <[email-masked]>
Date: Thu, 27 Sep 2012 19:23:50 +0000

Pls. find below some of my questions and comments on the draft-ietf-siprec-protocol-06 document (I apologize if these have been addressed earlier; pls. point me to mailing list discussions if these have been already been addressed).

Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2:
---------------------------------------------------------------------

The SIPREC protocol draft section 5.2 suggests the use of INVITE, RE-INVITE or UPDATE for conveying metadata from the SRC to the SRS. This may have been discussed in SIPREC WG earlier, but the choice of these methods for delivering metadata seems counterintuitive. This choice certainly misses some use cases.

IMHO, the metadata information flow seems to better fit a SUBSCRIBE/NOTIFY mechanism. The protocol should allow for decoupling of RS session management (such as adding and removing media streams) from metadata event communication. These two protocol communications are somewhat independent. For example, the RS session management will tend to be real-time with SDP changes back-and-forth to avoid clipping of media. The metadata events are less real-time demanding because they can be correlated with the recorded media as long as the timestamps between the two flows are synchronized. For these reasons, the metadata generation/consumption logic may exist in different processing units in the SRC/SRC as compared to the RS session management and RTP media handling. This is one of the reasons why the SIPREC protocol allows for a non-SIP mechanism delivery of metadata even though it is out of scope of SIPREC (section 4).

The CS/RS lifecycle diagrams in section 4 in RFC 6341 highlight some of these requirements. In particular, use case 4 in RFC 6341 describes a scenario where the RS exists longer than a CS. As a practical implementation of this use case, the SRC sends a metadata event to the SRS indicating a user logon (note that this means that metadata events span a user logon lifespan and not just the CS lifespan) when the user initially logs on but hasn't participated in a CS at this point. Depending on the capacity available at the SRS, the logon event triggers an INVITE from the SRS to the SRS to establish the RS. The logon event is delivered through a subscription that the SRS has previously established with the SRC. Such a message flow prevents clipping of the initial media samples from being recorded, which is the case when CS and RS are racing to establish at the same time. There are also use cases around push-to-talk where metadata events are required but turning RTP on and off through SDP exchange (sendonly, inactive) is expensive and more prone to media clipping.

In the SUBSCRIBE/NOTIFY mechanism, the SRC will subscribe to the SRS for the metadata events. The SRC will push metadata events to the SRS as the CS undergoes state changes (initiation, teardown, hold/resume etc.) or when the user state that is targeted for recording undergoes changes. The SUBSCRIBE/NOTIFY mechanism also allows for built in bootstrapping of the SRS state where the SRS recovers after a failure (the first NOTIFY to the SUBSCRIBE will carry the current snapshot of the recording metadata; there may also be historical CS information in this NOTIFY). Sending an UPDATE for a 'media snapshot request' from SRS to SRC (as shown in Figure 2) seems counterintuitive to the usage of the UPDATE method (why and what is the SRS updating the SRC about the RS for?). A SUBSCRIBE will always fetch the current state as per the definition.

Indicating recording preference in SDP (a=record, a=recordpref), Section 5.3:
-----------------------------------------------------------------------------

The notion that a CS is being recorded or not seems more like a SIP-level construct (or maybe a metadata-level construct) as opposed to an SDP-level context. Are these attributes really describing some characteristic about the media being carried in the RS RTP (described by SDP) or are they describing an RS characteristic itself? When an RS carries multiple CSes, I'm assuming that the metadata will uniquely identify each media stream in the RS (e.g. the SDP a=label token will also be present in the metadata in some form) and so such attributes can be placed in the metadata.

In section 5.3, if the SRC chooses to ignore SRS' request to turn off recording, how does the SRS learn about that and what should the SRS do if it continues to receive media from the SRC?

Section 6.1, '+sip.rec' and 'siprec' tags':
-------------------------------------------

Section 6.1 states:

   In addition, when an SRC sends a REGISTER request
   to a registrar, the SRC MUST include the '+sip.src' feature tag to
   indicate the that it is a SRC.

The purpose of the Contact URI tags '+sip.src' and '+sip.srs' is not very clear from the description. They don't seem to be helping with the negotiating aspect of the recording feature and the SRS /SRS communication may not be through a proxy server (which has access to a registrar's location service). The notion of an SRC registering using the REGISTER method is also not very clear (e.g. when the SRC is an SBC, does it register as a UA with a registrar)?

These Contact URI tags seem to overlap with the 'siprec' tag. Why does an SRC or SRS must ensure that either one of these Contact URI tags (depending on the direction of the INVITE) AND the 'siprec' tag must be present in the RS INVITE?

Section 7.1, Scope of a=label:
------------------------------

I think the following statement in section 7.1 could be clarified (I think this means that the label can be reused after the previous stream with that label is no longer active):

   The scope of the label name only applies to the same SIP message as the
   SDP, meaning that the label name can be reused by another media
   stream within the same recording session.

Regards,

Raj Jain