>>>>>=20
>>>>>=20
>>>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>>>> has been successfully submitted by Paul H. Kyzivat and posted to =
the
>>>>> IETF repository.
>>>>>=20
>>>>> Name: draft-yan-siprec-msrp-recording
>>>>> Revision: 01
>>>>> Title: Overview for MSRP Recording based on SIPREC
>>>>> Document date: 2014-05-28
>>>>> Group: Individual Submission
>>>>> Pages: 9
>>>>> URL:
>>>>> =
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt=
>>>>>=20
>>>>> Status: =
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>>>> Htmlized: =
http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>>>> Diff: =
http://www.ietf.org/rfcdiff?url2=3Ddraft-yan-siprec-msrp-recording-01
>>>>>=20
>>>>> Abstract:
>>>>> SIPREC is capable of recording interactive text media that is
>>>>> transmitted via RTP. However that format is not commonly used =
for
>>>>> message or chat scenarios. There is also a need for recording =
text
>>>>> media carried via MSRP. One case of note is exchange of text =
between
>>>>> hearing-impaired users and emergence service bureaus. Also,
>>>>> recording support is needed for MSRP used in chat conferences =
and
>>>>> multimedia conferences.
>>>>>=20
>>>>> This document describes how to achieve MSRP channel recording =
within
>>>>> the mechanism of SIP Recording (SIPREC).
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission
>>>>> until the htmlized version and diff are available at =
tools.ietf.org.
>>>>>=20
>>>>> The IETF Secretariat
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> siprec mailing list
>>>>> siprec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>=20
>>>=20
>>> _______________________________________________
>>> siprec mailing list
>>> siprec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/siprec
>>=20
>>=20
>=20
--Apple-Mail=_615C2824-3A04-4ECB-B9F2-C647468C18A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
On 7/1/14 5:34 PM, Brian Rosen wrote:
I=92ve reviewed this document. I think it is a very =
good start, and think we can get it ready to ship quite =
quickly.
I have the following comments:
We need to specify =
a way to send and save REPORTS that are sent/received on the CS to the =
SRS. If, for example, a message sent by a party to another is not =
received completely,
and a REPORT js generated on the RS, we =
need to somehow record than in the CS.
I guess CS =
and RS need to be swapped in the above line, right?
Yeah =
doh!
You have =
a note about reports, but it isn=92t clear if you mean reports in the CS =
or the RS. Both have to be recorded, but at least in the RS, the =
SRS has all the info needed.
I just have a =
placeholder, because I haven't thought much about it yet.
I =
especially hadn't thought about reports on the RS. Note that the SRS =
won't be sending anything except reports to the SRC, so there is no =
reason for the SRC to be sending reports to the SRS about the RS msrp =
session.
Yeah, but it has to send reports it got on the =
CS somehow
Conversely, =
suppose the SRC gets a report from the SRS that something hasn't made it =
successfully. What should it do? (I can't think of anything useful for =
it do do.) I guess this is analogous to the SRC getting RTCP reports =
indicating packet loss of RTP media. We don't talk about =
that.
No, I think if the SRC gets a report of a problem =
on the CS it must record that.
I think =
if we neglected to record known problems detected in RTCP reports then =
we need to fix that too at some point =97 if the SRC knows about a =
problem, that has to be recorded.
But reports on the CS are significant information that =
could be important to record. I think they can't be sent as MSRP =
reports. I suspect we must find a way to encapsulate them as regular =
MSRP messages. But that seems messy. Ideas are =
welcome.
Yeah, I think that=92s right, and I think it=92s =
messy. Sending them in metadata is a possibility. Extending =
reports in some manner is a possibility.
I think there is a problem =
with the text about adding a CPIM wrapper if there isn=92t one. I =
think the recording has to know if the original message was sent by some =
entity other than the one in the CPIM =46rom (that is, we have to =
preserve the MSRP From). The SRS has to know whether the original =
message had a CPIM header, and its contents. If the SRC =
changes the message (by adding the wrapper) I think the SRS has to be =
able to figure that out, and record that fact in some =
way.
I hear you, though I'm not yet convinced how =
important it is for the SRS to be able to make this =
distinction.
I think the recording is what the SRC got. =
If you can=92t effectively reproduce what the SRC gets, the =
mechanism is not adequate.
I =
think the only way to be *certain* that the SRS can distinguish these is =
to wrap *every* message, even those that already contain CPIM headers. =
Then the SRS would know that the outer wrapper was always from the SRC, =
and that if there was another cpim wrapper inside then it was from the =
CS. But that seems like overkill.
Yeah, I=92d prefer not =
to do that
If we only put =
CPIM wrappers on messages that don't already have them, then we could =
put something *special* in them. But there would be no guarantee that =
the CS didn't use that.
There is always a way. We =
can extend CPIM if we need to.
We could also introduce a new mime type similar to =
CPIM, but specially for recording. If we constrained the usage of that =
then we might be able to claim that it could never appear on the CS. But =
I would prefer to avoid this.
I=92d rather just extend =
CPIM
When we echo a message from the RS to the CS, we=92re =
going to lose the MESSAGE-ID from the RS. That=92s a problem. =
We have to save that info in the recording. A hack would be =
to use the same message ID in both the CS and the RS, possibly with some =
prefix.
I worry a bit about chunking in the RS differently from =
chunking in the CS. I may be mistaken, but if the chunking is different, =
will that affect the byte-range response in a failure =
report?
Don't the above issues have analogs for =
RTP/RTCP?
No, i don=92t think so. Message ID is =
much more of a real id then anything you find in an RTP header. =
You can derive wall time, which might be similar, but not =
really.
Do we have =
any more requirement to solve them here than we did =
there?
The URIs in the original to/from =
need to be captured, but they will be different in the RS. Need to =
fix that.
I assume you are talking about the to/from =
in CPIM, right? Why do they need to be different in the =
RS?
MSRP To/=46rom in the RS is SRS/SRC. If there =
wasn=92t any CPIM, we could add it, in which case MSRP To/=46rom in CS =
becomes CPIM To/=46rom in RS. If there is CPIM already, we need to =
preserve it, and then we need to solve sending CS MSRP To/=46rom in the =
RS.
Do we need to say something about max-size issues between =
CS and RS?
Probably. Seems like a policy issue in =
the SRS. If the SRS doesn't want to record large messages. Maybe we want =
to specify that the SRC MUST honor the SRS's max-size, bypassing =
recording of messages that are too big. (Or perhaps inserting special =
small messages as placeholders for the bypassed =
messages.)
Yeah, something. Basically, to avoid =
problems, CS max has to be at least as big as RS max. I think =
that=92s just a MUST as a by-the-way.
You can=92t possibly not =
change -metadata. As an example. you have to allow an msrp AoR for =
a participant
Hmm. I guess so. I was thinking that =
we were lenient in the AoR type, but I guess not.
Since the =
metadata isn't done yet, maybe we can change it before it is done, to =
allow this. (Allow any URI.)
Depends on how we solve =
some of these other issues.
That one leaped out at me, have to =
look harder to see if there are others. Interaction of the term =
=93Participant=94 for example.
Yes, I think we have to =
extend Participant to handle nicks.
A participant =
can already have multiple AoR/Name pairs. So we could add the nickname =
as one of those.
Would have to be labeled in some =
way
(We really did try to =
plan ahead with the metadata.)
Probably =
also to handle the SIP session URI vs the MSRP =
URIs
Note that the metadata associates participants =
with both the CS and individual media streams. So the SIP session URIs =
are already covered there.
I=92m missing something, but =
it=92s probably lack of clue on how metadata works. =
And, I spotted another metadata change =
problem:
6.5.1. Attributes
Participant has a single defined attribute:
o AoR / Name pair list - This attribute is a list of Name/AoR
tuples. An AoR MAY be a SIP/SIPS/TEL URI. Name represents
Participant name(SIP display name) or dialed number (DN) (when
known). Multiple tuples are allowed for cases where a participant
has more than one AoR. (For example a P-Asserted-identity header
[RFC3325] =
can have both SIP and TEL URIs.)
Have to add msrp/msrps to the list. Does =
the MSRP To/=46rom HAVE to be an msrp/msrps scheme, or can it be a sip =
AoR? If the latter, we could have a corner case where the SIP AoR =
and the MSRP AoR were both SIP but =
different.
=
Thanks,
Paul
Brian
On Jun 26, 2014, at 12:32 PM, Paul Kyzivat =
<pkyzivat@alum.mit.edu>=
wrote:
Trying one more time. =
Please!!!
On 6/3/14 2:46 PM, Paul Kyzivat wrote:
Can I get some people in the wg to review and comment on =
this version?
Thanks,
=
Paul
On 5/28/14 6:10 PM, Paul Kyzivat =
wrote:
I've submitted a revised version of =
the msrp recording draft.
This one is substantially fleshed out. It =
certainly needs more tweaking,
but is complete enough that you should =
be able to make meaningful
comments on the approach.
=
Thanks,
=
Paul
-------- Original Message =
--------
Subject: New Version Notification =
for
draft-yan-siprec-msrp-recording-01.txt
Date: Wed, 28 May 2014 =
15:03:24 -0700
From: internet-drafts@ietf.org
T=
o: Michael Yan <michael.yan@huawei.com>, =
"Paul H. Kyzivat"
<pkyzivat@alum.mit.edu>, =
"Michael Yan" <michael.yan@huawei.com>,
=
"Paul Kyzivat" <pkyzivat@alum.mit.edu>
A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
has =
been successfully submitted by Paul H. Kyzivat and posted to the
IETF =
repository.
Name: =
draft-yan-siprec-msrp-recording<=
br>Revision: 01
Title: =
Overview for MSRP Recording =
based on SIPREC
Document date: 2014-05-28
Group: =
Individual =
Submission
Pages: =
9
URL:
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-record=
ing-01.txt
Status: =
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
Htmli=
zed: =
http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
Diff: =
http://www.ietf.org/rfcdiff?url2=3Ddraft-yan-siprec-msrp-recording-01
<=
br>Abstract:
SIPREC is capable of recording =
interactive text media that is
transmitted via =
RTP. However that format is not commonly used for
=
message or chat scenarios. There is also a need =
for recording text
media carried via MSRP. =
One case of note is exchange of text between
=
hearing-impaired users and emergence service bureaus. =
Also,
recording support is needed for MSRP =
used in chat conferences and
multimedia =
conferences.
This document describes how to =
achieve MSRP channel recording within
the =
mechanism of SIP Recording (SIPREC).
Please =
note that it may take a couple of minutes from the time =
of
submission
until the htmlized version and diff are available at =
tools.ietf.org.
The IETF =
Secretariat
___________________________________________=
____
siprec mailing =
list
siprec@ietf.org
https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
s=
iprec mailing list
siprec@ietf.org
https://www.ietf.or=
g/mailman/listinfo/siprec
________________________=
_______________________
siprec mailing list
siprec@ietf.org
https://www.ietf.or=
g/mailman/listinfo/siprec
=
--Apple-Mail=_615C2824-3A04-4ECB-B9F2-C647468C18A2--
From nobody Thu Jul 3 13:20:40 2014
Return-Path:
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 4FBDF1B2B55; Thu, 3 Jul 2014 13:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 EpCDYUOWrToy; Thu, 3 Jul 2014 13:20:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C511B2B9A; Thu, 3 Jul 2014 13:20:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140703202010.10313.91660.idtracker@ietfa.amsl.com>
Date: Thu, 03 Jul 2014 13:20:10 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/f9NPNLF6Yl26FqDoq3tvYozpWH8
Cc: siprec@ietf.org
Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Recording Working Group Discussion List
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 03 Jul 2014 20:20:34 -0000
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP Recording Working Group of the IETF.
Title : Session Recording Protocol
Authors : Leon Portman
Henry Lum
Charles Eckel
Alan Johnston
Andrew Hutton
Filename : draft-ietf-siprec-protocol-13.txt
Pages : 42
Date : 2014-07-03
Abstract:
This document specifies the use of the Session Initiation Protocol
(SIP), the Session Description Protocol (SDP), and the Real Time
Protocol (RTP) for delivering real-time media and metadata from a
Communication Session (CS) to a recording device. The Session
Recording Protocol specifies the use of SIP, SDP, and RTP to
establish a Recording Session (RS) between the Session Recording
Client (SRC), which is on the path of the CS, and a Session Recording
Server (SRS) at the recording device.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-siprec-protocol-13
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-protocol-13
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
From nobody Thu Jul 3 13:31:42 2014
Return-Path:
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 B1C941B2A5A for ; Thu, 3 Jul 2014 13:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 3FdWK9r-z3Hg for ; Thu, 3 Jul 2014 13:31:39 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99FC1B2A26 for ; Thu, 3 Jul 2014 13:31:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2071; q=dns/txt; s=iport; t=1404419499; x=1405629099; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/3PZrr0uEUlDWC7jlesQNFjisivL6RZS9n+UwOFVPvo=; b=NK7t1K2+5RB4o3sslJXHoYKdRi6Hs/wGoNrHetVXGp4/ak4hYeXp18jW PJAJTMCtIhk5JY6KJCaAfLanvG8vrneWyeLp4aEmHKsXtViwdv37vfZNT sYxnoSFpr41AV0Yk/noGu+6SFGCHaIMisoE6adfJVQJbKb+YIOQFAMtuj E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmYIACe8tVOtJA2J/2dsb2JhbABagw1SUwe+XYZsUwGBDhZ1hAQBAQQBAQE3NBsCAQg2ECcLJQIEEwmIOQgFyUkXjymEQwWadoFIkkODQ4Iw
X-IronPort-AV: E=Sophos;i="5.01,596,1400025600"; d="scan'208";a="337711131"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2014 20:31:38 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s63KVcdX032677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 3 Jul 2014 20:31:38 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.242]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 15:31:37 -0500
From: "Charles Eckel (eckelcu)"
To: "siprec@ietf.org"
Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
Thread-Index: AQHPlvxNjHZ8hx4HoEuoLv/B3nK8sZuOrBIA
Date: Thu, 3 Jul 2014 20:31:36 +0000
Message-ID:
References: <20140703202010.10313.91660.idtracker@ietfa.amsl.com>
In-Reply-To: <20140703202010.10313.91660.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.144.205]
Content-Type: text/plain; charset="us-ascii"
Content-ID:
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/dbZ983S7p9FpCl1q-7InYc1toCk
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-13.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 03 Jul 2014 20:31:40 -0000
This update addresses the FIR vs. SIP INFO issue as well as the WGLC
comments. Please have a look and share any comments.
Cheers,
Charles
On 7/3/14, 1:20 PM, "internet-drafts@ietf.org"
wrote:
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the SIP Recording Working Group of the IETF.
>
> Title : Session Recording Protocol
> Authors : Leon Portman
> Henry Lum
> Charles Eckel
> Alan Johnston
> Andrew Hutton
> Filename : draft-ietf-siprec-protocol-13.txt
> Pages : 42
> Date : 2014-07-03
>
>Abstract:
> This document specifies the use of the Session Initiation Protocol
> (SIP), the Session Description Protocol (SDP), and the Real Time
> Protocol (RTP) for delivering real-time media and metadata from a
> Communication Session (CS) to a recording device. The Session
> Recording Protocol specifies the use of SIP, SDP, and RTP to
> establish a Recording Session (RS) between the Session Recording
> Client (SRC), which is on the path of the CS, and a Session Recording
> Server (SRS) at the recording device.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-siprec-protocol-13
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-13
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>siprec mailing list
>siprec@ietf.org
>https://www.ietf.org/mailman/listinfo/siprec
From nobody Thu Jul 3 13:36:50 2014
Return-Path:
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 569081B2A2C for ; Thu, 3 Jul 2014 13:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level:
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 oIbmFP7EVcdp for ; Thu, 3 Jul 2014 13:36:47 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD9F1A035E for ; Thu, 3 Jul 2014 13:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4147; q=dns/txt; s=iport; t=1404419806; x=1405629406; h=from:to:subject:date:message-id:mime-version; bh=Z+trS0svKSLqa4NeK6iJ1v+YtwkWac8KzXwH2CHXt/0=; b=U5HkFzXuDONce7Gso9sJPmzO2hRj50CmBnexKcXxrAv1J9xJLr7FtRT6 A7EK8xfVB6t/Rv3Oz1QaQlcmLBKs0U3ZUtji/tQyUvC1NRClQbr8KVqkX DtfdfcJRl324H1aPMDDeqGy9RGLJF+6BZAHfE4gUEqx+V8DUrsazyrHDc g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFALm+tVOtJA2I/2dsb2JhbABagkZHUlrGHIEPFnWEAwECBC1eAQgEDQMBAig5FAkKBAESiEINyUgTBI53BxMNEYQ9BZp2lAuDQ2yBRA
X-IronPort-AV: E=Sophos; i="5.01,597,1400025600"; d="scan'208,217"; a="58178122"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 03 Jul 2014 20:36:25 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s63KaO9P023527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 20:36:24 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.242]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 15:36:24 -0500
From: "Charles Eckel (eckelcu)"
To: "Hutton, Andrew" , "siprec@ietf.org"
Thread-Topic: [siprec] SIPREC Meeting and Agenda for IETF90.
Thread-Index: AQHPlv50J5MdcRGuSAucGlMXUhaygg==
Date: Thu, 3 Jul 2014 20:36:24 +0000
Message-ID:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.144.205]
Content-Type: multipart/alternative; boundary="_000_CFDB0BBF2D0ECeckelcuciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/pCnlLX4EIKpTjwSsvxfsdY_Mxkk
Subject: Re: [siprec] SIPREC Meeting and Agenda for IETF90.
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 03 Jul 2014 20:36:48 -0000
--_000_CFDB0BBF2D0ECeckelcuciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
I just posted an update to the protocol draft. I do not anticipate requirin=
g agenda time in Toronto, but it really depends on folks reviewing the draf=
t and identifying any issues.
Cheers,
Charles
From: , Andrew >
Date: Wednesday, July 2, 2014 at 2:32 AM
To: "siprec@ietf.org" >
Subject: [siprec] SIPREC Meeting and Agenda for IETF90.
Hi All,
We need to submit a draft agenda by the 7th of July so please if you want t=
o present during the SIPREC Session then please let me know.
We are currently scheduled for the Friday 11:50 slot (https://datatracker.i=
etf.org/meeting/90/agenda.html) but there have been some changes to the age=
nda over the last couple of days including SIPREC being moved so there coul=
d still be late changes.
I will send a message to the list if the SIPREC session is moved again.
Regards
Andy
--_000_CFDB0BBF2D0ECeckelcuciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <0461C1A81A07334396B7A724749D51E5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
I just posted an update to the protocol draft. I do not anticipate req=
uiring agenda time in Toronto, but it really depends on folks reviewing the=
draft and identifying any issues.
Cheers,
Charles
Hi All,
We need to submit a draft agenda by the 7th of July so please if you =
want to present during the SIPREC Session then please let me know.
I will send a message to the list if the SIPREC session is moved again=
.
Regards
Andy
--_000_CFDB0BBF2D0ECeckelcuciscocom_--
From nobody Wed Jul 9 15:22:44 2014
Return-Path:
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 A76A41A0065 for ; Wed, 9 Jul 2014 15:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 SBAIZ0959y3Q for ; Wed, 9 Jul 2014 15:22:40 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 653AD1A0123 for ; Wed, 9 Jul 2014 15:22:40 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id QJMh1o00716LCl05CNNfVb; Wed, 09 Jul 2014 22:22:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id QNNf1o00o3ZTu2S3SNNf57; Wed, 09 Jul 2014 22:22:39 +0000
Message-ID: <53BDC0AF.1060906@alum.mit.edu>
Date: Wed, 09 Jul 2014 18:22:39 -0400
From: Paul Kyzivat
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian Rosen
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <53B58B0B.1060004@alum.mit.edu> <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net>
In-Reply-To: <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404944560; bh=bY3SZL627+bPcACiiHjT+vnqxY3kDZaquboRqBq5e7g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q0int0caGmZolQUSECXM9/P6K9oQf0HzQmsi8E2wjYzL2Mkd2E+KI39nEnCH6mJbu vOpRd+105wXJRPb9mqbyNfps8gdu3WXyO0a+MoksXkCnECPd1PwfiyC5j7DBY/TVpv vQzOkxxBIaYDG1PgRIQKFg686uTqT/OgjUDWM7AUlbPq2pmEjBJcVpvbfdv1st3Z/g mR3UOLbOdyZRFp9YNfr5QcSHCuoyoH1mH5XGeD8vJ0e1EUBVxOs7wMgKvYVAYqdD0N /FMod3a01UGhowGosJw3jvx86HM4s9iU26unv4nhglrwVqS2JyZpcChY7EeRBEJSFh BJ5X2ucDBopMA==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/ZHWd06LB9mW55xva1V_O6VhPclA
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Jul 2014 22:22:42 -0000
Brian - inline
On 7/3/14 3:25 PM, Brian Rosen wrote:
>
> On Jul 3, 2014, at 12:55 PM, Paul Kyzivat > wrote:
>
>> On 7/1/14 5:34 PM, Brian Rosen wrote:
>>> I’ve reviewed this document. I think it is a very good start, and
>>> think we can get it ready to ship quite quickly.
>>>
>>> I have the following comments:
>>>
>>> We need to specify a way to send and save REPORTS that are
>>> sent/received on the CS to the SRS. If, for example, a message sent
>>> by a party to another is not received completely,
>>> and a REPORT js generated on the RS, we need to somehow record than
>>> in the CS.
>>
>> I guess CS and RS need to be swapped in the above line, right?
> Yeah doh!
>>
>>> You have a note about reports, but it isn’t clear if you mean reports
>>> in the CS or the RS. Both have to be recorded, but at least in the
>>> RS, the SRS has all the info needed.
>>
>> I just have a placeholder, because I haven't thought much about it yet.
>>
>> I especially hadn't thought about reports on the RS. Note that the SRS
>> won't be sending anything except reports to the SRC, so there is no
>> reason for the SRC to be sending reports to the SRS about the RS msrp
>> session.
> Yeah, but it has to send reports it got on the CS somehow
>
>>
>> Conversely, suppose the SRC gets a report from the SRS that something
>> hasn't made it successfully. What should it do? (I can't think of
>> anything useful for it do do.) I guess this is analogous to the SRC
>> getting RTCP reports indicating packet loss of RTP media. We don't
>> talk about that.
> No, I think if the SRC gets a report of a problem on the CS it must
> record that.
That is a different case. I was specifically talking about the case
where the SRC gets a report from the *SRS*. There is nothing useful it
can do. Obviously the SRS knows about the problem (it sent the report),
so it can record an indication of the problem without the SRC having to
tell it.
> I think if we neglected to record known problems detected in RTCP
> reports then we need to fix that too at some point — if the SRC knows
> about a problem, that has to be recorded.
>
>>
>> But reports on the CS are significant information that could be
>> important to record.
This is the case you were talking about.
>> I think they can't be sent as MSRP reports. I
>> suspect we must find a way to encapsulate them as regular MSRP
>> messages. But that seems messy. Ideas are welcome.
> Yeah, I think that’s right, and I think it’s messy. Sending them in
> metadata is a possibility.
I don't think we can bound the rate that these occur. So I am very
reluctant to use the metadata mechanism to deal with them.
> Extending reports in some manner is a
> possibility.
Yes, this is possible. But it would be nice to avoid modifying MSRP.
>>> I think there is a problem with the text about adding a CPIM wrapper
>>> if there isn’t one. I think the recording has to know if the
>>> original message was sent by some entity other than the one in the
>>> CPIM From (that is, we have to preserve the MSRP From). The SRS has
>>> to know whether the original message had a CPIM header, and its
>>> contents. If the SRC changes the message (by adding the wrapper) I
>>> think the SRS has to be able to figure that out, and record that fact
>>> in some way.
>>
>> I hear you, though I'm not yet convinced how important it is for the
>> SRS to be able to make this distinction.
> I think the recording is what the SRC got. If you can’t effectively
> reproduce what the SRC gets, the mechanism is not adequate.
Does introducing a CPIM wrapper where there was none (making explict
what had been implicit) prevent reproducing what the SRC got?
Consider that we allow the SRC to transcode media before sending it to
the SRS. And we permit the SRC to transcode media before recording it.
In both of those cases we can't reproduce *exactly* what the SRC got.
What is so different here?
>> I think the only way to be *certain* that the SRS can distinguish
>> these is to wrap *every* message, even those that already contain CPIM
>> headers. Then the SRS would know that the outer wrapper was always
>> from the SRC, and that if there was another cpim wrapper inside then
>> it was from the CS. But that seems like overkill.
> Yeah, I’d prefer not to do that
>
>>
>> If we only put CPIM wrappers on messages that don't already have them,
>> then we could put something *special* in them. But there would be no
>> guarantee that the CS didn't use that.
> There is always a way. We can extend CPIM if we need to.
Yes we could. If we feel that we must.
>> We could also introduce a new mime type similar to CPIM, but specially
>> for recording. If we constrained the usage of that then we might be
>> able to claim that it could never appear on the CS. But I would prefer
>> to avoid this.
> I’d rather just extend CPIM
This is a matter of taste. I could go either way. It would be nice to
not have to extend CPIM.
>>> When we echo a message from the RS to the CS, we’re going to lose the
>>> MESSAGE-ID from the RS. That’s a problem. We have to save that info
>>> in the recording. A hack would be to use the same message ID in both
>>> the CS and the RS, possibly with some prefix.
After studying 4975 awhile I think we could do this. It *should* be ok
to use the old message-ids as-is - they are supposed to be globally
unique, across sessions. (Of course if we reuse them then they won't be
globally unique.)
If we are hyper, we could allow the SRC to add a prefix. But that
introduces complications if we are doing redundant SRCs sending to the
same SRS, because we won't recognize when we get the same message on
both paths.
>>> I worry a bit about chunking in the RS differently from chunking in
>>> the CS. I may be mistaken, but if the chunking is different, will
>>> that affect the byte-range response in a failure report?
The whole point of reporting byte ranges is that they are independent of
the chunking. I don't think this is an issue.
>> Don't the above issues have analogs for RTP/RTCP?
> No, i don’t think so. Message ID is much more of a real id then
> anything you find in an RTP header. You can derive wall time, which
> might be similar, but not really.
I guess what is different about message id is that its scope encompasses
multiple MSRP sessions. If the CS participants drop one session and
start another, and resend messages with the same ids, then I guess we do
want the SRS to understand that they were updating the same message.
>> Do we have any more requirement to solve them here than we did there?
>>
>>> The URIs in the original to/from need to be captured, but they will
>>> be different in the RS. Need to fix that.
>>
>> I assume you are talking about the to/from in CPIM, right? Why do they
>> need to be different in the RS?
> MSRP To/From in the RS is SRS/SRC.
OK.
> If there wasn’t any CPIM, we could
> add it, in which case MSRP To/From in CS becomes CPIM To/From in RS.
Why? It doesn't have to be if we don't want that. I would expect the SRC
to insert URIs that it knows from the CS for the participants in this
MSRP session. These would probably be the SIP URIs from the CS SIP
session of the sender and receiver of the MSRP session in the CS.
> If
> there is CPIM already, we need to preserve it, and then we need to solve
> sending CS MSRP To/From in the RS.
Why do we need the MSRP To/From at all? Those are just artificial things
used to identify particular sessions.
>>> Do we need to say something about max-size issues between CS and RS?
>>
>> Probably. Seems like a policy issue in the SRS. If the SRS doesn't
>> want to record large messages. Maybe we want to specify that the SRC
>> MUST honor the SRS's max-size, bypassing recording of messages that
>> are too big. (Or perhaps inserting special small messages as
>> placeholders for the bypassed messages.)
> Yeah, something. Basically, to avoid problems, CS max has to be at
> least as big as RS max. I think that’s just a MUST as a by-the-way.
I don't think so. We give the SRS a lot of lattitude about what it
records. If it wants to bound its resources by refusing to record small
messages, then that is its business.
We can't expect the CS to change its behavior to suit the RS. And IIUC
max-size is not negotiated, it is declared by the receiver. So there is
no way to communicate the max-size from the CS to the RS.
Also, max-size is only a hint - the sender need not honor it.
We *could* specify that the SRC SHOULD NOT forward messages on the RS
that exceed the SRS's max-size. I don't think there is much else we can
or should do.
>>> You can’t possibly not change -metadata. As an example. you have to
>>> allow an msrp AoR for a participant
>>
>> Hmm. I guess so. I was thinking that we were lenient in the AoR type,
>> but I guess not.
Based on my own comments above, I don't know why we need to have an msrp
AOR for a participant. I think we would identify participants in an MSRP
media session by sip URI.
>> Since the metadata isn't done yet, maybe we can change it before it is
>> done, to allow this. (Allow any URI.)
> Depends on how we solve some of these other issues.
> That one leaped out at me, have to look harder to see if there are
> others. Interaction of the term “Participant” for example.
>
>>
>>> Yes, I think we have to extend Participant to handle nicks.
>>
>> A participant can already have multiple AoR/Name pairs. So we could
>> add the nickname as one of those.
> Would have to be labeled in some way
I went back to review the chat stuff that defines Nickname. (It still
isn't an RFC!) I remembered wrong - the nickname isn't represented as a
URI. Ideally we would manage it in-band in the MSRP. But the way
nicknames are managed doesn't work very well for us. An msrp session is
bound to at most one nickname at any point in time.
We could work with that, sending NICKNAME requests on the RS msrp
session as needed to set the nickname to match that of the message we
want to send. But that would be unpleasant.
An alternative would be to define the use of Use-Nickname with a SEND
message. It currently isn't defined, but draft-ietf-simple-chat-18
leaves it open to be defined in the future.
We would want to specify that the SRS will be especially lenient
(promiscuous) in approving the use of nicknames.
>> (We really did try to plan ahead with the metadata.)
>>
>>> Probably also to handle the SIP session URI vs the MSRP URIs
>>
>> Note that the metadata associates participants with both the CS and
>> individual media streams. So the SIP session URIs are already covered
>> there.
> I’m missing something, but it’s probably lack of clue on how metadata
> works.
> And, I spotted another metadata change problem:
>
>
>
> 6.5.1
> .
> Attributes
>
>
>
> Participant has a single defined attribute:
>
> o AoR / Name pair list - This attribute is a list of Name/AoR
> tuples. An AoR MAY be a SIP/SIPS/TEL URI. Name represents
> Participant name(SIP display name) or dialed number (DN) (when
> known). Multiple tuples are allowed for cases where a participant
> has more than one AoR. (For example a P-Asserted-identity header
> [RFC3325 ] can have both SIP and TEL URIs.)
>
>
> Have to add msrp/msrps to the list. Does the MSRP To/From HAVE to be an
> msrp/msrps scheme, or can it be a sip AoR? If the latter, we could have
> a corner case where the SIP AoR and the MSRP AoR were both SIP but
> different.
The MSRP From/To URIs must be MSRP URIs.
But, I still don't see why we need to care about preserving those in the
recording.
I must say that this is the kind of discussion I have been hoping to
have - to nail down the nitty-gritty details.
Thanks,
Paul
>> Thanks,
>> Paul
>>
>>> Brian
>>>
>>> On Jun 26, 2014, at 12:32 PM, Paul Kyzivat >> > wrote:
>>>
>>>> Trying one more time. Please!!!
>>>>
>>>> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>>>>> Can I get some people in the wg to review and comment on this version?
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>>>>> I've submitted a revised version of the msrp recording draft.
>>>>>> This one is substantially fleshed out. It certainly needs more
>>>>>> tweaking,
>>>>>> but is complete enough that you should be able to make meaningful
>>>>>> comments on the approach.
>>>>>>
>>>>>> Thanks,
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> Subject: New Version Notification for
>>>>>> draft-yan-siprec-msrp-recording-01.txt
>>>>>> Date: Wed, 28 May 2014 15:03:24 -0700
>>>>>> From: internet-drafts@ietf.org
>>>>>> To: Michael Yan >>>>> >, "Paul H. Kyzivat"
>>>>>> >,
>>>>>> "Michael Yan" >>>>> >,
>>>>>> "Paul Kyzivat" >>>>> >
>>>>>>
>>>>>>
>>>>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>>>>> has been successfully submitted by Paul H. Kyzivat and posted to the
>>>>>> IETF repository.
>>>>>>
>>>>>> Name: draft-yan-siprec-msrp-recording
>>>>>> Revision: 01
>>>>>> Title: Overview for MSRP Recording based on SIPREC
>>>>>> Document date: 2014-05-28
>>>>>> Group: Individual Submission
>>>>>> Pages: 9
>>>>>> URL:
>>>>>> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt
>>>>>>
>>>>>> Status:
>>>>>> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>>>>> Htmlized:
>>>>>> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>>>>> Diff:
>>>>>> http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-01
>>>>>>
>>>>>> Abstract:
>>>>>> SIPREC is capable of recording interactive text media that is
>>>>>> transmitted via RTP. However that format is not commonly used for
>>>>>> message or chat scenarios. There is also a need for recording text
>>>>>> media carried via MSRP. One case of note is exchange of text
>>>>>> between
>>>>>> hearing-impaired users and emergence service bureaus. Also,
>>>>>> recording support is needed for MSRP used in chat conferences and
>>>>>> multimedia conferences.
>>>>>>
>>>>>> This document describes how to achieve MSRP channel recording
>>>>>> within
>>>>>> the mechanism of SIP Recording (SIPREC).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>> submission
>>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> siprec mailing list
>>>>>> siprec@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> siprec mailing list
>>>>> siprec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>
>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>>
>>
>
From nobody Wed Jul 9 15:49:05 2014
Return-Path:
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 76F411A014E for ; Wed, 9 Jul 2014 15:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level:
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham
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 rv3ja-I9hxLt for ; Wed, 9 Jul 2014 15:49:00 -0700 (PDT)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA941A014C for ; Wed, 9 Jul 2014 15:48:59 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id il7so9136459vcb.27 for ; Wed, 09 Jul 2014 15:48:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=T/0ET7KUtiDsAAOuV46seoNI1tYV2WT/eYADyFPdtBg=; b=KLO8rTBd/PP0qL6FgLO9te0KXRJ2d9SQlN0UNrgDlwt5qtAbswgwmJy0emYvYFnmPh KP+EpgHJK7wd00gBlQl6UurqCb7RZvDhEu1RkGpsoH+mCFL5j7nFXLHsLCDSBe6cQYeO tB4GXBgBxhc54xG+VwF0AlOXnKNqH+rpptF3oOCKfNVqD1cC/nciPtUpJO8CaQFX6v8N JVZLc2njxIpGciYX064WuQKT4VgM0JaE19C87vUZGjZxEJByysNlgtZDG+xTt81S3/Y5 MrbBNyVOslu+kNKe7zIEJCMGlX53Ypl3/zP21XIaUlNU0VAhK1OZOA1GeOpIa78PMZjc P1CQ==
X-Gm-Message-State: ALoCoQkvkoEXgAGd3duzThQz+R9ycGTbcueKSdtkIMy4GsSzurWPeaphh4E0Hq82N2mtcMWuwSk6
X-Received: by 10.52.228.163 with SMTP id sj3mr34519462vdc.30.1404946138933; Wed, 09 Jul 2014 15:48:58 -0700 (PDT)
Received: from [192.168.129.103] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id i10sm87865054qaq.22.2014.07.09.15.48.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 15:48:57 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Brian Rosen
In-Reply-To: <53BDC0AF.1060906@alum.mit.edu>
Date: Wed, 9 Jul 2014 15:48:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D3E761E-94FE-4C10-98BE-A87ACAE554CA@brianrosen.net>
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <53B58B0B.1060004@alum.mit.edu> <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net> <53BDC0AF.1060906@alum.mit.edu>
To: Paul Kyzivat
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/RfNczCas3pMsOkfo_JnnOfcQXMk
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 09 Jul 2014 22:49:03 -0000
Hopefully, we aren=92t getting too deep in levels
On Jul 9, 2014, at 3:22 PM, Paul Kyzivat wrote:
> Brian - inline
>=20
> On 7/3/14 3:25 PM, Brian Rosen wrote:
>>=20
>> On Jul 3, 2014, at 12:55 PM, Paul Kyzivat > > wrote:
>>=20
>>> On 7/1/14 5:34 PM, Brian Rosen wrote:
>>>> I=92ve reviewed this document. I think it is a very good start, =
and
>>>> think we can get it ready to ship quite quickly.
>>>>=20
>>>> I have the following comments:
>>>>=20
>>>> We need to specify a way to send and save REPORTS that are
>>>> sent/received on the CS to the SRS. If, for example, a message =
sent
>>>> by a party to another is not received completely,
>>>> and a REPORT js generated on the RS, we need to somehow record =
than
>>>> in the CS.
>>>=20
>>> I guess CS and RS need to be swapped in the above line, right?
>> Yeah doh!
>>>=20
>>>> You have a note about reports, but it isn=92t clear if you mean =
reports
>>>> in the CS or the RS. Both have to be recorded, but at least in the
>>>> RS, the SRS has all the info needed.
>>>=20
>>> I just have a placeholder, because I haven't thought much about it =
yet.
>>>=20
>>> I especially hadn't thought about reports on the RS. Note that the =
SRS
>>> won't be sending anything except reports to the SRC, so there is no
>>> reason for the SRC to be sending reports to the SRS about the RS =
msrp
>>> session.
>> Yeah, but it has to send reports it got on the CS somehow
>>=20
>>>=20
>>> Conversely, suppose the SRC gets a report from the SRS that =
something
>>> hasn't made it successfully. What should it do? (I can't think of
>>> anything useful for it do do.) I guess this is analogous to the SRC
>>> getting RTCP reports indicating packet loss of RTP media. We don't
>>> talk about that.
>> No, I think if the SRC gets a report of a problem on the CS it must
>> record that.
>=20
> That is a different case. I was specifically talking about the case =
where the SRC gets a report from the *SRS*. There is nothing useful it =
can do. Obviously the SRS knows about the problem (it sent the report), =
so it can record an indication of the problem without the SRC having to =
tell it.
Right, my bad. The SRS knows, it can record it.
>=20
>> I think if we neglected to record known problems detected in RTCP
>> reports then we need to fix that too at some point =97 if the SRC =
knows
>> about a problem, that has to be recorded.
>>=20
>>>=20
>>> But reports on the CS are significant information that could be
>>> important to record.
>=20
> This is the case you were talking about.
Yeah
>=20
>>> I think they can't be sent as MSRP reports. I
>>> suspect we must find a way to encapsulate them as regular MSRP
>>> messages. But that seems messy. Ideas are welcome.
>> Yeah, I think that=92s right, and I think it=92s messy. Sending them =
in
>> metadata is a possibility.
>=20
> I don't think we can bound the rate that these occur. So I am very =
reluctant to use the metadata mechanism to deal with them.
Understand, but encapsulation in MSRP would use a lot of BW also
>=20
>> Extending reports in some manner is a
>> possibility.
>=20
> Yes, this is possible. But it would be nice to avoid modifying MSRP.
Yeah, but might be lesser of evils
>=20
>>>> I think there is a problem with the text about adding a CPIM =
wrapper
>>>> if there isn=92t one. I think the recording has to know if the
>>>> original message was sent by some entity other than the one in the
>>>> CPIM =46rom (that is, we have to preserve the MSRP From). The SRS =
has
>>>> to know whether the original message had a CPIM header, and its
>>>> contents. If the SRC changes the message (by adding the wrapper) =
I
>>>> think the SRS has to be able to figure that out, and record that =
fact
>>>> in some way.
>>>=20
>>> I hear you, though I'm not yet convinced how important it is for the
>>> SRS to be able to make this distinction.
>> I think the recording is what the SRC got. If you can=92t =
effectively
>> reproduce what the SRC gets, the mechanism is not adequate.
>=20
> Does introducing a CPIM wrapper where there was none (making explict =
what had been implicit) prevent reproducing what the SRC got?
Because the SRS can=92t distinguish between the SRC receiving a wrapped =
message from a case where the SRC did the wrapping on the RS.
>=20
> Consider that we allow the SRC to transcode media before sending it to =
the SRS. And we permit the SRC to transcode media before recording it. =
In both of those cases we can't reproduce *exactly* what the SRC got.
I think this is substantively different but YMMV
>=20
> What is so different here?
>=20
>>> I think the only way to be *certain* that the SRS can distinguish
>>> these is to wrap *every* message, even those that already contain =
CPIM
>>> headers. Then the SRS would know that the outer wrapper was always
>>> from the SRC, and that if there was another cpim wrapper inside then
>>> it was from the CS. But that seems like overkill.
>> Yeah, I=92d prefer not to do that
>>=20
>>>=20
>>> If we only put CPIM wrappers on messages that don't already have =
them,
>>> then we could put something *special* in them. But there would be no
>>> guarantee that the CS didn't use that.
>> There is always a way. We can extend CPIM if we need to.
>=20
> Yes we could. If we feel that we must.
>=20
>>> We could also introduce a new mime type similar to CPIM, but =
specially
>>> for recording. If we constrained the usage of that then we might be
>>> able to claim that it could never appear on the CS. But I would =
prefer
>>> to avoid this.
>> I=92d rather just extend CPIM
>=20
> This is a matter of taste. I could go either way. It would be nice to =
not have to extend CPIM.
Something has to give. Probably a good topic for the meeting
>=20
>>>> When we echo a message from the RS to the CS, we=92re going to lose =
the
>>>> MESSAGE-ID from the RS. That=92s a problem. We have to save that =
info
>>>> in the recording. A hack would be to use the same message ID in =
both
>>>> the CS and the RS, possibly with some prefix.
>=20
> After studying 4975 awhile I think we could do this. It *should* be ok =
to use the old message-ids as-is - they are supposed to be globally =
unique, across sessions. (Of course if we reuse them then they won't be =
globally unique.)
>=20
> If we are hyper, we could allow the SRC to add a prefix. But that =
introduces complications if we are doing redundant SRCs sending to the =
same SRS, because we won't recognize when we get the same message on =
both paths.
Yeah, I understand. If the SRC adds a prefix, it could be different =
from the prefix the redundant SRC uses and the SRS could figure it out.
>=20
>>>> I worry a bit about chunking in the RS differently from chunking in
>>>> the CS. I may be mistaken, but if the chunking is different, will
>>>> that affect the byte-range response in a failure report?
>=20
> The whole point of reporting byte ranges is that they are independent =
of the chunking. I don't think this is an issue.
Okay
>=20
>>> Don't the above issues have analogs for RTP/RTCP?
>> No, i don=92t think so. Message ID is much more of a real id then
>> anything you find in an RTP header. You can derive wall time, which
>> might be similar, but not really.
>=20
> I guess what is different about message id is that its scope =
encompasses multiple MSRP sessions. If the CS participants drop one =
session and start another, and resend messages with the same ids, then I =
guess we do want the SRS to understand that they were updating the same =
message.
Yes, and probably more.
>=20
>>> Do we have any more requirement to solve them here than we did =
there?
>>>=20
>>>> The URIs in the original to/from need to be captured, but they will
>>>> be different in the RS. Need to fix that.
>>>=20
>>> I assume you are talking about the to/from in CPIM, right? Why do =
they
>>> need to be different in the RS?
>> MSRP To/=46rom in the RS is SRS/SRC.
>=20
> OK.
>=20
>> If there wasn=92t any CPIM, we could
>> add it, in which case MSRP To/=46rom in CS becomes CPIM To/=46rom in =
RS.
>=20
> Why? It doesn't have to be if we don't want that. I would expect the =
SRC to insert URIs that it knows from the CS for the participants in =
this MSRP session. These would probably be the SIP URIs from the CS SIP =
session of the sender and receiver of the MSRP session in the CS.
The SRS has to be able to derive what was MSRP To/=46rom in the CS was. =
It=92s recording what the SRC saw.
>=20
>> If
>> there is CPIM already, we need to preserve it, and then we need to =
solve
>> sending CS MSRP To/=46rom in the RS.
>=20
> Why do we need the MSRP To/=46rom at all? Those are just artificial =
things used to identify particular sessions.
I think the recording has to record what the SRC got. I don=92t think =
it=92s good enough to derive a notion of session, create new session IDs =
and then just use them. The recording has to be able to reproduce what =
the SRC saw.
>=20
>>>> Do we need to say something about max-size issues between CS and =
RS?
>>>=20
>>> Probably. Seems like a policy issue in the SRS. If the SRS doesn't
>>> want to record large messages. Maybe we want to specify that the SRC
>>> MUST honor the SRS's max-size, bypassing recording of messages that
>>> are too big. (Or perhaps inserting special small messages as
>>> placeholders for the bypassed messages.)
>> Yeah, something. Basically, to avoid problems, CS max has to be at
>> least as big as RS max. I think that=92s just a MUST as a =
by-the-way.
>=20
> I don't think so. We give the SRS a lot of lattitude about what it =
records. If it wants to bound its resources by refusing to record small =
messages, then that is its business.
>=20
> We can't expect the CS to change its behavior to suit the RS. And IIUC =
max-size is not negotiated, it is declared by the receiver. So there is =
no way to communicate the max-size from the CS to the RS.
>=20
> Also, max-size is only a hint - the sender need not honor it.
>=20
> We *could* specify that the SRC SHOULD NOT forward messages on the RS =
that exceed the SRS's max-size. I don't think there is much else we can =
or should do.
Looks like we have to just have a discussion on the issue in the doc. =
The limitation is that the SRC doesn=92t know the SRS max until after =
the CS is established, so it can=92t do something like reflect the RS =
max into the CS. As you point out, that=92s not really desirable in the =
first place. So, probably just point out the issues and say it=92s a =
system design issue to make sure the RS can handle what could occur on =
the CS or recording will be impaired. I=92m okay with SHOULD NOT on the =
RS.
=20
>=20
>>>> You can=92t possibly not change -metadata. As an example. you have =
to
>>>> allow an msrp AoR for a participant
>>>=20
>>> Hmm. I guess so. I was thinking that we were lenient in the AoR =
type,
>>> but I guess not.
>=20
> Based on my own comments above, I don't know why we need to have an =
msrp AOR for a participant. I think we would identify participants in an =
MSRP media session by sip URI.
Again, I think we have to record what is in the CS. If the CS =
identifies a participant by an MSRP AoR, we need to record that. We can =
use whatever we want in the RS itself, so long as we can reproduce what =
was in the original CS.
>=20
>>> Since the metadata isn't done yet, maybe we can change it before it =
is
>>> done, to allow this. (Allow any URI.)
>> Depends on how we solve some of these other issues.
>> That one leaped out at me, have to look harder to see if there are
>> others. Interaction of the term =93Participant=94 for example.
>>=20
>>>=20
>>>> Yes, I think we have to extend Participant to handle nicks.
>>>=20
>>> A participant can already have multiple AoR/Name pairs. So we could
>>> add the nickname as one of those.
>> Would have to be labeled in some way
>=20
> I went back to review the chat stuff that defines Nickname. (It still =
isn't an RFC!) I remembered wrong - the nickname isn't represented as a =
URI. Ideally we would manage it in-band in the MSRP. But the way =
nicknames are managed doesn't work very well for us. An msrp session is =
bound to at most one nickname at any point in time.
>=20
> We could work with that, sending NICKNAME requests on the RS msrp =
session as needed to set the nickname to match that of the message we =
want to send. But that would be unpleasant.
>=20
> An alternative would be to define the use of Use-Nickname with a SEND =
message. It currently isn't defined, but draft-ietf-simple-chat-18 =
leaves it open to be defined in the future.
>=20
> We would want to specify that the SRS will be especially lenient =
(promiscuous) in approving the use of nicknames.
Hmmm, lots to think about. Probably want to consult the chat authors.
>=20
>>> (We really did try to plan ahead with the metadata.)
>>>=20
>>>> Probably also to handle the SIP session URI vs the MSRP URIs
>>>=20
>>> Note that the metadata associates participants with both the CS and
>>> individual media streams. So the SIP session URIs are already =
covered
>>> there.
>> I=92m missing something, but it=92s probably lack of clue on how =
metadata
>> works.
>> And, I spotted another metadata change problem:
>>=20
>>=20
>>=20
>> 6.5.1
>> =
.
>> Attributes
>>=20
>>=20
>>=20
>> Participant has a single defined attribute:
>>=20
>> o AoR / Name pair list - This attribute is a list of Name/AoR
>> tuples. An AoR MAY be a SIP/SIPS/TEL URI. Name represents
>> Participant name(SIP display name) or dialed number (DN) (when
>> known). Multiple tuples are allowed for cases where a =
participant
>> has more than one AoR. (For example a P-Asserted-identity =
header
>> [RFC3325 ] can have both =
SIP and TEL URIs.)
>>=20
>>=20
>> Have to add msrp/msrps to the list. Does the MSRP To/=46rom HAVE to =
be an
>> msrp/msrps scheme, or can it be a sip AoR? If the latter, we could =
have
>> a corner case where the SIP AoR and the MSRP AoR were both SIP but
>> different.
>=20
> The MSRP From/To URIs must be MSRP URIs.
>=20
> But, I still don't see why we need to care about preserving those in =
the recording.
>=20
> I must say that this is the kind of discussion I have been hoping to =
have - to nail down the nitty-gritty details.
Happy to be of service as more than a co-chair :)
>=20
> Thanks,
> Paul
>=20
>>> Thanks,
>>> Paul
>>>=20
>>>> Brian
>>>>=20
>>>> On Jun 26, 2014, at 12:32 PM, Paul Kyzivat >>> > wrote:
>>>>=20
>>>>> Trying one more time. Please!!!
>>>>>=20
>>>>> On 6/3/14 2:46 PM, Paul Kyzivat wrote:
>>>>>> Can I get some people in the wg to review and comment on this =
version?
>>>>>>=20
>>>>>> Thanks,
>>>>>> Paul
>>>>>>=20
>>>>>> On 5/28/14 6:10 PM, Paul Kyzivat wrote:
>>>>>>> I've submitted a revised version of the msrp recording draft.
>>>>>>> This one is substantially fleshed out. It certainly needs more
>>>>>>> tweaking,
>>>>>>> but is complete enough that you should be able to make =
meaningful
>>>>>>> comments on the approach.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> Paul
>>>>>>>=20
>>>>>>>=20
>>>>>>> -------- Original Message --------
>>>>>>> Subject: New Version Notification for
>>>>>>> draft-yan-siprec-msrp-recording-01.txt
>>>>>>> Date: Wed, 28 May 2014 15:03:24 -0700
>>>>>>> From: internet-drafts@ietf.org
>>>>>>> To: Michael Yan >>>>>> >, "Paul H. Kyzivat"
>>>>>>> >,
>>>>>>> "Michael Yan" >>>>>> >,
>>>>>>> "Paul Kyzivat" >>>>>> >
>>>>>>>=20
>>>>>>>=20
>>>>>>> A new version of I-D, draft-yan-siprec-msrp-recording-01.txt
>>>>>>> has been successfully submitted by Paul H. Kyzivat and posted to =
the
>>>>>>> IETF repository.
>>>>>>>=20
>>>>>>> Name: draft-yan-siprec-msrp-recording
>>>>>>> Revision: 01
>>>>>>> Title: Overview for MSRP Recording based on SIPREC
>>>>>>> Document date: 2014-05-28
>>>>>>> Group: Individual Submission
>>>>>>> Pages: 9
>>>>>>> URL:
>>>>>>> =
http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-01.txt=
>>>>>>>=20
>>>>>>> Status:
>>>>>>> =
https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>>>>>> Htmlized:
>>>>>>> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-01
>>>>>>> Diff:
>>>>>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-yan-siprec-msrp-recording-01
>>>>>>>=20
>>>>>>> Abstract:
>>>>>>> SIPREC is capable of recording interactive text media that is
>>>>>>> transmitted via RTP. However that format is not commonly used =
for
>>>>>>> message or chat scenarios. There is also a need for recording =
text
>>>>>>> media carried via MSRP. One case of note is exchange of text
>>>>>>> between
>>>>>>> hearing-impaired users and emergence service bureaus. Also,
>>>>>>> recording support is needed for MSRP used in chat conferences =
and
>>>>>>> multimedia conferences.
>>>>>>>=20
>>>>>>> This document describes how to achieve MSRP channel recording
>>>>>>> within
>>>>>>> the mechanism of SIP Recording (SIPREC).
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> Please note that it may take a couple of minutes from the time =
of
>>>>>>> submission
>>>>>>> until the htmlized version and diff are available at =
tools.ietf.org.
>>>>>>>=20
>>>>>>> The IETF Secretariat
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> siprec mailing list
>>>>>>> siprec@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> siprec mailing list
>>>>>> siprec@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> siprec mailing list
>>>>> siprec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>=20
>>>>=20
>>>=20
>>=20
>=20
From nobody Thu Jul 10 15:00:24 2014
Return-Path:
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 4E4421B27CF for ; Thu, 10 Jul 2014 15:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 WS-Q8geudB-L for ; Thu, 10 Jul 2014 15:00:22 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01C1B27B8 for ; Thu, 10 Jul 2014 15:00:22 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id QlJ11o0030mv7h05Dm0Mxd; Thu, 10 Jul 2014 22:00:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id Qm0M1o00T3ZTu2S3Xm0MMQ; Thu, 10 Jul 2014 22:00:21 +0000
Message-ID: <53BF0CF5.8090503@alum.mit.edu>
Date: Thu, 10 Jul 2014 18:00:21 -0400
From: Paul Kyzivat
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian Rosen
References: <20140528220324.16934.76369.idtracker@ietfa.amsl.com> <53865EEC.7000605@alum.mit.edu> <538E1806.9040908@alum.mit.edu> <53AC4B1A.9050707@alum.mit.edu> <53B58B0B.1060004@alum.mit.edu> <616B2EC5-2715-4756-B58D-9802859AB158@brianrosen.net> <53BDC0AF.1060906@alum.mit.edu> <0D3E761E-94FE-4C10-98BE-A87ACAE554CA@brianrosen.net>
In-Reply-To: <0D3E761E-94FE-4C10-98BE-A87ACAE554CA@brianrosen.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405029621; bh=VLgg6pwR6Iw0ol3UGKVJEk+LC/FJCWO/K0ZwxXNRSQA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Jx4O1fyySw8qCu7kgpfh6eMvRJN6INYAOGzkcZmlzzIWnjSYZczgHRu6InXWCZxWt Esh0vLweUwiY1xTdSmA1fOeFQl0SP7vZpVvmVPXedDSIs1D6/7r51tKRdedzLst7Kz 1kp7YGiBwT4tdSrbhCARgSCFjrJU4VH1nw/c978aBZ7PK5PPYtkERxokOu/vj3h6WN DVHSBC+3ya8acQzWRkesxt7DZTY+W9OznaGz1RQ9VP0viDJDeWcz2okS1BYCl0XVaY gx+dxwMhmPjlXkSHDyPnwrdzK9/PfV638vQ5008DKrWVnO0DnLljcZ5YDs70RLr+8O R0O/W+ycj2odQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/3hgGCFk1OH6YfWvU26lPMI_0RFU
Cc: siprec@ietf.org
Subject: Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-01.txt
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 10 Jul 2014 22:00:23 -0000
On 7/9/14 6:48 PM, Brian Rosen wrote:
> Hopefully, we aren’t getting too deep in levels
I'll try to thin it out here.
>>>> But reports on the CS are significant information that could be
>>>> important to record.
>>>> I think they can't be sent as MSRP reports. I
>>>> suspect we must find a way to encapsulate them as regular MSRP
>>>> messages. But that seems messy. Ideas are welcome.
>>> Yeah, I think that’s right, and I think it’s messy. Sending them in
>>> metadata is a possibility.
>>
>> I don't think we can bound the rate that these occur. So I am very reluctant to use the metadata mechanism to deal with them.
> Understand, but encapsulation in MSRP would use a lot of BW also
Really?
I guess for small messages, if getting success reports, the traffic
could double, or more. Certainly putting it into metadata wouldn't be
better in that case.
In any case, this is probably much less bandwidth that audio, much less
video.
One question is whether it is necessary to record success reports.
Leaving them out would help.
>>> Extending reports in some manner is a
>>> possibility.
>>
>> Yes, this is possible. But it would be nice to avoid modifying MSRP.
> Yeah, but might be lesser of evils
ISTM that we have a variety of extra stuff that we might need to send.
So a consistent way to do so might be appropriate.
I think that one or more special content types would serve the purpose.
And we wouldn't have to send those in CPIM wrappers. That would make it
clear that they are "special".
In addition to Reports, there is a need to send indications when an MSRP
send failed. And maybe to send a place holder for messages that exceed
the max-size declared by the SRS.
>>>>> I think there is a problem with the text about adding a CPIM wrapper
>>>>> if there isn’t one. I think the recording has to know if the
>>>>> original message was sent by some entity other than the one in the
>>>>> CPIM From (that is, we have to preserve the MSRP From). The SRS has
>>>>> to know whether the original message had a CPIM header, and its
>>>>> contents. If the SRC changes the message (by adding the wrapper) I
>>>>> think the SRS has to be able to figure that out, and record that fact
>>>>> in some way.
>>>>
>>>> I hear you, though I'm not yet convinced how important it is for the
>>>> SRS to be able to make this distinction.
>>> I think the recording is what the SRC got. If you can’t effectively
>>> reproduce what the SRC gets, the mechanism is not adequate.
>>
>> Does introducing a CPIM wrapper where there was none (making explict what had been implicit) prevent reproducing what the SRC got?
> Because the SRS can’t distinguish between the SRC receiving a wrapped message from a case where the SRC did the wrapping on the RS.
And AFAICT it doesn't matter.
I will bring this up in Toronto.
>>>> If we only put CPIM wrappers on messages that don't already have them,
>>>> then we could put something *special* in them. But there would be no
>>>> guarantee that the CS didn't use that.
>>> There is always a way. We can extend CPIM if we need to.
>>
>> Yes we could. If we feel that we must.
>>
>>>> We could also introduce a new mime type similar to CPIM, but specially
>>>> for recording. If we constrained the usage of that then we might be
>>>> able to claim that it could never appear on the CS. But I would prefer
>>>> to avoid this.
>>> I’d rather just extend CPIM
>>
>> This is a matter of taste. I could go either way. It would be nice to not have to extend CPIM.
> Something has to give. Probably a good topic for the meeting
I looked at CPIM again. It has its own extensibility mechanism built in,
that we could use. But it has a price. You have to declare the extension
(with a URI) in every message where it is used. That is in addition to
the extension header itself. So it will be expensive for passing what is
fundamentally one bit of information.
I will bring this up in Toronto.
> The SRS has to be able to derive what was MSRP To/From in the CS was. It’s recording what the SRC saw.
...
> I think the recording has to record what the SRC got. I don’t think it’s good enough to derive a notion of session, create new session IDs and then just use them. The recording has to be able to reproduce what the SRC saw.
I don't get it. The MSRP To/From are just artifacts. They aren't
interesting in a recording.
If I wanted to "reenact" the session, I would expect that the new one
would have different MSRP URIs. And that would not affect the fidelity
of the reenactment.
I'll bring it up in Toronto - *what* we aim to capture in the recording,
and what is not needed.
>> I went back to review the chat stuff that defines Nickname. (It still isn't an RFC!) I remembered wrong - the nickname isn't represented as a URI. Ideally we would manage it in-band in the MSRP. But the way nicknames are managed doesn't work very well for us. An msrp session is bound to at most one nickname at any point in time.
>>
>> We could work with that, sending NICKNAME requests on the RS msrp session as needed to set the nickname to match that of the message we want to send. But that would be unpleasant.
>>
>> An alternative would be to define the use of Use-Nickname with a SEND message. It currently isn't defined, but draft-ietf-simple-chat-18 leaves it open to be defined in the future.
>>
>> We would want to specify that the SRS will be especially lenient (promiscuous) in approving the use of nicknames.
> Hmmm, lots to think about. Probably want to consult the chat authors.
I sent a query to the authors, and to the simple list (if anybody still
on it), asking for them to please help with this. Will see if we get any
response.
Thanks,
Paul
From nobody Mon Jul 14 09:27:41 2014
Return-Path:
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 767AF1A0AF5 for ; Mon, 14 Jul 2014 09:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 FOZuNlkRnVRD for ; Mon, 14 Jul 2014 09:27:26 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3551A0AD3 for ; Mon, 14 Jul 2014 09:27:26 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 2ED041EB8493 for ; Mon, 14 Jul 2014 18:27:25 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Mon, 14 Jul 2014 18:27:24 +0200
From: "Hutton, Andrew"
To: "siprec@ietf.org"
Thread-Topic: IETF90 SIPREC Meeting Agenda.
Thread-Index: Ac+fgHzEpDz9RcXUQP+kcIiIbzaaVg==
Date: Mon, 14 Jul 2014 16:27:24 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E23050@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/siprec/O5Bjj2-lpAhrji6QdfBhPLvr1dg
Subject: [siprec] IETF90 SIPREC Meeting Agenda.
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Recording Working Group Discussion List
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 14 Jul 2014 16:27:33 -0000
Hi All,
Today is the deadline for updating the agenda for IETF90 meetings.
So far regarding SIPREC we only have one request to present and that is on =
MSRP Recording (http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-=
01)
Our meeting is set for Friday, July 25th 2014, 11:50 - 13:20 GMT (Salon B)
The full agenda can be found at: https://datatracker.ietf.org/meeting/90/ag=
enda/siprec/
Regards
Andy
From nobody Sun Jul 20 10:37:39 2014
Return-Path:
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 ; 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 ; 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