[siprec] Feddback on draft-yan-siprec-msrp-recording-01

Saúl Ibarra Corretgé <saul@ag-projects.com> Sun, 20 July 2014 17:37 UTC

Return-Path: <saul@ag-projects.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5241B28F1 for <siprec@ietfa.amsl.com>; Sun, 20 Jul 2014 10:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.51
X-Spam-Level: *
X-Spam-Status: No, score=1.51 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh8kGjPa0sPj for <siprec@ietfa.amsl.com>; Sun, 20 Jul 2014 10:37:36 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id E6E581B28F0 for <siprec@ietf.org>; Sun, 20 Jul 2014 10:37:33 -0700 (PDT)
Received: from imac.saghul.lan (g154115.upc-g.chello.nl [80.57.154.115]) by mail.sipthor.net (Postfix) with ESMTPSA id 3794216DC719 for <siprec@ietf.org>; Sun, 20 Jul 2014 19:37:32 +0200 (CEST)
From: Saúl Ibarra Corretgé <saul@ag-projects.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_D17EBB4D-0FB8-487B-860B-E0484E544F43"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Message-Id: <1F3FB8A4-1EE7-45DA-9796-F0DF4AE5EF4F@ag-projects.com>
Date: Sun, 20 Jul 2014 19:37:47 +0200
To: siprec@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/b-yeK7GBL2XWAIl7T23_pevWFYc
Subject: [siprec] Feddback on draft-yan-siprec-msrp-recording-01
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jul 2014 17:37:38 -0000

Hi all,

Paul recently asked if Icould have a look at this draft since I’ve worked on some MSRP implementations and participated on some discussions over at SIMPLE, so here it goes :-)

Disclaimer: I´m not all that familiar with SIPREC and all prior discussions about this draft, so apologies if I guessed something incorrectly and / or repeated something.

1. Introduction

Some SIPREC related acronyms are expanded the first time they are used, but not all. It might help to do so at least the first time they are used. Is this what would go on Section 2?


3.1 MSRP Client acts as SRC

Is there any defined mechanism to notify an endpoint that the session is going to be recorded? If a client is going to act as a SRC then I guess it should add some indication to the SDP so the other endpoint can decide if she wants to maintain that chat conversation, knowing that it will be recorded. Now, if recording can be toggled on and off while in the middle of a session then some other mechanism might be necessary, perhaps a header in an empty SEND chunk?


3.2.  MSRP Relay acts as SRC

I see this section is still on the works. I think there are 2 separate cases: using an outbound relay and using an inbound one. A user may choose to use an outbound relay for recording purposes, in which case this would need to be signalled to the relay somehow. If the recipient of an INVITE needs to use an inbound relay for NAT traversal purposes, she might also be interested in recording the session.

As mentioned above, perhaps a header in the empty SEND chunk used to bind the session could be used to let the other endpoint know the session is going to be recorded.


4.  MSRP Media Stream Mixing

I think CPIM should me made a MUST here. There is no way to know who sent what (including the switch itself) unless CPIM is in use. Also, there would be no way to send private messages across a switch unless CPIM is used.

Also, not sure if as part of this draft or perhaps a new one, but the recording mechanism could also be used in reverse by the MSRP switch, to replay the conference history to new participants who join.


8. Recording Chatrooms

IMHO, if a chatroom record messages it should advertise so in the a=chatroom attribute, i.e.: “a=chatroom:nickname private-messages
 siprec”.


Again, this is the first time I come across SIPREC, so please take the above with a grain of salt.


Regards,

--
Saúl Ibarra Corretgé
AG Projects