Subject: Re: [siprec] draft-ietf-siprec-protocol-02

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Nov 2011 18:13:58 -0500

I was just reviewing draft-ietf-siprec-protocol-02, and the following 
are things I noted along the way:

Section 4.2:

    Metadata is transported in the body of INVITE or UPDATE messages.
    Certain metadata, such as the attributes of the recorded media stream
    are located in the SDP of the recording session.

I think we should point out that this is typically going to require 
multipart support. Perhaps:

    Metadata is transported within the body of INVITE or UPDATE messages
    for the recording session. Most metadata is located in a siprec
    specific body part, but certain metadata, such as the attributes
    of the recorded media stream, are located in the SDP offer or answer.
    In many cases this means a message will contain both a siprec
    specific part as well as an SDP part, contained within a body of
    type multipart/mixed.

Figure 3:

Shouldn't the first message be:
     (1) INVITE (metadata snapshot(1) + SDP offer)

Section 5.1:

    An SRS uses the presence of the 'src' feature
    tag in dialog creating and modifying requests and responses to
    confirm that the dialog being created is for the purpose of a
    Recording Session. ... Other SIP Recording extensions and behaviors
    can be triggered by the presence of this feature tag.

This is an abuse of the feature tag mechanism. The tag indicates a 
*capability*. It shouldn't be used to infer intent. OTOH, I think it 
would be ok to interpret the presence of metadata in the message as an 
indication that request is intended for the purpose of establishing an RS.

Also, the option tag should be "sip.src". (Indicated as "+sip.src" in 
the Contact header.)

    Since SIP Caller Preferences extensions are optional to implement for
    routing proxies, there is no guarantee that a recording session will
    be routed to an SRC or SRS.  A new options tag is introduced:
    "siprec".  As per [RFC3261], only an SRC or an SRS can accept this
    option tag in a recording session.  An SRC SHOULD include the
    "siprec" option tag in the Require header when initiating a Recording
    Session so that other types of user agents can simply reject the
    INVITE request with a 420 Bad Extension.

This doesn't distinguish between SRC and SRS behavior. It might be 
better to have two option tags: src and srs.

If that was done, its not evident that the feature tags add anything. It 
would be simpler to have the INVITE contain:

	Supported: src
	Require: srs

(An RS initiated by the SRS would invert those.)

6.1

Given the work that is being done in other WGs on multiplexing media 
streams on RTP streams, I wonder if we ought to revisit our decision to 
always map a CS media stream uniquely to an RS m-line, and instead 
consider allowing multiplexing. (But doing this would require more 
description in metadata and/or SDP.)

6.1.1

    ... To
    add a recorded stream to the recording session, the SRC sends a new
    SDP offer by adding a new media stream description or by reusing an
    old media stream which had been previously disabled, according to the
    procedures in [RFC3264].

Its not necessary to disable one before reusing it. You can repurpose a 
stream in one step. How about:

    ... To
    add a recorded stream to the recording session, the SRC sends a new
    SDP offer by adding a new media stream description or by reusing an
    media stream which had been previously disabled or that is no
    longer needed, according to the procedures in [RFC3264].

Section 9:

    ... In order
    not to lose the NAT bindings for the RTP/RTCP ports opened for the
    recorded streams, the SRC and SRS SHOULD follow the recommendations
    provided in [RFC6263] to maintain the NAT bindings.

The recommendation involves also enabling multiplexing of rtcp and rtp. 
If that is what we are going to do it would be worth calling that out, 
and showing it in the examples.

But that document also only applies when ICE isn't used.

Maybe this should all be addressed as part of draft-eckel-siprec-rtp-rec.

Section 10.1.1

    A new SDP attribute "recordpref" is introduced.  The SDP attribute
    appears at the media level and can appear in an SDP offer or answer.
    The recording indication applies to the specified media stream only.
    The following is the ABNF of the recordpref attribute:

IMO this attribute should be permitted at either session or media level, 
with session level establishing a default for all media. (Thus only one 
session level attribute need be supplied to request that all media 
should/shouldn't be recorded.)

Section 10.2.1

The comments above for "recordpref" also apply to "record".

    The recording attribute is a declaration by an endpoint in the CS to
    indicate whether recording is taking place.

This seems wrong. The indication is from the SRC toward and endpoint. 
How about:

    The recording attribute is a declaration by the SRC to an endpoint
    in the CS to indicate whether recording is taking place.  For
    example, if a UA (A)

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Sun, 13 Nov 2011 20:42:43 -0500

Paul Hi

Thank you for the review. Please see below

Leon

On Nov 11, 2011, at 6:13 PM, Paul Kyzivat wrote:

> I was just reviewing draft-ietf-siprec-protocol-02, and the following are things I noted along the way:
> 
> Section 4.2:
> 
> I think we should point out that this is typically going to require multipart support. Perhaps:
> 

[Leon] I agree

>    (1) INVITE (metadata snapshot(1) + SDP offer)
[Leon] Correct ,it is also true for persistent recording use case

> This is an abuse of the feature tag mechanism. The tag indicates a *capability*. It shouldn't be used to infer intent. OTOH, I think it would be ok to interpret the presence of metadata in the message as an indication that request is intended for the purpose of establishing an RS.
> 
> Also, the option tag should be "sip.src". (Indicated as "+sip.src" in the Contact header.)
> 
[Leon] I will add it to open items to the IETF 82 presentation. The main question is if we always have metadata in RS INVITE. I think we always should have also for persistent use case as well, even it only describes preallocated media sessions and not specific CS.

> This doesn't distinguish between SRC and SRS behavior. It might be better to have two option tags: src and srs.
> 
> If that was done, its not evident that the feature tags add anything. It would be simpler to have the INVITE contain:
> 
> 	Supported: src
> 	Require: srs
> 

[Leon] Will add as an open item to the presentation
> 
> 6.1
> 
> Given the work that is being done in other WGs on multiplexing media streams on RTP streams, I wonder if we ought to revisit our decision to always map a CS media stream uniquely to an RS m-line, and instead consider allowing multiplexing. (But doing this would require more description in metadata and/or SDP.)
> 
[Leon] I believe the decision was not to prevent support for multiplexing but just not to require it.
> Its not necessary to disable one before reusing it. You can repurpose a stream in one step. How about:
> 
>   ... To
[Leon] I am ok with that

> The recommendation involves also enabling multiplexing of rtcp and rtp. If that is what we are going to do it would be worth calling that out, and showing it in the examples.
> 

[Leon] I am ok with that
> IMO this attribute should be permitted at either session or media level, with session level establishing a default for all media. (Thus only one session level attribute need be supplied to request that all media should/shouldn't be recorded.)

[Leon] I am ok with that
> This seems wrong. The indication is from the SRC toward and endpoint. How about:
> 
[Leon] Agree, we should fix it in the document
> 	Thanks,
> 	Paul
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 16 Nov 2011 01:58:34 -0800

Sorry, just catching up things now. Regarding this snippet:

> > The recommendation involves also enabling multiplexing of rtcp and
rtp. If that is what we are going
> to do it would be worth calling that out, and showing it in the
examples.
> > Maybe this should all be addressed as part of
draft-eckel-siprec-rtp-rec.

draft-eckel-siprec-rtp-rec-03, section 10, reads as follows:

   It is anticipated that media streams in SIPREC may exist in inactive
   states for extended periods of times for an of a number of valid
   reasons.  In order for the bindings and any pinholes in NATs/
   firewalls to remain active during such intervals, it is RECOMMENDED
   to follow the keep-alive procedure recommended in "Application
   Mechanism for Keeping Alive the NAT Mappings Associated to RTP/RTP
   Control Protocol (RTCP) Flows" [RFC6263] for all RTP media streams.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Leon Portman
> Sent: Monday, November 14, 2011 9:43 AM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [siprec] draft-ietf-siprec-protocol-02
> 
> Paul Hi
> 
> > I was just reviewing draft-ietf-siprec-protocol-02, and the
following are things I noted along the
> way:
> > This is an abuse of the feature tag mechanism. The tag indicates a
*capability*. It shouldn't be
> used to infer intent. OTOH, I think it would be ok to interpret the
presence of metadata in the
> message as an indication that request is intended for the purpose of
establishing an RS.
> [Leon] I will add it to open items to the IETF 82 presentation. The
main question is if we always have
> metadata in RS INVITE. I think we always should have also for
persistent use case as well, even it
> only describes preallocated media sessions and not specific CS.
> 
better to have two option tags:
> src and srs.
> >
> > If that was done, its not evident that the feature tags add
anything. It would be simpler to have
> the INVITE contain:
streams on RTP streams, I
> wonder if we ought to revisit our decision to always map a CS media
stream uniquely to an RS m-line,
> and instead consider allowing multiplexing. (But doing this would
require more description in metadata
> and/or SDP.)
> > Its not necessary to disable one before reusing it. You can
repurpose a stream in one step. How
> about:
> > The recommendation involves also enabling multiplexing of rtcp and
rtp. If that is what we are going
> to do it would be worth calling that out, and showing it in the
examples.
> > IMO this attribute should be permitted at either session or media
level, with session level
> establishing a default for all media. (Thus only one session level
attribute need be supplied to
> request that all media should/shouldn't be recorded.)
> 
> [Leon] I am ok with that
> >
> > Section 10.2.1
> >

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 16 Nov 2011 08:41:46 -0800

Just trying to catch up on the messages. I agree with the comments below
and will make the changes suggested.

> > If that was done, its not evident that the feature tags add
anything.
> It would be simpler to have the INVITE contain:
> >
> > 	Supported: src
> > 	Require: srs
> >

I like the idea of simplifying the intent as options tags only using
separate options tags for src and srs. This way we are sure only an SRS
can accept the recording session coming from an SRC.

The feature tag can still be useful for registration purposes so the
registrar knows that a contact is an SRS.

Regards,
Henry

> Sent: November-13-11 8:43 PM
> To: Paul Kyzivat
> Cc: [email-masked]
following
> main question is if we always have metadata in RS INVITE. I think we
> always should have also for persistent use case as well, even it only
> describes preallocated media sessions and not specific CS.
> 
anything.
> It would be simpler to have the INVITE contain:
> >
> > 	Supported: src
> > 	Require: srs
> >
repurpose
> a stream in one step. How about:
> >
> >   ... To
> rtp. If that is what we are going to do it would be worth calling that
> out, and showing it in the examples.
> >
> > Maybe this should all be addressed as part of
draft-eckel-siprec-rtp-
> rec.
> level, with session level establishing a default for all media. (Thus
> only one session level attribute need be supplied to request that all
> media should/shouldn't be recorded.)
> 
> [Leon] I am ok with that
> >
> > Section 10.2.1
> >

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Nov 2011 03:47:04 +0800

I hope we can have a live discussion of this during our meeting.
Its getting hard to figure out who has what in mind now.

	Thanks,
	Paul